From nobody Tue Aug 9 10:18:45 2016 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 5BDD612D0E7 for ; Tue, 9 Aug 2016 10:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.467 X-Spam-Level: X-Spam-Status: No, score=-5.467 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=-1.247, 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 5fC8d_MSZWzq for ; Tue, 9 Aug 2016 10:18:41 -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 48D4612B03C for ; Tue, 9 Aug 2016 10:18:41 -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 u79HIei8006152 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 9 Aug 2016 17:18:40 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u79HIeGP026808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 9 Aug 2016 17:18:40 GMT Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u79HIdFk019521 for ; Tue, 9 Aug 2016 17:18:39 GMT Received: from [192.168.1.15] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 09 Aug 2016 10:18:39 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_878C1B1F-3EEF-46EE-9D5F-B654F649A0C6" Message-Id: <14E2EF51-7123-4E91-87DD-56AEA08202C1@oracle.com> Date: Tue, 9 Aug 2016 10:18:38 -0700 To: id-event@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Subject: [Id-event] Summarizing recent discussions on ID-Event token draft X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 09 Aug 2016 17:18:43 -0000 --Apple-Mail=_878C1B1F-3EEF-46EE-9D5F-B654F649A0C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I thought I would update the list on some discussions that have been = happening over in the OpenID Connect and RISC working groups conference = calls. These discussions have been about the core spec and the role of = =E2=80=9Ctop-level=E2=80=9D attributes vs. event =E2=80=9Cextension=E2=80=9D= attributes.=20 See: https://tools.ietf.org/html/draft-hunt-idevent-token-01 In particular should =E2=80=9Csub=E2=80=9D be used in the top level to = =E2=80=9Cpoint=E2=80=9D to the subject (in the broader english sense) of = the event, or should it be constrained to the SAML/ID Token definition = which is the authenticated user. =20 Taken in the narrower definition, it is important to observe that in an = ID Token, =E2=80=9Csub=E2=80=9D and =E2=80=9Ciss=E2=80=9D go together. = The issuer provides the context for the authenticated subject = identifier. The problem with events, is that it might not be the AS (or = OP) which is issuing the event. =20 To summarize a fair amount of discussion, the feeling seems to be the = following: * The Event Token top level attributes should be fairly limited and not = include the sub attribute. =20 * For events that are about a user, the relevant event specification = may include a =E2=80=9Csub=E2=80=9D attribute within the event=E2=80=99s = sub-object and not in the top-level. Further that sub-object can also = include the issuer of the user. =20 * The top-level =E2=80=9Ciss=E2=80=9D shall mean the issuer of the event = where the state change occurred. * =E2=80=9Csub=E2=80=9D should not be present in the top level = structure. Also, =E2=80=9Cevents=E2=80=9D must also be present. Here would be a new example logout: { <=E2=80=94 top level is about the event itself -> "iss": "https://server.example.com", "aud": "s6BhdRkqt3", "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", "iat": 1458668180, "exp": 1458668580, "events": [ "https://specs.openid.net/logout " ], "https://specs.openid.net/logout ": { <- This level is defined entirely by the event URI-> "iss": "https://oidc.example.com", =E2=80=9Cjti": "08a5019c-17e1-4977-8f42-65a12843ea02=E2=80=9D, "sub": "248289761001=E2=80=9D, =E2=80=9Cexp=E2=80=9D: } } In the above example note that the =E2=80=9Cevent=E2=80=9D object can = have its own iss and subject (sub or jti) that have meaning within the = context of an OpenID OP provider. The issuer of the event can be = different (the top-level) and represents the entity that signs the event = (if it is signed). The top-level attributes identify an individual event and are used to = validate the event (signing etc). Where as the nested object contains = all of the data about the event and is defined by the profiling = specification (e.g. a possible OpenID Logout Event spec). In this case, = in OpenID, logging out usually translates into revoking an ID Token. = Thus the =E2=80=9Cjti=E2=80=9D for the ID token (08a5019c...843ea02) is = included in the Logout object. Side note. Regarding =E2=80=9Clogout=E2=80=9D, it might be useful to = include the expiry of the ID Token in case the subscriber has not yet = received an ID Token. This would let the subscriber know how long it = needs to keep the revocation information for. IOW=E2=80=A6after the the = ID Token is expired, the subscriber would no longer need to track the = revocation state. It is also good to observe that the =E2=80=9Caud=E2=80=9D at the top = level describes the subscriber of the event. This may also be different = then the original audience of the ID Token. So to conclude. By making top-level attributes strictly about the events = own validation, and nested objects about the event, we avoid collisions = in definitions such as the issuer of the event, vs. the original issuer = of a security assertion. I hope I=E2=80=99ve gotten everyone=E2=80=99s feedback correct here. = Lets continue to discuss. I will revise the draft to follow the groups = thinking here. Phil @independentid www.independentid.com = phil.hunt@oracle.com = --Apple-Mail=_878C1B1F-3EEF-46EE-9D5F-B654F649A0C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I thought I would update the list on some discussions that = have been happening over in the OpenID Connect and RISC working groups = conference calls.

These discussions have been about the core spec and the role = of =E2=80=9Ctop-level=E2=80=9D attributes vs. event =E2=80=9Cextension=E2=80= =9D attributes. 
See: https://tools.ietf.org/html/draft-hunt-idevent-token-01

In particular = should =E2=80=9Csub=E2=80=9D be used in the top level to =E2=80=9Cpoint=E2= =80=9D to the subject (in the broader english sense) of the event, or = should it be constrained to the SAML/ID Token definition which is the = authenticated user.  

Taken in the narrower definition, it is important to observe = that in an ID Token, =E2=80=9Csub=E2=80=9D and =E2=80=9Ciss=E2=80=9D go = together.  The issuer provides the context for the authenticated = subject identifier. The problem with events, is that it might not be the = AS (or OP) which is issuing the event.  

To summarize a fair amount of = discussion, the feeling seems to be the following:

*  The Event Token = top level attributes should be fairly limited and not include the sub = attribute.  
*  For events that are about = a user, the relevant event specification may include a =E2=80=9Csub=E2=80=9D= attribute within the event=E2=80=99s sub-object and not in the = top-level. Further that sub-object can also include the issuer of the = user.  
* The top-level =E2=80=9Ciss=E2=80=9D = shall mean the issuer of the event where the state change = occurred.
*  =E2=80=9Csub=E2=80=9D should not = be present in the top level structure.  Also, =E2=80=9Cevents=E2=80=9D= must also be present.

Here would be a new example logout:
{
  <=E2=80=94 top =
level is about the event itself ->
  "iss": "https://server.example.com",
  "aud": "s6BhdRkqt3",
  "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
  "iat": 1458668180,
  "exp": 1458668580,
  "events": [
    "https://specs.openid.net/logout"
  ],
  "https://specs.openid.net/logout": {
    <- This level is defined entirely by the event =
URI->

    =
"iss": "https://oidc.example.com",

    =E2=80=9Cjti": =
"08a5019c-17e1-4977-8f42-65a12843ea02=E2=80=9D,
    "sub": =
"248289761001=E2=80=9D,
 =
   =E2=80=9Cexp=E2=80=9D: <ID token expiry>
  }
}

In = the above example note that the =E2=80=9Cevent=E2=80=9D object can have = its own iss and subject (sub or jti) that have meaning within the = context of an OpenID OP provider.  The issuer of the event can be = different (the top-level) and represents the entity that signs the event = (if it is signed).

The top-level attributes identify an individual event and are = used to validate the event (signing etc).  Where as the nested = object contains all of the data about the event and is defined by the = profiling specification (e.g. a possible OpenID Logout Event spec). =  In this case, in OpenID, logging out usually translates into = revoking an ID Token. Thus the =E2=80=9Cjti=E2=80=9D for the ID token = (08a5019c...843ea02) is included in the Logout object.

Side note. =  Regarding =E2=80=9Clogout=E2=80=9D, it might be useful to include = the expiry of the ID Token in case the subscriber has not yet received = an ID Token. This would let the subscriber know how long it needs to = keep the revocation information for.  IOW=E2=80=A6after the the ID = Token is expired, the subscriber would no longer need to track the = revocation state.

It is also good to observe that the =E2=80=9Caud=E2=80=9D at = the top level describes the subscriber of the event.  This may also = be different then the original audience of the ID Token.

So to conclude. By = making top-level attributes strictly about the events own validation, = and nested objects about the event, we avoid collisions in definitions = such as the issuer of the event, vs. the original issuer of a security = assertion.

I = hope I=E2=80=99ve gotten everyone=E2=80=99s feedback correct here. Lets = continue to discuss. I will revise the draft to follow the groups = thinking here.




= --Apple-Mail=_878C1B1F-3EEF-46EE-9D5F-B654F649A0C6-- From nobody Tue Aug 9 11:54:48 2016 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 4398712D0E5 for ; Tue, 9 Aug 2016 11:54:45 -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 ls7lZy5C2dJN for ; Tue, 9 Aug 2016 11:54:42 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0105.outbound.protection.outlook.com [104.47.38.105]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CD8B12B013 for ; Tue, 9 Aug 2016 11:54: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=ATJgQv2OKyGS/jD3N3uFfywOtrzNrFwgyfNrXfgkekI=; b=Ezf1/ogLc4ZfdiRH5jduDQZSpKYCZXqggzWtdw1jrCHUNOwTieUMfgx9atAbeXPhiAtMNuIa1iEhM8ef/1TCdq5XVHFG2/5ehzOT/7CUPRVu7HdjkTZ24cHSLcf7iOGGm/hQKkJnJEYGSX11bwFG6jCuU/9zFS+Y0RaYwJnh+RM= Received: from SN1PR0301MB1645.namprd03.prod.outlook.com (10.162.130.139) by SN1PR0301MB1645.namprd03.prod.outlook.com (10.162.130.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Tue, 9 Aug 2016 18:54:39 +0000 Received: from SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) by SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) with mapi id 15.01.0549.025; Tue, 9 Aug 2016 18:54:39 +0000 From: Mike Jones To: Phil Hunt , "id-event@ietf.org" Thread-Topic: [Id-event] Summarizing recent discussions on ID-Event token draft Thread-Index: AQHR8mIWLvqeOEkcuEuQk5SeT4z/pKBA9pTw Date: Tue, 9 Aug 2016 18:54:39 +0000 Message-ID: References: <14E2EF51-7123-4E91-87DD-56AEA08202C1@oracle.com> In-Reply-To: <14E2EF51-7123-4E91-87DD-56AEA08202C1@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [206.47.171.251] x-ms-office365-filtering-correlation-id: 4f16924c-74d0-487c-f2ff-08d3c0869dbd x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1645; 6:LuMzYZeqnIwiXpU6edCtT79EdUEyuDrUMUFIqd31pqjPTBusbkSdMcADqLXjobqWta91nXb2t6z97DkrazhIopxXq5WpBYHZ+Te2lbzsonC1CurQTgjJSvq1gfs4npBM1S1gOWhzJNPJQTDGKssxUJqjLAS9/x5FhsEcAc+gs6m+LQZqv/sLBg9GcFD8mCteYtn3WYzT/KIFT/lwfbniQ+HlluDUC1VA1gspeDpZKSvAfdDd1qUVxxwzDVpFjF0sb52/LXbpB9TbhzLZgZgD8W/xcs6v0rfWdsEz2Qt8VsNshcXFCR8yXlgxp9VpZq2SxRwBV+XxPpi3qhKGSxlKKA==; 5:XOHx1aiFjM1VueTZ+qH1bVmYSl34SrqxXYlNUjxyTyS1Jaj2h80FQ0ZuMqBXoLG4nLXK8o4qt7gF2EGKvgm5nahM2L7ZfPU9yWbxTU3v9W4axEu76qx75HGu+kep9gStJQF3pBxoLvrlqp13ZtZ0zA==; 24:Etvr/SsFOwkVUaB83bTy0f8W1ofPl9/74DBxqhaFpZOsUciMaKynxwB5rSfJ4Nm5EsbUa7qNqwnlPMQT6pXMj8Nm3DqzdoSTKMAfHZpR7W0=; 7:T9/cM3C2N76GXE2KDBHxdVZ9rSujyUI3bo321l5V5uNuCDq9EiiGt4tbVAPDj/QczUs+iQAZcKJ4UUbUTZ0SCu6jZ1tv7V/ozmvyAzwLaBR9dI65H1RMLzXNzHW6+j1e5QQgqN8wANx3g+RJQI8UeCMt9FgfmwyIgzh4fcpQaOXcDRzL7dh7EbZqNw7aJXLdE1CCClzp2LU7S0XrhqTbcfdzGBWWTSZXS6GFO2MeVh+NlmrEx2KaxkwfAVd9UeSP x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1645; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(278428928389397)(192374486261705)(21748063052155)(21532816269658)(146099531331640); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:SN1PR0301MB1645; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1645; x-forefront-prvs: 0029F17A3F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(377454003)(189002)(76576001)(19300405004)(86612001)(97736004)(5001770100001)(19617315012)(16601075003)(16236675004)(106356001)(106116001)(101416001)(19625215002)(76176999)(54356999)(50986999)(19609705001)(19580405001)(19580395003)(33656002)(2906002)(1680700002)(586003)(2950100001)(2900100001)(15975445007)(92566002)(77096005)(102836003)(790700001)(6116002)(3846002)(74316002)(81156014)(81166006)(8936002)(9686002)(7696003)(7736002)(7906003)(7846002)(8676002)(3660700001)(3280700002)(2501003)(11100500001)(66066001)(68736007)(10090500001)(10290500002)(10400500002)(5005710100001)(8990500004)(189998001)(107886002)(99286002)(105586002)(5002640100001)(122556002)(575784001)(86362001)(87936001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0301MB1645; H:SN1PR0301MB1645.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB1645C699D5475DA865258110F51C0SN1PR0301MB1645_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Aug 2016 18:54:39.2082 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1645 Archived-At: Subject: Re: [Id-event] Summarizing recent discussions on ID-Event token draft X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 09 Aug 2016 18:54:45 -0000 --_000_SN1PR0301MB1645C699D5475DA865258110F51C0SN1PR0301MB1645_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB3cml0aW5nIHRoaXMsIFBoaWwuICBVbmZvcnR1bmF0ZWx5LCB0aGUgc3VtbWFy eSBiZWxvdyBkb2VzIG5vdCBpbmNsdWRlIG15IGZlZWRiYWNrLCB3aGljaCBhdCB0aGUgZXNzZW5j ZSwgaXMgdG8ga2VlcCB0aGUgSUQgRXZlbnRzIGRhdGEgc3RydWN0dXJlIGFzIHNpbXBsZSBhbmQg Z2VuZXJhbC1wdXJwb3NlIGFzIHBvc3NpYmxlLiAgKEkgc3Ryb25nbHkgYmVsaWV2ZSB0aGF0IEpX VCBpcyB0aGUgc3VjY2VzcyBpdCBpcyBiZWNhdXNlIHdlIG1hZGUgSldUIGFzIHNpbXBsZSBhbmQg Z2VuZXJhbC1wdXJwb3NlIGFzIHBvc3NpYmxlLCBhbmQgd2Ugc2hvdWxkIGZvbGxvdyB0aGlzIHN1 Y2Nlc3NmdWwgZXhhbXBsZSBhbmQgZG8gdGhlIHNhbWUgaGVyZS4pDQoNCkkgYmVsaWV2ZSB0aGF0 IHRoZSBJRCBFdmVudHMgc3BlYyBuZWVkcyB0byBpbmNsdWRlIHRoZXNlIHRoaW5ncywgYW5kIHRo ZXNlIHRoaW5ncyBvbmx5Og0KDQrCtyAgICAgICBEZWZpbmUgb2YgdGhlIOKAnGV2ZW50c+KAnSBj bGFpbQ0KDQrCtyAgICAgICBEZWZpbmUgdGhhdCBhbiBldmVudCBuYW1lIGNhbiBiZSB1c2VkIGFz IGEgdG9wLWxldmVsIGNsYWltDQoNCsK3ICAgICAgIFJlcXVpcmUgdGhhdCDigJxpc3PigJ0gYmUg aW5jbHVkZWQgYW5kIHRoYXQgdGhlIEpXVCBiZSBzaWduZWQgYnkgdGhlIGlzc3Vlcg0KDQrCtyAg ICAgICBJbmNsdWRlIGEgc3RhdGVtZW50IGFsb25nIHRoZSBsaW5lcyBvZiDigJxUaGUgY2xhaW1z IHRvIGJlIGluY2x1ZGVkIHdpdGggYW55IHBhcnRpY3VsYXIgZXZlbnQgYXJlIHRvIGJlIGRlZmlu ZWQgYnkgdGhlIGV2ZW504oCdDQoNCkFuZCBJ4oCZZCBzdG9wIHRoZXJlLg0KDQpJdCBzaG91bGQg YmUgZW50aXJlbHkgdXAgdG8gYXBwbGljYXRpb25zIHRvIHNheSB3aGF0IGNsYWltcyBhcmUgaW5j bHVkZWQgd2l0aCBldmVudHMgdGhleSBkZWZpbmUgYW5kIHdoYXQgdGhlaXIgZm9ybWF0IGFuZCBt ZWFuaW5ncyBhcmUuICBUaGVuIHRoZSBJRCBFdmVudHMgc3BlYyB3aWxsIGJlIGFzIGdlbmVyYWwt cHVycG9zZSBhcyBwb3NzaWJsZSwgd2l0aCBpdCBiZWluZyBuYXR1cmFsIGZvciBpdCB0byBiZSB1 c2VkIGluIGVzc2VudGlhbGx5IGFsbCBKU09OIEV2ZW50IGNvbnRleHRzLg0KDQpBcyBzb29uIGFz IHdlIHN0YXJ0IHB1dHRpbmcgcmVzdHJpY3Rpb25zIG9uIHRoZSB1c2Ugb2YgcGFydGljdWxhciBj bGFpbXMgYnkgZXZlbnRzLCB3ZeKAmXJlIG1ha2luZyB0aGUgSUQgRXZlbnRzIHNwZWMgbGVzcyBn ZW5lcmFsLXB1cnBvc2UgYW5kIGxlc3MgbmF0dXJhbCB0byB1c2UuICBJbiBwYXJ0aWN1bGFyLCB0 aGUgb25seSB0aGluZyB0aGF0IHRoZSBzcGVjIHNob3VsZCBzYXkgYWJvdXQgdGhlIOKAnHN1YuKA nSBjbGFpbSBpcyB0aGF0IOKAnExpa2UgYWxsIG90aGVyIGNsYWltcyBvdGhlciB0aGFuIOKAmGV2 ZW50c+KAmSBhbmQg4oCYaXNz4oCZLCB3aGV0aGVyIHRoZSDigJhzdWLigJkgY2xhaW0gaXMgdG8g YmUgaW5jbHVkZWQgd2l0aCBhbiBldmVudCBpcyBlbnRpcmVseSBldmVudC1zcGVjaWZpYy4gIFRo ZSBjbGFpbXMgdG8gYmUgaW5jbHVkZWQgd2l0aCBhbnkgcGFydGljdWxhciBldmVudCBhcmUgZXhw bGljaXRseSBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIHNwZWNpZmljYXRpb24u4oCdDQoNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBN aWtlDQoNCkZyb206IElkLWV2ZW50IFttYWlsdG86aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIFBoaWwgSHVudA0KU2VudDogVHVlc2RheSwgQXVndXN0IDksIDIwMTYgMTA6 MTkgQU0NClRvOiBpZC1ldmVudEBpZXRmLm9yZw0KU3ViamVjdDogW0lkLWV2ZW50XSBTdW1tYXJp emluZyByZWNlbnQgZGlzY3Vzc2lvbnMgb24gSUQtRXZlbnQgdG9rZW4gZHJhZnQNCg0KSSB0aG91 Z2h0IEkgd291bGQgdXBkYXRlIHRoZSBsaXN0IG9uIHNvbWUgZGlzY3Vzc2lvbnMgdGhhdCBoYXZl IGJlZW4gaGFwcGVuaW5nIG92ZXIgaW4gdGhlIE9wZW5JRCBDb25uZWN0IGFuZCBSSVNDIHdvcmtp bmcgZ3JvdXBzIGNvbmZlcmVuY2UgY2FsbHMuDQoNClRoZXNlIGRpc2N1c3Npb25zIGhhdmUgYmVl biBhYm91dCB0aGUgY29yZSBzcGVjIGFuZCB0aGUgcm9sZSBvZiDigJx0b3AtbGV2ZWzigJ0gYXR0 cmlidXRlcyB2cy4gZXZlbnQg4oCcZXh0ZW5zaW9u4oCdIGF0dHJpYnV0ZXMuDQpTZWU6IGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1odW50LWlkZXZlbnQtdG9rZW4tMDENCg0KSW4g cGFydGljdWxhciBzaG91bGQg4oCcc3Vi4oCdIGJlIHVzZWQgaW4gdGhlIHRvcCBsZXZlbCB0byDi gJxwb2ludOKAnSB0byB0aGUgc3ViamVjdCAoaW4gdGhlIGJyb2FkZXIgZW5nbGlzaCBzZW5zZSkg b2YgdGhlIGV2ZW50LCBvciBzaG91bGQgaXQgYmUgY29uc3RyYWluZWQgdG8gdGhlIFNBTUwvSUQg VG9rZW4gZGVmaW5pdGlvbiB3aGljaCBpcyB0aGUgYXV0aGVudGljYXRlZCB1c2VyLg0KDQpUYWtl biBpbiB0aGUgbmFycm93ZXIgZGVmaW5pdGlvbiwgaXQgaXMgaW1wb3J0YW50IHRvIG9ic2VydmUg dGhhdCBpbiBhbiBJRCBUb2tlbiwg4oCcc3Vi4oCdIGFuZCDigJxpc3PigJ0gZ28gdG9nZXRoZXIu ICBUaGUgaXNzdWVyIHByb3ZpZGVzIHRoZSBjb250ZXh0IGZvciB0aGUgYXV0aGVudGljYXRlZCBz dWJqZWN0IGlkZW50aWZpZXIuIFRoZSBwcm9ibGVtIHdpdGggZXZlbnRzLCBpcyB0aGF0IGl0IG1p Z2h0IG5vdCBiZSB0aGUgQVMgKG9yIE9QKSB3aGljaCBpcyBpc3N1aW5nIHRoZSBldmVudC4NCg0K VG8gc3VtbWFyaXplIGEgZmFpciBhbW91bnQgb2YgZGlzY3Vzc2lvbiwgdGhlIGZlZWxpbmcgc2Vl bXMgdG8gYmUgdGhlIGZvbGxvd2luZzoNCg0KKiAgVGhlIEV2ZW50IFRva2VuIHRvcCBsZXZlbCBh dHRyaWJ1dGVzIHNob3VsZCBiZSBmYWlybHkgbGltaXRlZCBhbmQgbm90IGluY2x1ZGUgdGhlIHN1 YiBhdHRyaWJ1dGUuDQoqICBGb3IgZXZlbnRzIHRoYXQgYXJlIGFib3V0IGEgdXNlciwgdGhlIHJl bGV2YW50IGV2ZW50IHNwZWNpZmljYXRpb24gbWF5IGluY2x1ZGUgYSDigJxzdWLigJ0gYXR0cmli dXRlIHdpdGhpbiB0aGUgZXZlbnTigJlzIHN1Yi1vYmplY3QgYW5kIG5vdCBpbiB0aGUgdG9wLWxl dmVsLiBGdXJ0aGVyIHRoYXQgc3ViLW9iamVjdCBjYW4gYWxzbyBpbmNsdWRlIHRoZSBpc3N1ZXIg b2YgdGhlIHVzZXIuDQoqIFRoZSB0b3AtbGV2ZWwg4oCcaXNz4oCdIHNoYWxsIG1lYW4gdGhlIGlz c3VlciBvZiB0aGUgZXZlbnQgd2hlcmUgdGhlIHN0YXRlIGNoYW5nZSBvY2N1cnJlZC4NCiogIOKA nHN1YuKAnSBzaG91bGQgbm90IGJlIHByZXNlbnQgaW4gdGhlIHRvcCBsZXZlbCBzdHJ1Y3R1cmUu ICBBbHNvLCDigJxldmVudHPigJ0gbXVzdCBhbHNvIGJlIHByZXNlbnQuDQoNCkhlcmUgd291bGQg YmUgYSBuZXcgZXhhbXBsZSBsb2dvdXQ6DQoNCnsNCg0KICA84oCUIHRvcCBsZXZlbCBpcyBhYm91 dCB0aGUgZXZlbnQgaXRzZWxmIC0+DQoNCiAgImlzcyI6ICJodHRwczovL3NlcnZlci5leGFtcGxl LmNvbSIsDQoNCiAgImF1ZCI6ICJzNkJoZFJrcXQzIiwNCg0KICAianRpIjogIjNkMGMzY2Y3OTc1 ODRiZDE5M2JkMGZiMWJkNGU3ZDMwIiwNCg0KICAiaWF0IjogMTQ1ODY2ODE4MCwNCg0KICAiZXhw IjogMTQ1ODY2ODU4MCwNCg0KICAiZXZlbnRzIjogWw0KDQogICAgImh0dHBzOi8vc3BlY3Mub3Bl bmlkLm5ldC9sb2dvdXQiDQoNCiAgXSwNCg0KICAiaHR0cHM6Ly9zcGVjcy5vcGVuaWQubmV0L2xv Z291dCI6IHsNCg0KICAgIDwtIFRoaXMgbGV2ZWwgaXMgZGVmaW5lZCBlbnRpcmVseSBieSB0aGUg ZXZlbnQgVVJJLT4NCg0KICAgICJpc3MiOiAiaHR0cHM6Ly9vaWRjLmV4YW1wbGUuY29tIiwNCg0K ICAgIOKAnGp0aSI6ICIwOGE1MDE5Yy0xN2UxLTQ5NzctOGY0Mi02NWExMjg0M2VhMDLigJ0sDQoN CiAgICAic3ViIjogIjI0ODI4OTc2MTAwMeKAnSwNCg0KICAgIOKAnGV4cOKAnTogPElEIHRva2Vu IGV4cGlyeT4NCg0KICB9DQoNCn0NCg0KSW4gdGhlIGFib3ZlIGV4YW1wbGUgbm90ZSB0aGF0IHRo ZSDigJxldmVudOKAnSBvYmplY3QgY2FuIGhhdmUgaXRzIG93biBpc3MgYW5kIHN1YmplY3QgKHN1 YiBvciBqdGkpIHRoYXQgaGF2ZSBtZWFuaW5nIHdpdGhpbiB0aGUgY29udGV4dCBvZiBhbiBPcGVu SUQgT1AgcHJvdmlkZXIuICBUaGUgaXNzdWVyIG9mIHRoZSBldmVudCBjYW4gYmUgZGlmZmVyZW50 ICh0aGUgdG9wLWxldmVsKSBhbmQgcmVwcmVzZW50cyB0aGUgZW50aXR5IHRoYXQgc2lnbnMgdGhl IGV2ZW50IChpZiBpdCBpcyBzaWduZWQpLg0KDQpUaGUgdG9wLWxldmVsIGF0dHJpYnV0ZXMgaWRl bnRpZnkgYW4gaW5kaXZpZHVhbCBldmVudCBhbmQgYXJlIHVzZWQgdG8gdmFsaWRhdGUgdGhlIGV2 ZW50IChzaWduaW5nIGV0YykuICBXaGVyZSBhcyB0aGUgbmVzdGVkIG9iamVjdCBjb250YWlucyBh bGwgb2YgdGhlIGRhdGEgYWJvdXQgdGhlIGV2ZW50IGFuZCBpcyBkZWZpbmVkIGJ5IHRoZSBwcm9m aWxpbmcgc3BlY2lmaWNhdGlvbiAoZS5nLiBhIHBvc3NpYmxlIE9wZW5JRCBMb2dvdXQgRXZlbnQg c3BlYykuICBJbiB0aGlzIGNhc2UsIGluIE9wZW5JRCwgbG9nZ2luZyBvdXQgdXN1YWxseSB0cmFu c2xhdGVzIGludG8gcmV2b2tpbmcgYW4gSUQgVG9rZW4uIFRodXMgdGhlIOKAnGp0aeKAnSBmb3Ig dGhlIElEIHRva2VuICgwOGE1MDE5Yy4uLjg0M2VhMDIpIGlzIGluY2x1ZGVkIGluIHRoZSBMb2dv dXQgb2JqZWN0Lg0KDQpTaWRlIG5vdGUuICBSZWdhcmRpbmcg4oCcbG9nb3V04oCdLCBpdCBtaWdo dCBiZSB1c2VmdWwgdG8gaW5jbHVkZSB0aGUgZXhwaXJ5IG9mIHRoZSBJRCBUb2tlbiBpbiBjYXNl IHRoZSBzdWJzY3JpYmVyIGhhcyBub3QgeWV0IHJlY2VpdmVkIGFuIElEIFRva2VuLiBUaGlzIHdv dWxkIGxldCB0aGUgc3Vic2NyaWJlciBrbm93IGhvdyBsb25nIGl0IG5lZWRzIHRvIGtlZXAgdGhl IHJldm9jYXRpb24gaW5mb3JtYXRpb24gZm9yLiAgSU9X4oCmYWZ0ZXIgdGhlIHRoZSBJRCBUb2tl biBpcyBleHBpcmVkLCB0aGUgc3Vic2NyaWJlciB3b3VsZCBubyBsb25nZXIgbmVlZCB0byB0cmFj ayB0aGUgcmV2b2NhdGlvbiBzdGF0ZS4NCg0KSXQgaXMgYWxzbyBnb29kIHRvIG9ic2VydmUgdGhh dCB0aGUg4oCcYXVk4oCdIGF0IHRoZSB0b3AgbGV2ZWwgZGVzY3JpYmVzIHRoZSBzdWJzY3JpYmVy IG9mIHRoZSBldmVudC4gIFRoaXMgbWF5IGFsc28gYmUgZGlmZmVyZW50IHRoZW4gdGhlIG9yaWdp bmFsIGF1ZGllbmNlIG9mIHRoZSBJRCBUb2tlbi4NCg0KU28gdG8gY29uY2x1ZGUuIEJ5IG1ha2lu ZyB0b3AtbGV2ZWwgYXR0cmlidXRlcyBzdHJpY3RseSBhYm91dCB0aGUgZXZlbnRzIG93biB2YWxp ZGF0aW9uLCBhbmQgbmVzdGVkIG9iamVjdHMgYWJvdXQgdGhlIGV2ZW50LCB3ZSBhdm9pZCBjb2xs aXNpb25zIGluIGRlZmluaXRpb25zIHN1Y2ggYXMgdGhlIGlzc3VlciBvZiB0aGUgZXZlbnQsIHZz LiB0aGUgb3JpZ2luYWwgaXNzdWVyIG9mIGEgc2VjdXJpdHkgYXNzZXJ0aW9uLg0KDQpJIGhvcGUg SeKAmXZlIGdvdHRlbiBldmVyeW9uZeKAmXMgZmVlZGJhY2sgY29ycmVjdCBoZXJlLiBMZXRzIGNv bnRpbnVlIHRvIGRpc2N1c3MuIEkgd2lsbCByZXZpc2UgdGhlIGRyYWZ0IHRvIGZvbGxvdyB0aGUg Z3JvdXBzIHRoaW5raW5nIGhlcmUuDQoNClBoaWwNCg0KQGluZGVwZW5kZW50aWQNCnd3dy5pbmRl cGVuZGVudGlkLmNvbTxodHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tPg0KcGhpbC5odW50QG9y YWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPg0KDQoNCg0KDQo= --_000_SN1PR0301MB1645C699D5475DA865258110F51C0SN1PR0301MB1645_ 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 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJh Z3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdp bi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRp di5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7 bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFt aWx5OkNvbnNvbGFzO30NCnNwYW4uYXBwbGUtc3R5bGUtc3Bhbg0KCXttc28tc3R5bGUtbmFtZTph cHBsZS1zdHlsZS1zcGFuO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y OiMwMDIwNjA7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3Qg bDANCgl7bXNvLWxpc3QtaWQ6MTQ3MjU1NjgxMjsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCglt c28tbGlzdC10ZW1wbGF0ZS1pZHM6LTQ1MzQ2MzYzNiA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5 MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9 DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxl dmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXtt YXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMwMDIwNjAiPlRoYW5rcyBmb3Igd3JpdGluZyB0aGlzLCBQaGlsLiZuYnNwOyBVbmZv cnR1bmF0ZWx5LCB0aGUgc3VtbWFyeSBiZWxvdyBkb2VzIG5vdCBpbmNsdWRlIG15IGZlZWRiYWNr LCB3aGljaCBhdCB0aGUgZXNzZW5jZSwgaXMgdG8ga2VlcCB0aGUgSUQgRXZlbnRzIGRhdGEgc3Ry dWN0dXJlIGFzDQogc2ltcGxlIGFuZCBnZW5lcmFsLXB1cnBvc2UgYXMgcG9zc2libGUuICZuYnNw OyhJIHN0cm9uZ2x5IGJlbGlldmUgdGhhdCBKV1QgaXMgdGhlIHN1Y2Nlc3MgaXQgaXMgYmVjYXVz ZSB3ZSBtYWRlIEpXVCBhcyBzaW1wbGUgYW5kIGdlbmVyYWwtcHVycG9zZSBhcyBwb3NzaWJsZSwg YW5kIHdlIHNob3VsZCBmb2xsb3cgdGhpcyBzdWNjZXNzZnVsIGV4YW1wbGUgYW5kIGRvIHRoZSBz YW1lIGhlcmUuKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+SSBi ZWxpZXZlIHRoYXQgdGhlIElEIEV2ZW50cyBzcGVjIG5lZWRzIHRvIGluY2x1ZGUgdGhlc2UgdGhp bmdzLCBhbmQgdGhlc2UgdGhpbmdzIG9ubHk6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6 bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xvcjojMDAyMDYwIj48c3BhbiBzdHlsZT0i bXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3Nw YW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAi PkRlZmluZSBvZiB0aGUg4oCcZXZlbnRz4oCdIGNsYWltPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNv LWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xvcjojMDAyMDYwIj48c3BhbiBz dHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMw MDIwNjAiPkRlZmluZSB0aGF0IGFuIGV2ZW50IG5hbWUgY2FuIGJlIHVzZWQgYXMgYSB0b3AtbGV2 ZWwgY2xhaW08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFw aCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFb aWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6U3ltYm9sO2NvbG9yOiMwMDIwNjAiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3 PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwh W2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+UmVxdWlyZSB0aGF0IOKAnGlz c+KAnSBiZSBpbmNsdWRlZCBhbmQgdGhhdCB0aGUgSldUIGJlIHNpZ25lZCBieSB0aGUgaXNzdWVy PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxl PSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBw b3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlN5bWJv bDtjb2xvcjojMDAyMDYwIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0 eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPkluY2x1ZGUgYSBzdGF0ZW1lbnQgYWxvbmcg dGhlIGxpbmVzIG9mIOKAnFRoZSBjbGFpbXMgdG8gYmUgaW5jbHVkZWQgd2l0aCBhbnkgcGFydGlj dWxhciBldmVudCBhcmUgdG8gYmUgZGVmaW5lZCBieSB0aGUgZXZlbnTigJ08bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAw MjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPkFuZCBJ4oCZZCBzdG9wIHRoZXJlLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+SXQgc2hvdWxkIGJlIGVudGly ZWx5IHVwIHRvIGFwcGxpY2F0aW9ucyB0byBzYXkgd2hhdCBjbGFpbXMgYXJlIGluY2x1ZGVkIHdp dGggZXZlbnRzIHRoZXkgZGVmaW5lIGFuZCB3aGF0IHRoZWlyIGZvcm1hdCBhbmQgbWVhbmluZ3Mg YXJlLiZuYnNwOyBUaGVuIHRoZSBJRCBFdmVudHMgc3BlYw0KIHdpbGwgYmUgYXMgZ2VuZXJhbC1w dXJwb3NlIGFzIHBvc3NpYmxlLCB3aXRoIGl0IGJlaW5nIG5hdHVyYWwgZm9yIGl0IHRvIGJlIHVz ZWQgaW4gZXNzZW50aWFsbHkgYWxsIEpTT04gRXZlbnQgY29udGV4dHMuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIw NjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5BcyBzb29uIGFzIHdlIHN0YXJ0IHB1dHRpbmcg cmVzdHJpY3Rpb25zIG9uIHRoZSB1c2Ugb2YgcGFydGljdWxhciBjbGFpbXMgYnkgZXZlbnRzLCB3 ZeKAmXJlIG1ha2luZyB0aGUgSUQgRXZlbnRzIHNwZWMgbGVzcyBnZW5lcmFsLXB1cnBvc2UgYW5k IGxlc3MgbmF0dXJhbCB0byB1c2UuJm5ic3A7DQogSW4gcGFydGljdWxhciwgdGhlIG9ubHkgdGhp bmcgdGhhdCB0aGUgc3BlYyBzaG91bGQgc2F5IGFib3V0IHRoZSDigJxzdWLigJ0gY2xhaW0gaXMg dGhhdCDigJxMaWtlIGFsbCBvdGhlciBjbGFpbXMgb3RoZXIgdGhhbiDigJhldmVudHPigJkgYW5k IOKAmGlzc+KAmSwgd2hldGhlciB0aGUg4oCYc3Vi4oCZIGNsYWltIGlzIHRvIGJlIGluY2x1ZGVk IHdpdGggYW4gZXZlbnQgaXMgZW50aXJlbHkgZXZlbnQtc3BlY2lmaWMuJm5ic3A7IFRoZSBjbGFp bXMgdG8gYmUgaW5jbHVkZWQgd2l0aCBhbnkNCiBwYXJ0aWN1bGFyIGV2ZW50IGFyZSBleHBsaWNp dGx5IG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbi7igJ08bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxzcGFuIHN0eWxl PSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48L3NwYW4+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gSWQtZXZlbnQgW21haWx0bzppZC1l dmVudC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5QaGlsIEh1bnQ8YnI+ DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgQXVndXN0IDksIDIwMTYgMTA6MTkgQU08YnI+DQo8Yj5U bzo8L2I+IGlkLWV2ZW50QGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtJZC1ldmVudF0g U3VtbWFyaXppbmcgcmVjZW50IGRpc2N1c3Npb25zIG9uIElELUV2ZW50IHRva2VuIGRyYWZ0PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aG91Z2h0IEkg d291bGQgdXBkYXRlIHRoZSBsaXN0IG9uIHNvbWUgZGlzY3Vzc2lvbnMgdGhhdCBoYXZlIGJlZW4g aGFwcGVuaW5nIG92ZXIgaW4gdGhlIE9wZW5JRCBDb25uZWN0IGFuZCBSSVNDIHdvcmtpbmcgZ3Jv dXBzIGNvbmZlcmVuY2UgY2FsbHMuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5UaGVzZSBkaXNjdXNzaW9ucyBoYXZlIGJlZW4gYWJvdXQgdGhlIGNvcmUgc3Bl YyBhbmQgdGhlIHJvbGUgb2Yg4oCcdG9wLWxldmVs4oCdIGF0dHJpYnV0ZXMgdnMuIGV2ZW50IOKA nGV4dGVuc2lvbuKAnSBhdHRyaWJ1dGVzLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2VlOiA8YSBocmVmPSJodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaHVudC1pZGV2ZW50LXRva2VuLTAxIj4NCmh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1odW50LWlkZXZlbnQtdG9rZW4tMDE8L2E+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIHBhcnRpY3VsYXIg c2hvdWxkIOKAnHN1YuKAnSBiZSB1c2VkIGluIHRoZSB0b3AgbGV2ZWwgdG8g4oCccG9pbnTigJ0g dG8gdGhlIHN1YmplY3QgKGluIHRoZSBicm9hZGVyIGVuZ2xpc2ggc2Vuc2UpIG9mIHRoZSBldmVu dCwgb3Igc2hvdWxkIGl0IGJlIGNvbnN0cmFpbmVkIHRvIHRoZSBTQU1ML0lEIFRva2VuIGRlZmlu aXRpb24gd2hpY2ggaXMgdGhlIGF1dGhlbnRpY2F0ZWQgdXNlci4gJm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRha2VuIGluIHRoZSBu YXJyb3dlciBkZWZpbml0aW9uLCBpdCBpcyBpbXBvcnRhbnQgdG8gb2JzZXJ2ZSB0aGF0IGluIGFu IElEIFRva2VuLCDigJxzdWLigJ0gYW5kIOKAnGlzc+KAnSBnbyB0b2dldGhlci4gJm5ic3A7VGhl IGlzc3VlciBwcm92aWRlcyB0aGUgY29udGV4dCBmb3IgdGhlIGF1dGhlbnRpY2F0ZWQgc3ViamVj dCBpZGVudGlmaWVyLiBUaGUgcHJvYmxlbSB3aXRoIGV2ZW50cywgaXMgdGhhdCBpdCBtaWdodCBu b3QgYmUgdGhlDQogQVMgKG9yIE9QKSB3aGljaCBpcyBpc3N1aW5nIHRoZSBldmVudC4gJm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRv IHN1bW1hcml6ZSBhIGZhaXIgYW1vdW50IG9mIGRpc2N1c3Npb24sIHRoZSBmZWVsaW5nIHNlZW1z IHRvIGJlIHRoZSBmb2xsb3dpbmc6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiogJm5ic3A7VGhlIEV2ZW50IFRva2VuIHRvcCBsZXZlbCBhdHRy aWJ1dGVzIHNob3VsZCBiZSBmYWlybHkgbGltaXRlZCBhbmQgbm90IGluY2x1ZGUgdGhlIHN1YiBh dHRyaWJ1dGUuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+KiAmbmJzcDtGb3IgZXZlbnRzIHRoYXQgYXJlIGFib3V0IGEgdXNlciwgdGhl IHJlbGV2YW50IGV2ZW50IHNwZWNpZmljYXRpb24gbWF5IGluY2x1ZGUgYSDigJxzdWLigJ0gYXR0 cmlidXRlIHdpdGhpbiB0aGUgZXZlbnTigJlzIHN1Yi1vYmplY3QgYW5kIG5vdCBpbiB0aGUgdG9w LWxldmVsLiBGdXJ0aGVyIHRoYXQgc3ViLW9iamVjdCBjYW4gYWxzbyBpbmNsdWRlIHRoZSBpc3N1 ZXIgb2YgdGhlIHVzZXIuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+KiBUaGUgdG9wLWxldmVsIOKAnGlzc+KAnSBzaGFsbCBtZWFuIHRo ZSBpc3N1ZXIgb2YgdGhlIGV2ZW50IHdoZXJlIHRoZSBzdGF0ZSBjaGFuZ2Ugb2NjdXJyZWQuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4qICZuYnNw O+KAnHN1YuKAnSBzaG91bGQgbm90IGJlIHByZXNlbnQgaW4gdGhlIHRvcCBsZXZlbCBzdHJ1Y3R1 cmUuICZuYnNwO0Fsc28sIOKAnGV2ZW50c+KAnSBtdXN0IGFsc28gYmUgcHJlc2VudC48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGVyZSB3b3Vs ZCBiZSBhIG5ldyBleGFtcGxlIGxvZ291dDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+ezxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPiZuYnNwOyAmbHQ74oCUIHRv cCBsZXZlbCBpcyBhYm91dCB0aGUgZXZlbnQgaXRzZWxmIC0mZ3Q7PG86cD48L286cD48L3ByZT4N CjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+Jm5ic3A7IDxzcGFuIHN0eWxl PSJjb2xvcjojNUUzMEVCIj4mcXVvdDtpc3MmcXVvdDs6ICZxdW90OzxhIGhyZWY9Imh0dHBzOi8v c2VydmVyLmV4YW1wbGUuY29tIj5odHRwczovL3NlcnZlci5leGFtcGxlLmNvbTwvYT4mcXVvdDss PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTph bHdheXMiPjxzcGFuIHN0eWxlPSJjb2xvcjojNUUzMEVCIj4mbmJzcDsgJnF1b3Q7YXVkJnF1b3Q7 OiAmcXVvdDtzNkJoZFJrcXQzJnF1b3Q7LDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBz dHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iY29sb3I6IzVFMzBF QiI+Jm5ic3A7ICZxdW90O2p0aSZxdW90OzogJnF1b3Q7M2QwYzNjZjc5NzU4NGJkMTkzYmQwZmIx YmQ0ZTdkMzAmcXVvdDssPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdl LWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJjb2xvcjojNUUzMEVCIj4mbmJzcDsg JnF1b3Q7aWF0JnF1b3Q7OiAxNDU4NjY4MTgwLDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iY29sb3I6IzVF MzBFQiI+Jm5ic3A7ICZxdW90O2V4cCZxdW90OzogMTQ1ODY2ODU4MCw8bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5 bGU9ImNvbG9yOiM1RTMwRUIiPiZuYnNwOyAmcXVvdDtldmVudHMmcXVvdDs6IFs8bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNw YW4gc3R5bGU9ImNvbG9yOiM1RTMwRUIiPiZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDs8YSBocmVm PSJodHRwczovL3NwZWNzLm9wZW5pZC5uZXQvbG9nb3V0Ij5odHRwczovL3NwZWNzLm9wZW5pZC5u ZXQvbG9nb3V0PC9hPiZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0i cGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iY29sb3I6IzVFMzBFQiI+Jm5i c3A7IF0sPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJl Zm9yZTphbHdheXMiPiA8c3BhbiBzdHlsZT0iY29sb3I6I0U2M0I3QSI+Jm5ic3A7JnF1b3Q7PGEg aHJlZj0iaHR0cHM6Ly9zcGVjcy5vcGVuaWQubmV0L2xvZ291dCI+aHR0cHM6Ly9zcGVjcy5vcGVu aWQubmV0L2xvZ291dDwvYT4mcXVvdDs6IHs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUg c3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImNvbG9yOiNFNjNC N0EiPiZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7LSBUaGlzIGxldmVsIGlzIGRlZmluZWQgZW50aXJl bHkgYnkgdGhlIGV2ZW50IFVSSS0mZ3Q7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0 eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJjb2xvcjojRTYzQjdB Ij4mbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7aXNzJnF1b3Q7OiAmcXVvdDs8YSBocmVmPSJodHRw czovL29pZGMuZXhhbXBsZS5jb20iPmh0dHBzOi8vb2lkYy5leGFtcGxlLmNvbTwvYT4mcXVvdDss PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTph bHdheXMiPjxzcGFuIHN0eWxlPSJjb2xvcjojRTYzQjdBIj4mbmJzcDsmbmJzcDsmbmJzcDsg4oCc anRpJnF1b3Q7OiAmcXVvdDswOGE1MDE5Yy0xN2UxLTQ5NzctOGY0Mi02NWExMjg0M2VhMDLigJ0s PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTph bHdheXMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOiNFNjNCN0EiPiZuYnNw OyZuYnNwOyZuYnNwOyAmcXVvdDtzdWImcXVvdDs6ICZxdW90OzI0ODI4OTc2MTAwMeKAnSw8L3Nw YW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5 cyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6I0U2M0I3QSI+Jm5ic3A7Jm5i c3A7Jm5ic3A7IOKAnGV4cOKAnTogJmx0O0lEIHRva2VuIGV4cGlyeSZndDs8bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6I0U2M0I3QSI+Jm5ic3A7IH08L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdCI+fTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SW4gdGhlIGFib3ZlIGV4YW1wbGUgbm90ZSB0aGF0IHRoZSDigJxldmVudOKAnSBv YmplY3QgY2FuIGhhdmUgaXRzIG93biBpc3MgYW5kIHN1YmplY3QgKHN1YiBvciBqdGkpIHRoYXQg aGF2ZSBtZWFuaW5nIHdpdGhpbiB0aGUgY29udGV4dCBvZiBhbiBPcGVuSUQgT1AgcHJvdmlkZXIu ICZuYnNwO1RoZSBpc3N1ZXIgb2YgdGhlIGV2ZW50IGNhbiBiZSBkaWZmZXJlbnQgKHRoZSB0b3At bGV2ZWwpIGFuZCByZXByZXNlbnRzIHRoZQ0KIGVudGl0eSB0aGF0IHNpZ25zIHRoZSBldmVudCAo aWYgaXQgaXMgc2lnbmVkKS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VGhlIHRvcC1sZXZlbCBhdHRyaWJ1dGVzIGlkZW50aWZ5IGFuIGluZGl2 aWR1YWwgZXZlbnQgYW5kIGFyZSB1c2VkIHRvIHZhbGlkYXRlIHRoZSBldmVudCAoc2lnbmluZyBl dGMpLiAmbmJzcDtXaGVyZSBhcyB0aGUgbmVzdGVkIG9iamVjdCBjb250YWlucyBhbGwgb2YgdGhl IGRhdGEgYWJvdXQgdGhlIGV2ZW50IGFuZCBpcyBkZWZpbmVkIGJ5IHRoZSBwcm9maWxpbmcgc3Bl Y2lmaWNhdGlvbiAoZS5nLiBhIHBvc3NpYmxlDQogT3BlbklEIExvZ291dCBFdmVudCBzcGVjKS4g Jm5ic3A7SW4gdGhpcyBjYXNlLCBpbiBPcGVuSUQsIGxvZ2dpbmcgb3V0IHVzdWFsbHkgdHJhbnNs YXRlcyBpbnRvIHJldm9raW5nIGFuIElEIFRva2VuLiBUaHVzIHRoZSDigJxqdGnigJ0gZm9yIHRo ZSBJRCB0b2tlbiAoMDhhNTAxOWMuLi44NDNlYTAyKSBpcyBpbmNsdWRlZCBpbiB0aGUgTG9nb3V0 IG9iamVjdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+U2lkZSBub3RlLiAmbmJzcDtSZWdhcmRpbmcg4oCcbG9nb3V04oCdLCBpdCBtaWdodCBi ZSB1c2VmdWwgdG8gaW5jbHVkZSB0aGUgZXhwaXJ5IG9mIHRoZSBJRCBUb2tlbiBpbiBjYXNlIHRo ZSBzdWJzY3JpYmVyIGhhcyBub3QgeWV0IHJlY2VpdmVkIGFuIElEIFRva2VuLiBUaGlzIHdvdWxk IGxldCB0aGUgc3Vic2NyaWJlciBrbm93IGhvdyBsb25nIGl0IG5lZWRzIHRvIGtlZXAgdGhlIHJl dm9jYXRpb24gaW5mb3JtYXRpb24gZm9yLg0KICZuYnNwO0lPV+KApmFmdGVyIHRoZSB0aGUgSUQg VG9rZW4gaXMgZXhwaXJlZCwgdGhlIHN1YnNjcmliZXIgd291bGQgbm8gbG9uZ2VyIG5lZWQgdG8g dHJhY2sgdGhlIHJldm9jYXRpb24gc3RhdGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IGlzIGFsc28gZ29vZCB0byBvYnNlcnZlIHRoYXQg dGhlIOKAnGF1ZOKAnSBhdCB0aGUgdG9wIGxldmVsIGRlc2NyaWJlcyB0aGUgc3Vic2NyaWJlciBv ZiB0aGUgZXZlbnQuICZuYnNwO1RoaXMgbWF5IGFsc28gYmUgZGlmZmVyZW50IHRoZW4gdGhlIG9y aWdpbmFsIGF1ZGllbmNlIG9mIHRoZSBJRCBUb2tlbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U28gdG8gY29uY2x1ZGUuIEJ5IG1ha2luZyB0 b3AtbGV2ZWwgYXR0cmlidXRlcyBzdHJpY3RseSBhYm91dCB0aGUgZXZlbnRzIG93biB2YWxpZGF0 aW9uLCBhbmQgbmVzdGVkIG9iamVjdHMgYWJvdXQgdGhlIGV2ZW50LCB3ZSBhdm9pZCBjb2xsaXNp b25zIGluIGRlZmluaXRpb25zIHN1Y2ggYXMgdGhlIGlzc3VlciBvZiB0aGUgZXZlbnQsIHZzLiB0 aGUgb3JpZ2luYWwgaXNzdWVyIG9mIGEgc2VjdXJpdHkgYXNzZXJ0aW9uLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGhvcGUgSeKAmXZlIGdv dHRlbiBldmVyeW9uZeKAmXMgZmVlZGJhY2sgY29ycmVjdCBoZXJlLiBMZXRzIGNvbnRpbnVlIHRv IGRpc2N1c3MuIEkgd2lsbCByZXZpc2UgdGhlIGRyYWZ0IHRvIGZvbGxvdyB0aGUgZ3JvdXBzIHRo aW5raW5nIGhlcmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlBoaWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+QGluZGVwZW5kZW50aWQ8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxhIGhyZWY9Imh0dHA6Ly93d3cuaW5kZXBlbmRlbnRp ZC5jb20iPnd3dy5pbmRlcGVuZGVudGlkLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29t Ij5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_SN1PR0301MB1645C699D5475DA865258110F51C0SN1PR0301MB1645_-- From nobody Tue Aug 9 12:06:52 2016 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 8CDF112D78C for ; Tue, 9 Aug 2016 12:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.467 X-Spam-Level: X-Spam-Status: No, score=-5.467 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=-1.247, 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 RWk1rRWFeAPz for ; Tue, 9 Aug 2016 12:06:48 -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 3E3AE12D54F for ; Tue, 9 Aug 2016 12:06:48 -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 u79J6l0j032445 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 9 Aug 2016 19:06:47 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u79J6kO2002552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 9 Aug 2016 19:06:46 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 u79J6kfK023426; Tue, 9 Aug 2016 19:06:46 GMT Received: from [192.168.1.15] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 09 Aug 2016 19:06:45 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_714A4010-99B8-4C09-9793-6EF61F473503" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Phil Hunt In-Reply-To: Date: Tue, 9 Aug 2016 12:06:44 -0700 Message-Id: References: <14E2EF51-7123-4E91-87DD-56AEA08202C1@oracle.com> To: Mike Jones X-Mailer: Apple Mail (2.3124) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: "id-event@ietf.org" Subject: Re: [Id-event] Summarizing recent discussions on ID-Event token draft X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 09 Aug 2016 19:06:50 -0000 --Apple-Mail=_714A4010-99B8-4C09-9793-6EF61F473503 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I didn=E2=80=99t cover this as I didn=E2=80=99t want to confuse people = with too many things. But I think we agree on all of the below. I=E2=80=99m not sure that we need a =E2=80=9Cname=E2=80=9D. What is your = intention there. Phil @independentid www.independentid.com = phil.hunt@oracle.com = > On Aug 9, 2016, at 11:54 AM, Mike Jones = wrote: >=20 > Thanks for writing this, Phil. Unfortunately, the summary below does = not include my feedback, which at the essence, is to keep the ID Events = data structure as simple and general-purpose as possible. (I strongly = believe that JWT is the success it is because we made JWT as simple and = general-purpose as possible, and we should follow this successful = example and do the same here.) > =20 > I believe that the ID Events spec needs to include these things, and = these things only: > =C2=B7 Define of the =E2=80=9Cevents=E2=80=9D claim > =C2=B7 Define that an event name can be used as a top-level = claim > =C2=B7 Require that =E2=80=9Ciss=E2=80=9D be included and that = the JWT be signed by the issuer > =C2=B7 Include a statement along the lines of =E2=80=9CThe = claims to be included with any particular event are to be defined by the = event=E2=80=9D > =20 > And I=E2=80=99d stop there. > =20 > It should be entirely up to applications to say what claims are = included with events they define and what their format and meanings are. = Then the ID Events spec will be as general-purpose as possible, with it = being natural for it to be used in essentially all JSON Event contexts. > =20 > As soon as we start putting restrictions on the use of particular = claims by events, we=E2=80=99re making the ID Events spec less = general-purpose and less natural to use. In particular, the only thing = that the spec should say about the =E2=80=9Csub=E2=80=9D claim is that = =E2=80=9CLike all other claims other than =E2=80=98events=E2=80=99 and = =E2=80=98iss=E2=80=99, whether the =E2=80=98sub=E2=80=99 claim is to be = included with an event is entirely event-specific. The claims to be = included with any particular event are explicitly outside the scope of = this specification.=E2=80=9D > =20 > -- Mike > =C2=A0 <> > From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Phil = Hunt > Sent: Tuesday, August 9, 2016 10:19 AM > To: id-event@ietf.org > Subject: [Id-event] Summarizing recent discussions on ID-Event token = draft > =20 > I thought I would update the list on some discussions that have been = happening over in the OpenID Connect and RISC working groups conference = calls. > =20 > These discussions have been about the core spec and the role of = =E2=80=9Ctop-level=E2=80=9D attributes vs. event =E2=80=9Cextension=E2=80=9D= attributes.=20 > See: https://tools.ietf.org/html/draft-hunt-idevent-token-01 = > =20 > In particular should =E2=80=9Csub=E2=80=9D be used in the top level to = =E2=80=9Cpoint=E2=80=9D to the subject (in the broader english sense) of = the event, or should it be constrained to the SAML/ID Token definition = which is the authenticated user. =20 > =20 > Taken in the narrower definition, it is important to observe that in = an ID Token, =E2=80=9Csub=E2=80=9D and =E2=80=9Ciss=E2=80=9D go = together. The issuer provides the context for the authenticated subject = identifier. The problem with events, is that it might not be the AS (or = OP) which is issuing the event. =20 > =20 > To summarize a fair amount of discussion, the feeling seems to be the = following: > =20 > * The Event Token top level attributes should be fairly limited and = not include the sub attribute. =20 > * For events that are about a user, the relevant event specification = may include a =E2=80=9Csub=E2=80=9D attribute within the event=E2=80=99s = sub-object and not in the top-level. Further that sub-object can also = include the issuer of the user. =20 > * The top-level =E2=80=9Ciss=E2=80=9D shall mean the issuer of the = event where the state change occurred. > * =E2=80=9Csub=E2=80=9D should not be present in the top level = structure. Also, =E2=80=9Cevents=E2=80=9D must also be present. > =20 > Here would be a new example logout: > { > <=E2=80=94 top level is about the event itself -> > "iss": "https://server.example.com ", > "aud": "s6BhdRkqt3", > "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", > "iat": 1458668180, > "exp": 1458668580, > "events": [ > "https://specs.openid.net/logout = " > ], > "https://specs.openid.net/logout ": = { > <- This level is defined entirely by the event URI-> > "iss": "https://oidc.example.com ", > =E2=80=9Cjti": "08a5019c-17e1-4977-8f42-65a12843ea02=E2=80=9D, > "sub": "248289761001=E2=80=9D, > =E2=80=9Cexp=E2=80=9D: > } > } > =20 > In the above example note that the =E2=80=9Cevent=E2=80=9D object can = have its own iss and subject (sub or jti) that have meaning within the = context of an OpenID OP provider. The issuer of the event can be = different (the top-level) and represents the entity that signs the event = (if it is signed). > =20 > The top-level attributes identify an individual event and are used to = validate the event (signing etc). Where as the nested object contains = all of the data about the event and is defined by the profiling = specification (e.g. a possible OpenID Logout Event spec). In this case, = in OpenID, logging out usually translates into revoking an ID Token. = Thus the =E2=80=9Cjti=E2=80=9D for the ID token (08a5019c...843ea02) is = included in the Logout object. > =20 > Side note. Regarding =E2=80=9Clogout=E2=80=9D, it might be useful to = include the expiry of the ID Token in case the subscriber has not yet = received an ID Token. This would let the subscriber know how long it = needs to keep the revocation information for. IOW=E2=80=A6after the the = ID Token is expired, the subscriber would no longer need to track the = revocation state. > =20 > It is also good to observe that the =E2=80=9Caud=E2=80=9D at the top = level describes the subscriber of the event. This may also be different = then the original audience of the ID Token. > =20 > So to conclude. By making top-level attributes strictly about the = events own validation, and nested objects about the event, we avoid = collisions in definitions such as the issuer of the event, vs. the = original issuer of a security assertion. > =20 > I hope I=E2=80=99ve gotten everyone=E2=80=99s feedback correct here. = Lets continue to discuss. I will revise the draft to follow the groups = thinking here. > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com --Apple-Mail=_714A4010-99B8-4C09-9793-6EF61F473503 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I didn=E2=80=99t cover this as I didn=E2=80=99t want to = confuse people with too many things.

But I think we agree on all of the = below.

I=E2=80=99= m not sure that we need a =E2=80=9Cname=E2=80=9D. What is your intention = there.




On Aug 9, 2016, at 11:54 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Thanks for writing this, Phil.  = Unfortunately, the summary below does not include my feedback, which at = the essence, is to keep the ID Events data structure as simple and = general-purpose as possible.  (I strongly believe that JWT is the = success it is because we made JWT as simple and general-purpose as = possible, and we should follow this successful example and do the same = here.)
 
I believe that the ID = Events spec needs to include these things, and these things only:
=C2=B7       Define of the =E2=80=9Cevents=E2=80=9D = claim
=C2=B7       Define that an event name can be used as a = top-level claim
=C2=B7       Require that =E2=80=9Ciss=E2=80=9D be = included and that the JWT be signed by the issuer
=C2=B7       Include a statement along the lines of = =E2=80=9CThe claims to be included with any particular event are to be = defined by the event=E2=80=9D
 
And I=E2=80=99d stop = there.
 
It should be entirely up = to applications to say what claims are included with events they define = and what their format and meanings are.  Then the ID Events spec = will be as general-purpose as possible, with it being natural for it to = be used in essentially all JSON Event contexts.
 
As = soon as we start putting restrictions on the use of particular claims by = events, we=E2=80=99re making the ID Events spec less general-purpose and = less natural to use.  In particular, the only thing that the spec = should say about the =E2=80=9Csub=E2=80=9D claim is that =E2=80=9CLike = all other claims other than =E2=80=98events=E2=80=99 and =E2=80=98iss=E2=80= =99, whether the =E2=80=98sub=E2=80=99 claim is to be included with an = event is entirely event-specific.  The claims to be included with = any particular event are explicitly outside the scope of this = specification.=E2=80=9D
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;       -- Mike
 
From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf = Of Phil Hunt
Sent: Tuesday, August 9, 2016 = 10:19 AM
To: id-event@ietf.org
Subject: [Id-event] Summarizing = recent discussions on ID-Event token draft
 
I thought I would update the list on some discussions that = have been happening over in the OpenID Connect and RISC working groups = conference calls.
 
These discussions have been about the core spec and = the role of =E2=80=9Ctop-level=E2=80=9D attributes vs. event = =E2=80=9Cextension=E2=80=9D attributes. 
 
In particular should =E2=80=9Csub=E2=80=9D = be used in the top level to =E2=80=9Cpoint=E2=80=9D to the subject (in = the broader english sense) of the event, or should it be constrained to = the SAML/ID Token definition which is the authenticated user.  
 
Taken in the narrower definition, it is = important to observe that in an ID Token, =E2=80=9Csub=E2=80=9D and = =E2=80=9Ciss=E2=80=9D go together.  The issuer provides the context = for the authenticated subject identifier. The problem with events, is = that it might not be the AS (or OP) which is issuing the event. =  
 
To summarize a fair amount of discussion, the feeling = seems to be the following:
 
*  The Event Token top level attributes should = be fairly limited and not include the sub attribute.  
*  For events that are about a user, the relevant event = specification may include a =E2=80=9Csub=E2=80=9D attribute within the = event=E2=80=99s sub-object and not in the top-level. Further that = sub-object can also include the issuer of the user.  
* The top-level =E2=80=9Ciss=E2=80=9D shall mean the issuer = of the event where the state change occurred.
*  =E2=80=9Csub=E2=80=9D should not be present in the = top level structure.  Also, =E2=80=9Cevents=E2=80=9D must also be = present.
 
Here would be a new example logout:
{
  <=E2=80=94=
 top level is about the event itself ->
  "iss": "https://server.example.com",
  =
"aud": "s6BhdRkqt3",
  "jti": =
"3d0c3cf797584bd193bd0fb1bd4e7d30",
  "iat": = 1458668180,
  "exp": 1458668580,
  =
"events": [
    "https://specs.openid.net/logout"
  =
],
  "https://specs.openid.net/logout": {
    <- This level is defined entirely by =
the event URI->
    "iss": "https://oidc.example.com",
    =E2=80=9Cjti": =
"08a5019c-17e1-4977-8f42-65a12843ea02=E2=80=9D,
    "sub": "248289761001=E2=80=9D,
    =E2=80=9Cexp=E2=80=9D: <ID token =
expiry>
  }
}
 
In the above example note that the = =E2=80=9Cevent=E2=80=9D object can have its own iss and subject (sub or = jti) that have meaning within the context of an OpenID OP provider. =  The issuer of the event can be different (the top-level) and = represents the entity that signs the event (if it is signed).
 
The top-level attributes identify an = individual event and are used to validate the event (signing etc). =  Where as the nested object contains all of the data about the = event and is defined by the profiling specification (e.g. a possible = OpenID Logout Event spec).  In this case, in OpenID, logging out = usually translates into revoking an ID Token. Thus the =E2=80=9Cjti=E2=80=9D= for the ID token (08a5019c...843ea02) is included in the Logout = object.
 
Side note.  Regarding =E2=80=9Clogout=E2=80=9D, = it might be useful to include the expiry of the ID Token in case the = subscriber has not yet received an ID Token. This would let the = subscriber know how long it needs to keep the revocation information = for.  IOW=E2=80=A6after the the ID Token is expired, the subscriber = would no longer need to track the revocation state.
 
It is also good to observe that the = =E2=80=9Caud=E2=80=9D at the top level describes the subscriber of the = event.  This may also be different then the original audience of = the ID Token.
 
So to conclude. By making top-level attributes = strictly about the events own validation, and nested objects about the = event, we avoid collisions in definitions such as the issuer of the = event, vs. the original issuer of a security assertion.
 
I hope I=E2=80=99ve gotten everyone=E2=80=99= s feedback correct here. Lets continue to discuss. I will revise the = draft to follow the groups thinking here.
 
Phil
 
@independentid
www.independentid.com
phil.hunt@oracle.com

= --Apple-Mail=_714A4010-99B8-4C09-9793-6EF61F473503-- From nobody Tue Aug 9 12:13:09 2016 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 633B812D7C8 for ; Tue, 9 Aug 2016 12:13:07 -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 naQB_6EFt8H6 for ; Tue, 9 Aug 2016 12:13:04 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0094.outbound.protection.outlook.com [104.47.33.94]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31AC412D7B1 for ; Tue, 9 Aug 2016 12:13:04 -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=JtbrzS7wtm15NKnN5fPjCZ0GNmgCoYCtVVfgsWE+xSs=; b=I0R8DS8Mp3hfHL+EH00xiq26fYncFJy+tqWBw2uT0m/BlpVGqRrl5CfG9IeBUK2G9aTKZZ80L9DklvMcAWnPWbpnhHIisQRKKIbr3V417HLA1uJvuoDg27r3ci8zxqPj4XnoSL1NX6qy9Hp0fvQmQ94Tk4vJNIqVpv2PN+oP9Z8= Received: from SN1PR0301MB1645.namprd03.prod.outlook.com (10.162.130.139) by SN1PR0301MB1646.namprd03.prod.outlook.com (10.162.130.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Tue, 9 Aug 2016 19:12:55 +0000 Received: from SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) by SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) with mapi id 15.01.0549.025; Tue, 9 Aug 2016 19:12:55 +0000 From: Mike Jones To: Phil Hunt Thread-Topic: [Id-event] Summarizing recent discussions on ID-Event token draft Thread-Index: AQHR8mIWLvqeOEkcuEuQk5SeT4z/pKBA9pTwgAAG/gCAAABNAA== Date: Tue, 9 Aug 2016 19:12:54 +0000 Message-ID: References: <14E2EF51-7123-4E91-87DD-56AEA08202C1@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [206.47.171.251] x-ms-office365-filtering-correlation-id: 7b59b455-aaae-4f73-ca61-08d3c0892ae3 x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1646; 6:j3nr2oZWxOAM+DV0srpIGv7a/dtm6SeRy+IsDqzAYs3pYZuMHimJJUv1webnPBhW7C3jd/3H+DlaOLzThEo6gUlmQZkcgahf2KKJ1lwwmyf9tOyoCnwuwwnhgSzy5Ip7lbFGrnXrnnhkRAMjCSMYE8h59fEpRsl/pu/qVPRJZOAXNXYtRjO58z4St7kQPpe0t9XD2Xk6nGi+EnnkwjnHBjx1NrR0fVRin42rabuph7++I8KJgk4FL9+HcdvWdUA/EuWIQuOxoxLB9P5+EPsSb9KWkB5CQNH2suhIV9NWJmFl2gMzUe/z5fECqcXXtrH4u15XJGc0RdGnYPiavWdhxA==; 5:uHLTqDPa1M0Xr8qJeGnAoErOm7XIIVXtz1Uq87wWstuZg3iGRShK59JV78lDvTaSpQXua/PKHFjosAPRAMWWNkRHlywMoIBJ0o8orGX4nTMJq1xJuW4cXnprNqVDt6wxQiqARf7vH3NBd5NigM3bIQ==; 24:crXl3k8H7TFGksmkuDLrz270M/P/yIt10aFjn22Z/j8hsQ9ebDP+144bLbjFlnCDWJrIiNQFfhCx+pBR/rCkVtannccXvg7KEnqG3scxrgg=; 7:WkU8iyB1+Glwu4Y0/X66EowyBnwAKdme/qk+I9qR+Ag5pe66EGR2ccS5XfD6HXa4ZmTtj1ehCFSx5sftPI7GIUTU6gWEWkgdhpRg7FyC5kCz5ngLjoJ6T43T2lZnuOkQ5dxLyJ1SDfjjLRPK/9/mzyk7XzldP1f42O71bVqhbYEgKMaAURenXmcfGHEAAvQ3q41hBDDl/WtyMtccrhy3Z7vhyRn7Zvk2eCugJZXIjO6pteWAUXec8tUyk5KELEW6 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1646; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(278428928389397)(192374486261705)(21748063052155)(21532816269658)(146099531331640); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:SN1PR0301MB1646; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1646; x-forefront-prvs: 0029F17A3F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(377454003)(189002)(24454002)(199003)(43784003)(33656002)(76576001)(16236675004)(86362001)(575784001)(87936001)(76176999)(54356999)(5002640100001)(50986999)(101416001)(19625215002)(19300405004)(7906003)(66066001)(74316002)(7846002)(16601075003)(19580405001)(7736002)(7696003)(86612001)(19580395003)(92566002)(19609705001)(122556002)(81166006)(8990500004)(105586002)(10400500002)(10290500002)(5005710100001)(11100500001)(189998001)(8676002)(110136002)(586003)(97736004)(81156014)(106356001)(106116001)(3846002)(6116002)(790700001)(102836003)(68736007)(9686002)(4326007)(1680700002)(99286002)(2906002)(8936002)(15975445007)(2900100001)(3660700001)(2950100001)(10090500001)(19617315012)(3280700002)(77096005); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0301MB1646; H:SN1PR0301MB1645.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB16458A377399DFECBA108D17F51C0SN1PR0301MB1645_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Aug 2016 19:12:54.9784 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1646 Archived-At: Cc: "id-event@ietf.org" Subject: Re: [Id-event] Summarizing recent discussions on ID-Event token draft X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 09 Aug 2016 19:13:07 -0000 --_000_SN1PR0301MB16458A377399DFECBA108D17F51C0SN1PR0301MB1645_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gZ2xhZCB0byBoZWFyIHRoYXQgd2UgYWdyZWUgb24ga2VlcGluZyBpdCBhcyBzaW1wbGUg YW5kIGdlbmVyYWwtcHVycG9zZSBhcyBwb3NzaWJsZSBhbmQgdGhhdCB5b3UgYWdyZWUgd2l0aCBt eSB3cml0ZS11cC4gIEkgdGhpbmsgd2UgdGhlbiBoYXZlIGEgZ29vZCBwYXRoIGZvcndhcmQuDQoN CknigJltIG5vdCBzdXJlIHdoYXQgeW91IG1lYW4gYnkg4oCcSeKAmW0gbm90IHN1cmUgdGhhdCB3 ZSBuZWVkIGEg4oCcbmFtZeKAnS4gV2hhdCBpcyB5b3VyIGludGVudGlvbiB0aGVyZS7igJ0gIFRo ZSBvbmx5IHBsYWNlIEkgdXNlZCB0aGUgd29yZCDigJxuYW1l4oCdIHdhcyBpbiBteSBzdGF0ZW1l bnQg4oCcRGVmaW5lIHRoYXQgYW4gZXZlbnQgbmFtZSBjYW4gYmUgdXNlZCBhcyBhIHRvcC1sZXZl bCBjbGFpbeKAnS4gIFdoYXQgSSB3YXMgdHJ5aW5nIHRvIGdldCBhdCBpcyB3YXMgdGhhdCBpZiDi gJxodHRwOi8vc3BlY3Mub3BlbmlkLm5ldC9sb2dvdXTigJ0gaXMgdXNlZCBhcyBhbiBldmVudCBu YW1lLCB0aGF0IGl0IGNhbiBhbHNvIGJlIHVzZWQgYXMgYSBjbGFpbSBuYW1lIGluIHRoZSBKV1Qg Y29udGFpbmluZyBpbmZvcm1hdGlvbiBhYm91dCB0aGUgZXZlbnQuICAoTWF5YmUgSeKAmW0gbm90 IHVzaW5nIHRoZSBjb3JyZWN0IHRlcm1pbm9sb2d5LCBoZW5jZSB0aGUgdW5pbnRlbmRlZCBjb25m dXNpb24g4pi6LikNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFRoYW5rcyBhZ2FpbiwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IFBoaWwgSHVudCBbbWFp bHRvOnBoaWwuaHVudEBvcmFjbGUuY29tXQ0KU2VudDogVHVlc2RheSwgQXVndXN0IDksIDIwMTYg MTI6MDcgUE0NClRvOiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+DQpD YzogaWQtZXZlbnRAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbSWQtZXZlbnRdIFN1bW1hcml6aW5n IHJlY2VudCBkaXNjdXNzaW9ucyBvbiBJRC1FdmVudCB0b2tlbiBkcmFmdA0KDQpJIGRpZG7igJl0 IGNvdmVyIHRoaXMgYXMgSSBkaWRu4oCZdCB3YW50IHRvIGNvbmZ1c2UgcGVvcGxlIHdpdGggdG9v IG1hbnkgdGhpbmdzLg0KDQpCdXQgSSB0aGluayB3ZSBhZ3JlZSBvbiBhbGwgb2YgdGhlIGJlbG93 Lg0KDQpJ4oCZbSBub3Qgc3VyZSB0aGF0IHdlIG5lZWQgYSDigJxuYW1l4oCdLiBXaGF0IGlzIHlv dXIgaW50ZW50aW9uIHRoZXJlLg0KDQpQaGlsDQoNCkBpbmRlcGVuZGVudGlkDQp3d3cuaW5kZXBl bmRlbnRpZC5jb208aHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNvbT4NCnBoaWwuaHVudEBvcmFj bGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4NCg0KDQoNCg0KT24gQXVnIDksIDIw MTYsIGF0IDExOjU0IEFNLCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208 bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KDQpUaGFua3MgZm9y IHdyaXRpbmcgdGhpcywgUGhpbC4gIFVuZm9ydHVuYXRlbHksIHRoZSBzdW1tYXJ5IGJlbG93IGRv ZXMgbm90IGluY2x1ZGUgbXkgZmVlZGJhY2ssIHdoaWNoIGF0IHRoZSBlc3NlbmNlLCBpcyB0byBr ZWVwIHRoZSBJRCBFdmVudHMgZGF0YSBzdHJ1Y3R1cmUgYXMgc2ltcGxlIGFuZCBnZW5lcmFsLXB1 cnBvc2UgYXMgcG9zc2libGUuICAoSSBzdHJvbmdseSBiZWxpZXZlIHRoYXQgSldUIGlzIHRoZSBz dWNjZXNzIGl0IGlzIGJlY2F1c2Ugd2UgbWFkZSBKV1QgYXMgc2ltcGxlIGFuZCBnZW5lcmFsLXB1 cnBvc2UgYXMgcG9zc2libGUsIGFuZCB3ZSBzaG91bGQgZm9sbG93IHRoaXMgc3VjY2Vzc2Z1bCBl eGFtcGxlIGFuZCBkbyB0aGUgc2FtZSBoZXJlLikNCg0KSSBiZWxpZXZlIHRoYXQgdGhlIElEIEV2 ZW50cyBzcGVjIG5lZWRzIHRvIGluY2x1ZGUgdGhlc2UgdGhpbmdzLCBhbmQgdGhlc2UgdGhpbmdz IG9ubHk6DQrigKIgICAgICAgRGVmaW5lIG9mIHRoZSDigJxldmVudHPigJ0gY2xhaW0NCuKAoiAg ICAgICBEZWZpbmUgdGhhdCBhbiBldmVudCBuYW1lIGNhbiBiZSB1c2VkIGFzIGEgdG9wLWxldmVs IGNsYWltDQrigKIgICAgICAgUmVxdWlyZSB0aGF0IOKAnGlzc+KAnSBiZSBpbmNsdWRlZCBhbmQg dGhhdCB0aGUgSldUIGJlIHNpZ25lZCBieSB0aGUgaXNzdWVyDQrigKIgICAgICAgSW5jbHVkZSBh IHN0YXRlbWVudCBhbG9uZyB0aGUgbGluZXMgb2Yg4oCcVGhlIGNsYWltcyB0byBiZSBpbmNsdWRl ZCB3aXRoIGFueSBwYXJ0aWN1bGFyIGV2ZW50IGFyZSB0byBiZSBkZWZpbmVkIGJ5IHRoZSBldmVu dOKAnQ0KDQpBbmQgSeKAmWQgc3RvcCB0aGVyZS4NCg0KSXQgc2hvdWxkIGJlIGVudGlyZWx5IHVw IHRvIGFwcGxpY2F0aW9ucyB0byBzYXkgd2hhdCBjbGFpbXMgYXJlIGluY2x1ZGVkIHdpdGggZXZl bnRzIHRoZXkgZGVmaW5lIGFuZCB3aGF0IHRoZWlyIGZvcm1hdCBhbmQgbWVhbmluZ3MgYXJlLiAg VGhlbiB0aGUgSUQgRXZlbnRzIHNwZWMgd2lsbCBiZSBhcyBnZW5lcmFsLXB1cnBvc2UgYXMgcG9z c2libGUsIHdpdGggaXQgYmVpbmcgbmF0dXJhbCBmb3IgaXQgdG8gYmUgdXNlZCBpbiBlc3NlbnRp YWxseSBhbGwgSlNPTiBFdmVudCBjb250ZXh0cy4NCg0KQXMgc29vbiBhcyB3ZSBzdGFydCBwdXR0 aW5nIHJlc3RyaWN0aW9ucyBvbiB0aGUgdXNlIG9mIHBhcnRpY3VsYXIgY2xhaW1zIGJ5IGV2ZW50 cywgd2XigJlyZSBtYWtpbmcgdGhlIElEIEV2ZW50cyBzcGVjIGxlc3MgZ2VuZXJhbC1wdXJwb3Nl IGFuZCBsZXNzIG5hdHVyYWwgdG8gdXNlLiAgSW4gcGFydGljdWxhciwgdGhlIG9ubHkgdGhpbmcg dGhhdCB0aGUgc3BlYyBzaG91bGQgc2F5IGFib3V0IHRoZSDigJxzdWLigJ0gY2xhaW0gaXMgdGhh dCDigJxMaWtlIGFsbCBvdGhlciBjbGFpbXMgb3RoZXIgdGhhbiDigJhldmVudHPigJkgYW5kIOKA mGlzc+KAmSwgd2hldGhlciB0aGUg4oCYc3Vi4oCZIGNsYWltIGlzIHRvIGJlIGluY2x1ZGVkIHdp dGggYW4gZXZlbnQgaXMgZW50aXJlbHkgZXZlbnQtc3BlY2lmaWMuICBUaGUgY2xhaW1zIHRvIGJl IGluY2x1ZGVkIHdpdGggYW55IHBhcnRpY3VsYXIgZXZlbnQgYXJlIGV4cGxpY2l0bHkgb3V0c2lk ZSB0aGUgc2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uLuKAnQ0KDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBJ ZC1ldmVudCBbbWFpbHRvOmlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQ aGlsIEh1bnQNClNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCA5LCAyMDE2IDEwOjE5IEFNDQpUbzogaWQt ZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOmlkLWV2ZW50QGlldGYub3JnPg0KU3ViamVjdDogW0lkLWV2 ZW50XSBTdW1tYXJpemluZyByZWNlbnQgZGlzY3Vzc2lvbnMgb24gSUQtRXZlbnQgdG9rZW4gZHJh ZnQNCg0KSSB0aG91Z2h0IEkgd291bGQgdXBkYXRlIHRoZSBsaXN0IG9uIHNvbWUgZGlzY3Vzc2lv bnMgdGhhdCBoYXZlIGJlZW4gaGFwcGVuaW5nIG92ZXIgaW4gdGhlIE9wZW5JRCBDb25uZWN0IGFu ZCBSSVNDIHdvcmtpbmcgZ3JvdXBzIGNvbmZlcmVuY2UgY2FsbHMuDQoNClRoZXNlIGRpc2N1c3Np b25zIGhhdmUgYmVlbiBhYm91dCB0aGUgY29yZSBzcGVjIGFuZCB0aGUgcm9sZSBvZiDigJx0b3At bGV2ZWzigJ0gYXR0cmlidXRlcyB2cy4gZXZlbnQg4oCcZXh0ZW5zaW9u4oCdIGF0dHJpYnV0ZXMu DQpTZWU6IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1odW50LWlkZXZlbnQtdG9r ZW4tMDENCg0KSW4gcGFydGljdWxhciBzaG91bGQg4oCcc3Vi4oCdIGJlIHVzZWQgaW4gdGhlIHRv cCBsZXZlbCB0byDigJxwb2ludOKAnSB0byB0aGUgc3ViamVjdCAoaW4gdGhlIGJyb2FkZXIgZW5n bGlzaCBzZW5zZSkgb2YgdGhlIGV2ZW50LCBvciBzaG91bGQgaXQgYmUgY29uc3RyYWluZWQgdG8g dGhlIFNBTUwvSUQgVG9rZW4gZGVmaW5pdGlvbiB3aGljaCBpcyB0aGUgYXV0aGVudGljYXRlZCB1 c2VyLg0KDQpUYWtlbiBpbiB0aGUgbmFycm93ZXIgZGVmaW5pdGlvbiwgaXQgaXMgaW1wb3J0YW50 IHRvIG9ic2VydmUgdGhhdCBpbiBhbiBJRCBUb2tlbiwg4oCcc3Vi4oCdIGFuZCDigJxpc3PigJ0g Z28gdG9nZXRoZXIuICBUaGUgaXNzdWVyIHByb3ZpZGVzIHRoZSBjb250ZXh0IGZvciB0aGUgYXV0 aGVudGljYXRlZCBzdWJqZWN0IGlkZW50aWZpZXIuIFRoZSBwcm9ibGVtIHdpdGggZXZlbnRzLCBp cyB0aGF0IGl0IG1pZ2h0IG5vdCBiZSB0aGUgQVMgKG9yIE9QKSB3aGljaCBpcyBpc3N1aW5nIHRo ZSBldmVudC4NCg0KVG8gc3VtbWFyaXplIGEgZmFpciBhbW91bnQgb2YgZGlzY3Vzc2lvbiwgdGhl IGZlZWxpbmcgc2VlbXMgdG8gYmUgdGhlIGZvbGxvd2luZzoNCg0KKiAgVGhlIEV2ZW50IFRva2Vu IHRvcCBsZXZlbCBhdHRyaWJ1dGVzIHNob3VsZCBiZSBmYWlybHkgbGltaXRlZCBhbmQgbm90IGlu Y2x1ZGUgdGhlIHN1YiBhdHRyaWJ1dGUuDQoqICBGb3IgZXZlbnRzIHRoYXQgYXJlIGFib3V0IGEg dXNlciwgdGhlIHJlbGV2YW50IGV2ZW50IHNwZWNpZmljYXRpb24gbWF5IGluY2x1ZGUgYSDigJxz dWLigJ0gYXR0cmlidXRlIHdpdGhpbiB0aGUgZXZlbnTigJlzIHN1Yi1vYmplY3QgYW5kIG5vdCBp biB0aGUgdG9wLWxldmVsLiBGdXJ0aGVyIHRoYXQgc3ViLW9iamVjdCBjYW4gYWxzbyBpbmNsdWRl IHRoZSBpc3N1ZXIgb2YgdGhlIHVzZXIuDQoqIFRoZSB0b3AtbGV2ZWwg4oCcaXNz4oCdIHNoYWxs IG1lYW4gdGhlIGlzc3VlciBvZiB0aGUgZXZlbnQgd2hlcmUgdGhlIHN0YXRlIGNoYW5nZSBvY2N1 cnJlZC4NCiogIOKAnHN1YuKAnSBzaG91bGQgbm90IGJlIHByZXNlbnQgaW4gdGhlIHRvcCBsZXZl bCBzdHJ1Y3R1cmUuICBBbHNvLCDigJxldmVudHPigJ0gbXVzdCBhbHNvIGJlIHByZXNlbnQuDQoN CkhlcmUgd291bGQgYmUgYSBuZXcgZXhhbXBsZSBsb2dvdXQ6DQoNCnsNCg0KICA84oCUIHRvcCBs ZXZlbCBpcyBhYm91dCB0aGUgZXZlbnQgaXRzZWxmIC0+DQoNCiAgImlzcyI6ICJodHRwczovL3Nl cnZlci5leGFtcGxlLmNvbTxodHRwczovL3NlcnZlci5leGFtcGxlLmNvbS8+IiwNCg0KICAiYXVk IjogInM2QmhkUmtxdDMiLA0KDQogICJqdGkiOiAiM2QwYzNjZjc5NzU4NGJkMTkzYmQwZmIxYmQ0 ZTdkMzAiLA0KDQogICJpYXQiOiAxNDU4NjY4MTgwLA0KDQogICJleHAiOiAxNDU4NjY4NTgwLA0K DQogICJldmVudHMiOiBbDQoNCiAgICAiaHR0cHM6Ly9zcGVjcy5vcGVuaWQubmV0L2xvZ291dCIN Cg0KICBdLA0KDQogICJodHRwczovL3NwZWNzLm9wZW5pZC5uZXQvbG9nb3V0Ijogew0KDQogICAg PC0gVGhpcyBsZXZlbCBpcyBkZWZpbmVkIGVudGlyZWx5IGJ5IHRoZSBldmVudCBVUkktPg0KDQog ICAgImlzcyI6ICJodHRwczovL29pZGMuZXhhbXBsZS5jb208aHR0cHM6Ly9vaWRjLmV4YW1wbGUu Y29tLz4iLA0KDQogICAg4oCcanRpIjogIjA4YTUwMTljLTE3ZTEtNDk3Ny04ZjQyLTY1YTEyODQz ZWEwMuKAnSwNCg0KICAgICJzdWIiOiAiMjQ4Mjg5NzYxMDAx4oCdLA0KDQogICAg4oCcZXhw4oCd OiA8SUQgdG9rZW4gZXhwaXJ5Pg0KDQogIH0NCg0KfQ0KDQpJbiB0aGUgYWJvdmUgZXhhbXBsZSBu b3RlIHRoYXQgdGhlIOKAnGV2ZW504oCdIG9iamVjdCBjYW4gaGF2ZSBpdHMgb3duIGlzcyBhbmQg c3ViamVjdCAoc3ViIG9yIGp0aSkgdGhhdCBoYXZlIG1lYW5pbmcgd2l0aGluIHRoZSBjb250ZXh0 IG9mIGFuIE9wZW5JRCBPUCBwcm92aWRlci4gIFRoZSBpc3N1ZXIgb2YgdGhlIGV2ZW50IGNhbiBi ZSBkaWZmZXJlbnQgKHRoZSB0b3AtbGV2ZWwpIGFuZCByZXByZXNlbnRzIHRoZSBlbnRpdHkgdGhh dCBzaWducyB0aGUgZXZlbnQgKGlmIGl0IGlzIHNpZ25lZCkuDQoNClRoZSB0b3AtbGV2ZWwgYXR0 cmlidXRlcyBpZGVudGlmeSBhbiBpbmRpdmlkdWFsIGV2ZW50IGFuZCBhcmUgdXNlZCB0byB2YWxp ZGF0ZSB0aGUgZXZlbnQgKHNpZ25pbmcgZXRjKS4gIFdoZXJlIGFzIHRoZSBuZXN0ZWQgb2JqZWN0 IGNvbnRhaW5zIGFsbCBvZiB0aGUgZGF0YSBhYm91dCB0aGUgZXZlbnQgYW5kIGlzIGRlZmluZWQg YnkgdGhlIHByb2ZpbGluZyBzcGVjaWZpY2F0aW9uIChlLmcuIGEgcG9zc2libGUgT3BlbklEIExv Z291dCBFdmVudCBzcGVjKS4gIEluIHRoaXMgY2FzZSwgaW4gT3BlbklELCBsb2dnaW5nIG91dCB1 c3VhbGx5IHRyYW5zbGF0ZXMgaW50byByZXZva2luZyBhbiBJRCBUb2tlbi4gVGh1cyB0aGUg4oCc anRp4oCdIGZvciB0aGUgSUQgdG9rZW4gKDA4YTUwMTljLi4uODQzZWEwMikgaXMgaW5jbHVkZWQg aW4gdGhlIExvZ291dCBvYmplY3QuDQoNClNpZGUgbm90ZS4gIFJlZ2FyZGluZyDigJxsb2dvdXTi gJ0sIGl0IG1pZ2h0IGJlIHVzZWZ1bCB0byBpbmNsdWRlIHRoZSBleHBpcnkgb2YgdGhlIElEIFRv a2VuIGluIGNhc2UgdGhlIHN1YnNjcmliZXIgaGFzIG5vdCB5ZXQgcmVjZWl2ZWQgYW4gSUQgVG9r ZW4uIFRoaXMgd291bGQgbGV0IHRoZSBzdWJzY3JpYmVyIGtub3cgaG93IGxvbmcgaXQgbmVlZHMg dG8ga2VlcCB0aGUgcmV2b2NhdGlvbiBpbmZvcm1hdGlvbiBmb3IuICBJT1figKZhZnRlciB0aGUg dGhlIElEIFRva2VuIGlzIGV4cGlyZWQsIHRoZSBzdWJzY3JpYmVyIHdvdWxkIG5vIGxvbmdlciBu ZWVkIHRvIHRyYWNrIHRoZSByZXZvY2F0aW9uIHN0YXRlLg0KDQpJdCBpcyBhbHNvIGdvb2QgdG8g b2JzZXJ2ZSB0aGF0IHRoZSDigJxhdWTigJ0gYXQgdGhlIHRvcCBsZXZlbCBkZXNjcmliZXMgdGhl IHN1YnNjcmliZXIgb2YgdGhlIGV2ZW50LiAgVGhpcyBtYXkgYWxzbyBiZSBkaWZmZXJlbnQgdGhl biB0aGUgb3JpZ2luYWwgYXVkaWVuY2Ugb2YgdGhlIElEIFRva2VuLg0KDQpTbyB0byBjb25jbHVk ZS4gQnkgbWFraW5nIHRvcC1sZXZlbCBhdHRyaWJ1dGVzIHN0cmljdGx5IGFib3V0IHRoZSBldmVu dHMgb3duIHZhbGlkYXRpb24sIGFuZCBuZXN0ZWQgb2JqZWN0cyBhYm91dCB0aGUgZXZlbnQsIHdl IGF2b2lkIGNvbGxpc2lvbnMgaW4gZGVmaW5pdGlvbnMgc3VjaCBhcyB0aGUgaXNzdWVyIG9mIHRo ZSBldmVudCwgdnMuIHRoZSBvcmlnaW5hbCBpc3N1ZXIgb2YgYSBzZWN1cml0eSBhc3NlcnRpb24u DQoNCkkgaG9wZSBJ4oCZdmUgZ290dGVuIGV2ZXJ5b25l4oCZcyBmZWVkYmFjayBjb3JyZWN0IGhl cmUuIExldHMgY29udGludWUgdG8gZGlzY3Vzcy4gSSB3aWxsIHJldmlzZSB0aGUgZHJhZnQgdG8g Zm9sbG93IHRoZSBncm91cHMgdGhpbmtpbmcgaGVyZS4NCg0KUGhpbA0KDQpAaW5kZXBlbmRlbnRp ZA0Kd3d3LmluZGVwZW5kZW50aWQuY29tPGh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20vPg0K cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPg0KDQo= --_000_SN1PR0301MB16458A377399DFECBA108D17F51C0SN1PR0301MB1645_ 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 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxl LW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7 fQ0Kc3Bhbi5hcHBsZS1zdHlsZS1zcGFuDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLXN0eWxlLXNw YW47fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUt Y29udmVydGVkLXNwYWNlO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxl LW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNv bGFzO30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXpl OjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFy Z2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5J4oCZbSBnbGFkIHRvIGhl YXIgdGhhdCB3ZSBhZ3JlZSBvbiBrZWVwaW5nIGl0IGFzIHNpbXBsZSBhbmQgZ2VuZXJhbC1wdXJw b3NlIGFzIHBvc3NpYmxlIGFuZCB0aGF0IHlvdSBhZ3JlZSB3aXRoIG15IHdyaXRlLXVwLiZuYnNw OyBJIHRoaW5rIHdlIHRoZW4gaGF2ZSBhIGdvb2QgcGF0aA0KIGZvcndhcmQuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMw MDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5J4oCZbSBub3Qgc3VyZSB3aGF0IHlvdSBt ZWFuIGJ5IOKAnDwvc3Bhbj5J4oCZbSBub3Qgc3VyZSB0aGF0IHdlIG5lZWQgYSDigJxuYW1l4oCd LiBXaGF0IGlzIHlvdXIgaW50ZW50aW9uIHRoZXJlLjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAy MDYwIj7igJ0mbmJzcDsNCiBUaGUgb25seSBwbGFjZSBJIHVzZWQgdGhlIHdvcmQg4oCcbmFtZeKA nSB3YXMgaW4gbXkgc3RhdGVtZW50IOKAnDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAw MjA2MCI+RGVmaW5lIHRoYXQgYW4gZXZlbnQgbmFtZSBjYW4gYmUgdXNlZCBhcyBhIHRvcC1sZXZl bCBjbGFpbTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+4oCdLiZuYnNwOw0K IFdoYXQgSSB3YXMgdHJ5aW5nIHRvIGdldCBhdCBpcyB3YXMgdGhhdCBpZiDigJxodHRwOi8vc3Bl Y3Mub3BlbmlkLm5ldC9sb2dvdXTigJ0gaXMgdXNlZCBhcyBhbiBldmVudCBuYW1lLCB0aGF0IGl0 IGNhbiBhbHNvIGJlIHVzZWQgYXMgYSBjbGFpbSBuYW1lIGluIHRoZSBKV1QgY29udGFpbmluZyBp bmZvcm1hdGlvbiBhYm91dCB0aGUgZXZlbnQuJm5ic3A7IChNYXliZSBJ4oCZbSBub3QgdXNpbmcg dGhlIGNvcnJlY3QgdGVybWlub2xvZ3ksIGhlbmNlIHRoZSB1bmludGVuZGVkDQogY29uZnVzaW9u IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGlu Z3M7Y29sb3I6IzAwMjA2MCI+Sjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+ Lik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGFua3MgYWdhaW4sPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIw NjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRD b21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9hPjwvcD4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3Nl Ij48L3NwYW4+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4gUGhpbCBIdW50IFttYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb21dDQo8YnI+DQo8Yj5T ZW50OjwvYj4gVHVlc2RheSwgQXVndXN0IDksIDIwMTYgMTI6MDcgUE08YnI+DQo8Yj5Ubzo8L2I+ IE1pa2UgSm9uZXMgJmx0O01pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSZndDs8YnI+DQo8Yj5D Yzo8L2I+IGlkLWV2ZW50QGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbSWQtZXZl bnRdIFN1bW1hcml6aW5nIHJlY2VudCBkaXNjdXNzaW9ucyBvbiBJRC1FdmVudCB0b2tlbiBkcmFm dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZGlkbuKA mXQgY292ZXIgdGhpcyBhcyBJIGRpZG7igJl0IHdhbnQgdG8gY29uZnVzZSBwZW9wbGUgd2l0aCB0 b28gbWFueSB0aGluZ3MuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5CdXQgSSB0aGluayB3ZSBhZ3JlZSBvbiBhbGwgb2YgdGhlIGJlbG93LjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J4oCZbSBub3Qgc3Vy ZSB0aGF0IHdlIG5lZWQgYSDigJxuYW1l4oCdLiBXaGF0IGlzIHlvdXIgaW50ZW50aW9uIHRoZXJl LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+UGhpbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj5AaW5kZXBlbmRlbnRpZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+PGEgaHJlZj0iaHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNvbSI+d3d3LmluZGVwZW5k ZW50aWQuY29tPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij48YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iPnBoaWwuaHVudEBvcmFjbGUu Y29tPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBBdWcgOSwgMjAx NiwgYXQgMTE6NTQgQU0sIE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpv bmVzQG1pY3Jvc29mdC5jb20iPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPlRoYW5rcyBmb3Igd3JpdGluZyB0aGlzLCBQaGlsLiZu YnNwOyBVbmZvcnR1bmF0ZWx5LCB0aGUgc3VtbWFyeSBiZWxvdyBkb2VzIG5vdCBpbmNsdWRlIG15 IGZlZWRiYWNrLCB3aGljaCBhdCB0aGUgZXNzZW5jZSwgaXMgdG8ga2VlcCB0aGUgSUQgRXZlbnRz IGRhdGEgc3RydWN0dXJlIGFzDQogc2ltcGxlIGFuZCBnZW5lcmFsLXB1cnBvc2UgYXMgcG9zc2li bGUuICZuYnNwOyhJIHN0cm9uZ2x5IGJlbGlldmUgdGhhdCBKV1QgaXMgdGhlIHN1Y2Nlc3MgaXQg aXMgYmVjYXVzZSB3ZSBtYWRlIEpXVCBhcyBzaW1wbGUgYW5kIGdlbmVyYWwtcHVycG9zZSBhcyBw b3NzaWJsZSwgYW5kIHdlIHNob3VsZCBmb2xsb3cgdGhpcyBzdWNjZXNzZnVsIGV4YW1wbGUgYW5k IGRvIHRoZSBzYW1lIGhlcmUuKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+SSBiZWxpZXZlIHRoYXQgdGhlIElE IEV2ZW50cyBzcGVjIG5lZWRzIHRvIGluY2x1ZGUgdGhlc2UgdGhpbmdzLCBhbmQgdGhlc2UgdGhp bmdzIG9ubHk6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDot LjI1aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtj b2xvcjojMDAyMDYwIj7Ctzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9y OiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMwMDIwNjAiPkRlZmluZQ0KIG9mIHRoZSDigJxldmVudHPigJ0gY2xhaW08L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbiI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOiMwMDIwNjAi PsK3PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzAwMjA2MCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAw MjA2MCI+RGVmaW5lDQogdGhhdCBhbiBldmVudCBuYW1lIGNhbiBiZSB1c2VkIGFzIGEgdG9wLWxl dmVsIGNsYWltPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDot LjI1aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtj b2xvcjojMDAyMDYwIj7Ctzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9y OiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMwMDIwNjAiPlJlcXVpcmUNCiB0aGF0IOKAnGlzc+KAnSBiZSBpbmNsdWRlZCBh bmQgdGhhdCB0aGUgSldUIGJlIHNpZ25lZCBieSB0aGUgaXNzdWVyPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW4iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xvcjojMDAyMDYwIj7Ctzwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPkluY2x1ZGUN CiBhIHN0YXRlbWVudCBhbG9uZyB0aGUgbGluZXMgb2Yg4oCcVGhlIGNsYWltcyB0byBiZSBpbmNs dWRlZCB3aXRoIGFueSBwYXJ0aWN1bGFyIGV2ZW50IGFyZSB0byBiZSBkZWZpbmVkIGJ5IHRoZSBl dmVudOKAnTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+QW5kIEnigJlkIHN0b3AgdGhlcmUuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAy MDYwIj5JdCBzaG91bGQgYmUgZW50aXJlbHkgdXAgdG8gYXBwbGljYXRpb25zIHRvIHNheSB3aGF0 IGNsYWltcyBhcmUgaW5jbHVkZWQgd2l0aCBldmVudHMgdGhleSBkZWZpbmUgYW5kIHdoYXQgdGhl aXIgZm9ybWF0IGFuZCBtZWFuaW5ncyBhcmUuJm5ic3A7IFRoZW4gdGhlIElEIEV2ZW50cyBzcGVj DQogd2lsbCBiZSBhcyBnZW5lcmFsLXB1cnBvc2UgYXMgcG9zc2libGUsIHdpdGggaXQgYmVpbmcg bmF0dXJhbCBmb3IgaXQgdG8gYmUgdXNlZCBpbiBlc3NlbnRpYWxseSBhbGwgSlNPTiBFdmVudCBj b250ZXh0cy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPkFzIHNvb24gYXMgd2Ugc3RhcnQgcHV0dGluZyByZXN0 cmljdGlvbnMgb24gdGhlIHVzZSBvZiBwYXJ0aWN1bGFyIGNsYWltcyBieSBldmVudHMsIHdl4oCZ cmUgbWFraW5nIHRoZSBJRCBFdmVudHMgc3BlYyBsZXNzIGdlbmVyYWwtcHVycG9zZSBhbmQgbGVz cyBuYXR1cmFsIHRvIHVzZS4mbmJzcDsNCiBJbiBwYXJ0aWN1bGFyLCB0aGUgb25seSB0aGluZyB0 aGF0IHRoZSBzcGVjIHNob3VsZCBzYXkgYWJvdXQgdGhlIOKAnHN1YuKAnSBjbGFpbSBpcyB0aGF0 IOKAnExpa2UgYWxsIG90aGVyIGNsYWltcyBvdGhlciB0aGFuIOKAmGV2ZW50c+KAmSBhbmQg4oCY aXNz4oCZLCB3aGV0aGVyIHRoZSDigJhzdWLigJkgY2xhaW0gaXMgdG8gYmUgaW5jbHVkZWQgd2l0 aCBhbiBldmVudCBpcyBlbnRpcmVseSBldmVudC1zcGVjaWZpYy4mbmJzcDsgVGhlIGNsYWltcyB0 byBiZSBpbmNsdWRlZCB3aXRoIGFueQ0KIHBhcnRpY3VsYXIgZXZlbnQgYXJlIGV4cGxpY2l0bHkg b3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uLuKAnTwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2 MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj RTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFu Pjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPklkLWV2ZW50DQogWzxhIGhyZWY9Im1haWx0bzppZC1l dmVudC1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZzwv YT5dPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiPk9u IEJlaGFsZiBPZjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj48L2I+UGhpbCBIdW50PGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlR1ZXNkYXksIEF1Z3VzdCA5LCAyMDE2IDEwOjE5IEFN PGJyPg0KPGI+VG86PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86aWQtZXZlbnRAaWV0Zi5vcmciPmlkLWV2ZW50QGlldGYu b3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj5bSWQtZXZlbnRdIFN1bW1hcml6aW5nIHJlY2VudCBkaXNjdXNz aW9ucyBvbiBJRC1FdmVudCB0b2tlbiBkcmFmdDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhvdWdo dCBJIHdvdWxkIHVwZGF0ZSB0aGUgbGlzdCBvbiBzb21lIGRpc2N1c3Npb25zIHRoYXQgaGF2ZSBi ZWVuIGhhcHBlbmluZyBvdmVyIGluIHRoZSBPcGVuSUQgQ29ubmVjdCBhbmQgUklTQyB3b3JraW5n IGdyb3VwcyBjb25mZXJlbmNlIGNhbGxzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlc2UgZGlzY3Vz c2lvbnMgaGF2ZSBiZWVuIGFib3V0IHRoZSBjb3JlIHNwZWMgYW5kIHRoZSByb2xlIG9mIOKAnHRv cC1sZXZlbOKAnSBhdHRyaWJ1dGVzIHZzLiBldmVudCDigJxleHRlbnNpb27igJ0gYXR0cmlidXRl cy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlNlZTo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWh1bnQtaWRldmVudC10b2tlbi0wMSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWh1bnQtaWRldmVudC10b2tlbi0wMTwvc3Bhbj48 L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIHBhcnRpY3VsYXIgc2hvdWxkIOKAnHN1 YuKAnSBiZSB1c2VkIGluIHRoZSB0b3AgbGV2ZWwgdG8g4oCccG9pbnTigJ0gdG8gdGhlIHN1Ympl Y3QgKGluIHRoZSBicm9hZGVyIGVuZ2xpc2ggc2Vuc2UpIG9mIHRoZSBldmVudCwgb3Igc2hvdWxk IGl0IGJlIGNvbnN0cmFpbmVkIHRvIHRoZSBTQU1ML0lEIFRva2VuIGRlZmluaXRpb24gd2hpY2gg aXMgdGhlIGF1dGhlbnRpY2F0ZWQgdXNlci4gJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRha2VuIGluIHRoZSBuYXJyb3dlciBkZWZpbml0aW9uLCBpdCBpcyBpbXBvcnRhbnQgdG8g b2JzZXJ2ZSB0aGF0IGluIGFuIElEIFRva2VuLCDigJxzdWLigJ0gYW5kIOKAnGlzc+KAnSBnbyB0 b2dldGhlci4gJm5ic3A7VGhlIGlzc3VlciBwcm92aWRlcyB0aGUgY29udGV4dCBmb3IgdGhlIGF1 dGhlbnRpY2F0ZWQgc3ViamVjdCBpZGVudGlmaWVyLiBUaGUgcHJvYmxlbSB3aXRoIGV2ZW50cywg aXMgdGhhdCBpdCBtaWdodCBub3QgYmUgdGhlDQogQVMgKG9yIE9QKSB3aGljaCBpcyBpc3N1aW5n IHRoZSBldmVudC4gJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRvIHN1bW1hcml6 ZSBhIGZhaXIgYW1vdW50IG9mIGRpc2N1c3Npb24sIHRoZSBmZWVsaW5nIHNlZW1zIHRvIGJlIHRo ZSBmb2xsb3dpbmc6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiogJm5ic3A7VGhlIEV2ZW50 IFRva2VuIHRvcCBsZXZlbCBhdHRyaWJ1dGVzIHNob3VsZCBiZSBmYWlybHkgbGltaXRlZCBhbmQg bm90IGluY2x1ZGUgdGhlIHN1YiBhdHRyaWJ1dGUuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KiAmbmJzcDtG b3IgZXZlbnRzIHRoYXQgYXJlIGFib3V0IGEgdXNlciwgdGhlIHJlbGV2YW50IGV2ZW50IHNwZWNp ZmljYXRpb24gbWF5IGluY2x1ZGUgYSDigJxzdWLigJ0gYXR0cmlidXRlIHdpdGhpbiB0aGUgZXZl bnTigJlzIHN1Yi1vYmplY3QgYW5kIG5vdCBpbiB0aGUgdG9wLWxldmVsLiBGdXJ0aGVyIHRoYXQg c3ViLW9iamVjdCBjYW4gYWxzbyBpbmNsdWRlIHRoZSBpc3N1ZXIgb2YgdGhlIHVzZXIuICZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+KiBUaGUgdG9wLWxldmVsIOKAnGlzc+KAnSBzaGFsbCBtZWFuIHRoZSBpc3N1 ZXIgb2YgdGhlIGV2ZW50IHdoZXJlIHRoZSBzdGF0ZSBjaGFuZ2Ugb2NjdXJyZWQuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4qICZuYnNwO+KAnHN1YuKAnSBzaG91bGQgbm90IGJlIHByZXNlbnQgaW4gdGhlIHRvcCBsZXZl bCBzdHJ1Y3R1cmUuICZuYnNwO0Fsc28sIOKAnGV2ZW50c+KAnSBtdXN0IGFsc28gYmUgcHJlc2Vu dC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGVyZSB3b3VsZCBiZSBhIG5ldyBleGFtcGxl IGxvZ291dDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHls ZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj57PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5 bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+Jm5ic3A7ICZsdDvigJQgdG9wIGxldmVsIGlz IGFib3V0IHRoZSBldmVudCBpdHNlbGYgLSZndDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHls ZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj4mbmJzcDsgPHNwYW4gc3R5bGU9ImNvbG9yOiM1 RTMwRUIiPiZxdW90O2lzcyZxdW90OzogJnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9zZXJ2ZXIuZXhh bXBsZS5jb20vIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3NlcnZlci5leGFt cGxlLmNvbTwvc3Bhbj48L2E+JnF1b3Q7LDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBz dHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iY29sb3I6IzVFMzBF QiI+Jm5ic3A7ICZxdW90O2F1ZCZxdW90OzogJnF1b3Q7czZCaGRSa3F0MyZxdW90Oyw8L3NwYW4+ PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+ PHNwYW4gc3R5bGU9ImNvbG9yOiM1RTMwRUIiPiZuYnNwOyAmcXVvdDtqdGkmcXVvdDs6ICZxdW90 OzNkMGMzY2Y3OTc1ODRiZDE5M2JkMGZiMWJkNGU3ZDMwJnF1b3Q7LDwvc3Bhbj48bzpwPjwvbzpw PjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHls ZT0iY29sb3I6IzVFMzBFQiI+Jm5ic3A7ICZxdW90O2lhdCZxdW90OzogMTQ1ODY2ODE4MCw8L3Nw YW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5 cyI+PHNwYW4gc3R5bGU9ImNvbG9yOiM1RTMwRUIiPiZuYnNwOyAmcXVvdDtleHAmcXVvdDs6IDE0 NTg2Njg1ODAsPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFr LWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJjb2xvcjojNUUzMEVCIj4mbmJzcDsgJnF1b3Q7 ZXZlbnRzJnF1b3Q7OiBbPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdl LWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJjb2xvcjojNUUzMEVCIj4mbmJzcDsm bmJzcDsmbmJzcDsgJnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9zcGVjcy5vcGVuaWQubmV0L2xvZ291 dCI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly9zcGVjcy5vcGVuaWQubmV0L2xv Z291dDwvc3Bhbj48L2E+JnF1b3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxl PSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJjb2xvcjojNUUzMEVCIj4m bmJzcDsgXSw8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWst YmVmb3JlOmFsd2F5cyI+IDxzcGFuIHN0eWxlPSJjb2xvcjojRTYzQjdBIj4mbmJzcDsmcXVvdDs8 YSBocmVmPSJodHRwczovL3NwZWNzLm9wZW5pZC5uZXQvbG9nb3V0Ij48c3BhbiBzdHlsZT0iY29s b3I6cHVycGxlIj5odHRwczovL3NwZWNzLm9wZW5pZC5uZXQvbG9nb3V0PC9zcGFuPjwvYT4mcXVv dDs6IHs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVm b3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImNvbG9yOiNFNjNCN0EiPiZuYnNwOyZuYnNwOyZuYnNw OyAmbHQ7LSBUaGlzIGxldmVsIGlzIGRlZmluZWQgZW50aXJlbHkgYnkgdGhlIGV2ZW50IFVSSS0m Z3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9y ZTphbHdheXMiPjxzcGFuIHN0eWxlPSJjb2xvcjojRTYzQjdBIj4mbmJzcDsmbmJzcDsmbmJzcDsg JnF1b3Q7aXNzJnF1b3Q7OiAmcXVvdDs8YSBocmVmPSJodHRwczovL29pZGMuZXhhbXBsZS5jb20v Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL29pZGMuZXhhbXBsZS5jb208L3Nw YW4+PC9hPiZxdW90Oyw8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2Ut YnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImNvbG9yOiNFNjNCN0EiPiZuYnNwOyZu YnNwOyZuYnNwOyDigJxqdGkmcXVvdDs6ICZxdW90OzA4YTUwMTljLTE3ZTEtNDk3Ny04ZjQyLTY1 YTEyODQzZWEwMuKAnSw8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2Ut YnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6 I0U2M0I3QSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O3N1YiZxdW90OzogJnF1b3Q7MjQ4Mjg5 NzYxMDAx4oCdLDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVh ay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjojRTYz QjdBIj4mbmJzcDsmbmJzcDsmbmJzcDsg4oCcZXhw4oCdOiAmbHQ7SUQgdG9rZW4gZXhwaXJ5Jmd0 Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6 YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjojRTYzQjdBIj4mbmJz cDsgfTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZv cmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+fTwvc3Bhbj48bzpwPjwv bzpwPjwvcHJlPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkluIHRoZSBhYm92ZSBleGFtcGxlIG5vdGUgdGhhdCB0aGUg4oCcZXZlbnTigJ0gb2Jq ZWN0IGNhbiBoYXZlIGl0cyBvd24gaXNzIGFuZCBzdWJqZWN0IChzdWIgb3IganRpKSB0aGF0IGhh dmUgbWVhbmluZyB3aXRoaW4gdGhlIGNvbnRleHQgb2YgYW4gT3BlbklEIE9QIHByb3ZpZGVyLiAm bmJzcDtUaGUgaXNzdWVyIG9mIHRoZSBldmVudCBjYW4gYmUgZGlmZmVyZW50ICh0aGUgdG9wLWxl dmVsKSBhbmQgcmVwcmVzZW50cyB0aGUNCiBlbnRpdHkgdGhhdCBzaWducyB0aGUgZXZlbnQgKGlm IGl0IGlzIHNpZ25lZCkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSB0b3AtbGV2ZWwg YXR0cmlidXRlcyBpZGVudGlmeSBhbiBpbmRpdmlkdWFsIGV2ZW50IGFuZCBhcmUgdXNlZCB0byB2 YWxpZGF0ZSB0aGUgZXZlbnQgKHNpZ25pbmcgZXRjKS4gJm5ic3A7V2hlcmUgYXMgdGhlIG5lc3Rl ZCBvYmplY3QgY29udGFpbnMgYWxsIG9mIHRoZSBkYXRhIGFib3V0IHRoZSBldmVudCBhbmQgaXMg ZGVmaW5lZCBieSB0aGUgcHJvZmlsaW5nIHNwZWNpZmljYXRpb24gKGUuZy4gYSBwb3NzaWJsZQ0K IE9wZW5JRCBMb2dvdXQgRXZlbnQgc3BlYykuICZuYnNwO0luIHRoaXMgY2FzZSwgaW4gT3BlbklE LCBsb2dnaW5nIG91dCB1c3VhbGx5IHRyYW5zbGF0ZXMgaW50byByZXZva2luZyBhbiBJRCBUb2tl bi4gVGh1cyB0aGUg4oCcanRp4oCdIGZvciB0aGUgSUQgdG9rZW4gKDA4YTUwMTljLi4uODQzZWEw MikgaXMgaW5jbHVkZWQgaW4gdGhlIExvZ291dCBvYmplY3QuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlNpZGUgbm90ZS4gJm5ic3A7UmVnYXJkaW5nIOKAnGxvZ291dOKAnSwgaXQgbWlnaHQg YmUgdXNlZnVsIHRvIGluY2x1ZGUgdGhlIGV4cGlyeSBvZiB0aGUgSUQgVG9rZW4gaW4gY2FzZSB0 aGUgc3Vic2NyaWJlciBoYXMgbm90IHlldCByZWNlaXZlZCBhbiBJRCBUb2tlbi4gVGhpcyB3b3Vs ZCBsZXQgdGhlIHN1YnNjcmliZXIga25vdyBob3cgbG9uZyBpdCBuZWVkcyB0byBrZWVwIHRoZSBy ZXZvY2F0aW9uIGluZm9ybWF0aW9uIGZvci4NCiAmbmJzcDtJT1figKZhZnRlciB0aGUgdGhlIElE IFRva2VuIGlzIGV4cGlyZWQsIHRoZSBzdWJzY3JpYmVyIHdvdWxkIG5vIGxvbmdlciBuZWVkIHRv IHRyYWNrIHRoZSByZXZvY2F0aW9uIHN0YXRlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J dCBpcyBhbHNvIGdvb2QgdG8gb2JzZXJ2ZSB0aGF0IHRoZSDigJxhdWTigJ0gYXQgdGhlIHRvcCBs ZXZlbCBkZXNjcmliZXMgdGhlIHN1YnNjcmliZXIgb2YgdGhlIGV2ZW50LiAmbmJzcDtUaGlzIG1h eSBhbHNvIGJlIGRpZmZlcmVudCB0aGVuIHRoZSBvcmlnaW5hbCBhdWRpZW5jZSBvZiB0aGUgSUQg VG9rZW4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvIHRvIGNvbmNsdWRlLiBCeSBtYWtp bmcgdG9wLWxldmVsIGF0dHJpYnV0ZXMgc3RyaWN0bHkgYWJvdXQgdGhlIGV2ZW50cyBvd24gdmFs aWRhdGlvbiwgYW5kIG5lc3RlZCBvYmplY3RzIGFib3V0IHRoZSBldmVudCwgd2UgYXZvaWQgY29s bGlzaW9ucyBpbiBkZWZpbml0aW9ucyBzdWNoIGFzIHRoZSBpc3N1ZXIgb2YgdGhlIGV2ZW50LCB2 cy4gdGhlIG9yaWdpbmFsIGlzc3VlciBvZiBhIHNlY3VyaXR5IGFzc2VydGlvbi48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SSBob3BlIEnigJl2ZSBnb3R0ZW4gZXZlcnlvbmXigJlzIGZlZWRi YWNrIGNvcnJlY3QgaGVyZS4gTGV0cyBjb250aW51ZSB0byBkaXNjdXNzLiBJIHdpbGwgcmV2aXNl IHRoZSBkcmFmdCB0byBmb2xsb3cgdGhlIGdyb3VwcyB0aGlua2luZyBoZXJlLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+UGhpbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5AaW5kZXBlbmRlbnRpZDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGEgaHJlZj0iaHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNvbS8iPjxzcGFuIHN0 eWxlPSJjb2xvcjpwdXJwbGUiPnd3dy5pbmRlcGVuZGVudGlkLmNvbTwvc3Bhbj48L2E+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNv bSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cGhpbC5odW50QG9yYWNsZS5jb208L3NwYW4+ PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_SN1PR0301MB16458A377399DFECBA108D17F51C0SN1PR0301MB1645_-- From nobody Tue Aug 9 12:40:09 2016 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 C79E012B060 for ; Tue, 9 Aug 2016 12:40:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.467 X-Spam-Level: X-Spam-Status: No, score=-5.467 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=-1.247, 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 06tU8W5hskcx for ; Tue, 9 Aug 2016 12:40: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 8005012B006 for ; Tue, 9 Aug 2016 12:40:03 -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 u79Je2kd011286 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 9 Aug 2016 19:40: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 u79Je2uN014949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 9 Aug 2016 19:40:02 GMT Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u79Je1Fc009042; Tue, 9 Aug 2016 19:40:01 GMT Received: from [192.168.1.15] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 09 Aug 2016 12:40:00 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_A2CF9C3D-337C-4A6E-B1B1-2AF180E9B402" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Phil Hunt In-Reply-To: Date: Tue, 9 Aug 2016 12:39:59 -0700 Message-Id: References: <14E2EF51-7123-4E91-87DD-56AEA08202C1@oracle.com> To: Mike Jones X-Mailer: Apple Mail (2.3124) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: "id-event@ietf.org" Subject: Re: [Id-event] Summarizing recent discussions on ID-Event token draft X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 09 Aug 2016 19:40:06 -0000 --Apple-Mail=_A2CF9C3D-337C-4A6E-B1B1-2AF180E9B402 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I was referring to this in your email "Define that an event name can be used as a top-level claim=E2=80=9D Is this different from the event uri? Phil @independentid www.independentid.com = phil.hunt@oracle.com = > On Aug 9, 2016, at 12:12 PM, Mike Jones = wrote: >=20 > I=E2=80=99m glad to hear that we agree on keeping it as simple and = general-purpose as possible and that you agree with my write-up. I = think we then have a good path forward. > =20 > I=E2=80=99m not sure what you mean by =E2=80=9CI=E2=80=99m not sure = that we need a =E2=80=9Cname=E2=80=9D. What is your intention there.=E2=80= =9D The only place I used the word =E2=80=9Cname=E2=80=9D was in my = statement =E2=80=9CDefine that an event name can be used as a top-level = claim=E2=80=9D. What I was trying to get at is was that if = =E2=80=9Chttp://specs.openid.net/logout = =E2=80=9D is used as an event name, that = it can also be used as a claim name in the JWT containing information = about the event. (Maybe I=E2=80=99m not using the correct terminology, = hence the unintended confusion J.) > =20 > Thanks again, > -- Mike > =C2=A0 <> > From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 > Sent: Tuesday, August 9, 2016 12:07 PM > To: Mike Jones > Cc: id-event@ietf.org > Subject: Re: [Id-event] Summarizing recent discussions on ID-Event = token draft > =20 > I didn=E2=80=99t cover this as I didn=E2=80=99t want to confuse people = with too many things. > =20 > But I think we agree on all of the below. > =20 > I=E2=80=99m not sure that we need a =E2=80=9Cname=E2=80=9D. What is = your intention there. > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > =20 > =20 >=20 > =20 > On Aug 9, 2016, at 11:54 AM, Mike Jones > wrote: > =20 > Thanks for writing this, Phil. Unfortunately, the summary below does = not include my feedback, which at the essence, is to keep the ID Events = data structure as simple and general-purpose as possible. (I strongly = believe that JWT is the success it is because we made JWT as simple and = general-purpose as possible, and we should follow this successful = example and do the same here.) > =20 > I believe that the ID Events spec needs to include these things, and = these things only: > =C2=B7 Define of the =E2=80=9Cevents=E2=80=9D claim > =C2=B7 Define that an event name can be used as a top-level = claim > =C2=B7 Require that =E2=80=9Ciss=E2=80=9D be included and that = the JWT be signed by the issuer > =C2=B7 Include a statement along the lines of =E2=80=9CThe = claims to be included with any particular event are to be defined by the = event=E2=80=9D > =20 > And I=E2=80=99d stop there. > =20 > It should be entirely up to applications to say what claims are = included with events they define and what their format and meanings are. = Then the ID Events spec will be as general-purpose as possible, with it = being natural for it to be used in essentially all JSON Event contexts. > =20 > As soon as we start putting restrictions on the use of particular = claims by events, we=E2=80=99re making the ID Events spec less = general-purpose and less natural to use. In particular, the only thing = that the spec should say about the =E2=80=9Csub=E2=80=9D claim is that = =E2=80=9CLike all other claims other than =E2=80=98events=E2=80=99 and = =E2=80=98iss=E2=80=99, whether the =E2=80=98sub=E2=80=99 claim is to be = included with an event is entirely event-specific. The claims to be = included with any particular event are explicitly outside the scope of = this specification.=E2=80=9D > =20 > -- Mike > =20 > From: Id-event [mailto:id-event-bounces@ietf.org = ] On Behalf Of Phil Hunt > Sent: Tuesday, August 9, 2016 10:19 AM > To: id-event@ietf.org > Subject: [Id-event] Summarizing recent discussions on ID-Event token = draft > =20 > I thought I would update the list on some discussions that have been = happening over in the OpenID Connect and RISC working groups conference = calls. > =20 > These discussions have been about the core spec and the role of = =E2=80=9Ctop-level=E2=80=9D attributes vs. event =E2=80=9Cextension=E2=80=9D= attributes.=20 > See: https://tools.ietf.org/html/draft-hunt-idevent-token-01 = > =20 > In particular should =E2=80=9Csub=E2=80=9D be used in the top level to = =E2=80=9Cpoint=E2=80=9D to the subject (in the broader english sense) of = the event, or should it be constrained to the SAML/ID Token definition = which is the authenticated user. =20 > =20 > Taken in the narrower definition, it is important to observe that in = an ID Token, =E2=80=9Csub=E2=80=9D and =E2=80=9Ciss=E2=80=9D go = together. The issuer provides the context for the authenticated subject = identifier. The problem with events, is that it might not be the AS (or = OP) which is issuing the event. =20 > =20 > To summarize a fair amount of discussion, the feeling seems to be the = following: > =20 > * The Event Token top level attributes should be fairly limited and = not include the sub attribute. =20 > * For events that are about a user, the relevant event specification = may include a =E2=80=9Csub=E2=80=9D attribute within the event=E2=80=99s = sub-object and not in the top-level. Further that sub-object can also = include the issuer of the user. =20 > * The top-level =E2=80=9Ciss=E2=80=9D shall mean the issuer of the = event where the state change occurred. > * =E2=80=9Csub=E2=80=9D should not be present in the top level = structure. Also, =E2=80=9Cevents=E2=80=9D must also be present. > =20 > Here would be a new example logout: > { > <=E2=80=94 top level is about the event itself -> > "iss": "https://server.example.com ", > "aud": "s6BhdRkqt3", > "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", > "iat": 1458668180, > "exp": 1458668580, > "events": [ > "https://specs.openid.net/logout = " > ], > "https://specs.openid.net/logout ": = { > <- This level is defined entirely by the event URI-> > "iss": "https://oidc.example.com ", > =E2=80=9Cjti": "08a5019c-17e1-4977-8f42-65a12843ea02=E2=80=9D, > "sub": "248289761001=E2=80=9D, > =E2=80=9Cexp=E2=80=9D: > } > } > =20 > In the above example note that the =E2=80=9Cevent=E2=80=9D object can = have its own iss and subject (sub or jti) that have meaning within the = context of an OpenID OP provider. The issuer of the event can be = different (the top-level) and represents the entity that signs the event = (if it is signed). > =20 > The top-level attributes identify an individual event and are used to = validate the event (signing etc). Where as the nested object contains = all of the data about the event and is defined by the profiling = specification (e.g. a possible OpenID Logout Event spec). In this case, = in OpenID, logging out usually translates into revoking an ID Token. = Thus the =E2=80=9Cjti=E2=80=9D for the ID token (08a5019c...843ea02) is = included in the Logout object. > =20 > Side note. Regarding =E2=80=9Clogout=E2=80=9D, it might be useful to = include the expiry of the ID Token in case the subscriber has not yet = received an ID Token. This would let the subscriber know how long it = needs to keep the revocation information for. IOW=E2=80=A6after the the = ID Token is expired, the subscriber would no longer need to track the = revocation state. > =20 > It is also good to observe that the =E2=80=9Caud=E2=80=9D at the top = level describes the subscriber of the event. This may also be different = then the original audience of the ID Token. > =20 > So to conclude. By making top-level attributes strictly about the = events own validation, and nested objects about the event, we avoid = collisions in definitions such as the issuer of the event, vs. the = original issuer of a security assertion. > =20 > I hope I=E2=80=99ve gotten everyone=E2=80=99s feedback correct here. = Lets continue to discuss. I will revise the draft to follow the groups = thinking here. > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event = --Apple-Mail=_A2CF9C3D-337C-4A6E-B1B1-2AF180E9B402 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I was referring to this in your email
"Define that an event name can be used as a top-level = claim=E2=80=9D


Is this = different from the event uri?




On Aug 9, 2016, at 12:12 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

I=E2=80=99m glad to hear that we agree on = keeping it as simple and general-purpose as possible and that you agree = with my write-up.  I think we then have a good path forward.
 
I=E2=80= =99m not sure what you mean by =E2=80=9CI=E2=80=99m not sure that = we need a =E2=80=9Cname=E2=80=9D. What is your intention there.=E2=80=9D  The only place I used the = word =E2=80=9Cname=E2=80=9D was in my statement =E2=80=9CDefine that an event name can be used as a = top-level claim=E2=80=9D.  = What I was trying to get at is was that if =E2=80=9Chttp://specs.openid.net/logout=E2=80=9D is used as an = event name, that it can also be used as a claim name in the JWT = containing information about the event.  (Maybe I=E2=80=99m not = using the correct terminology, hence the unintended confusion J.)
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;       Thanks again,
          &nb= sp;            = ;            &= nbsp;           &nb= sp;       -- Mike
 
From: Phil Hunt [mailto:phil.hunt@oracle.com] 
Sent: Tuesday, August 9, 2016 = 12:07 PM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: id-event@ietf.org
Subject: Re: [Id-event] Summarizing = recent discussions on ID-Event token draft
 
I didn=E2=80=99t cover this as I didn=E2=80=99t want to = confuse people with too many things.
 
But I think we agree on all of the below.
 
I=E2=80=99m not sure that we need a = =E2=80=9Cname=E2=80=9D. What is your intention there.
 
Phil
 
@independentid
www.independentid.com
phil.hunt@oracle.com
 
 

 

 
On = Aug 9, 2016, at 11:54 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:
 
Thanks for writing this, Phil.  Unfortunately, the = summary below does not include my feedback, which at the essence, is to = keep the ID Events data structure as simple and general-purpose as = possible.  (I strongly believe that JWT is the success it is = because we made JWT as simple and general-purpose as possible, and we = should follow this successful example and do the same here.)
 
I believe that the ID = Events spec needs to include these things, and these things = only:
=C2=B7       Define of the =E2=80=9Cevents=E2=80=9D = claim
=C2=B7       Define that an event name can be used as a = top-level claim
=C2=B7       Require that =E2=80=9Ciss=E2=80=9D be = included and that the JWT be signed by the issuer
=C2=B7       Include a statement along the lines of = =E2=80=9CThe claims to be included with any particular event are to be = defined by the event=E2=80=9D
 
And I=E2=80=99d stop = there.
 
It should be entirely up to applications to = say what claims are included with events they define and what their = format and meanings are.  Then the ID Events spec will be as = general-purpose as possible, with it being natural for it to be used in = essentially all JSON Event contexts.
 
As soon as we start = putting restrictions on the use of particular claims by events, we=E2=80=99= re making the ID Events spec less general-purpose and less natural to = use.  In particular, the only thing that the spec should say about = the =E2=80=9Csub=E2=80=9D claim is that =E2=80=9CLike all other claims = other than =E2=80=98events=E2=80=99 and =E2=80=98iss=E2=80=99, whether = the =E2=80=98sub=E2=80=99 claim is to be included with an event is = entirely event-specific.  The claims to be included with any = particular event are explicitly outside the scope of this = specification.=E2=80=9D
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;       -- Mike
 
From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf = Of Phil Hunt
Sent: Tuesday, August 9, 2016 = 10:19 AM
To: id-event@ietf.org
Subject: [Id-event] Summarizing = recent discussions on ID-Event token draft
 
I thought I would update the list on some discussions that = have been happening over in the OpenID Connect and RISC working groups = conference calls.
 
These discussions have been about the = core spec and the role of =E2=80=9Ctop-level=E2=80=9D attributes vs. = event =E2=80=9Cextension=E2=80=9D attributes. 
See: https://tools.ietf.org/html/draft-hunt-idevent-token-01<= /a>
 
In particular should =E2=80=9Csub=E2=80=9D = be used in the top level to =E2=80=9Cpoint=E2=80=9D to the subject (in = the broader english sense) of the event, or should it be constrained to = the SAML/ID Token definition which is the authenticated user.  
 
Taken in the narrower definition, it is = important to observe that in an ID Token, =E2=80=9Csub=E2=80=9D and = =E2=80=9Ciss=E2=80=9D go together.  The issuer provides the context = for the authenticated subject identifier. The problem with events, is = that it might not be the AS (or OP) which is issuing the event. =  
 
To summarize a fair amount of discussion, = the feeling seems to be the following:
 
*  The Event Token top level = attributes should be fairly limited and not include the sub attribute. =  
*  For events = that are about a user, the relevant event specification may include a = =E2=80=9Csub=E2=80=9D attribute within the event=E2=80=99s sub-object = and not in the top-level. Further that sub-object can also include the = issuer of the user.  
* = The top-level =E2=80=9Ciss=E2=80=9D shall mean the issuer of the event = where the state change occurred.
*  =E2=80=9Csub=E2=80=9D should not = be present in the top level structure.  Also, =E2=80=9Cevents=E2=80=9D= must also be present.
Here = would be a new example logout:
{
  <=E2=80=94 top level is about the event itself =
->
  "iss": "https://server.example.com",
  =
"aud": "s6BhdRkqt3",
  "jti": =
"3d0c3cf797584bd193bd0fb1bd4e7d30",
  "iat": = 1458668180,
  "exp": 1458668580,
  =
"events": [
    "https://specs.openid.net/logout"
  =
],
  "https://specs.openid.net/logout": {
    <- This level is defined entirely by =
the event URI->
    "iss": "https://oidc.example.com",
    =E2=80=9Cjti": =
"08a5019c-17e1-4977-8f42-65a12843ea02=E2=80=9D,
    "sub": "248289761001=E2=80=9D,
    =E2=80=9Cexp=E2=80=9D: <ID token =
expiry>
  }
}
 
In the above example note that the = =E2=80=9Cevent=E2=80=9D object can have its own iss and subject (sub or = jti) that have meaning within the context of an OpenID OP provider. =  The issuer of the event can be different (the top-level) and = represents the entity that signs the event (if it is signed).
 
The top-level attributes identify an = individual event and are used to validate the event (signing etc). =  Where as the nested object contains all of the data about the = event and is defined by the profiling specification (e.g. a possible = OpenID Logout Event spec).  In this case, in OpenID, logging out = usually translates into revoking an ID Token. Thus the =E2=80=9Cjti=E2=80=9D= for the ID token (08a5019c...843ea02) is included in the Logout = object.
 
Side note.  Regarding =E2=80=9Clogout=E2= =80=9D, it might be useful to include the expiry of the ID Token in case = the subscriber has not yet received an ID Token. This would let the = subscriber know how long it needs to keep the revocation information = for.  IOW=E2=80=A6after the the ID Token is expired, the subscriber = would no longer need to track the revocation state.
 
It is also good to observe that the = =E2=80=9Caud=E2=80=9D at the top level describes the subscriber of the = event.  This may also be different then the original audience of = the ID Token.
 
So to conclude. By making top-level = attributes strictly about the events own validation, and nested objects = about the event, we avoid collisions in definitions such as the issuer = of the event, vs. the original issuer of a security assertion.
 
I hope I=E2=80=99ve gotten everyone=E2=80=99= s feedback correct here. Lets continue to discuss. I will revise the = draft to follow the groups thinking here.
 
Phil
 
@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=_A2CF9C3D-337C-4A6E-B1B1-2AF180E9B402-- From nobody Tue Aug 9 16:15:19 2016 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 0AC1712D8AD for ; Tue, 9 Aug 2016 16:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.947 X-Spam-Level: X-Spam-Status: No, score=-3.947 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=-1.247, 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 DjGldxU-AR4G for ; Tue, 9 Aug 2016 16:15:14 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c: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 BA97412D8DD for ; Tue, 9 Aug 2016 16:15:13 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id i5so66825758wmg.0 for ; Tue, 09 Aug 2016 16:15:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=o6F1ybeSBR1s1TmAVvgAJ4K4Qugf7Z3KW8/GECaom6c=; b=dQ97Nl1IaTUJrZgMwXp3mMb5egrNZHNBhsNTgdtAukYv1Zpi0NH5jKgIXFUC9QRAOw B/9VkJ8Dl3w9NcVLKJ6OJ1+EI4S54DfeJ2qhF4vekxbCKeC2+NKuD1m3D9uIZ93tL3Qp nTHPoLj28VU2j4xCHa8qgqQ+oXcKAl59EfEScJZLnEMe4EzuSuJFADeTHb7WVanPb1km Askte5OiqS/Sdw7f08n2JrNchu6SHrnXpI4td+FYHHra1g8Z5T/cVe9vdlyB4b5i98K7 bWP5cNIgZynzdK9TXZXn3AFeu0ZH7mHpbiNOCeXHI92/zl1mqZxQlbIEE93rUqirhfJt 25oQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=o6F1ybeSBR1s1TmAVvgAJ4K4Qugf7Z3KW8/GECaom6c=; b=V69CpmA//9q5uC7R0+k1DXKmqF+wzaOoKa0C+57rPSllvalrlTkTNfd6CG0O9ROWOX V5K1SJ7b1UsVKPFHSLO+6eXhgXINag5J1au4Fok7sVPT9MEXu3cF0JhaRa8LJh41kXih AzISxHmZGLt3wRPg+lByh+vVIoj3GYZnbcQtmY7+E4H8myKv5DX0aB4v+QbcINYRrA3s 56YpzLViEfgzl10WhxoGivbewWTzAIxCPA5rOXilaxWLp2ZJ01du+0ARwKU29Jmhaa91 whqc0kE/FM7hvvtH7+iUo/8RRm5Pvu0RH9Muab0dWCvGDcRptVbMFrqiU8dDfAAynTSG 2auA== X-Gm-Message-State: AEkoouumqUh2dgZxSX5ermklz3Esp3giu8+fr5udAmeWuQIjO6RO2/Y5XDadToFzrVfmuZ7t4UAUSvPfSjYD29Qm X-Received: by 10.194.142.198 with SMTP id ry6mr721783wjb.62.1470784511958; Tue, 09 Aug 2016 16:15:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.167.78 with HTTP; Tue, 9 Aug 2016 16:14:51 -0700 (PDT) In-Reply-To: References: <14E2EF51-7123-4E91-87DD-56AEA08202C1@oracle.com> From: Marius Scurtescu Date: Tue, 9 Aug 2016 16:14:51 -0700 Message-ID: To: Phil Hunt Content-Type: multipart/alternative; boundary=089e0122f43860a6140539abb469 Archived-At: Cc: Mike Jones , "id-event@ietf.org" Subject: Re: [Id-event] Summarizing recent discussions on ID-Event token draft X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 09 Aug 2016 23:15:17 -0000 --089e0122f43860a6140539abb469 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Mike, are you suggesting that a sub claim can only show up at the event level and not at the top level: In particular, the only thing that the spec should say about the =E2=80=9Cs= ub=E2=80=9D > claim is that =E2=80=9CLike all other claims other than =E2=80=98events= =E2=80=99 and =E2=80=98iss=E2=80=99, whether > the =E2=80=98sub=E2=80=99 claim is to be included with an event is entire= ly event-specific. A top level sub and multiple events are incompatible IMO. Do we have a compelling reason to support multiple events per message? Marius On Tue, Aug 9, 2016 at 12:39 PM, Phil Hunt wrote: > I was referring to this in your email > "Define that an event name can be used as a top-level claim=E2=80=9D > > > Is this different from the event uri? > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > On Aug 9, 2016, at 12:12 PM, Mike Jones > wrote: > > I=E2=80=99m glad to hear that we agree on keeping it as simple and genera= l-purpose > as possible and that you agree with my write-up. I think we then have a > good path forward. > > I=E2=80=99m not sure what you mean by =E2=80=9CI=E2=80=99m not sure that = we need a =E2=80=9Cname=E2=80=9D. What > is your intention there.=E2=80=9D The only place I used the word =E2=80= =9Cname=E2=80=9D was in > my statement =E2=80=9CDefine that an event name can be used as a top-leve= l claim=E2=80=9D. > What I was trying to get at is was that if =E2=80=9Chttp://specs.openid.n= et/logout=E2=80=9D > is used as an event name, that it can also be used as a claim name in the > JWT containing information about the event. (Maybe I=E2=80=99m not using= the > correct terminology, hence the unintended confusion J.) > > Thanks again, > -- Mike > > *From:* Phil Hunt [mailto:phil.hunt@oracle.com ] > *Sent:* Tuesday, August 9, 2016 12:07 PM > *To:* Mike Jones > *Cc:* id-event@ietf.org > *Subject:* Re: [Id-event] Summarizing recent discussions on ID-Event > token draft > > I didn=E2=80=99t cover this as I didn=E2=80=99t want to confuse people wi= th too many > things. > > But I think we agree on all of the below. > > I=E2=80=99m not sure that we need a =E2=80=9Cname=E2=80=9D. What is your = intention there. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > > On Aug 9, 2016, at 11:54 AM, Mike Jones > wrote: > > Thanks for writing this, Phil. Unfortunately, the summary below does not > include my feedback, which at the essence, is to keep the ID Events data > structure as simple and general-purpose as possible. (I strongly believe > that JWT is the success it is because we made JWT as simple and > general-purpose as possible, and we should follow this successful example > and do the same here.) > > I believe that the ID Events spec needs to include these things, and thes= e > things only: > =C2=B7 Define of the =E2=80=9Cevents=E2=80=9D claim > =C2=B7 Define that an event name can be used as a top-level claim > =C2=B7 Require that =E2=80=9Ciss=E2=80=9D be included and that the = JWT be signed by the > issuer > =C2=B7 Include a statement along the lines of =E2=80=9CThe claims t= o be included > with any particular event are to be defined by the event=E2=80=9D > > And I=E2=80=99d stop there. > > It should be entirely up to applications to say what claims are included > with events they define and what their format and meanings are. Then the > ID Events spec will be as general-purpose as possible, with it being > natural for it to be used in essentially all JSON Event contexts. > > As soon as we start putting restrictions on the use of particular claims > by events, we=E2=80=99re making the ID Events spec less general-purpose a= nd less > natural to use. In particular, the only thing that the spec should say > about the =E2=80=9Csub=E2=80=9D claim is that =E2=80=9CLike all other cla= ims other than =E2=80=98events=E2=80=99 > and =E2=80=98iss=E2=80=99, whether the =E2=80=98sub=E2=80=99 claim is to = be included with an event is > entirely event-specific. The claims to be included with any particular > event are explicitly outside the scope of this specification.=E2=80=9D > > -- Mike > > *From:* Id-event [mailto:id-event-bounces@ietf.org > ] *On Behalf Of *Phil Hunt > *Sent:* Tuesday, August 9, 2016 10:19 AM > *To:* id-event@ietf.org > *Subject:* [Id-event] Summarizing recent discussions on ID-Event token > draft > > I thought I would update the list on some discussions that have been > happening over in the OpenID Connect and RISC working groups conference > calls. > > These discussions have been about the core spec and the role of > =E2=80=9Ctop-level=E2=80=9D attributes vs. event =E2=80=9Cextension=E2=80= =9D attributes. > See: https://tools.ietf.org/html/draft-hunt-idevent-token-01 > > In particular should =E2=80=9Csub=E2=80=9D be used in the top level to = =E2=80=9Cpoint=E2=80=9D to the > subject (in the broader english sense) of the event, or should it be > constrained to the SAML/ID Token definition which is the authenticated > user. > > Taken in the narrower definition, it is important to observe that in an I= D > Token, =E2=80=9Csub=E2=80=9D and =E2=80=9Ciss=E2=80=9D go together. The = issuer provides the context for > the authenticated subject identifier. The problem with events, is that it > might not be the AS (or OP) which is issuing the event. > > To summarize a fair amount of discussion, the feeling seems to be the > following: > > * The Event Token top level attributes should be fairly limited and not > include the sub attribute. > * For events that are about a user, the relevant event specification may > include a =E2=80=9Csub=E2=80=9D attribute within the event=E2=80=99s sub-= object and not in the > top-level. Further that sub-object can also include the issuer of the use= r. > > * The top-level =E2=80=9Ciss=E2=80=9D shall mean the issuer of the event = where the state > change occurred. > * =E2=80=9Csub=E2=80=9D should not be present in the top level structure= . Also, =E2=80=9Cevents=E2=80=9D > must also be present. > > Here would be a new example logout: > > { > > <=E2=80=94 top level is about the event itself -> > > "iss": "https://server.example.com", > > "aud": "s6BhdRkqt3", > > "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", > > "iat": 1458668180, > > "exp": 1458668580, > > "events": [ > > "https://specs.openid.net/logout" > > ], > > "https://specs.openid.net/logout": { > > <- This level is defined entirely by the event URI-> > > "iss": "https://oidc.example.com", > > =E2=80=9Cjti": "08a5019c-17e1-4977-8f42-65a12843ea02=E2=80=9D, > > "sub": "248289761001=E2=80=9D, > > =E2=80=9Cexp=E2=80=9D: > > } > > } > > > In the above example note that the =E2=80=9Cevent=E2=80=9D object can hav= e its own iss and > subject (sub or jti) that have meaning within the context of an OpenID OP > provider. The issuer of the event can be different (the top-level) and > represents the entity that signs the event (if it is signed). > > The top-level attributes identify an individual event and are used to > validate the event (signing etc). Where as the nested object contains al= l > of the data about the event and is defined by the profiling specification > (e.g. a possible OpenID Logout Event spec). In this case, in OpenID, > logging out usually translates into revoking an ID Token. Thus the =E2=80= =9Cjti=E2=80=9D > for the ID token (08a5019c...843ea02) is included in the Logout object. > > Side note. Regarding =E2=80=9Clogout=E2=80=9D, it might be useful to inc= lude the expiry > of the ID Token in case the subscriber has not yet received an ID Token. > This would let the subscriber know how long it needs to keep the revocati= on > information for. IOW=E2=80=A6after the the ID Token is expired, the subs= criber > would no longer need to track the revocation state. > > It is also good to observe that the =E2=80=9Caud=E2=80=9D at the top leve= l describes the > subscriber of the event. This may also be different then the original > audience of the ID Token. > > So to conclude. By making top-level attributes strictly about the events > own validation, and nested objects about the event, we avoid collisions i= n > definitions such as the issuer of the event, vs. the original issuer of a > security assertion. > > I hope I=E2=80=99ve gotten everyone=E2=80=99s feedback correct here. Lets= continue to > discuss. I will revise the draft to follow the groups thinking here. > > Phil > > @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 > > --089e0122f43860a6140539abb469 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Mike, are you suggesting that a sub claim can only show up= at the event level and not at the top level:

In particular, the only thing that the s= pec should say about the =E2=80=9Csub=E2=80=9D claim is that =E2=80=9CLike = all other claims other than =E2=80=98events=E2=80=99 and =E2=80=98iss=E2=80= =99, whether the =E2=80=98sub=E2=80=99 claim is to be included with an even= t is entirely event-specific.

A top level s= ub and multiple events are incompatible IMO.

Do we= have a compelling reason to support multiple events per message?


Marius

On Tue, Aug 9, 2016 at 12:39 PM, Phil Hunt <= span dir=3D"ltr"><phil.hunt@oracle.com> wrote:
I was referring to this in your e= mail
"Define that an event name can be used as a top-level c= laim=E2=80=9D


Is this different from the event uri?<= /div>




On Aug 9, 2016, at 12:12 PM, Mike J= ones <M= ichael.Jones@microsoft.com> wrote:

I=E2=80=99m glad to hear that we agree on keeping it as simple= and general-purpose as possible and that you agree with my write-up.=C2=A0= I think we then have a good path forward.
=C2=A0
I=E2=80=99m not sure what you mean by =E2=80=9CI=E2=80=99m= not sure that we need a =E2=80=9Cname=E2=80=9D. What is your intention the= re.=E2=80=9D=C2=A0 The only place I used the word =E2=80=9Cname=E2=80= =9D was in my statement =E2=80=9CDefine that an event name can= be used as a top-level claim=E2=80=9D.=C2=A0 What I was tryin= g to get at is was that if =E2=80=9Chttp= ://specs.openid.net/logout=E2=80=9D is used as an event name, that= it can also be used as a claim name in the JWT containing information abou= t the event.=C2=A0 (Maybe I=E2=80=99m not using the correct terminology, he= nce the unintended confusion=C2=A0J.)
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Thanks again,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =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
<= span>
F= rom:=C2=A0= Phil Hunt [mailto= :phil.hunt@oracle.com]=C2=A0
Sent:=C2=A0Tuesday, August 9, 2016 12:07 PM
<= b>To:=C2=A0= Mike Jones <Michael.Jones@microsoft.com>
Cc:=C2=A0id-event@ietf.org
Subject:= =C2=A0Re: [Id-event] Summarizing recent discussions on ID-Event token draft<= /u>
=C2=A0
I didn=E2=80=99t cov= er this as I didn=E2=80=99t want to confuse people with too many things.=
=C2=A0
But I think we agree on all of the below.<= /u>
=C2=A0
I=E2=80=99m not sure that we need a =E2= =80=9Cname=E2=80=9D. What is your intention there.
=C2=A0
=
Phil<= /div>
=C2=A0
@independentid
=C2=A0
=C2=A0

=C2=A0

=C2= =A0
On Aug 9, 2016, at 11:54 AM, Mike Jones <Michael.Jones@microsoft.com> wr= ote:
=C2=A0
Thanks for writing this, Phil.= =C2=A0 Unfortunately, the summary below does not include my feedback, which= at the essence, is to keep the ID Events data structure as simple and gene= ral-purpose as possible. =C2=A0(I strongly believe that JWT is the success = it is because we made JWT as simple and general-purpose as possible, and we= should follow this successful example and do the same here.)=
=C2=A0
I believe that the ID Ev= ents spec needs to include these things, and these things only:
=C2= =B7=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0Define of the =E2=80=9Cevents=E2=80=9D clai= m
=C2=B7=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Define that an event name can b= e used as a top-level claim
=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Requi= re that =E2=80=9Ciss=E2=80=9D be included and that the JWT be signed by the= issuer
=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Include a statement along = the lines of =E2=80=9CThe claims to be included with any particular event a= re to be defined by the event=E2=80=9D
=C2=A0
<= div style=3D"margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times = New Roman',serif">And I=E2=80=99d stop there.
=C2=A0<= /div>
It should be entirely up to ap= plications to say what claims are included with events they define and what= their format and meanings are.=C2=A0 Then the ID Events spec will be as ge= neral-purpose as possible, with it being natural for it to be used in essen= tially all JSON Event contexts.
=C2=A0
As soon as we start putting restrictions on the use of= particular claims by events, we=E2=80=99re making the ID Events spec less = general-purpose and less natural to use.=C2=A0 In particular, the only thin= g that the spec should say about the =E2=80=9Csub=E2=80=9D claim is that = =E2=80=9CLike all other claims other than =E2=80=98events=E2=80=99 and =E2= =80=98iss=E2=80=99, whether the =E2=80=98sub=E2=80=99 claim is to be includ= ed with an event is entirely event-specific.=C2=A0 The claims to be include= d with any particular event are explicitly outside the scope of this specif= ication.=E2=80=9D
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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
<= /div>
=C2=A0
From:= =C2=A0Id-event [= mailto:id-event-bounces@ietf.org<= /a>]=C2=A0On Behalf Of=C2=A0Phil Hunt
Sent:=C2=A0Tuesday, August 9, 2016 10:19 AM<= br>To:= =C2=A0id-event@ietf.org
Subje= ct:=C2=A0[Id-event] Summarizing recent discussions on ID-Event token draft
=C2=A0<= u>
I thought I would upda= te the list on some discussions that have been happening over in the OpenID= Connect and RISC working groups conference calls.
=C2=A0
These discussions have been about the core sp= ec and the role of =E2=80=9Ctop-level=E2=80=9D attributes vs. event =E2=80= =9Cextension=E2=80=9D attributes.=C2=A0
=C2=A0
<= div>
In particular should =E2=80=9Csub=E2=80=9D = be used in the top level to =E2=80=9Cpoint=E2=80=9D to the subject (in the = broader english sense) of the event, or should it be constrained to the SAM= L/ID Token definition which is the authenticated user. =C2=A0=
=C2=A0
Taken in the narrower defini= tion, it is important to observe that in an ID Token, =E2=80=9Csub=E2=80=9D= and =E2=80=9Ciss=E2=80=9D go together.=C2=A0 The issuer provides the conte= xt for the authenticated subject identifier. The problem with events, is th= at it might not be the AS (or OP) which is issuing the event. =C2=A0=
=C2=A0<= /u>
To summarize a fair a= mount of discussion, the feeling seems to be the following:
=C2=A0
=
* =C2=A0The Event Token top le= vel attributes should be fairly limited and not include the sub attribute. = =C2=A0
* = =C2=A0For events that are about a user, the relevant event specification ma= y include a =E2=80=9Csub=E2=80=9D attribute within the event=E2=80=99s sub-= object and not in the top-level. Further that sub-object can also include t= he issuer of the user. =C2=A0
* The top-level =E2=80=9Ciss=E2=80=9D shall mean the iss= uer of the event where the state change occurred.
=
* =C2=A0=E2=80=9Csub=E2=80=9D should= not be present in the top level structure.=C2=A0 Also, =E2=80=9Cevents=E2= =80=9D must also be present.
=C2=A0
Here would be a new example logout:
= 
{
=C2=A0 <=E2=80=
=94 top level is about the event itself ->
=C2=A0 "iss": "https://server.exam=
ple.com",
=C2=A0 "aud": "s6BhdRkqt3",<=
/span>
=C2=A0 "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30&q=
uot;,
=C2=A0 "iat": 1458668180,
=C2=A0 "exp": 1458668=
580,
=C2=A0 "events": [
<=
span style=3D"color:rgb(94,48,235)">=C2=A0=C2=A0=C2=A0 "https://specs.openid.net=
/logout"
=C2=A0 ],
 =C2=A0"https://specs.openid.net/logout": {
=C2=A0=C2=A0=C2=A0 <- This level is define=
d entirely by the event URI->
=C2=A0=C2=A0=C2=A0 "iss": &quo=
t;https://oidc.e=
xample.com",
=C2=A0=C2=A0=C2=A0 =E2=80=9Cjti": "=
;08a5019c-17e1-4977-8f42-65a12843ea02=E2=80=9D,
=C2=
=A0=C2=A0=C2=A0 "sub": "248289761001=E2=80=9D,=

=C2=A0=C2=A0=C2=A0 =E2=80=9Cexp=E2=80=9D: <ID token expiry>
=C2=A0 }
}
In=
 the above example note that the =E2=80=9Cevent=E2=80=9D object can have it=
s own iss and subject (sub or jti) that have meaning within the context of =
an OpenID OP provider.=C2=A0 The issuer of the event can be different (the =
top-level) and represents the entity that signs the event (if it is signed)=
.
=C2=A0=

The top-level=
 attributes identify an individual event and are used to validate the event=
 (signing etc).=C2=A0 Where as the nested object contains all of the data a=
bout the event and is defined by the profiling specification (e.g. a possib=
le OpenID Logout Event spec).=C2=A0 In this case, in OpenID, logging out us=
ually translates into revoking an ID Token. Thus the =E2=80=9Cjti=E2=80=9D =
for the ID token (08a5019c...843ea02) is included in the Logout object.<=
/u>
=C2=A0<=
u>
Side note.=C2=A0 R=
egarding =E2=80=9Clogout=E2=80=9D, it might be useful to include the expiry=
 of the ID Token in case the subscriber has not yet received an ID Token. T=
his would let the subscriber know how long it needs to keep the revocation =
information for.=C2=A0 IOW=E2=80=A6after the the ID Token is expired, the s=
ubscriber would no longer need to track the revocation state.=

=C2=A0
It is also good to observe t=
hat the =E2=80=9Caud=E2=80=9D at the top level describes the subscriber of =
the event.=C2=A0 This may also be different then the original audience of t=
he ID Token.
So=
 to conclude. By making top-level attributes strictly about the events own =
validation, and nested objects about the event, we avoid collisions in defi=
nitions such as the issuer of the event, vs. the original issuer of a secur=
ity assertion.
=C2=A0
=
I hope I=E2=80=99ve gotten everyone=E2=80=99s feedback correct here. Lets c=
ontinue to discuss. I will revise the draft to follow the groups thinking h=
ere.
=C2=A0=
=C2=A0
_______________________________________________
Id-event mailing list<= br style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-wei= ght:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-tran= sform:none;white-space:normal;word-spacing:0px">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


--089e0122f43860a6140539abb469-- From nobody Tue Aug 9 16:26:09 2016 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 A6A4012D8E3 for ; Tue, 9 Aug 2016 16:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.466 X-Spam-Level: X-Spam-Status: No, score=-5.466 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=-1.247, 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 FKvY_DXOuYyB for ; Tue, 9 Aug 2016 16:26:05 -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 D9E7812D892 for ; Tue, 9 Aug 2016 16:26:04 -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 u79NQ2BA013343 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 9 Aug 2016 23:26:02 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u79NQ2vW009184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 9 Aug 2016 23:26:02 GMT Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u79NPuX3018583; Tue, 9 Aug 2016 23:26:01 GMT Received: from [25.188.164.164] (/24.114.22.128) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 09 Aug 2016 16:25:56 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-E9713696-8EEC-4AF3-BD14-1F335CE88893 Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (13G34) In-Reply-To: Date: Tue, 9 Aug 2016 16:25:51 -0700 Content-Transfer-Encoding: 7bit Message-Id: <433C6F49-EA72-463F-A8F6-8FAEBF8631DF@oracle.com> References: <14E2EF51-7123-4E91-87DD-56AEA08202C1@oracle.com> To: Marius Scurtescu X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: Mike Jones , "id-event@ietf.org" Subject: Re: [Id-event] Summarizing recent discussions on ID-Event token draft X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 09 Aug 2016 23:26:09 -0000 --Apple-Mail-E9713696-8EEC-4AF3-BD14-1F335CE88893 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Probably not. There is a reason to say that multiple related events could be= in the same message.=20 For example a scim acnt reset and a risc reset.=20 Thought it doesn't have to be that way.=20 More likely adding extensions might be important later on. Eg to provide cla= ssification or proprietary signaling needs.=20 Phil > On Aug 9, 2016, at 4:14 PM, Marius Scurtescu wrote= : >=20 > Mike, are you suggesting that a sub claim can only show up at the event le= vel and not at the top level: >=20 >> In particular, the only thing that the spec should say about the =E2=80=9C= sub=E2=80=9D claim is that =E2=80=9CLike all other claims other than =E2=80=98= events=E2=80=99 and =E2=80=98iss=E2=80=99, whether the =E2=80=98sub=E2=80=99= claim is to be included with an event is entirely event-specific. >=20 > A top level sub and multiple events are incompatible IMO. >=20 > Do we have a compelling reason to support multiple events per message? >=20 >=20 > Marius >=20 >> On Tue, Aug 9, 2016 at 12:39 PM, Phil Hunt wrote: >> I was referring to this in your email >> "Define that an event name can be used as a top-level claim=E2=80=9D >>=20 >>=20 >> Is this different from the event uri? >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >>=20 >>> On Aug 9, 2016, at 12:12 PM, Mike Jones wr= ote: >>>=20 >>> I=E2=80=99m glad to hear that we agree on keeping it as simple and gener= al-purpose as possible and that you agree with my write-up. I think we then= have a good path forward. >>> =20 >>> I=E2=80=99m not sure what you mean by =E2=80=9CI=E2=80=99m not sure that= we need a =E2=80=9Cname=E2=80=9D. What is your intention there.=E2=80=9D T= he only place I used the word =E2=80=9Cname=E2=80=9D was in my statement =E2= =80=9CDefine that an event name can be used as a top-level claim=E2=80=9D. W= hat I was trying to get at is was that if =E2=80=9Chttp://specs.openid.net/l= ogout=E2=80=9D is used as an event name, that it can also be used as a claim= name in the JWT containing information about the event. (Maybe I=E2=80=99m= not using the correct terminology, hence the unintended confusion J.) >>> =20 >>> Thanks again, >>> -- Mike >>> =20 >>> From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 >>> Sent: Tuesday, August 9, 2016 12:07 PM >>> To: Mike Jones >>> Cc: id-event@ietf.org >>> Subject: Re: [Id-event] Summarizing recent discussions on ID-Event token= draft >>> =20 >>> I didn=E2=80=99t cover this as I didn=E2=80=99t want to confuse people w= ith too many things. >>> =20 >>> But I think we agree on all of the below. >>> =20 >>> I=E2=80=99m not sure that we need a =E2=80=9Cname=E2=80=9D. What is your= intention there. >>> =20 >>> Phil >>> =20 >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>> =20 >>> =20 >>> =20 >>>=20 >>> =20 >>> On Aug 9, 2016, at 11:54 AM, Mike Jones wr= ote: >>> =20 >>> Thanks for writing this, Phil. Unfortunately, the summary below does no= t include my feedback, which at the essence, is to keep the ID Events data s= tructure as simple and general-purpose as possible. (I strongly believe tha= t JWT is the success it is because we made JWT as simple and general-purpose= as possible, and we should follow this successful example and do the same h= ere.) >>> =20 >>> I believe that the ID Events spec needs to include these things, and the= se things only: >>> =C2=B7 Define of the =E2=80=9Cevents=E2=80=9D claim >>> =C2=B7 Define that an event name can be used as a top-level claim >>> =C2=B7 Require that =E2=80=9Ciss=E2=80=9D be included and that the= JWT be signed by the issuer >>> =C2=B7 Include a statement along the lines of =E2=80=9CThe claims t= o be included with any particular event are to be defined by the event=E2=80= =9D >>> =20 >>> And I=E2=80=99d stop there. >>> =20 >>> It should be entirely up to applications to say what claims are included= with events they define and what their format and meanings are. Then the I= D Events spec will be as general-purpose as possible, with it being natural f= or it to be used in essentially all JSON Event contexts. >>> =20 >>> As soon as we start putting restrictions on the use of particular claims= by events, we=E2=80=99re making the ID Events spec less general-purpose and= less natural to use. In particular, the only thing that the spec should sa= y about the =E2=80=9Csub=E2=80=9D claim is that =E2=80=9CLike all other clai= ms other than =E2=80=98events=E2=80=99 and =E2=80=98iss=E2=80=99, whether th= e =E2=80=98sub=E2=80=99 claim is to be included with an event is entirely ev= ent-specific. The claims to be included with any particular event are expli= citly outside the scope of this specification.=E2=80=9D >>> =20 >>> -- Mike >>> =20 >>> From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Phil Hunt= >>> Sent: Tuesday, August 9, 2016 10:19 AM >>> To: id-event@ietf.org >>> Subject: [Id-event] Summarizing recent discussions on ID-Event token dra= ft >>> =20 >>> I thought I would update the list on some discussions that have been hap= pening over in the OpenID Connect and RISC working groups conference calls. >>> =20 >>> These discussions have been about the core spec and the role of =E2=80=9C= top-level=E2=80=9D attributes vs. event =E2=80=9Cextension=E2=80=9D attribut= es.=20 >>> See: https://tools.ietf.org/html/draft-hunt-idevent-token-01 >>> =20 >>> In particular should =E2=80=9Csub=E2=80=9D be used in the top level to =E2= =80=9Cpoint=E2=80=9D to the subject (in the broader english sense) of the ev= ent, or should it be constrained to the SAML/ID Token definition which is th= e authenticated user. =20 >>> =20 >>> Taken in the narrower definition, it is important to observe that in an I= D Token, =E2=80=9Csub=E2=80=9D and =E2=80=9Ciss=E2=80=9D go together. The i= ssuer provides the context for the authenticated subject identifier. The pro= blem with events, is that it might not be the AS (or OP) which is issuing th= e event. =20 >>> =20 >>> To summarize a fair amount of discussion, the feeling seems to be the fo= llowing: >>> =20 >>> * The Event Token top level attributes should be fairly limited and not= include the sub attribute. =20 >>> * For events that are about a user, the relevant event specification ma= y include a =E2=80=9Csub=E2=80=9D attribute within the event=E2=80=99s sub-o= bject and not in the top-level. Further that sub-object can also include the= issuer of the user. =20 >>> * The top-level =E2=80=9Ciss=E2=80=9D shall mean the issuer of the event= where the state change occurred. >>> * =E2=80=9Csub=E2=80=9D should not be present in the top level structur= e. Also, =E2=80=9Cevents=E2=80=9D must also be present. >>> =20 >>> Here would be a new example logout: >>> { >>> <=E2=80=94 top level is about the event itself -> >>> "iss": "https://server.example.com", >>> "aud": "s6BhdRkqt3", >>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>> "iat": 1458668180, >>> "exp": 1458668580, >>> "events": [ >>> "https://specs.openid.net/logout" >>> ], >>> "https://specs.openid.net/logout": { >>> <- This level is defined entirely by the event URI-> >>> "iss": "https://oidc.example.com", >>> =E2=80=9Cjti": "08a5019c-17e1-4977-8f42-65a12843ea02=E2=80=9D, >>> "sub": "248289761001=E2=80=9D, >>> =E2=80=9Cexp=E2=80=9D: >>> } >>> } >>> =20 >>> In the above example note that the =E2=80=9Cevent=E2=80=9D object can ha= ve its own iss and subject (sub or jti) that have meaning within the context= of an OpenID OP provider. The issuer of the event can be different (the to= p-level) and represents the entity that signs the event (if it is signed). >>> =20 >>> The top-level attributes identify an individual event and are used to va= lidate the event (signing etc). Where as the nested object contains all of t= he data about the event and is defined by the profiling specification (e.g. a= possible OpenID Logout Event spec). In this case, in OpenID, logging out u= sually translates into revoking an ID Token. Thus the =E2=80=9Cjti=E2=80=9D f= or the ID token (08a5019c...843ea02) is included in the Logout object. >>> =20 >>> Side note. Regarding =E2=80=9Clogout=E2=80=9D, it might be useful to in= clude the expiry of the ID Token in case the subscriber has not yet received= an ID Token. This would let the subscriber know how long it needs to keep t= he revocation information for. IOW=E2=80=A6after the the ID Token is expire= d, the subscriber would no longer need to track the revocation state. >>> =20 >>> It is also good to observe that the =E2=80=9Caud=E2=80=9D at the top lev= el describes the subscriber of the event. This may also be different then t= he original audience of the ID Token. >>> =20 >>> So to conclude. By making top-level attributes strictly about the events= own validation, and nested objects about the event, we avoid collisions in d= efinitions such as the issuer of the event, vs. the original issuer of a sec= urity assertion. >>> =20 >>> I hope I=E2=80=99ve gotten everyone=E2=80=99s feedback correct here. Let= s continue to discuss. I will revise the draft to follow the groups thinking= here. >>> =20 >>> Phil >>> =20 >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>> =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://www.ietf.org/mailman/listinfo/id-event --Apple-Mail-E9713696-8EEC-4AF3-BD14-1F335CE88893 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Probably not. There is a reason to say= that multiple related events could be in the same message. 

For exampl= e a scim acnt reset and a risc reset. 

Thought it doesn't have to be t= hat way. 

More likely adding extensions might be important later on. E= g to provide classification or proprietary signaling needs. 

Phi= l

On Aug 9, 2016, at 4:14 PM, Marius Scurtescu <mscurtescu@google.com> wrote:

Mike, are you suggesting= that a sub claim can only show up at the event level and not at the top lev= el:

In particu= lar, the only thing that the spec should say about the =E2=80=9Csub=E2=80=9D= claim is that =E2=80=9CLike all other claims other than =E2=80=98events=E2=80= =99 and =E2=80=98iss=E2=80=99, whether the =E2=80=98sub=E2=80=99 claim is to= be included with an event is entirely event-specific.

=
A top level sub and multiple events are incompatible IMO.

Do we have a compelling reason to support multiple events p= er message?


Marius

On Tue, Aug 9, 2016 at 12:39 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
I was referring to this in your email<= div>"Define that an event name can be used as a top-level claim<= font color=3D"#002060" face=3D"Calibri, sans-serif">=E2=80=9D


Is this different from the event uri?



I=E2= =80=99m glad to hear that we agree on keeping it as simple and general-purpo= se as possible and that you agree with my write-up.  I think we then ha= ve a good path forward.
&n= bsp;
I=E2=80=99m not sure what you mea= n by =E2=80=9CI=E2=80=99m not sure that we need a =E2=80=9Cname=E2=80= =9D. What is your intention there.=E2=80=9D  The only place I used= the word =E2=80=9Cname=E2=80=9D was in my statement =E2=80=9CDe= fine that an event name can be used as a top-level claim=E2=80=9D= .  What I was trying to get at is was that if =E2=80=9Chttp://specs.openid.net/logout=E2=80=9D is used as= an event name, that it can also be used as a claim name in the JWT containi= ng information about the event.  (Maybe I=E2=80=99m not using the corre= ct terminology, hence the unintended confusion J.)<= /span>
 
           &nbs= p;            &n= bsp;           &= nbsp;            = ;      Thanks again,
          &= nbsp;            = ;           &nbs= p;            &n= bsp;       -- Mike
<= div style=3D"margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New R= oman',serif">&n= bsp;
From: Phil Hunt [mailto:phil.hunt@oracle.com] 
Sent: Tuesday, August 9, 2016 12= :07 PM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: id-event@ietf.org
Sub= ject: <= /span>Re: [Id-event] Summarizing recent discussions on ID-Event token draft<= u>
<= u> 
I didn=E2=80=99t cover this as I didn= =E2=80=99t want to confuse people with too many things.
<= div>
 
But I th= ink we agree on all of the below.
 
I=E2=80=99m not sure tha= t we need a =E2=80=9Cname=E2=80=9D. What is your intention there.<= /u>
 
<= div>
Phil
<= /div>
 
@independentid
 
 

 

 
On Aug 9, 2016, at 11:54 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:
 
Thanks fo= r writing this, Phil.  Unfortunately, the summary below does not includ= e my feedback, which at the essence, is to keep the ID Events data structure= as simple and general-purpose as possible.  (I strongly believe that J= WT is the success it is because we made JWT as simple and general-purpose as= possible, and we should follow this successful example and do the same here= .)
 <= /u>
I believe that the ID Events s= pec needs to include these things, and these things only:
=C2=B7      <= span class=3D"m_-6534435573639673786apple-converted-space"> Define of the =E2=80=9Cevents=E2=80=9D claim
=C2=B7       <= span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(0,32,9= 6)">Define that an event name can be used as a top-level claim=
=C2=B7     &= nbsp; Require that =E2=80=9Ciss=E2=80=9D be included and that the JW= T be signed by the issuer
=C2=B7       Include a statement alo= ng the lines of =E2=80=9CThe claims to be included with any particular event= are to be defined by the event=E2=80=9D
 
And I=E2=80=99d stop there.
 
= It should be entirely up to applications to say what claims are included wit= h events they define and what their format and meanings are.  Then the I= D Events spec will be as general-purpose as possible, with it being natural f= or it to be used in essentially all JSON Event contexts.
 
=
As soon as we start putting restrictions on the use o= f particular claims by events, we=E2=80=99re making the ID Events spec less g= eneral-purpose and less natural to use.  In particular, the only thing t= hat the spec should say about the =E2=80=9Csub=E2=80=9D claim is that =E2=80= =9CLike all other claims other than =E2=80=98events=E2=80=99 and =E2=80=98is= s=E2=80=99, whether the =E2=80=98sub=E2=80=99 claim is to be included with a= n event is entirely event-specific.  The claims to be included with any= particular event are explicitly outside the scope of this specification.=E2= =80=9D
 =
    &n= bsp;            =             &nbs= p;           &nb= sp;             -= - Mike
 =
From: Id= -event [mailto:id-event-bounces@ietf.org] = On Behalf Of Phil Hunt
Sent: Tuesday, August 9, 2016 10:19 A= M
To:&= nbsp;id-event@ietf.org
Subject:=  [Id-event] Summarizing recent discussions on ID-Event token draft=
 
I thought I would update the list on some discu= ssions that have been happening over in the OpenID Connect and RISC working g= roups conference calls.
&nb= sp;
These discussions= have been about the core spec and the role of =E2=80=9Ctop-level=E2=80=9D a= ttributes vs. event =E2=80=9Cextension=E2=80=9D attributes. <= /u>
 
=
In particular should =E2=80=9Csub=E2=80=9D be used i= n the top level to =E2=80=9Cpoint=E2=80=9D to the subject (in the broader en= glish sense) of the event, or should it be constrained to the SAML/ID Token d= efinition which is the authenticated user.  
<= /div>
 
Taken in the narrower definition, it is important to observe t= hat in an ID Token, =E2=80=9Csub=E2=80=9D and =E2=80=9Ciss=E2=80=9D go toget= her.  The issuer provides the context for the authenticated subject ide= ntifier. The problem with events, is that it might not be the AS (or OP) whi= ch is issuing the event.  
 
To s= ummarize a fair amount of discussion, the feeling seems to be the following:=
 =
*  The Event Token top level a= ttributes should be fairly limited and not include the sub attribute.  =
*  For events t= hat are about a user, the relevant event specification may include a =E2=80=9C= sub=E2=80=9D attribute within the event=E2=80=99s sub-object and not in the t= op-level. Further that sub-object can also include the issuer of the user. &= nbsp;
* The top-level =E2= =80=9Ciss=E2=80=9D shall mean the issuer of the event where the state change= occurred.
*  =E2= =80=9Csub=E2=80=9D should not be present in the top level structure.  A= lso, =E2=80=9Cevents=E2=80=9D must also be present.
 
Here would be a new example logout:
{
  <=E2=80=94 top level is a=
bout the event itself ->
  "iss": "https://server.example.com",
= 
  "aud": "s6BhdRkqt3",<=
u>
  "jti": "<=
wbr>3d0c3cf797584bd193bd0fb1bd4e7d30",
  "iat": 1458668180,
  "exp": 1458668580=
,
  "=
events": [
    "https://specs.openid.net/logout"<=
/u>
  ],=

  "https://specs.openid.net/logout": {
    <- This level is defined entirely by t=
he event URI->
    "iss": "https://oidc.example.com",
    =E2=80=9C=
jti": "08a5019c-17e1-4977-8f42-65a12843ea02=E2=80=9D,<=
/u>
 &nbs=
p;  "sub": "248289761001=E2=80=9D,
    =E2=80=9Cex=
p=E2=80=9D: <ID token expiry>
  }
}
 
In= the above example note that the =E2=80=9Cevent=E2=80=9D object can have its= own iss and subject (sub or jti) that have meaning within the context of an= OpenID OP provider.  The issuer of the event can be different (the top= -level) and represents the entity that signs the event (if it is signed).=
 
The top-level attributes identify an i= ndividual event and are used to validate the event (signing etc).  Wher= e as the nested object contains all of the data about the event and is defin= ed by the profiling specification (e.g. a possible OpenID Logout Event spec)= .  In this case, in OpenID, logging out usually translates into revokin= g an ID Token. Thus the =E2=80=9Cjti=E2=80=9D for the ID token (08a5019c...8= 43ea02) is included in the Logout object.
 
Side note.  Regarding =E2=80=9Clogout=E2=80=9D, it might be usef= ul to include the expiry of the ID Token in case the subscriber has not yet r= eceived an ID Token. This would let the subscriber know how long it needs to= keep the revocation information for.  IOW=E2=80=A6after the the ID Tok= en is expired, the subscriber would no longer need to track the revocation s= tate.
 =
It is also good to observe tha= t the =E2=80=9Caud=E2=80=9D at the top level describes the subscriber of the= event.  This may also be different then the original audience of the I= D Token.
 
So to conclude. By making t= op-level attributes strictly about the events own validation, and nested obj= ects about the event, we avoid collisions in definitions such as the issuer o= f the event, vs. the original issuer of a security assertion.<= /div>
 
I hope I=E2=80=99ve gotten everyone=E2=80=99s fee= dback correct here. Lets continue to discuss. I will revise the draft to fol= low the groups thinking here.
 
=
Phil
<= div style=3D"margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New R= oman',serif"> 
@= independentid
<= /div>
 
=
_______________________________________________
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<= br>

____________________= ___________________________
Id-event mailing list
= Id-event@ietf.org
<= span>https://www.= ietf.org/mailman/listinfo/id-event
<= /html>= --Apple-Mail-E9713696-8EEC-4AF3-BD14-1F335CE88893-- From nobody Thu Aug 11 04:54:23 2016 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 B9D5312D1BB for ; Thu, 11 Aug 2016 04:54:21 -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 BhPunHPJM59V for ; Thu, 11 Aug 2016 04:54:18 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0132.outbound.protection.outlook.com [104.47.42.132]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97AAC12D529 for ; Thu, 11 Aug 2016 04:54: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=SAIFJca2q+NP93nfZFJUPN7UMk80pClXUZRUvQ+Uav0=; b=fqmMq9gkJIJNpSXaNcJCPbK1oPPly/S+ZIJ7YGKZ40+de+1eNQwpTK/8JUBNurzoJWBITBi1RoxREj4TkiSHfUrONLW48/G5ZmDwC/DfQcQDorFYpqPENdQNW6p7axIJ50ZfoboRkpyAMqKeIKeGrt2snX4YRJBJ02vfP8V1oMA= Received: from SN1PR0301MB1645.namprd03.prod.outlook.com (10.162.130.139) by SN1PR0301MB1646.namprd03.prod.outlook.com (10.162.130.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Thu, 11 Aug 2016 11:54:16 +0000 Received: from SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) by SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) with mapi id 15.01.0549.025; Thu, 11 Aug 2016 11:54:16 +0000 From: Mike Jones To: Marius Scurtescu , Phil Hunt Thread-Topic: [Id-event] Summarizing recent discussions on ID-Event token draft Thread-Index: AQHR8mIWLvqeOEkcuEuQk5SeT4z/pKBA9pTwgAAG/gCAAABNAIAACP2AgAA8CICAAmTu0A== Date: Thu, 11 Aug 2016 11:54:15 +0000 Message-ID: References: <14E2EF51-7123-4E91-87DD-56AEA08202C1@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [2601:182:c600:7b13:bc92:8b9b:74aa:1c0b] x-ms-office365-filtering-correlation-id: eb009827-75e1-4fac-fd44-08d3c1de3855 x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1646; 6:Z/tcKKfpDDOl0C27odd3C0VLwjB926Ox9x5xcF+VbrIJ/bLCvvzNAEghJ8gxX6oFnx+GUpjyCoUpdYPi4EnIIeVhQwCmfFqGK/WBWQNtYP7GhFm/m/ts7yX7jjsJTjbUD+sNmrYDNPYEqUIXAuwOiyprcxy85oqf4UBA6crAefJgHli5O2VhABU+38I8ELVfKkScKouLewWnNCUxeNHLdUOJu4Bgt5cHR2YVdW3ssrZNgBUwgYhiHDYFdFPnBvT9uv0oV/2+xJ0udh6HeA13uQ+BEClJZQA9QmHkgA6fqtQRdzFg45eyiWRwsN48g0EP+czrbwt92kzXkaAwzaOM7g==; 5:hGGIblP9YKwnuEtut8rbZtB3DQXw9G88t61dBU5a44Qhc9gGSdjZgtmHnAuj3M0rIUiqQSCxhklR8Wa4BhkkTzvp1Ias528DjPAompffLL9oNVxTjlsV4A+hlJe43LVySejw5ZDLI3eHePsQ/tK9ZQ==; 24:R2txwwL2g87ADT88M4LJTHeRaXwHaZxXn44dcP4IsmFf/fvciF9BZo4rRaZ/IZJ2cHvySjWy3yTmirD67Xgv4cO2r9t3xyx8G5JslJj94XY=; 7:Eewqmzw+xLpHvcSRjMyi5JDLzsUenTFJJQUqBl1FfHVkhM3/eNAPSiLKa2WAszyXaYAOH1vBNR4RQKNWXxcNeQHlfOmXXPITYq/D01vo+R8PuOo+RJVD7QvE0XCAKs9oKmebeqNov5LfpV8WNfms0gFzViy2YMYK4MQGilOpTP9JDzWrGwZQIZKl9BQymeqOyzyGwsY6bzrEzyjDwQVxzLPKj7MkUJvlTdOsns3c5Inf7VlTJIfiDfWu4c9DeOlL x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1646; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(278428928389397)(192374486261705)(211936372134217)(21748063052155)(21532816269658)(146099531331640); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040171)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:SN1PR0301MB1646; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1646; x-forefront-prvs: 0031A0FFAF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(199003)(24454002)(377454003)(43784003)(76576001)(16236675004)(50986999)(33656002)(5002640100001)(76176999)(54356999)(101416001)(575784001)(87936001)(86362001)(92566002)(86612001)(74316002)(19609705001)(19580405001)(19300405004)(7906003)(16601075003)(7846002)(7736002)(19580395003)(19625215002)(81166006)(122556002)(11100500001)(105586002)(5001770100001)(10400500002)(8990500004)(5005710100001)(8676002)(15975445007)(7696003)(189998001)(97736004)(10290500002)(19617315012)(81156014)(586003)(106356001)(93886004)(106116001)(6116002)(1860700003)(102836003)(68736007)(4326007)(790700001)(9686002)(2900100001)(10090500001)(2906002)(3660700001)(2950100001)(8936002)(99286002)(77096005)(3280700002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0301MB1646; H:SN1PR0301MB1645.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB164547C185B3ECB3AD9BDDC1F51E0SN1PR0301MB1645_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Aug 2016 11:54:15.9970 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1646 Archived-At: Cc: "id-event@ietf.org" Subject: Re: [Id-event] Summarizing recent discussions on ID-Event token draft X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 11 Aug 2016 11:54:22 -0000 --_000_SN1PR0301MB164547C185B3ECB3AD9BDDC1F51E0SN1PR0301MB1645_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm8sIEnigJltIG5vdCBzYXlpbmcgdGhhdCDigJxzdWLigJ0gY2Fubm90IGFwcGVhciBhdCB0aGUg dG9wIGxldmVsLiAgSeKAmW0gc2F5aW5nIHRoYXQg4oCcc3Vi4oCdIHdpbGwgb25seSBvY2N1ciBh dCB0aGUgdG9wIGxldmVsIGlmIHRoZSBwYXJ0aWN1bGFyIGV2ZW50IGRlZmluZXMgdGhhdCDigJxz dWLigJ0gaXMgdXNlZCBpbiB0aGF0IHdheSBmb3IgdGhhdCBldmVudC4NCg0KVGhlcmUgYXJlIHBy b2JhYmx5IHVzZSBjYXNlcyBmb3IgbXVsdGlwbGUgZXZlbnRzIHBlciBtZXNzYWdlIGJ1dCBJIGRv dWJ0IHRoZXJlIGFyZSB1c2UgY2FzZXMgZm9yIG11bHRpcGxlICp1bnJlbGF0ZWQqIGV2ZW50cyBw ZXIgbWVzc2FnZS4gIEJ5IGRlZmluaXRpb24sIHJlbGF0ZWQgZXZlbnRzIHRoYXQgdXNlIHRvcC1s ZXZlbCBjbGFpbXMgd291bGQgbmVlZCB0byB1c2UgdGhlbSBpbiBhIGNvbXBhdGlibGUgd2F5LiAg SSBkb27igJl0IHNlZSB0aGF0IGFzIGJlaW5nIGEgcHJvYmxlbS4NCg0KVGhhdCBiZWluZyBzYWlk LCB0aGUgcHJlZG9taW5hbnQgdXNlIGNhc2UgaXMgbGlrZWx5IHRvIGJlIGEgc2luZ2xlIGV2ZW50 IHBlciBKV1QuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogTWFyaXVzIFNjdXJ0ZXNj dSBbbWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbV0NClNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCA5 LCAyMDE2IDc6MTUgUE0NClRvOiBQaGlsIEh1bnQgPHBoaWwuaHVudEBvcmFjbGUuY29tPg0KQ2M6 IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT47IGlkLWV2ZW50QGlldGYu b3JnDQpTdWJqZWN0OiBSZTogW0lkLWV2ZW50XSBTdW1tYXJpemluZyByZWNlbnQgZGlzY3Vzc2lv bnMgb24gSUQtRXZlbnQgdG9rZW4gZHJhZnQNCg0KTWlrZSwgYXJlIHlvdSBzdWdnZXN0aW5nIHRo YXQgYSBzdWIgY2xhaW0gY2FuIG9ubHkgc2hvdyB1cCBhdCB0aGUgZXZlbnQgbGV2ZWwgYW5kIG5v dCBhdCB0aGUgdG9wIGxldmVsOg0KDQpJbiBwYXJ0aWN1bGFyLCB0aGUgb25seSB0aGluZyB0aGF0 IHRoZSBzcGVjIHNob3VsZCBzYXkgYWJvdXQgdGhlIOKAnHN1YuKAnSBjbGFpbSBpcyB0aGF0IOKA nExpa2UgYWxsIG90aGVyIGNsYWltcyBvdGhlciB0aGFuIOKAmGV2ZW50c+KAmSBhbmQg4oCYaXNz 4oCZLCB3aGV0aGVyIHRoZSDigJhzdWLigJkgY2xhaW0gaXMgdG8gYmUgaW5jbHVkZWQgd2l0aCBh biBldmVudCBpcyBlbnRpcmVseSBldmVudC1zcGVjaWZpYy4NCg0KQSB0b3AgbGV2ZWwgc3ViIGFu ZCBtdWx0aXBsZSBldmVudHMgYXJlIGluY29tcGF0aWJsZSBJTU8uDQoNCkRvIHdlIGhhdmUgYSBj b21wZWxsaW5nIHJlYXNvbiB0byBzdXBwb3J0IG11bHRpcGxlIGV2ZW50cyBwZXIgbWVzc2FnZT8N Cg0KDQpNYXJpdXMNCg0KT24gVHVlLCBBdWcgOSwgMjAxNiBhdCAxMjozOSBQTSwgUGhpbCBIdW50 IDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+PiB3cm90 ZToNCkkgd2FzIHJlZmVycmluZyB0byB0aGlzIGluIHlvdXIgZW1haWwNCiJEZWZpbmUgdGhhdCBh biBldmVudCBuYW1lIGNhbiBiZSB1c2VkIGFzIGEgdG9wLWxldmVsIGNsYWlt4oCdDQoNCg0KSXMg dGhpcyBkaWZmZXJlbnQgZnJvbSB0aGUgZXZlbnQgdXJpPw0KDQpQaGlsDQoNCkBpbmRlcGVuZGVu dGlkDQp3d3cuaW5kZXBlbmRlbnRpZC5jb208aHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNvbT4N CnBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4NCg0KDQoN Cg0KT24gQXVnIDksIDIwMTYsIGF0IDEyOjEyIFBNLCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVz QG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+IHdyb3Rl Og0KDQpJ4oCZbSBnbGFkIHRvIGhlYXIgdGhhdCB3ZSBhZ3JlZSBvbiBrZWVwaW5nIGl0IGFzIHNp bXBsZSBhbmQgZ2VuZXJhbC1wdXJwb3NlIGFzIHBvc3NpYmxlIGFuZCB0aGF0IHlvdSBhZ3JlZSB3 aXRoIG15IHdyaXRlLXVwLiAgSSB0aGluayB3ZSB0aGVuIGhhdmUgYSBnb29kIHBhdGggZm9yd2Fy ZC4NCg0KSeKAmW0gbm90IHN1cmUgd2hhdCB5b3UgbWVhbiBieSDigJxJ4oCZbSBub3Qgc3VyZSB0 aGF0IHdlIG5lZWQgYSDigJxuYW1l4oCdLiBXaGF0IGlzIHlvdXIgaW50ZW50aW9uIHRoZXJlLuKA nSAgVGhlIG9ubHkgcGxhY2UgSSB1c2VkIHRoZSB3b3JkIOKAnG5hbWXigJ0gd2FzIGluIG15IHN0 YXRlbWVudCDigJxEZWZpbmUgdGhhdCBhbiBldmVudCBuYW1lIGNhbiBiZSB1c2VkIGFzIGEgdG9w LWxldmVsIGNsYWlt4oCdLiAgV2hhdCBJIHdhcyB0cnlpbmcgdG8gZ2V0IGF0IGlzIHdhcyB0aGF0 IGlmIOKAnGh0dHA6Ly9zcGVjcy5vcGVuaWQubmV0L2xvZ291dOKAnSBpcyB1c2VkIGFzIGFuIGV2 ZW50IG5hbWUsIHRoYXQgaXQgY2FuIGFsc28gYmUgdXNlZCBhcyBhIGNsYWltIG5hbWUgaW4gdGhl IEpXVCBjb250YWluaW5nIGluZm9ybWF0aW9uIGFib3V0IHRoZSBldmVudC4gIChNYXliZSBJ4oCZ bSBub3QgdXNpbmcgdGhlIGNvcnJlY3QgdGVybWlub2xvZ3ksIGhlbmNlIHRoZSB1bmludGVuZGVk IGNvbmZ1c2lvbiDimLouKQ0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgVGhhbmtzIGFnYWluLA0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogUGhpbCBIdW50 IFttYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb21dDQpTZW50OiBUdWVzZGF5LCBBdWd1c3QgOSwg MjAxNiAxMjowNyBQTQ0KVG86IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNv bTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4NCkNjOiBpZC1ldmVudEBpZXRm Lm9yZzxtYWlsdG86aWQtZXZlbnRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0lkLWV2ZW50XSBT dW1tYXJpemluZyByZWNlbnQgZGlzY3Vzc2lvbnMgb24gSUQtRXZlbnQgdG9rZW4gZHJhZnQNCg0K SSBkaWRu4oCZdCBjb3ZlciB0aGlzIGFzIEkgZGlkbuKAmXQgd2FudCB0byBjb25mdXNlIHBlb3Bs ZSB3aXRoIHRvbyBtYW55IHRoaW5ncy4NCg0KQnV0IEkgdGhpbmsgd2UgYWdyZWUgb24gYWxsIG9m IHRoZSBiZWxvdy4NCg0KSeKAmW0gbm90IHN1cmUgdGhhdCB3ZSBuZWVkIGEg4oCcbmFtZeKAnS4g V2hhdCBpcyB5b3VyIGludGVudGlvbiB0aGVyZS4NCg0KUGhpbA0KDQpAaW5kZXBlbmRlbnRpZA0K d3d3LmluZGVwZW5kZW50aWQuY29tPGh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20vPg0KcGhp bC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPg0KDQoNCg0KDQpP biBBdWcgOSwgMjAxNiwgYXQgMTE6NTQgQU0sIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWlj cm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQoN ClRoYW5rcyBmb3Igd3JpdGluZyB0aGlzLCBQaGlsLiAgVW5mb3J0dW5hdGVseSwgdGhlIHN1bW1h cnkgYmVsb3cgZG9lcyBub3QgaW5jbHVkZSBteSBmZWVkYmFjaywgd2hpY2ggYXQgdGhlIGVzc2Vu Y2UsIGlzIHRvIGtlZXAgdGhlIElEIEV2ZW50cyBkYXRhIHN0cnVjdHVyZSBhcyBzaW1wbGUgYW5k IGdlbmVyYWwtcHVycG9zZSBhcyBwb3NzaWJsZS4gIChJIHN0cm9uZ2x5IGJlbGlldmUgdGhhdCBK V1QgaXMgdGhlIHN1Y2Nlc3MgaXQgaXMgYmVjYXVzZSB3ZSBtYWRlIEpXVCBhcyBzaW1wbGUgYW5k IGdlbmVyYWwtcHVycG9zZSBhcyBwb3NzaWJsZSwgYW5kIHdlIHNob3VsZCBmb2xsb3cgdGhpcyBz dWNjZXNzZnVsIGV4YW1wbGUgYW5kIGRvIHRoZSBzYW1lIGhlcmUuKQ0KDQpJIGJlbGlldmUgdGhh dCB0aGUgSUQgRXZlbnRzIHNwZWMgbmVlZHMgdG8gaW5jbHVkZSB0aGVzZSB0aGluZ3MsIGFuZCB0 aGVzZSB0aGluZ3Mgb25seToNCuKAoiAgICAgICBEZWZpbmUgb2YgdGhlIOKAnGV2ZW50c+KAnSBj bGFpbQ0K4oCiICAgICAgIERlZmluZSB0aGF0IGFuIGV2ZW50IG5hbWUgY2FuIGJlIHVzZWQgYXMg YSB0b3AtbGV2ZWwgY2xhaW0NCuKAoiAgICAgICBSZXF1aXJlIHRoYXQg4oCcaXNz4oCdIGJlIGlu Y2x1ZGVkIGFuZCB0aGF0IHRoZSBKV1QgYmUgc2lnbmVkIGJ5IHRoZSBpc3N1ZXINCuKAoiAgICAg ICBJbmNsdWRlIGEgc3RhdGVtZW50IGFsb25nIHRoZSBsaW5lcyBvZiDigJxUaGUgY2xhaW1zIHRv IGJlIGluY2x1ZGVkIHdpdGggYW55IHBhcnRpY3VsYXIgZXZlbnQgYXJlIHRvIGJlIGRlZmluZWQg YnkgdGhlIGV2ZW504oCdDQoNCkFuZCBJ4oCZZCBzdG9wIHRoZXJlLg0KDQpJdCBzaG91bGQgYmUg ZW50aXJlbHkgdXAgdG8gYXBwbGljYXRpb25zIHRvIHNheSB3aGF0IGNsYWltcyBhcmUgaW5jbHVk ZWQgd2l0aCBldmVudHMgdGhleSBkZWZpbmUgYW5kIHdoYXQgdGhlaXIgZm9ybWF0IGFuZCBtZWFu aW5ncyBhcmUuICBUaGVuIHRoZSBJRCBFdmVudHMgc3BlYyB3aWxsIGJlIGFzIGdlbmVyYWwtcHVy cG9zZSBhcyBwb3NzaWJsZSwgd2l0aCBpdCBiZWluZyBuYXR1cmFsIGZvciBpdCB0byBiZSB1c2Vk IGluIGVzc2VudGlhbGx5IGFsbCBKU09OIEV2ZW50IGNvbnRleHRzLg0KDQpBcyBzb29uIGFzIHdl IHN0YXJ0IHB1dHRpbmcgcmVzdHJpY3Rpb25zIG9uIHRoZSB1c2Ugb2YgcGFydGljdWxhciBjbGFp bXMgYnkgZXZlbnRzLCB3ZeKAmXJlIG1ha2luZyB0aGUgSUQgRXZlbnRzIHNwZWMgbGVzcyBnZW5l cmFsLXB1cnBvc2UgYW5kIGxlc3MgbmF0dXJhbCB0byB1c2UuICBJbiBwYXJ0aWN1bGFyLCB0aGUg b25seSB0aGluZyB0aGF0IHRoZSBzcGVjIHNob3VsZCBzYXkgYWJvdXQgdGhlIOKAnHN1YuKAnSBj bGFpbSBpcyB0aGF0IOKAnExpa2UgYWxsIG90aGVyIGNsYWltcyBvdGhlciB0aGFuIOKAmGV2ZW50 c+KAmSBhbmQg4oCYaXNz4oCZLCB3aGV0aGVyIHRoZSDigJhzdWLigJkgY2xhaW0gaXMgdG8gYmUg aW5jbHVkZWQgd2l0aCBhbiBldmVudCBpcyBlbnRpcmVseSBldmVudC1zcGVjaWZpYy4gIFRoZSBj bGFpbXMgdG8gYmUgaW5jbHVkZWQgd2l0aCBhbnkgcGFydGljdWxhciBldmVudCBhcmUgZXhwbGlj aXRseSBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIHNwZWNpZmljYXRpb24u4oCdDQoNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtl DQoNCkZyb206IElkLWV2ZW50IFttYWlsdG86aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIFBoaWwgSHVudA0KU2VudDogVHVlc2RheSwgQXVndXN0IDksIDIwMTYgMTA6MTkg QU0NClRvOiBpZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86aWQtZXZlbnRAaWV0Zi5vcmc+DQpTdWJq ZWN0OiBbSWQtZXZlbnRdIFN1bW1hcml6aW5nIHJlY2VudCBkaXNjdXNzaW9ucyBvbiBJRC1FdmVu dCB0b2tlbiBkcmFmdA0KDQpJIHRob3VnaHQgSSB3b3VsZCB1cGRhdGUgdGhlIGxpc3Qgb24gc29t ZSBkaXNjdXNzaW9ucyB0aGF0IGhhdmUgYmVlbiBoYXBwZW5pbmcgb3ZlciBpbiB0aGUgT3BlbklE IENvbm5lY3QgYW5kIFJJU0Mgd29ya2luZyBncm91cHMgY29uZmVyZW5jZSBjYWxscy4NCg0KVGhl c2UgZGlzY3Vzc2lvbnMgaGF2ZSBiZWVuIGFib3V0IHRoZSBjb3JlIHNwZWMgYW5kIHRoZSByb2xl IG9mIOKAnHRvcC1sZXZlbOKAnSBhdHRyaWJ1dGVzIHZzLiBldmVudCDigJxleHRlbnNpb27igJ0g YXR0cmlidXRlcy4NClNlZTogaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWh1bnQt aWRldmVudC10b2tlbi0wMQ0KDQpJbiBwYXJ0aWN1bGFyIHNob3VsZCDigJxzdWLigJ0gYmUgdXNl ZCBpbiB0aGUgdG9wIGxldmVsIHRvIOKAnHBvaW504oCdIHRvIHRoZSBzdWJqZWN0IChpbiB0aGUg YnJvYWRlciBlbmdsaXNoIHNlbnNlKSBvZiB0aGUgZXZlbnQsIG9yIHNob3VsZCBpdCBiZSBjb25z dHJhaW5lZCB0byB0aGUgU0FNTC9JRCBUb2tlbiBkZWZpbml0aW9uIHdoaWNoIGlzIHRoZSBhdXRo ZW50aWNhdGVkIHVzZXIuDQoNClRha2VuIGluIHRoZSBuYXJyb3dlciBkZWZpbml0aW9uLCBpdCBp cyBpbXBvcnRhbnQgdG8gb2JzZXJ2ZSB0aGF0IGluIGFuIElEIFRva2VuLCDigJxzdWLigJ0gYW5k IOKAnGlzc+KAnSBnbyB0b2dldGhlci4gIFRoZSBpc3N1ZXIgcHJvdmlkZXMgdGhlIGNvbnRleHQg Zm9yIHRoZSBhdXRoZW50aWNhdGVkIHN1YmplY3QgaWRlbnRpZmllci4gVGhlIHByb2JsZW0gd2l0 aCBldmVudHMsIGlzIHRoYXQgaXQgbWlnaHQgbm90IGJlIHRoZSBBUyAob3IgT1ApIHdoaWNoIGlz IGlzc3VpbmcgdGhlIGV2ZW50Lg0KDQpUbyBzdW1tYXJpemUgYSBmYWlyIGFtb3VudCBvZiBkaXNj dXNzaW9uLCB0aGUgZmVlbGluZyBzZWVtcyB0byBiZSB0aGUgZm9sbG93aW5nOg0KDQoqICBUaGUg RXZlbnQgVG9rZW4gdG9wIGxldmVsIGF0dHJpYnV0ZXMgc2hvdWxkIGJlIGZhaXJseSBsaW1pdGVk IGFuZCBub3QgaW5jbHVkZSB0aGUgc3ViIGF0dHJpYnV0ZS4NCiogIEZvciBldmVudHMgdGhhdCBh cmUgYWJvdXQgYSB1c2VyLCB0aGUgcmVsZXZhbnQgZXZlbnQgc3BlY2lmaWNhdGlvbiBtYXkgaW5j bHVkZSBhIOKAnHN1YuKAnSBhdHRyaWJ1dGUgd2l0aGluIHRoZSBldmVudOKAmXMgc3ViLW9iamVj dCBhbmQgbm90IGluIHRoZSB0b3AtbGV2ZWwuIEZ1cnRoZXIgdGhhdCBzdWItb2JqZWN0IGNhbiBh bHNvIGluY2x1ZGUgdGhlIGlzc3VlciBvZiB0aGUgdXNlci4NCiogVGhlIHRvcC1sZXZlbCDigJxp c3PigJ0gc2hhbGwgbWVhbiB0aGUgaXNzdWVyIG9mIHRoZSBldmVudCB3aGVyZSB0aGUgc3RhdGUg Y2hhbmdlIG9jY3VycmVkLg0KKiAg4oCcc3Vi4oCdIHNob3VsZCBub3QgYmUgcHJlc2VudCBpbiB0 aGUgdG9wIGxldmVsIHN0cnVjdHVyZS4gIEFsc28sIOKAnGV2ZW50c+KAnSBtdXN0IGFsc28gYmUg cHJlc2VudC4NCg0KSGVyZSB3b3VsZCBiZSBhIG5ldyBleGFtcGxlIGxvZ291dDoNCg0Kew0KDQog IDzigJQgdG9wIGxldmVsIGlzIGFib3V0IHRoZSBldmVudCBpdHNlbGYgLT4NCg0KICAiaXNzIjog Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tPGh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tLz4i LA0KDQogICJhdWQiOiAiczZCaGRSa3F0MyIsDQoNCiAgImp0aSI6ICIzZDBjM2NmNzk3NTg0YmQx OTNiZDBmYjFiZDRlN2QzMCIsDQoNCiAgImlhdCI6IDE0NTg2NjgxODAsDQoNCiAgImV4cCI6IDE0 NTg2Njg1ODAsDQoNCiAgImV2ZW50cyI6IFsNCg0KICAgICJodHRwczovL3NwZWNzLm9wZW5pZC5u ZXQvbG9nb3V0Ig0KDQogIF0sDQoNCiAgImh0dHBzOi8vc3BlY3Mub3BlbmlkLm5ldC9sb2dvdXQi OiB7DQoNCiAgICA8LSBUaGlzIGxldmVsIGlzIGRlZmluZWQgZW50aXJlbHkgYnkgdGhlIGV2ZW50 IFVSSS0+DQoNCiAgICAiaXNzIjogImh0dHBzOi8vb2lkYy5leGFtcGxlLmNvbTxodHRwczovL29p ZGMuZXhhbXBsZS5jb20vPiIsDQoNCiAgICDigJxqdGkiOiAiMDhhNTAxOWMtMTdlMS00OTc3LThm NDItNjVhMTI4NDNlYTAy4oCdLA0KDQogICAgInN1YiI6ICIyNDgyODk3NjEwMDHigJ0sDQoNCiAg ICDigJxleHDigJ06IDxJRCB0b2tlbiBleHBpcnk+DQoNCiAgfQ0KDQp9DQoNCkluIHRoZSBhYm92 ZSBleGFtcGxlIG5vdGUgdGhhdCB0aGUg4oCcZXZlbnTigJ0gb2JqZWN0IGNhbiBoYXZlIGl0cyBv d24gaXNzIGFuZCBzdWJqZWN0IChzdWIgb3IganRpKSB0aGF0IGhhdmUgbWVhbmluZyB3aXRoaW4g dGhlIGNvbnRleHQgb2YgYW4gT3BlbklEIE9QIHByb3ZpZGVyLiAgVGhlIGlzc3VlciBvZiB0aGUg ZXZlbnQgY2FuIGJlIGRpZmZlcmVudCAodGhlIHRvcC1sZXZlbCkgYW5kIHJlcHJlc2VudHMgdGhl IGVudGl0eSB0aGF0IHNpZ25zIHRoZSBldmVudCAoaWYgaXQgaXMgc2lnbmVkKS4NCg0KVGhlIHRv cC1sZXZlbCBhdHRyaWJ1dGVzIGlkZW50aWZ5IGFuIGluZGl2aWR1YWwgZXZlbnQgYW5kIGFyZSB1 c2VkIHRvIHZhbGlkYXRlIHRoZSBldmVudCAoc2lnbmluZyBldGMpLiAgV2hlcmUgYXMgdGhlIG5l c3RlZCBvYmplY3QgY29udGFpbnMgYWxsIG9mIHRoZSBkYXRhIGFib3V0IHRoZSBldmVudCBhbmQg aXMgZGVmaW5lZCBieSB0aGUgcHJvZmlsaW5nIHNwZWNpZmljYXRpb24gKGUuZy4gYSBwb3NzaWJs ZSBPcGVuSUQgTG9nb3V0IEV2ZW50IHNwZWMpLiAgSW4gdGhpcyBjYXNlLCBpbiBPcGVuSUQsIGxv Z2dpbmcgb3V0IHVzdWFsbHkgdHJhbnNsYXRlcyBpbnRvIHJldm9raW5nIGFuIElEIFRva2VuLiBU aHVzIHRoZSDigJxqdGnigJ0gZm9yIHRoZSBJRCB0b2tlbiAoMDhhNTAxOWMuLi44NDNlYTAyKSBp cyBpbmNsdWRlZCBpbiB0aGUgTG9nb3V0IG9iamVjdC4NCg0KU2lkZSBub3RlLiAgUmVnYXJkaW5n IOKAnGxvZ291dOKAnSwgaXQgbWlnaHQgYmUgdXNlZnVsIHRvIGluY2x1ZGUgdGhlIGV4cGlyeSBv ZiB0aGUgSUQgVG9rZW4gaW4gY2FzZSB0aGUgc3Vic2NyaWJlciBoYXMgbm90IHlldCByZWNlaXZl ZCBhbiBJRCBUb2tlbi4gVGhpcyB3b3VsZCBsZXQgdGhlIHN1YnNjcmliZXIga25vdyBob3cgbG9u ZyBpdCBuZWVkcyB0byBrZWVwIHRoZSByZXZvY2F0aW9uIGluZm9ybWF0aW9uIGZvci4gIElPV+KA pmFmdGVyIHRoZSB0aGUgSUQgVG9rZW4gaXMgZXhwaXJlZCwgdGhlIHN1YnNjcmliZXIgd291bGQg bm8gbG9uZ2VyIG5lZWQgdG8gdHJhY2sgdGhlIHJldm9jYXRpb24gc3RhdGUuDQoNCkl0IGlzIGFs c28gZ29vZCB0byBvYnNlcnZlIHRoYXQgdGhlIOKAnGF1ZOKAnSBhdCB0aGUgdG9wIGxldmVsIGRl c2NyaWJlcyB0aGUgc3Vic2NyaWJlciBvZiB0aGUgZXZlbnQuICBUaGlzIG1heSBhbHNvIGJlIGRp ZmZlcmVudCB0aGVuIHRoZSBvcmlnaW5hbCBhdWRpZW5jZSBvZiB0aGUgSUQgVG9rZW4uDQoNClNv IHRvIGNvbmNsdWRlLiBCeSBtYWtpbmcgdG9wLWxldmVsIGF0dHJpYnV0ZXMgc3RyaWN0bHkgYWJv dXQgdGhlIGV2ZW50cyBvd24gdmFsaWRhdGlvbiwgYW5kIG5lc3RlZCBvYmplY3RzIGFib3V0IHRo ZSBldmVudCwgd2UgYXZvaWQgY29sbGlzaW9ucyBpbiBkZWZpbml0aW9ucyBzdWNoIGFzIHRoZSBp c3N1ZXIgb2YgdGhlIGV2ZW50LCB2cy4gdGhlIG9yaWdpbmFsIGlzc3VlciBvZiBhIHNlY3VyaXR5 IGFzc2VydGlvbi4NCg0KSSBob3BlIEnigJl2ZSBnb3R0ZW4gZXZlcnlvbmXigJlzIGZlZWRiYWNr IGNvcnJlY3QgaGVyZS4gTGV0cyBjb250aW51ZSB0byBkaXNjdXNzLiBJIHdpbGwgcmV2aXNlIHRo ZSBkcmFmdCB0byBmb2xsb3cgdGhlIGdyb3VwcyB0aGlua2luZyBoZXJlLg0KDQpQaGlsDQoNCkBp bmRlcGVuZGVudGlkDQp3d3cuaW5kZXBlbmRlbnRpZC5jb208aHR0cDovL3d3dy5pbmRlcGVuZGVu dGlkLmNvbS8+DQpwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5j b20+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJ ZC1ldmVudCBtYWlsaW5nIGxpc3QNCklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBp ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQN Cg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSWQt ZXZlbnQgbWFpbGluZyBsaXN0DQpJZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86SWQtZXZlbnRAaWV0 Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50DQoN Cg== --_000_SN1PR0301MB164547C185B3ECB3AD9BDDC1F51E0SN1PR0301MB1645_ 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 DQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4w cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToi Q291cmllciBOZXciO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1h bDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy Z2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5tLTY1MzQ0MzU1NzM2Mzk2NzM3ODZhcHBsZS1zdHlsZS1z cGFuDQoJe21zby1zdHlsZS1uYW1lOm1fLTY1MzQ0MzU1NzM2Mzk2NzM3ODZhcHBsZS1zdHlsZS1z cGFuO30NCnNwYW4ubS02NTM0NDM1NTczNjM5NjczNzg2YXBwbGUtY29udmVydGVkLXNwYWNlDQoJ e21zby1zdHlsZS1uYW1lOm1fLTY1MzQ0MzU1NzM2Mzk2NzM3ODZhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2U7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQ cmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5F bWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzAwMjA2MDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5ObywgSeKAmW0gbm90 IHNheWluZyB0aGF0IOKAnHN1YuKAnSBjYW5ub3QgYXBwZWFyIGF0IHRoZSB0b3AgbGV2ZWwuJm5i c3A7IEnigJltIHNheWluZyB0aGF0IOKAnHN1YuKAnSB3aWxsIG9ubHkgb2NjdXIgYXQgdGhlIHRv cCBsZXZlbCBpZiB0aGUgcGFydGljdWxhciBldmVudCBkZWZpbmVzIHRoYXQg4oCcc3Vi4oCdDQog aXMgdXNlZCBpbiB0aGF0IHdheSBmb3IgdGhhdCBldmVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMwMDIwNjAiPlRoZXJlIGFyZSBwcm9iYWJseSB1c2UgY2FzZXMgZm9yIG11 bHRpcGxlIGV2ZW50cyBwZXIgbWVzc2FnZSBidXQgSSBkb3VidCB0aGVyZSBhcmUgdXNlIGNhc2Vz IGZvciBtdWx0aXBsZSAqPGI+dW5yZWxhdGVkPC9iPiogZXZlbnRzIHBlciBtZXNzYWdlLiZuYnNw OyBCeSBkZWZpbml0aW9uLA0KIHJlbGF0ZWQgZXZlbnRzIHRoYXQgdXNlIHRvcC1sZXZlbCBjbGFp bXMgd291bGQgbmVlZCB0byB1c2UgdGhlbSBpbiBhIGNvbXBhdGlibGUgd2F5LiZuYnNwOyBJIGRv buKAmXQgc2VlIHRoYXQgYXMgYmVpbmcgYSBwcm9ibGVtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzAwMjA2MCI+VGhhdCBiZWluZyBzYWlkLCB0aGUgcHJlZG9taW5hbnQgdXNl IGNhc2UgaXMgbGlrZWx5IHRvIGJlIGEgc2luZ2xlIGV2ZW50IHBlciBKV1QuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMw MDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29t cG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvYT48L3A+DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+ PC9zcGFuPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gTWFyaXVzIFNjdXJ0ZXNjdSBbbWFpbHRvOm1zY3Vy dGVzY3VAZ29vZ2xlLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBBdWd1c3QgOSwg MjAxNiA3OjE1IFBNPGJyPg0KPGI+VG86PC9iPiBQaGlsIEh1bnQgJmx0O3BoaWwuaHVudEBvcmFj bGUuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gTWlrZSBKb25lcyAmbHQ7TWljaGFlbC5Kb25lc0Bt aWNyb3NvZnQuY29tJmd0OzsgaWQtZXZlbnRAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IFtJZC1ldmVudF0gU3VtbWFyaXppbmcgcmVjZW50IGRpc2N1c3Npb25zIG9uIElELUV2ZW50 IHRva2VuIGRyYWZ0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWlrZSwg YXJlIHlvdSBzdWdnZXN0aW5nIHRoYXQgYSBzdWIgY2xhaW0gY2FuIG9ubHkgc2hvdyB1cCBhdCB0 aGUgZXZlbnQgbGV2ZWwgYW5kIG5vdCBhdCB0aGUgdG9wIGxldmVsOjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gcGFydGljdWxhciwgdGhlIG9u bHkgdGhpbmcgdGhhdCB0aGUgc3BlYyBzaG91bGQgc2F5IGFib3V0IHRoZSDigJxzdWLigJ0gY2xh aW0gaXMgdGhhdCDigJxMaWtlIGFsbCBvdGhlciBjbGFpbXMgb3RoZXIgdGhhbiDigJhldmVudHPi gJkgYW5kIOKAmGlzc+KAmSwgd2hldGhlciB0aGUg4oCYc3Vi4oCZIGNsYWltIGlzIHRvIGJlIGlu Y2x1ZGVkIHdpdGggYW4gZXZlbnQgaXMgZW50aXJlbHkgZXZlbnQtc3BlY2lmaWMuPG86cD48L286 cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BIHRv cCBsZXZlbCBzdWIgYW5kIG11bHRpcGxlIGV2ZW50cyBhcmUgaW5jb21wYXRpYmxlIElNTy48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RG8gd2Ug aGF2ZSBhIGNvbXBlbGxpbmcgcmVhc29uIHRvIHN1cHBvcnQgbXVsdGlwbGUgZXZlbnRzIHBlciBt ZXNzYWdlPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NYXJpdXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIEF1ZyA5LCAyMDE2IGF0IDEyOjM5IFBNLCBQ aGlsIEh1bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd2FzIHJlZmVy cmluZyB0byB0aGlzIGluIHlvdXIgZW1haWw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mcXVvdDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+RGVmaW5l IHRoYXQgYW4gZXZlbnQgbmFtZSBjYW4gYmUgdXNlZCBhcyBhIHRvcC1sZXZlbCBjbGFpbeKAnTwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SXMgdGhpcyBkaWZmZXJlbnQgZnJvbSB0aGUgZXZlbnQgdXJpPzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj5QaGlsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPkBpbmRlcGVuZGVudGlkPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj48YSBocmVmPSJodHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tIiB0YXJnZXQ9Il9ibGFu ayI+d3d3LmluZGVwZW5kZW50aWQuY29tPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj48YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRh cmdldD0iX2JsYW5rIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gQXVnIDksIDIwMTYsIGF0IDEyOjEyIFBNLCBNaWtlIEpvbmVz ICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIiB0YXJnZXQ9 Il9ibGFuayI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMwMDIwNjAiPknigJltIGdsYWQgdG8gaGVhciB0aGF0IHdlIGFncmVlIG9u IGtlZXBpbmcgaXQgYXMgc2ltcGxlIGFuZCBnZW5lcmFsLXB1cnBvc2UgYXMgcG9zc2libGUgYW5k IHRoYXQgeW91IGFncmVlIHdpdGggbXkgd3JpdGUtdXAuJm5ic3A7IEkgdGhpbmsgd2UgdGhlbiBo YXZlIGEgZ29vZCBwYXRoDQogZm9yd2FyZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2 MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPknigJltIG5vdCBzdXJl IHdoYXQgeW91IG1lYW4gYnkg4oCcPC9zcGFuPknigJltIG5vdCBzdXJlIHRoYXQgd2UgbmVlZCBh IOKAnG5hbWXigJ0uIFdoYXQgaXMgeW91ciBpbnRlbnRpb24gdGhlcmUuPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMwMDIwNjAiPuKAnSZuYnNwOw0KIFRoZSBvbmx5IHBsYWNlIEkgdXNlZCB0aGUgd29y ZCDigJxuYW1l4oCdIHdhcyBpbiBteSBzdGF0ZW1lbnQg4oCcRGVmaW5lIHRoYXQgYW4gZXZlbnQg bmFtZSBjYW4gYmUgdXNlZCBhcyBhIHRvcC1sZXZlbCBjbGFpbeKAnS4mbmJzcDsgV2hhdCBJIHdh cyB0cnlpbmcgdG8gZ2V0IGF0IGlzIHdhcyB0aGF0IGlmIOKAnDxhIGhyZWY9Imh0dHA6Ly9zcGVj cy5vcGVuaWQubmV0L2xvZ291dCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpw dXJwbGUiPmh0dHA6Ly9zcGVjcy5vcGVuaWQubmV0L2xvZ291dDwvc3Bhbj48L2E+4oCdDQogaXMg dXNlZCBhcyBhbiBldmVudCBuYW1lLCB0aGF0IGl0IGNhbiBhbHNvIGJlIHVzZWQgYXMgYSBjbGFp bSBuYW1lIGluIHRoZSBKV1QgY29udGFpbmluZyBpbmZvcm1hdGlvbiBhYm91dCB0aGUgZXZlbnQu Jm5ic3A7IChNYXliZSBJ4oCZbSBub3QgdXNpbmcgdGhlIGNvcnJlY3QgdGVybWlub2xvZ3ksIGhl bmNlIHRoZSB1bmludGVuZGVkIGNvbmZ1c2lvbjxzcGFuIGNsYXNzPSJtLTY1MzQ0MzU1NzM2Mzk2 NzM3ODZhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMwMDIwNjAi Pko8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPi4pPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYw Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhhbmtzIGFnYWluLDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgLS0gTWlrZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Im1fLTY1MzQ0MzU1NzM2Mzk2NzM3ODZf X01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9z cGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw aW4gMGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PkZyb206PC9zcGFuPjwvYj48c3BhbiBjbGFzcz0ibS02NTM0NDM1NTczNjM5NjczNzg2YXBwbGUt Y29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5QaGlsDQogSHVudCBbPGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFj bGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPl08 c3BhbiBjbGFzcz0ibS02NTM0NDM1NTczNjM5NjczNzg2YXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+PGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9Im0tNjUzNDQzNTU3MzYz OTY3Mzc4NmFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlR1ZXNkYXksIEF1Z3Vz dCA5LCAyMDE2IDEyOjA3IFBNPGJyPg0KPGI+VG86PC9iPjxzcGFuIGNsYXNzPSJtLTY1MzQ0MzU1 NzM2Mzk2NzM3ODZhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5NaWtlIEpvbmVz ICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIiB0YXJnZXQ9 Il9ibGFuayI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8 L2I+PHNwYW4gY2xhc3M9Im0tNjUzNDQzNTU3MzYzOTY3Mzc4NmFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzppZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPmlkLWV2ZW50QGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFu IGNsYXNzPSJtLTY1MzQ0MzU1NzM2Mzk2NzM3ODZhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj5SZTogW0lkLWV2ZW50XSBTdW1tYXJpemluZyByZWNlbnQgZGlzY3Vzc2lvbnMgb24g SUQtRXZlbnQgdG9rZW4gZHJhZnQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkg ZGlkbuKAmXQgY292ZXIgdGhpcyBhcyBJIGRpZG7igJl0IHdhbnQgdG8gY29uZnVzZSBwZW9wbGUg d2l0aCB0b28gbWFueSB0aGluZ3MuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CdXQgSSB0aGluayB3ZSBh Z3JlZSBvbiBhbGwgb2YgdGhlIGJlbG93LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J4oCZ bSBub3Qgc3VyZSB0aGF0IHdlIG5lZWQgYSDigJxuYW1l4oCdLiBXaGF0IGlzIHlvdXIgaW50ZW50 aW9uIHRoZXJlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBoaWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QGlu ZGVwZW5kZW50aWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5j b20vIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+d3d3LmluZGVw ZW5kZW50aWQuY29tPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJl Zj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5 bGU9ImNvbG9yOnB1cnBsZSI+cGhpbC5odW50QG9yYWNsZS5jb208L3NwYW4+PC9hPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk9uIEF1ZyA5LCAyMDE2LCBhdCAxMTo1NCBBTSwgTWlrZSBKb25lcyAm bHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJf YmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0 LmNvbTwvc3Bhbj48L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMDAyMDYwIj5UaGFua3MgZm9yIHdyaXRpbmcgdGhpcywgUGhpbC4mbmJzcDsg VW5mb3J0dW5hdGVseSwgdGhlIHN1bW1hcnkgYmVsb3cgZG9lcyBub3QgaW5jbHVkZSBteSBmZWVk YmFjaywgd2hpY2ggYXQgdGhlIGVzc2VuY2UsIGlzIHRvIGtlZXAgdGhlIElEIEV2ZW50cyBkYXRh IHN0cnVjdHVyZSBhcw0KIHNpbXBsZSBhbmQgZ2VuZXJhbC1wdXJwb3NlIGFzIHBvc3NpYmxlLiAm bmJzcDsoSSBzdHJvbmdseSBiZWxpZXZlIHRoYXQgSldUIGlzIHRoZSBzdWNjZXNzIGl0IGlzIGJl Y2F1c2Ugd2UgbWFkZSBKV1QgYXMgc2ltcGxlIGFuZCBnZW5lcmFsLXB1cnBvc2UgYXMgcG9zc2li bGUsIGFuZCB3ZSBzaG91bGQgZm9sbG93IHRoaXMgc3VjY2Vzc2Z1bCBleGFtcGxlIGFuZCBkbyB0 aGUgc2FtZSBoZXJlLik8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAw MjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIw NjAiPkkgYmVsaWV2ZSB0aGF0IHRoZSBJRCBFdmVudHMgc3BlYyBuZWVkcyB0byBpbmNsdWRlIHRo ZXNlIHRoaW5ncywgYW5kIHRoZXNlIHRoaW5ncyBvbmx5Ojwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpTeW1ib2w7Y29sb3I6IzAwMjA2MCI+wrc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo3LjBwdDtjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDs8c3BhbiBjbGFzcz0ibS02NTM0NDM1NTczNjM5NjczNzg2YXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5EZWZp bmUNCiBvZiB0aGUg4oCcZXZlbnRz4oCdIGNsYWltPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OlN5bWJvbDtjb2xvcjojMDAyMDYwIj7Ctzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcu MHB0O2NvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxz cGFuIGNsYXNzPSJtLTY1MzQ0MzU1NzM2Mzk2NzM3ODZhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPkRlZmluZQ0K IHRoYXQgYW4gZXZlbnQgbmFtZSBjYW4gYmUgdXNlZCBhcyBhIHRvcC1sZXZlbCBjbGFpbTwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6IzAwMjA2MCI+wrc8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0ibS02NTM0NDM1NTczNjM5NjczNzg2YXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMDAyMDYwIj5SZXF1aXJlDQogdGhhdCDigJxpc3PigJ0gYmUgaW5jbHVkZWQgYW5kIHRo YXQgdGhlIEpXVCBiZSBzaWduZWQgYnkgdGhlIGlzc3Vlcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpTeW1ib2w7Y29sb3I6IzAwMjA2MCI+wrc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo3LjBwdDtjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDs8c3BhbiBjbGFzcz0ibS02NTM0NDM1NTczNjM5NjczNzg2YXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5JbmNs dWRlDQogYSBzdGF0ZW1lbnQgYWxvbmcgdGhlIGxpbmVzIG9mIOKAnFRoZSBjbGFpbXMgdG8gYmUg aW5jbHVkZWQgd2l0aCBhbnkgcGFydGljdWxhciBldmVudCBhcmUgdG8gYmUgZGVmaW5lZCBieSB0 aGUgZXZlbnTigJ08L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2 MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAi PkFuZCBJ4oCZZCBzdG9wIHRoZXJlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzAwMjA2MCI+SXQgc2hvdWxkIGJlIGVudGlyZWx5IHVwIHRvIGFwcGxpY2F0aW9ucyB0byBz YXkgd2hhdCBjbGFpbXMgYXJlIGluY2x1ZGVkIHdpdGggZXZlbnRzIHRoZXkgZGVmaW5lIGFuZCB3 aGF0IHRoZWlyIGZvcm1hdCBhbmQgbWVhbmluZ3MgYXJlLiZuYnNwOyBUaGVuIHRoZSBJRCBFdmVu dHMgc3BlYw0KIHdpbGwgYmUgYXMgZ2VuZXJhbC1wdXJwb3NlIGFzIHBvc3NpYmxlLCB3aXRoIGl0 IGJlaW5nIG5hdHVyYWwgZm9yIGl0IHRvIGJlIHVzZWQgaW4gZXNzZW50aWFsbHkgYWxsIEpTT04g RXZlbnQgY29udGV4dHMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMw MDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAy MDYwIj5BcyBzb29uIGFzIHdlIHN0YXJ0IHB1dHRpbmcgcmVzdHJpY3Rpb25zIG9uIHRoZSB1c2Ug b2YgcGFydGljdWxhciBjbGFpbXMgYnkgZXZlbnRzLCB3ZeKAmXJlIG1ha2luZyB0aGUgSUQgRXZl bnRzIHNwZWMgbGVzcyBnZW5lcmFsLXB1cnBvc2UgYW5kIGxlc3MgbmF0dXJhbCB0byB1c2UuJm5i c3A7DQogSW4gcGFydGljdWxhciwgdGhlIG9ubHkgdGhpbmcgdGhhdCB0aGUgc3BlYyBzaG91bGQg c2F5IGFib3V0IHRoZSDigJxzdWLigJ0gY2xhaW0gaXMgdGhhdCDigJxMaWtlIGFsbCBvdGhlciBj bGFpbXMgb3RoZXIgdGhhbiDigJhldmVudHPigJkgYW5kIOKAmGlzc+KAmSwgd2hldGhlciB0aGUg 4oCYc3Vi4oCZIGNsYWltIGlzIHRvIGJlIGluY2x1ZGVkIHdpdGggYW4gZXZlbnQgaXMgZW50aXJl bHkgZXZlbnQtc3BlY2lmaWMuJm5ic3A7IFRoZSBjbGFpbXMgdG8gYmUgaW5jbHVkZWQgd2l0aCBh bnkNCiBwYXJ0aWN1bGFyIGV2ZW50IGFyZSBleHBsaWNpdGx5IG91dHNpZGUgdGhlIHNjb3BlIG9m IHRoaXMgc3BlY2lmaWNhdGlvbi7igJ08L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBN aWtlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBjbGFzcz0ibS02NTM0NDM1NTcz NjM5NjczNzg2YXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwv c3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JZC1ldmVudA0KIFs8YSBocmVmPSJtYWlsdG86 aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJj b2xvcjpwdXJwbGUiPm1haWx0bzppZC1ldmVudC1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT5d PHNwYW4gY2xhc3M9Im0tNjUzNDQzNTU3MzYzOTY3Mzc4NmFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjxiPk9uIEJlaGFsZiBPZjxzcGFuIGNsYXNzPSJtLTY1MzQ0MzU1NzM2Mzk2 NzM3ODZhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+UGhpbA0KIEh1bnQ8 YnI+DQo8Yj5TZW50OjwvYj48c3BhbiBjbGFzcz0ibS02NTM0NDM1NTczNjM5NjczNzg2YXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+VHVlc2RheSwgQXVndXN0IDksIDIwMTYgMTA6 MTkgQU08YnI+DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9Im0tNjUzNDQzNTU3MzYzOTY3Mzc4NmFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzppZC1ldmVu dEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmlk LWV2ZW50QGlldGYub3JnPC9zcGFuPjwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFz cz0ibS02NTM0NDM1NTczNjM5NjczNzg2YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+W0lkLWV2ZW50XSBTdW1tYXJpemluZyByZWNlbnQgZGlzY3Vzc2lvbnMgb24gSUQtRXZlbnQg dG9rZW4gZHJhZnQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JIHRob3VnaHQgSSB3b3VsZCB1cGRhdGUgdGhlIGxpc3Qgb24gc29tZSBkaXNjdXNzaW9u cyB0aGF0IGhhdmUgYmVlbiBoYXBwZW5pbmcgb3ZlciBpbiB0aGUgT3BlbklEIENvbm5lY3QgYW5k IFJJU0Mgd29ya2luZyBncm91cHMgY29uZmVyZW5jZSBjYWxscy48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXNlIGRpc2N1c3Npb25zIGhhdmUgYmVl biBhYm91dCB0aGUgY29yZSBzcGVjIGFuZCB0aGUgcm9sZSBvZiDigJx0b3AtbGV2ZWzigJ0gYXR0 cmlidXRlcyB2cy4gZXZlbnQg4oCcZXh0ZW5zaW9u4oCdIGF0dHJpYnV0ZXMuJm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5TZWU6PHNwYW4gY2xhc3M9Im0tNjUzNDQzNTU3MzYzOTY3Mzc4 NmFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1odW50LWlkZXZlbnQtdG9rZW4tMDEiIHRhcmdldD0iX2Js YW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaHVudC1pZGV2ZW50LXRva2VuLTAxPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gcGFydGljdWxhciBz aG91bGQg4oCcc3Vi4oCdIGJlIHVzZWQgaW4gdGhlIHRvcCBsZXZlbCB0byDigJxwb2ludOKAnSB0 byB0aGUgc3ViamVjdCAoaW4gdGhlIGJyb2FkZXIgZW5nbGlzaCBzZW5zZSkgb2YgdGhlIGV2ZW50 LCBvciBzaG91bGQgaXQgYmUgY29uc3RyYWluZWQgdG8gdGhlIFNBTUwvSUQgVG9rZW4gZGVmaW5p dGlvbiB3aGljaCBpcyB0aGUgYXV0aGVudGljYXRlZCB1c2VyLiAmbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGFrZW4gaW4gdGhl IG5hcnJvd2VyIGRlZmluaXRpb24sIGl0IGlzIGltcG9ydGFudCB0byBvYnNlcnZlIHRoYXQgaW4g YW4gSUQgVG9rZW4sIOKAnHN1YuKAnSBhbmQg4oCcaXNz4oCdIGdvIHRvZ2V0aGVyLiZuYnNwOyBU aGUgaXNzdWVyIHByb3ZpZGVzIHRoZSBjb250ZXh0IGZvciB0aGUgYXV0aGVudGljYXRlZCBzdWJq ZWN0IGlkZW50aWZpZXIuIFRoZSBwcm9ibGVtIHdpdGggZXZlbnRzLCBpcyB0aGF0IGl0IG1pZ2h0 IG5vdCBiZSB0aGUNCiBBUyAob3IgT1ApIHdoaWNoIGlzIGlzc3VpbmcgdGhlIGV2ZW50LiAmbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+VG8gc3VtbWFyaXplIGEgZmFpciBhbW91bnQgb2YgZGlzY3Vzc2lvbiwgdGhlIGZlZWxpbmcg c2VlbXMgdG8gYmUgdGhlIGZvbGxvd2luZzo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KiAmbmJzcDtUaGUgRXZlbnQgVG9rZW4gdG9wIGxl dmVsIGF0dHJpYnV0ZXMgc2hvdWxkIGJlIGZhaXJseSBsaW1pdGVkIGFuZCBub3QgaW5jbHVkZSB0 aGUgc3ViIGF0dHJpYnV0ZS4gJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4qICZuYnNw O0ZvciBldmVudHMgdGhhdCBhcmUgYWJvdXQgYSB1c2VyLCB0aGUgcmVsZXZhbnQgZXZlbnQgc3Bl Y2lmaWNhdGlvbiBtYXkgaW5jbHVkZSBhIOKAnHN1YuKAnSBhdHRyaWJ1dGUgd2l0aGluIHRoZSBl dmVudOKAmXMgc3ViLW9iamVjdCBhbmQgbm90IGluIHRoZSB0b3AtbGV2ZWwuIEZ1cnRoZXIgdGhh dCBzdWItb2JqZWN0IGNhbiBhbHNvIGluY2x1ZGUgdGhlIGlzc3VlciBvZiB0aGUgdXNlci4gJm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4qIFRoZSB0b3AtbGV2ZWwg4oCcaXNz4oCdIHNo YWxsIG1lYW4gdGhlIGlzc3VlciBvZiB0aGUgZXZlbnQgd2hlcmUgdGhlIHN0YXRlIGNoYW5nZSBv Y2N1cnJlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiogJm5ic3A74oCcc3Vi4oCdIHNob3Vs ZCBub3QgYmUgcHJlc2VudCBpbiB0aGUgdG9wIGxldmVsIHN0cnVjdHVyZS4mbmJzcDsgQWxzbywg 4oCcZXZlbnRz4oCdIG11c3QgYWxzbyBiZSBwcmVzZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZXJlIHdvdWxkIGJlIGEgbmV3IGV4 YW1wbGUgbG9nb3V0OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwcmU+ezxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyAmbHQ74oCUIHRvcCBsZXZl bCBpcyBhYm91dCB0aGUgZXZlbnQgaXRzZWxmIC0mZ3Q7PG86cD48L286cD48L3ByZT4NCjxwcmU+ Jm5ic3A7IDxzcGFuIHN0eWxlPSJjb2xvcjojNUUzMEVCIj4mcXVvdDtpc3MmcXVvdDs6ICZxdW90 OzxhIGhyZWY9Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tLyIgdGFyZ2V0PSJfYmxhbmsiPjxz cGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tPC9zcGFu PjwvYT4mcXVvdDssPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJj b2xvcjojNUUzMEVCIj4mbmJzcDsgJnF1b3Q7YXVkJnF1b3Q7OiAmcXVvdDtzNkJoZFJrcXQzJnF1 b3Q7LDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6IzVF MzBFQiI+Jm5ic3A7ICZxdW90O2p0aSZxdW90OzogJnF1b3Q7M2QwYzNjZjc5NzU4NGJkMTkzYmQw ZmIxYmQ0ZTdkMzAmcXVvdDssPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0 eWxlPSJjb2xvcjojNUUzMEVCIj4mbmJzcDsgJnF1b3Q7aWF0JnF1b3Q7OiAxNDU4NjY4MTgwLDwv c3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6IzVFMzBFQiI+ Jm5ic3A7ICZxdW90O2V4cCZxdW90OzogMTQ1ODY2ODU4MCw8L3NwYW4+PG86cD48L286cD48L3By ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOiM1RTMwRUIiPiZuYnNwOyAmcXVvdDtldmVudHMm cXVvdDs6IFs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9y OiM1RTMwRUIiPiZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDs8YSBocmVmPSJodHRwczovL3NwZWNz Lm9wZW5pZC5uZXQvbG9nb3V0IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1 cnBsZSI+aHR0cHM6Ly9zcGVjcy5vcGVuaWQubmV0L2xvZ291dDwvc3Bhbj48L2E+JnF1b3Q7PC9z cGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjojNUUzMEVCIj4m bmJzcDsgXSw8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+IDxzcGFuIHN0eWxlPSJjb2xv cjojRTYzQjdBIj4mbmJzcDsmcXVvdDs8YSBocmVmPSJodHRwczovL3NwZWNzLm9wZW5pZC5uZXQv bG9nb3V0IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6 Ly9zcGVjcy5vcGVuaWQubmV0L2xvZ291dDwvc3Bhbj48L2E+JnF1b3Q7OiB7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjojRTYzQjdBIj4mbmJzcDsmbmJz cDsmbmJzcDsgJmx0Oy0gVGhpcyBsZXZlbCBpcyBkZWZpbmVkIGVudGlyZWx5IGJ5IHRoZSBldmVu dCBVUkktJmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29s b3I6I0U2M0I3QSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O2lzcyZxdW90OzogJnF1b3Q7PGEg aHJlZj0iaHR0cHM6Ly9vaWRjLmV4YW1wbGUuY29tLyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0 eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vb2lkYy5leGFtcGxlLmNvbTwvc3Bhbj48L2E+JnF1 b3Q7LDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6I0U2 M0I3QSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IOKAnGp0aSZxdW90OzogJnF1b3Q7MDhhNTAxOWMtMTdl MS00OTc3LThmNDItNjVhMTI4NDNlYTAy4oCdLDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjojRTYzQjdBIj4mbmJzcDsmbmJz cDsmbmJzcDsgJnF1b3Q7c3ViJnF1b3Q7OiAmcXVvdDsyNDgyODk3NjEwMDHigJ0sPC9zcGFuPjxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9y OiNFNjNCN0EiPiZuYnNwOyZuYnNwOyZuYnNwOyDigJxleHDigJ06ICZsdDtJRCB0b2tlbiBleHBp cnkmZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2NvbG9yOiNFNjNCN0EiPiZuYnNwOyB9PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij59PC9zcGFuPjxvOnA+PC9vOnA+ PC9wcmU+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIHRoZSBhYm92ZSBleGFtcGxlIG5vdGUgdGhhdCB0 aGUg4oCcZXZlbnTigJ0gb2JqZWN0IGNhbiBoYXZlIGl0cyBvd24gaXNzIGFuZCBzdWJqZWN0IChz dWIgb3IganRpKSB0aGF0IGhhdmUgbWVhbmluZyB3aXRoaW4gdGhlIGNvbnRleHQgb2YgYW4gT3Bl bklEIE9QIHByb3ZpZGVyLiZuYnNwOyBUaGUgaXNzdWVyIG9mIHRoZSBldmVudCBjYW4gYmUgZGlm ZmVyZW50ICh0aGUgdG9wLWxldmVsKSBhbmQgcmVwcmVzZW50cyB0aGUNCiBlbnRpdHkgdGhhdCBz aWducyB0aGUgZXZlbnQgKGlmIGl0IGlzIHNpZ25lZCkuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSB0b3AtbGV2ZWwgYXR0cmlidXRl cyBpZGVudGlmeSBhbiBpbmRpdmlkdWFsIGV2ZW50IGFuZCBhcmUgdXNlZCB0byB2YWxpZGF0ZSB0 aGUgZXZlbnQgKHNpZ25pbmcgZXRjKS4mbmJzcDsgV2hlcmUgYXMgdGhlIG5lc3RlZCBvYmplY3Qg Y29udGFpbnMgYWxsIG9mIHRoZSBkYXRhIGFib3V0IHRoZSBldmVudCBhbmQgaXMgZGVmaW5lZCBi eSB0aGUgcHJvZmlsaW5nIHNwZWNpZmljYXRpb24gKGUuZy4gYSBwb3NzaWJsZQ0KIE9wZW5JRCBM b2dvdXQgRXZlbnQgc3BlYykuJm5ic3A7IEluIHRoaXMgY2FzZSwgaW4gT3BlbklELCBsb2dnaW5n IG91dCB1c3VhbGx5IHRyYW5zbGF0ZXMgaW50byByZXZva2luZyBhbiBJRCBUb2tlbi4gVGh1cyB0 aGUg4oCcanRp4oCdIGZvciB0aGUgSUQgdG9rZW4gKDA4YTUwMTljLi4uODQzZWEwMikgaXMgaW5j bHVkZWQgaW4gdGhlIExvZ291dCBvYmplY3QuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNpZGUgbm90ZS4mbmJzcDsgUmVnYXJkaW5nIOKA nGxvZ291dOKAnSwgaXQgbWlnaHQgYmUgdXNlZnVsIHRvIGluY2x1ZGUgdGhlIGV4cGlyeSBvZiB0 aGUgSUQgVG9rZW4gaW4gY2FzZSB0aGUgc3Vic2NyaWJlciBoYXMgbm90IHlldCByZWNlaXZlZCBh biBJRCBUb2tlbi4gVGhpcyB3b3VsZCBsZXQgdGhlIHN1YnNjcmliZXIga25vdyBob3cgbG9uZyBp dCBuZWVkcyB0byBrZWVwIHRoZSByZXZvY2F0aW9uIGluZm9ybWF0aW9uIGZvci4mbmJzcDsNCiBJ T1figKZhZnRlciB0aGUgdGhlIElEIFRva2VuIGlzIGV4cGlyZWQsIHRoZSBzdWJzY3JpYmVyIHdv dWxkIG5vIGxvbmdlciBuZWVkIHRvIHRyYWNrIHRoZSByZXZvY2F0aW9uIHN0YXRlLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBpcyBh bHNvIGdvb2QgdG8gb2JzZXJ2ZSB0aGF0IHRoZSDigJxhdWTigJ0gYXQgdGhlIHRvcCBsZXZlbCBk ZXNjcmliZXMgdGhlIHN1YnNjcmliZXIgb2YgdGhlIGV2ZW50LiZuYnNwOyBUaGlzIG1heSBhbHNv IGJlIGRpZmZlcmVudCB0aGVuIHRoZSBvcmlnaW5hbCBhdWRpZW5jZSBvZiB0aGUgSUQgVG9rZW4u PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlNvIHRvIGNvbmNsdWRlLiBCeSBtYWtpbmcgdG9wLWxldmVsIGF0dHJpYnV0ZXMgc3RyaWN0bHkg YWJvdXQgdGhlIGV2ZW50cyBvd24gdmFsaWRhdGlvbiwgYW5kIG5lc3RlZCBvYmplY3RzIGFib3V0 IHRoZSBldmVudCwgd2UgYXZvaWQgY29sbGlzaW9ucyBpbiBkZWZpbml0aW9ucyBzdWNoIGFzIHRo ZSBpc3N1ZXIgb2YgdGhlIGV2ZW50LCB2cy4gdGhlIG9yaWdpbmFsIGlzc3VlciBvZiBhIHNlY3Vy aXR5IGFzc2VydGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SSBob3BlIEnigJl2ZSBnb3R0ZW4gZXZlcnlvbmXigJlzIGZlZWRiYWNr IGNvcnJlY3QgaGVyZS4gTGV0cyBjb250aW51ZSB0byBkaXNjdXNzLiBJIHdpbGwgcmV2aXNlIHRo ZSBkcmFmdCB0byBmb2xsb3cgdGhlIGdyb3VwcyB0aGlua2luZyBoZXJlLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGhpbDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5AaW5kZXBlbmRlbnRpZDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cDovL3d3dy5pbmRlcGVuZGVudGlk LmNvbS8iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj53d3cuaW5k ZXBlbmRlbnRpZC5jb208L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0i X2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwv c3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQpJZC1ldmVudCBtYWlsaW5nIGxpc3Q8YnI+DQo8L3NwYW4+PGEgaHJlZj0ibWFp bHRvOklkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpwdXJwbGUiPklkLWV2ZW50QGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij48YnI+DQo8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9pZC1ldmVudCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6cHVy cGxlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50PC9zcGFu PjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KSWQtZXZl bnQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYub3JnIj5J ZC1ldmVudEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_SN1PR0301MB164547C185B3ECB3AD9BDDC1F51E0SN1PR0301MB1645_-- From nobody Thu Aug 11 06:39:56 2016 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 522E112D5D8 for ; Thu, 11 Aug 2016 06:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.465 X-Spam-Level: X-Spam-Status: No, score=-5.465 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, 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 aYD3Iv5KuOid for ; Thu, 11 Aug 2016 06:39:52 -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 8BFDE12D59A for ; Thu, 11 Aug 2016 06:39:52 -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 u7BDdouH005978 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 11 Aug 2016 13:39:50 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u7BDdnOh014432 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 11 Aug 2016 13:39:49 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 u7BDdm61026134; Thu, 11 Aug 2016 13:39:49 GMT Received: from [192.168.1.6] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 11 Aug 2016 06:39:47 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-3AC76CF9-7273-48C4-944B-C471ACB2E24D Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (13G34) In-Reply-To: Date: Thu, 11 Aug 2016 06:39:44 -0700 Content-Transfer-Encoding: 7bit Message-Id: <3F0DD3E6-46CD-4AA5-8F06-F79140F5D4BE@oracle.com> References: <14E2EF51-7123-4E91-87DD-56AEA08202C1@oracle.com> To: Mike Jones X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: "id-event@ietf.org" , Marius Scurtescu Subject: Re: [Id-event] Summarizing recent discussions on ID-Event token draft X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 11 Aug 2016 13:39:55 -0000 --Apple-Mail-3AC76CF9-7273-48C4-944B-C471ACB2E24D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I think using sub at the top level leads to complexity. Eg Can you provide a= rule for when top level is used or not by an individual spec? IMO. Top lev= el should always be used the same way by all implementers.=20 Based on the calls at risc/connect, we discussed that it would be best to mo= ve all event specifics to the event object area. This way different events c= an have different event addressing (eg sub/iss, uri, jit/iss). When iss is n= eeded to uniquely qualify a sub, it can be provided without conflicting with= the issuer of the event. Similarly jti and iss can be used for a revoked to= ken without conflicting with the event jti.=20 I plan to post a new draft shortly that will give some examples based on fee= dback from the openid risc/connect discussions. We can always change again.=20 Phil > On Aug 11, 2016, at 4:54 AM, Mike Jones wrot= e: >=20 > No, I=E2=80=99m not saying that =E2=80=9Csub=E2=80=9D cannot appear at the= top level. I=E2=80=99m saying that =E2=80=9Csub=E2=80=9D will only occur a= t the top level if the particular event defines that =E2=80=9Csub=E2=80=9D i= s used in that way for that event. > =20 > There are probably use cases for multiple events per message but I doubt t= here are use cases for multiple *unrelated* events per message. By definiti= on, related events that use top-level claims would need to use them in a com= patible way. I don=E2=80=99t see that as being a problem. > =20 > That being said, the predominant use case is likely to be a single event p= er JWT. > =20 > -- Mi= ke > =20 > From: Marius Scurtescu [mailto:mscurtescu@google.com]=20 > Sent: Tuesday, August 9, 2016 7:15 PM > To: Phil Hunt > Cc: Mike Jones ; id-event@ietf.org > Subject: Re: [Id-event] Summarizing recent discussions on ID-Event token d= raft > =20 > Mike, are you suggesting that a sub claim can only show up at the event le= vel and not at the top level: > =20 > In particular, the only thing that the spec should say about the =E2=80=9C= sub=E2=80=9D claim is that =E2=80=9CLike all other claims other than =E2=80=98= events=E2=80=99 and =E2=80=98iss=E2=80=99, whether the =E2=80=98sub=E2=80=99= claim is to be included with an event is entirely event-specific. > =20 > A top level sub and multiple events are incompatible IMO. > =20 > Do we have a compelling reason to support multiple events per message? > =20 >=20 > Marius > =20 > On Tue, Aug 9, 2016 at 12:39 PM, Phil Hunt wrote: > I was referring to this in your email > "Define that an event name can be used as a top-level claim=E2=80=9D > =20 > =20 > Is this different from the event uri? > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > =20 > =20 >=20 > =20 > On Aug 9, 2016, at 12:12 PM, Mike Jones wrot= e: > =20 > I=E2=80=99m glad to hear that we agree on keeping it as simple and general= -purpose as possible and that you agree with my write-up. I think we then h= ave a good path forward. > =20 > I=E2=80=99m not sure what you mean by =E2=80=9CI=E2=80=99m not sure that w= e need a =E2=80=9Cname=E2=80=9D. What is your intention there.=E2=80=9D The= only place I used the word =E2=80=9Cname=E2=80=9D was in my statement =E2=80= =9CDefine that an event name can be used as a top-level claim=E2=80=9D. Wha= t I was trying to get at is was that if =E2=80=9Chttp://specs.openid.net/log= out=E2=80=9D is used as an event name, that it can also be used as a claim n= ame in the JWT containing information about the event. (Maybe I=E2=80=99m n= ot using the correct terminology, hence the unintended confusion J.) > =20 > Thanks again, > -- Mike > =20 > From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 > Sent: Tuesday, August 9, 2016 12:07 PM > To: Mike Jones > Cc: id-event@ietf.org > Subject: Re: [Id-event] Summarizing recent discussions on ID-Event token d= raft > =20 > I didn=E2=80=99t cover this as I didn=E2=80=99t want to confuse people wit= h too many things. > =20 > But I think we agree on all of the below. > =20 > I=E2=80=99m not sure that we need a =E2=80=9Cname=E2=80=9D. What is your i= ntention there. > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > =20 > =20 >=20 > =20 > On Aug 9, 2016, at 11:54 AM, Mike Jones wrot= e: > =20 > Thanks for writing this, Phil. Unfortunately, the summary below does not i= nclude my feedback, which at the essence, is to keep the ID Events data stru= cture as simple and general-purpose as possible. (I strongly believe that J= WT is the success it is because we made JWT as simple and general-purpose as= possible, and we should follow this successful example and do the same here= .) > =20 > I believe that the ID Events spec needs to include these things, and these= things only: > =C2=B7 Define of the =E2=80=9Cevents=E2=80=9D claim > =C2=B7 Define that an event name can be used as a top-level claim > =C2=B7 Require that =E2=80=9Ciss=E2=80=9D be included and that the J= WT be signed by the issuer > =C2=B7 Include a statement along the lines of =E2=80=9CThe claims to= be included with any particular event are to be defined by the event=E2=80=9D= > =20 > And I=E2=80=99d stop there. > =20 > It should be entirely up to applications to say what claims are included w= ith events they define and what their format and meanings are. Then the ID E= vents spec will be as general-purpose as possible, with it being natural for= it to be used in essentially all JSON Event contexts. > =20 > As soon as we start putting restrictions on the use of particular claims b= y events, we=E2=80=99re making the ID Events spec less general-purpose and l= ess natural to use. In particular, the only thing that the spec should say a= bout the =E2=80=9Csub=E2=80=9D claim is that =E2=80=9CLike all other claims o= ther than =E2=80=98events=E2=80=99 and =E2=80=98iss=E2=80=99, whether the =E2= =80=98sub=E2=80=99 claim is to be included with an event is entirely event-s= pecific. The claims to be included with any particular event are explicitly= outside the scope of this specification.=E2=80=9D > =20 > -- Mike > =20 > From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Phil Hunt > Sent: Tuesday, August 9, 2016 10:19 AM > To: id-event@ietf.org > Subject: [Id-event] Summarizing recent discussions on ID-Event token draft= > =20 > I thought I would update the list on some discussions that have been happe= ning over in the OpenID Connect and RISC working groups conference calls. > =20 > These discussions have been about the core spec and the role of =E2=80=9Ct= op-level=E2=80=9D attributes vs. event =E2=80=9Cextension=E2=80=9D attribute= s.=20 > See: https://tools.ietf.org/html/draft-hunt-idevent-token-01 > =20 > In particular should =E2=80=9Csub=E2=80=9D be used in the top level to =E2= =80=9Cpoint=E2=80=9D to the subject (in the broader english sense) of the ev= ent, or should it be constrained to the SAML/ID Token definition which is th= e authenticated user. =20 > =20 > Taken in the narrower definition, it is important to observe that in an ID= Token, =E2=80=9Csub=E2=80=9D and =E2=80=9Ciss=E2=80=9D go together. The is= suer provides the context for the authenticated subject identifier. The prob= lem with events, is that it might not be the AS (or OP) which is issuing the= event. =20 > =20 > To summarize a fair amount of discussion, the feeling seems to be the foll= owing: > =20 > * The Event Token top level attributes should be fairly limited and not i= nclude the sub attribute. =20 > * For events that are about a user, the relevant event specification may i= nclude a =E2=80=9Csub=E2=80=9D attribute within the event=E2=80=99s sub-obje= ct and not in the top-level. Further that sub-object can also include the is= suer of the user. =20 > * The top-level =E2=80=9Ciss=E2=80=9D shall mean the issuer of the event w= here the state change occurred. > * =E2=80=9Csub=E2=80=9D should not be present in the top level structure.= Also, =E2=80=9Cevents=E2=80=9D must also be present. > =20 > Here would be a new example logout: > { > <=E2=80=94 top level is about the event itself -> > "iss": "https://server.example.com", > "aud": "s6BhdRkqt3", > "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", > "iat": 1458668180, > "exp": 1458668580, > "events": [ > "https://specs.openid.net/logout" > ], > "https://specs.openid.net/logout": { > <- This level is defined entirely by the event URI-> > "iss": "https://oidc.example.com", > =E2=80=9Cjti": "08a5019c-17e1-4977-8f42-65a12843ea02=E2=80=9D, > "sub": "248289761001=E2=80=9D, > =E2=80=9Cexp=E2=80=9D: > } > } > =20 > In the above example note that the =E2=80=9Cevent=E2=80=9D object can have= its own iss and subject (sub or jti) that have meaning within the context o= f an OpenID OP provider. The issuer of the event can be different (the top-= level) and represents the entity that signs the event (if it is signed). > =20 > The top-level attributes identify an individual event and are used to vali= date the event (signing etc). Where as the nested object contains all of th= e data about the event and is defined by the profiling specification (e.g. a= possible OpenID Logout Event spec). In this case, in OpenID, logging out u= sually translates into revoking an ID Token. Thus the =E2=80=9Cjti=E2=80=9D f= or the ID token (08a5019c...843ea02) is included in the Logout object. > =20 > Side note. Regarding =E2=80=9Clogout=E2=80=9D, it might be useful to incl= ude the expiry of the ID Token in case the subscriber has not yet received a= n ID Token. This would let the subscriber know how long it needs to keep the= revocation information for. IOW=E2=80=A6after the the ID Token is expired,= the subscriber would no longer need to track the revocation state. > =20 > It is also good to observe that the =E2=80=9Caud=E2=80=9D at the top level= describes the subscriber of the event. This may also be different then the= original audience of the ID Token. > =20 > So to conclude. By making top-level attributes strictly about the events o= wn validation, and nested objects about the event, we avoid collisions in de= finitions such as the issuer of the event, vs. the original issuer of a secu= rity assertion. > =20 > I hope I=E2=80=99ve gotten everyone=E2=80=99s feedback correct here. Lets c= ontinue to discuss. I will revise the draft to follow the groups thinking he= re. > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =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://www.ietf.org/mailman/listinfo/id-event --Apple-Mail-3AC76CF9-7273-48C4-944B-C471ACB2E24D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I think using sub at the top level lea= ds to complexity. Eg Can you provide a rule for when top level is used or no= t by an individual spec?  IMO. Top level should always be used the same= way by all implementers. 

Based on the calls at risc/connect, we disc= ussed that it would be best to move all event specifics to the event object a= rea. This way different events can have different event addressing (eg sub/i= ss, uri, jit/iss). When iss is needed to uniquely qualify a sub, it can be p= rovided without conflicting with the issuer of the event. Similarly jti and i= ss can be used for a revoked token without conflicting with the event jti.&n= bsp;

I plan to post a new draft shortly that will give some examples based o= n feedback from the openid risc/connect discussions.

We can always change a= gain. 

Phil

On Au= g 11, 2016, at 4:54 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

No, I=E2=80=99m not saying that =E2=80=9C= sub=E2=80=9D cannot appear at the top level.  I=E2=80=99m saying that =E2= =80=9Csub=E2=80=9D will only occur at the top level if the particular event d= efines that =E2=80=9Csub=E2=80=9D is used in that way for that event.

 

There are probably use cases for multip= le events per message but I doubt there are use cases for multiple *unrel= ated* events per message.  By definition, related events that use top-level claims would need to use them in a compat= ible way.  I don=E2=80=99t see that as being a problem.

 

That being said, the predominant use ca= se is likely to be a single event per JWT.

 

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

 =

From: Marius Scurtescu [mailto:mscurtescu@google.com]
Sent: Tuesday, August 9, 2016 7:15 PM
To: Phil Hunt <phil.hunt@o= racle.com>
Cc: Mike Jones <Mic= hael.Jones@microsoft.com>; id-ev= ent@ietf.org
Subject: Re: [Id-event] Summarizing recent discussions on ID-Event to= ken draft

 

Mike, are you suggesting that a sub claim can only sh= ow up at the event level and not at the top level:

 

In particular, the only thing that the spec should sa= y about the =E2=80=9Csub=E2=80=9D claim is that =E2=80=9CLike all other clai= ms other than =E2=80=98events=E2=80=99 and =E2=80=98iss=E2=80=99, whether th= e =E2=80=98sub=E2=80=99 claim is to be included with an event is entirely ev= ent-specific.

 

A top level sub and multiple events are incompatible I= MO.

 

Do we have a compelling reason to support multiple ev= ents per message?

 


Marius

 

On Tue, Aug 9, 2016 at 12:39 PM, Phil Hunt <phil.hunt@oracle.com= > wrote:

I was referring to this in your email

"Define that an event name can be used a= s a top-level claim=E2=80=9D

 

 

Is this different from the event uri?

 

Phil

 <= /p>

@independentid=

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

 <= /p>

 <= /p>

 

 

On Aug 9, 2016, at 12:12 PM, Mike Jones <Michael.Jones@microso= ft.com> wrote:

 

I=E2=80=99m glad to hear that we agree o= n keeping it as simple and general-purpose as possible and that you agree wi= th my write-up.  I think we then have a good path forward.

 

I=E2=80=99m not sure what you mean by =E2= =80=9CI=E2=80=99m not sure that we need a =E2=80=9Cname=E2=80=9D. Wha= t is your intention there.=E2=80=9D  The only place I used the word =E2=80=9Cname=E2=80=9D was in my statement =E2= =80=9CDefine that an event name can be used as a top-level claim=E2=80=9D.&n= bsp; What I was trying to get at is was that if =E2=80=9Chttp:= //specs.openid.net/logout=E2=80=9D is used as an event name, that it can also be used as a claim name in the J= WT containing information about the event.  (Maybe I=E2=80=99m not usin= g the correct terminology, hence the unintended confusion J.= )

 

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

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

 

From: Phil Hunt [mailto:phil= .hunt@oracle.com] 
Sent: = ;Tuesday, August 9, 2016 12:07 PM
To: <= /span>Mike Jones <Michael.Jones@microsoft.com>
Cc: <= /span>id-event@ietf.o= rg
Subject:&n= bsp;Re: [Id-event] Summarizing recent discussions on ID-Event token d= raft

 

I didn=E2=80=99t cover this as I didn=E2=80=99t want t= o confuse people with too many things.

 

But I think we agree on all of the below.<= /p>

 

I=E2=80=99m not sure that we need a =E2=80=9Cname=E2=80= =9D. What is your intention there.

 

 

 

 

 

On Aug 9, 2016, at 11:54 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

 

Thanks for writing this, Phil.  Un= fortunately, the summary below does not include my feedback, which at the es= sence, is to keep the ID Events data structure as simple and general-purpose as possible.  (I strongly believe that JWT i= s the success it is because we made JWT as simple and general-purpose as pos= sible, and we should follow this successful example and do the same here.)

 

I believe that the ID Events spec needs= to include these things, and these things only:

=C2=B7&nbs= p;      Define of the =E2=80=9Cevents=E2=80=9D claim

=C2=B7&nbs= p;      Define that an event name can be used as a top-level claim

=C2=B7&nbs= p;      Require that =E2=80=9Ciss=E2=80=9D be included and that the JWT be signed by the is= suer

=C2=B7&nbs= p;      Include a statement along the lines of =E2=80=9CThe claims to be included with any p= articular event are to be defined by the event=E2=80=9D

 

And I=E2=80=99d stop there.=

 

It should be entirely up to application= s to say what claims are included with events they define and what their for= mat and meanings are.  Then the ID Events spec will be as general-purpose as possible, with it being natural for it to be u= sed in essentially all JSON Event contexts.

 

As soon as we start putting restriction= s on the use of particular claims by events, we=E2=80=99re making the ID Eve= nts spec less general-purpose and less natural to use.  In particular, the only thing that the spec should say about the =E2=80=9Cs= ub=E2=80=9D claim is that =E2=80=9CLike all other claims other than =E2=80=98= events=E2=80=99 and =E2=80=98iss=E2=80=99, whether the =E2=80=98sub=E2=80=99= claim is to be included with an event is entirely event-specific.  The= claims to be included with any particular event are explicitly outside the scope of this specification.=E2= =80=9D

 

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

 

From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Phi= l Hunt
Sent: = ;Tuesday, August 9, 2016 10:19 AM
To: <= /span>id-event@ietf.org
Subject:&n= bsp;[Id-event] Summarizing recent discussions on ID-Event token draft=

 

I thought I would update the list on some discussions= that have been happening over in the OpenID Connect and RISC working groups= conference calls.

 

These discussions have been about the core spec and t= he role of =E2=80=9Ctop-level=E2=80=9D attributes vs. event =E2=80=9Cextensi= on=E2=80=9D attributes. 

 

In particular should =E2=80=9Csub=E2=80=9D be used in= the top level to =E2=80=9Cpoint=E2=80=9D to the subject (in the broader eng= lish sense) of the event, or should it be constrained to the SAML/ID Token d= efinition which is the authenticated user.  

 

Taken in the narrower definition, it is important to o= bserve that in an ID Token, =E2=80=9Csub=E2=80=9D and =E2=80=9Ciss=E2=80=9D g= o together.  The issuer provides the context for the authenticated subj= ect identifier. The problem with events, is that it might not be the AS (or OP) which is issuing the event.  

 

To summarize a fair amount of discussion, the feeling= seems to be the following:

 

*  The Event Token top level attributes should b= e fairly limited and not include the sub attribute.  

*  For events that are about a user, the relevan= t event specification may include a =E2=80=9Csub=E2=80=9D attribute within t= he event=E2=80=99s sub-object and not in the top-level. Further that sub-obj= ect can also include the issuer of the user.  

* The top-level =E2=80=9Ciss=E2=80=9D shall mean the i= ssuer of the event where the state change occurred.

*  =E2=80=9Csub=E2=80=9D should not be present i= n the top level structure.  Also, =E2=80=9Cevents=E2=80=9D must also be= present.

 

Here would be a new example logout:

{
  <=E2=80=94 top level is about the event itself ->
  "iss": "https://server.=
example.com",
  "aud": "s6BhdRkqt3",
  "jti": "3d0c3cf797584bd193bd0fb1bd=
4e7d30",
  "iat": 1458668180,
  "exp": 1458668580,
  "events": [

    "https:=
//specs.openid.net/logout"


  ],


  "https://specs.open=
id.net/logout": {


    <- This level is de=
fined entirely by the event URI->


    "iss": "https=
://oidc.example.com",


    =E2=80=9Cjti": "08a501=
9c-17e1-4977-8f42-65a12843ea02=E2=80=9D,


    "sub"=
: "248289761001=E2=80=9D,


    =E2=80=
=9Cexp=E2=80=9D: <ID token expiry>


  }


}








 














In the above example note that the =E2=80=9Cevent=E2=80=
=9D object can have its own iss and subject (sub or jti) that have meaning w=
ithin the context of an OpenID OP provider.  The issuer of the event ca=
n be different (the top-level) and represents the
 entity that signs the event (if it is signed).














 














The top-level attributes identify an individual event=
 and are used to validate the event (signing etc).  Where as the nested=
 object contains all of the data about the event and is defined by the profi=
ling specification (e.g. a possible
 OpenID Logout Event spec).  In this case, in OpenID, logging out usual=
ly translates into revoking an ID Token. Thus the =E2=80=9Cjti=E2=80=9D for t=
he ID token (08a5019c...843ea02) is included in the Logout object.














 














Side note.  Regarding =E2=80=9Clogout=E2=80=9D, i=
t might be useful to include the expiry of the ID Token in case the subscrib=
er has not yet received an ID Token. This would let the subscriber know how l=
ong it needs to keep the revocation information for. 
 IOW=E2=80=A6after the the ID Token is expired, the subscriber would no long=
er need to track the revocation state.














 














It is also good to observe that the =E2=80=9Caud=E2=80=
=9D at the top level describes the subscriber of the event.  This may a=
lso be different then the original audience of the ID Token.














 














So to conclude. By making top-level attributes strict=
ly about the events own validation, and nested objects about the event, we a=
void collisions in definitions such as the issuer of the event, vs. the orig=
inal issuer of a security assertion.














 














I hope I=E2=80=99ve gotten everyone=E2=80=99s feedbac=
k correct here. Lets continue to discuss. I will revise the draft to follow t=
he groups thinking here.














 

 

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

 


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

 

____________________= ___________________________
Id-event mailing list
= Id-event@ietf.org
<= span>https://www.= ietf.org/mailman/listinfo/id-event
<= /html>= --Apple-Mail-3AC76CF9-7273-48C4-944B-C471ACB2E24D-- From nobody Thu Aug 11 08:03:47 2016 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 E622A12D575 for ; Thu, 11 Aug 2016 08:03:44 -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 OlM6x3v3g_HR for ; Thu, 11 Aug 2016 08:03:40 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0130.outbound.protection.outlook.com [104.47.33.130]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE8E712D11B for ; Thu, 11 Aug 2016 08:03: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=RYI0XehCUZVO9KxRc79pXoI/zDgQXny0Ueep7sZe66I=; b=HCruPM1hCUGacQSEoVD08b7spAH8rvCP+0wcYx8ySUsKLrhcuvHfE3yDQUwSfrEXsOscBp1htkzbt1WwW1v2mpcX/calo8l5vt5YgKUBedXYfHEqcynima+DwvWGdYoxJMQOWLGKCfQPawA+6bT9KeGcQ+2DBWdzdHsu5/lxPZM= Received: from SN1PR0301MB1645.namprd03.prod.outlook.com (10.162.130.139) by SN1PR0301MB1647.namprd03.prod.outlook.com (10.162.130.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Thu, 11 Aug 2016 15:03:27 +0000 Received: from SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) by SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) with mapi id 15.01.0549.025; Thu, 11 Aug 2016 15:03:28 +0000 From: Mike Jones To: "Phil Hunt (IDM)" Thread-Topic: [Id-event] Summarizing recent discussions on ID-Event token draft Thread-Index: AQHR8mIWLvqeOEkcuEuQk5SeT4z/pKBA9pTwgAAG/gCAAABNAIAACP2AgAA8CICAAmTu0IAAHwwAgAAWu7A= Date: Thu, 11 Aug 2016 15:03:27 +0000 Message-ID: References: <14E2EF51-7123-4E91-87DD-56AEA08202C1@oracle.com> <3F0DD3E6-46CD-4AA5-8F06-F79140F5D4BE@oracle.com> In-Reply-To: <3F0DD3E6-46CD-4AA5-8F06-F79140F5D4BE@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.201.94.142] x-ms-office365-filtering-correlation-id: fd080cf2-f0d8-49c7-cdc8-08d3c1f8a69f x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1647; 6:56aimNKFGgCrhAjct2KSPRU0+U/9urWuHSSZgxtDwoHQGYA1d25L74J5vrIfmhPaPqVSEA00JfphAnd6D9smcW6LHjkXGP5LvZBghtB2Fs7jm02nnVynXu2UEpKZ3zZgbkz0Abw0RJpcAqIKFldYZdo+x7l2MR3+iX8Vd8D1IQlNEF8KKne4TeCK7yV6olCHSsC+z2vNLEhE2VM/P9ZRqfaiHtuPEaexx1F5N/GsqW00A7q2Er1Uc51nBaw4YVT6GhR8rDvCcTRezLLOY691V1Mz5eAb7ftfdyUz1KT3GxheP3djds3unpAgPRENJLIoHo26tltlGmllpK8q5LZC+A==; 5:uFTAtq7s8Hr8FUvf+mFT2BfsuyDyfNlj4GOtmBT7hgjpk496ZekcE3m34UP70XjPfINDeAJPY5zKd9TPZf9//HhEy0kqn2HhiQe3hHUg85HsEKwya665hTkjWW3j62qE40TBjeU0pPLQ+X2lu+7EFA==; 24:Qdj19LAO1WfB/nYdDo+C/BnJo+HcOu3aeA7qCwdUW12VCNFvKuP3fbRk2bTtGE8nLK2gR0MXutBRjy7DixZhgXfbdqN4VTzi09jIJ5tVUPY=; 7:/8L+/vfz/Sor1iazSNKJ76G2zjraOFIVas2Fn/UI4IG+7aT5m6nmd06mbtc9FY5ZffE21gSpb7oN5ZkLsV2NNBejV9KIXtoj/SbgG95LzjPs77RfEcp0Q6N+66bnMeimL7ipzPjtlz4bPiKWUlCiB/hxLQjktqcyqKDuInTMdxu93rmnAnoA0FhViw1EQXstvWNsbh3KNGSKbtJvltCt8zcxIjlXurCusNO3JwwPFffvPxHZ/nD6dq5T3KTOhZjN x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1647; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(278428928389397)(192374486261705)(211936372134217)(21748063052155)(21532816269658)(146099531331640); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:SN1PR0301MB1647; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1647; x-forefront-prvs: 0031A0FFAF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(43784003)(199003)(189002)(24454002)(377454003)(81166006)(97736004)(93886004)(7846002)(92566002)(586003)(2900100001)(74316002)(2950100001)(110136002)(77096005)(8676002)(6116002)(7906003)(15975445007)(7696003)(4326007)(790700001)(1860700003)(189998001)(3846002)(8990500004)(3280700002)(2906002)(122556002)(5005710100001)(7736002)(10400500002)(10090500001)(102836003)(10290500002)(8936002)(3660700001)(81156014)(9686002)(68736007)(5002640100001)(54356999)(19625215002)(50986999)(101416001)(76176999)(33656002)(99286002)(19300405004)(19580395003)(19617315012)(76576001)(19580405001)(106116001)(106356001)(86362001)(575784001)(19609705001)(16236675004)(87936001)(105586002)(16601075003)(66066001)(86612001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0301MB1647; H:SN1PR0301MB1645.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB164529CA9F3E68306F2F2EB2F51E0SN1PR0301MB1645_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Aug 2016 15:03:27.8911 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1647 Archived-At: Cc: "id-event@ietf.org" , Marius Scurtescu Subject: Re: [Id-event] Summarizing recent discussions on ID-Event token draft X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 11 Aug 2016 15:03:45 -0000 --_000_SN1PR0301MB164529CA9F3E68306F2F2EB2F51E0SN1PR0301MB1645_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIHNpbXBsZSBydWxlIGlzIHRoYXQgaWYgdGhlIHBhcnRpY3VsYXIgZXZlbnQgY2FsbHMgZm9y IHRoZSDigJxzdWLigJ0gY2xhaW0gdG8gYmUgYXQgdGhlIHRvcCBsZXZlbCwgdGhlbiBpdCBpcy4g IFRoaXMgaXMgbm8gZGlmZmVyZW50IGZyb20gYW55IG90aGVyIGNsYWltIHRoYXQgYW4gZXZlbnQg bWlnaHQgcGxhY2UgYXQgdGhlIHRvcCBsZXZlbC4NCg0KVGhlIGNvbXBsZXhpdHkgYXJpc2VzIGlm IOKAnHN1YuKAnSBpcyB1bm5lY2Vzc2FyaWx5IHNwZWNpYWwtY2FzZWQuICBXZSBzaG91bGRu4oCZ dCBkbyB0aGF0LCBiZWNhdXNlIGl0IGxpbWl0cyB0aGUgYXBwbGljYWJpbGl0eSBvZiB0aGUgc3Bl Y2lmaWNhdGlvbi4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogUGhpbCBIdW50IChJRE0pIFttYWlsdG86cGhp bC5odW50QG9yYWNsZS5jb21dDQpTZW50OiBUaHVyc2RheSwgQXVndXN0IDExLCAyMDE2IDk6NDAg QU0NClRvOiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+DQpDYzogTWFy aXVzIFNjdXJ0ZXNjdSA8bXNjdXJ0ZXNjdUBnb29nbGUuY29tPjsgaWQtZXZlbnRAaWV0Zi5vcmcN ClN1YmplY3Q6IFJlOiBbSWQtZXZlbnRdIFN1bW1hcml6aW5nIHJlY2VudCBkaXNjdXNzaW9ucyBv biBJRC1FdmVudCB0b2tlbiBkcmFmdA0KDQpJIHRoaW5rIHVzaW5nIHN1YiBhdCB0aGUgdG9wIGxl dmVsIGxlYWRzIHRvIGNvbXBsZXhpdHkuIEVnIENhbiB5b3UgcHJvdmlkZSBhIHJ1bGUgZm9yIHdo ZW4gdG9wIGxldmVsIGlzIHVzZWQgb3Igbm90IGJ5IGFuIGluZGl2aWR1YWwgc3BlYz8gIElNTy4g VG9wIGxldmVsIHNob3VsZCBhbHdheXMgYmUgdXNlZCB0aGUgc2FtZSB3YXkgYnkgYWxsIGltcGxl bWVudGVycy4NCg0KQmFzZWQgb24gdGhlIGNhbGxzIGF0IHJpc2MvY29ubmVjdCwgd2UgZGlzY3Vz c2VkIHRoYXQgaXQgd291bGQgYmUgYmVzdCB0byBtb3ZlIGFsbCBldmVudCBzcGVjaWZpY3MgdG8g dGhlIGV2ZW50IG9iamVjdCBhcmVhLiBUaGlzIHdheSBkaWZmZXJlbnQgZXZlbnRzIGNhbiBoYXZl IGRpZmZlcmVudCBldmVudCBhZGRyZXNzaW5nIChlZyBzdWIvaXNzLCB1cmksIGppdC9pc3MpLiBX aGVuIGlzcyBpcyBuZWVkZWQgdG8gdW5pcXVlbHkgcXVhbGlmeSBhIHN1YiwgaXQgY2FuIGJlIHBy b3ZpZGVkIHdpdGhvdXQgY29uZmxpY3Rpbmcgd2l0aCB0aGUgaXNzdWVyIG9mIHRoZSBldmVudC4g U2ltaWxhcmx5IGp0aSBhbmQgaXNzIGNhbiBiZSB1c2VkIGZvciBhIHJldm9rZWQgdG9rZW4gd2l0 aG91dCBjb25mbGljdGluZyB3aXRoIHRoZSBldmVudCBqdGkuDQoNCkkgcGxhbiB0byBwb3N0IGEg bmV3IGRyYWZ0IHNob3J0bHkgdGhhdCB3aWxsIGdpdmUgc29tZSBleGFtcGxlcyBiYXNlZCBvbiBm ZWVkYmFjayBmcm9tIHRoZSBvcGVuaWQgcmlzYy9jb25uZWN0IGRpc2N1c3Npb25zLg0KDQpXZSBj YW4gYWx3YXlzIGNoYW5nZSBhZ2Fpbi4NCg0KUGhpbA0KDQpPbiBBdWcgMTEsIDIwMTYsIGF0IDQ6 NTQgQU0sIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWlj aGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpObywgSeKAmW0gbm90IHNheWluZyB0 aGF0IOKAnHN1YuKAnSBjYW5ub3QgYXBwZWFyIGF0IHRoZSB0b3AgbGV2ZWwuICBJ4oCZbSBzYXlp bmcgdGhhdCDigJxzdWLigJ0gd2lsbCBvbmx5IG9jY3VyIGF0IHRoZSB0b3AgbGV2ZWwgaWYgdGhl IHBhcnRpY3VsYXIgZXZlbnQgZGVmaW5lcyB0aGF0IOKAnHN1YuKAnSBpcyB1c2VkIGluIHRoYXQg d2F5IGZvciB0aGF0IGV2ZW50Lg0KDQpUaGVyZSBhcmUgcHJvYmFibHkgdXNlIGNhc2VzIGZvciBt dWx0aXBsZSBldmVudHMgcGVyIG1lc3NhZ2UgYnV0IEkgZG91YnQgdGhlcmUgYXJlIHVzZSBjYXNl cyBmb3IgbXVsdGlwbGUgKnVucmVsYXRlZCogZXZlbnRzIHBlciBtZXNzYWdlLiAgQnkgZGVmaW5p dGlvbiwgcmVsYXRlZCBldmVudHMgdGhhdCB1c2UgdG9wLWxldmVsIGNsYWltcyB3b3VsZCBuZWVk IHRvIHVzZSB0aGVtIGluIGEgY29tcGF0aWJsZSB3YXkuICBJIGRvbuKAmXQgc2VlIHRoYXQgYXMg YmVpbmcgYSBwcm9ibGVtLg0KDQpUaGF0IGJlaW5nIHNhaWQsIHRoZSBwcmVkb21pbmFudCB1c2Ug Y2FzZSBpcyBsaWtlbHkgdG8gYmUgYSBzaW5nbGUgZXZlbnQgcGVyIEpXVC4NCg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgLS0gTWlrZQ0KDQpGcm9tOiBNYXJpdXMgU2N1cnRlc2N1IFttYWlsdG86bXNjdXJ0ZXNjdUBn b29nbGUuY29tXQ0KU2VudDogVHVlc2RheSwgQXVndXN0IDksIDIwMTYgNzoxNSBQTQ0KVG86IFBo aWwgSHVudCA8cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29t Pj4NCkNjOiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1p Y2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+OyBpZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86aWQt ZXZlbnRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0lkLWV2ZW50XSBTdW1tYXJpemluZyByZWNl bnQgZGlzY3Vzc2lvbnMgb24gSUQtRXZlbnQgdG9rZW4gZHJhZnQNCg0KTWlrZSwgYXJlIHlvdSBz dWdnZXN0aW5nIHRoYXQgYSBzdWIgY2xhaW0gY2FuIG9ubHkgc2hvdyB1cCBhdCB0aGUgZXZlbnQg bGV2ZWwgYW5kIG5vdCBhdCB0aGUgdG9wIGxldmVsOg0KDQpJbiBwYXJ0aWN1bGFyLCB0aGUgb25s eSB0aGluZyB0aGF0IHRoZSBzcGVjIHNob3VsZCBzYXkgYWJvdXQgdGhlIOKAnHN1YuKAnSBjbGFp bSBpcyB0aGF0IOKAnExpa2UgYWxsIG90aGVyIGNsYWltcyBvdGhlciB0aGFuIOKAmGV2ZW50c+KA mSBhbmQg4oCYaXNz4oCZLCB3aGV0aGVyIHRoZSDigJhzdWLigJkgY2xhaW0gaXMgdG8gYmUgaW5j bHVkZWQgd2l0aCBhbiBldmVudCBpcyBlbnRpcmVseSBldmVudC1zcGVjaWZpYy4NCg0KQSB0b3Ag bGV2ZWwgc3ViIGFuZCBtdWx0aXBsZSBldmVudHMgYXJlIGluY29tcGF0aWJsZSBJTU8uDQoNCkRv IHdlIGhhdmUgYSBjb21wZWxsaW5nIHJlYXNvbiB0byBzdXBwb3J0IG11bHRpcGxlIGV2ZW50cyBw ZXIgbWVzc2FnZT8NCg0KDQpNYXJpdXMNCg0KT24gVHVlLCBBdWcgOSwgMjAxNiBhdCAxMjozOSBQ TSwgUGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNs ZS5jb20+PiB3cm90ZToNCkkgd2FzIHJlZmVycmluZyB0byB0aGlzIGluIHlvdXIgZW1haWwNCiJE ZWZpbmUgdGhhdCBhbiBldmVudCBuYW1lIGNhbiBiZSB1c2VkIGFzIGEgdG9wLWxldmVsIGNsYWlt 4oCdDQoNCg0KSXMgdGhpcyBkaWZmZXJlbnQgZnJvbSB0aGUgZXZlbnQgdXJpPw0KDQpQaGlsDQoN CkBpbmRlcGVuZGVudGlkDQp3d3cuaW5kZXBlbmRlbnRpZC5jb208aHR0cDovL3d3dy5pbmRlcGVu ZGVudGlkLmNvbT4NCnBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xl LmNvbT4NCg0KDQoNCg0KT24gQXVnIDksIDIwMTYsIGF0IDEyOjEyIFBNLCBNaWtlIEpvbmVzIDxN aWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0 LmNvbT4+IHdyb3RlOg0KDQpJ4oCZbSBnbGFkIHRvIGhlYXIgdGhhdCB3ZSBhZ3JlZSBvbiBrZWVw aW5nIGl0IGFzIHNpbXBsZSBhbmQgZ2VuZXJhbC1wdXJwb3NlIGFzIHBvc3NpYmxlIGFuZCB0aGF0 IHlvdSBhZ3JlZSB3aXRoIG15IHdyaXRlLXVwLiAgSSB0aGluayB3ZSB0aGVuIGhhdmUgYSBnb29k IHBhdGggZm9yd2FyZC4NCg0KSeKAmW0gbm90IHN1cmUgd2hhdCB5b3UgbWVhbiBieSDigJxJ4oCZ bSBub3Qgc3VyZSB0aGF0IHdlIG5lZWQgYSDigJxuYW1l4oCdLiBXaGF0IGlzIHlvdXIgaW50ZW50 aW9uIHRoZXJlLuKAnSAgVGhlIG9ubHkgcGxhY2UgSSB1c2VkIHRoZSB3b3JkIOKAnG5hbWXigJ0g d2FzIGluIG15IHN0YXRlbWVudCDigJxEZWZpbmUgdGhhdCBhbiBldmVudCBuYW1lIGNhbiBiZSB1 c2VkIGFzIGEgdG9wLWxldmVsIGNsYWlt4oCdLiAgV2hhdCBJIHdhcyB0cnlpbmcgdG8gZ2V0IGF0 IGlzIHdhcyB0aGF0IGlmIOKAnGh0dHA6Ly9zcGVjcy5vcGVuaWQubmV0L2xvZ291dOKAnSBpcyB1 c2VkIGFzIGFuIGV2ZW50IG5hbWUsIHRoYXQgaXQgY2FuIGFsc28gYmUgdXNlZCBhcyBhIGNsYWlt IG5hbWUgaW4gdGhlIEpXVCBjb250YWluaW5nIGluZm9ybWF0aW9uIGFib3V0IHRoZSBldmVudC4g IChNYXliZSBJ4oCZbSBub3QgdXNpbmcgdGhlIGNvcnJlY3QgdGVybWlub2xvZ3ksIGhlbmNlIHRo ZSB1bmludGVuZGVkIGNvbmZ1c2lvbiDimLouKQ0KDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVGhhbmtzIGFnYWluLA0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJv bTogUGhpbCBIdW50IFttYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb21dDQpTZW50OiBUdWVzZGF5 LCBBdWd1c3QgOSwgMjAxNiAxMjowNyBQTQ0KVG86IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNA bWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4NCkNjOiBp ZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86aWQtZXZlbnRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTog W0lkLWV2ZW50XSBTdW1tYXJpemluZyByZWNlbnQgZGlzY3Vzc2lvbnMgb24gSUQtRXZlbnQgdG9r ZW4gZHJhZnQNCg0KSSBkaWRu4oCZdCBjb3ZlciB0aGlzIGFzIEkgZGlkbuKAmXQgd2FudCB0byBj b25mdXNlIHBlb3BsZSB3aXRoIHRvbyBtYW55IHRoaW5ncy4NCg0KQnV0IEkgdGhpbmsgd2UgYWdy ZWUgb24gYWxsIG9mIHRoZSBiZWxvdy4NCg0KSeKAmW0gbm90IHN1cmUgdGhhdCB3ZSBuZWVkIGEg 4oCcbmFtZeKAnS4gV2hhdCBpcyB5b3VyIGludGVudGlvbiB0aGVyZS4NCg0KUGhpbA0KDQpAaW5k ZXBlbmRlbnRpZA0Kd3d3LmluZGVwZW5kZW50aWQuY29tPGh0dHA6Ly93d3cuaW5kZXBlbmRlbnRp ZC5jb20vPg0KcGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29t Pg0KDQoNCg0KDQpPbiBBdWcgOSwgMjAxNiwgYXQgMTE6NTQgQU0sIE1pa2UgSm9uZXMgPE1pY2hh ZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29t Pj4gd3JvdGU6DQoNClRoYW5rcyBmb3Igd3JpdGluZyB0aGlzLCBQaGlsLiAgVW5mb3J0dW5hdGVs eSwgdGhlIHN1bW1hcnkgYmVsb3cgZG9lcyBub3QgaW5jbHVkZSBteSBmZWVkYmFjaywgd2hpY2gg YXQgdGhlIGVzc2VuY2UsIGlzIHRvIGtlZXAgdGhlIElEIEV2ZW50cyBkYXRhIHN0cnVjdHVyZSBh cyBzaW1wbGUgYW5kIGdlbmVyYWwtcHVycG9zZSBhcyBwb3NzaWJsZS4gIChJIHN0cm9uZ2x5IGJl bGlldmUgdGhhdCBKV1QgaXMgdGhlIHN1Y2Nlc3MgaXQgaXMgYmVjYXVzZSB3ZSBtYWRlIEpXVCBh cyBzaW1wbGUgYW5kIGdlbmVyYWwtcHVycG9zZSBhcyBwb3NzaWJsZSwgYW5kIHdlIHNob3VsZCBm b2xsb3cgdGhpcyBzdWNjZXNzZnVsIGV4YW1wbGUgYW5kIGRvIHRoZSBzYW1lIGhlcmUuKQ0KDQpJ IGJlbGlldmUgdGhhdCB0aGUgSUQgRXZlbnRzIHNwZWMgbmVlZHMgdG8gaW5jbHVkZSB0aGVzZSB0 aGluZ3MsIGFuZCB0aGVzZSB0aGluZ3Mgb25seToNCuKAoiAgICAgICBEZWZpbmUgb2YgdGhlIOKA nGV2ZW50c+KAnSBjbGFpbQ0K4oCiICAgICAgIERlZmluZSB0aGF0IGFuIGV2ZW50IG5hbWUgY2Fu IGJlIHVzZWQgYXMgYSB0b3AtbGV2ZWwgY2xhaW0NCuKAoiAgICAgICBSZXF1aXJlIHRoYXQg4oCc aXNz4oCdIGJlIGluY2x1ZGVkIGFuZCB0aGF0IHRoZSBKV1QgYmUgc2lnbmVkIGJ5IHRoZSBpc3N1 ZXINCuKAoiAgICAgICBJbmNsdWRlIGEgc3RhdGVtZW50IGFsb25nIHRoZSBsaW5lcyBvZiDigJxU aGUgY2xhaW1zIHRvIGJlIGluY2x1ZGVkIHdpdGggYW55IHBhcnRpY3VsYXIgZXZlbnQgYXJlIHRv IGJlIGRlZmluZWQgYnkgdGhlIGV2ZW504oCdDQoNCkFuZCBJ4oCZZCBzdG9wIHRoZXJlLg0KDQpJ dCBzaG91bGQgYmUgZW50aXJlbHkgdXAgdG8gYXBwbGljYXRpb25zIHRvIHNheSB3aGF0IGNsYWlt cyBhcmUgaW5jbHVkZWQgd2l0aCBldmVudHMgdGhleSBkZWZpbmUgYW5kIHdoYXQgdGhlaXIgZm9y bWF0IGFuZCBtZWFuaW5ncyBhcmUuICBUaGVuIHRoZSBJRCBFdmVudHMgc3BlYyB3aWxsIGJlIGFz IGdlbmVyYWwtcHVycG9zZSBhcyBwb3NzaWJsZSwgd2l0aCBpdCBiZWluZyBuYXR1cmFsIGZvciBp dCB0byBiZSB1c2VkIGluIGVzc2VudGlhbGx5IGFsbCBKU09OIEV2ZW50IGNvbnRleHRzLg0KDQpB cyBzb29uIGFzIHdlIHN0YXJ0IHB1dHRpbmcgcmVzdHJpY3Rpb25zIG9uIHRoZSB1c2Ugb2YgcGFy dGljdWxhciBjbGFpbXMgYnkgZXZlbnRzLCB3ZeKAmXJlIG1ha2luZyB0aGUgSUQgRXZlbnRzIHNw ZWMgbGVzcyBnZW5lcmFsLXB1cnBvc2UgYW5kIGxlc3MgbmF0dXJhbCB0byB1c2UuICBJbiBwYXJ0 aWN1bGFyLCB0aGUgb25seSB0aGluZyB0aGF0IHRoZSBzcGVjIHNob3VsZCBzYXkgYWJvdXQgdGhl IOKAnHN1YuKAnSBjbGFpbSBpcyB0aGF0IOKAnExpa2UgYWxsIG90aGVyIGNsYWltcyBvdGhlciB0 aGFuIOKAmGV2ZW50c+KAmSBhbmQg4oCYaXNz4oCZLCB3aGV0aGVyIHRoZSDigJhzdWLigJkgY2xh aW0gaXMgdG8gYmUgaW5jbHVkZWQgd2l0aCBhbiBldmVudCBpcyBlbnRpcmVseSBldmVudC1zcGVj aWZpYy4gIFRoZSBjbGFpbXMgdG8gYmUgaW5jbHVkZWQgd2l0aCBhbnkgcGFydGljdWxhciBldmVu dCBhcmUgZXhwbGljaXRseSBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIHNwZWNpZmljYXRpb24u 4oCdDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAtLSBNaWtlDQoNCkZyb206IElkLWV2ZW50IFttYWlsdG86aWQtZXZlbnQtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIFBoaWwgSHVudA0KU2VudDogVHVlc2RheSwgQXVndXN0IDks IDIwMTYgMTA6MTkgQU0NClRvOiBpZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86aWQtZXZlbnRAaWV0 Zi5vcmc+DQpTdWJqZWN0OiBbSWQtZXZlbnRdIFN1bW1hcml6aW5nIHJlY2VudCBkaXNjdXNzaW9u cyBvbiBJRC1FdmVudCB0b2tlbiBkcmFmdA0KDQpJIHRob3VnaHQgSSB3b3VsZCB1cGRhdGUgdGhl IGxpc3Qgb24gc29tZSBkaXNjdXNzaW9ucyB0aGF0IGhhdmUgYmVlbiBoYXBwZW5pbmcgb3ZlciBp biB0aGUgT3BlbklEIENvbm5lY3QgYW5kIFJJU0Mgd29ya2luZyBncm91cHMgY29uZmVyZW5jZSBj YWxscy4NCg0KVGhlc2UgZGlzY3Vzc2lvbnMgaGF2ZSBiZWVuIGFib3V0IHRoZSBjb3JlIHNwZWMg YW5kIHRoZSByb2xlIG9mIOKAnHRvcC1sZXZlbOKAnSBhdHRyaWJ1dGVzIHZzLiBldmVudCDigJxl eHRlbnNpb27igJ0gYXR0cmlidXRlcy4NClNlZTogaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWh1bnQtaWRldmVudC10b2tlbi0wMQ0KDQpJbiBwYXJ0aWN1bGFyIHNob3VsZCDigJxz dWLigJ0gYmUgdXNlZCBpbiB0aGUgdG9wIGxldmVsIHRvIOKAnHBvaW504oCdIHRvIHRoZSBzdWJq ZWN0IChpbiB0aGUgYnJvYWRlciBlbmdsaXNoIHNlbnNlKSBvZiB0aGUgZXZlbnQsIG9yIHNob3Vs ZCBpdCBiZSBjb25zdHJhaW5lZCB0byB0aGUgU0FNTC9JRCBUb2tlbiBkZWZpbml0aW9uIHdoaWNo IGlzIHRoZSBhdXRoZW50aWNhdGVkIHVzZXIuDQoNClRha2VuIGluIHRoZSBuYXJyb3dlciBkZWZp bml0aW9uLCBpdCBpcyBpbXBvcnRhbnQgdG8gb2JzZXJ2ZSB0aGF0IGluIGFuIElEIFRva2VuLCDi gJxzdWLigJ0gYW5kIOKAnGlzc+KAnSBnbyB0b2dldGhlci4gIFRoZSBpc3N1ZXIgcHJvdmlkZXMg dGhlIGNvbnRleHQgZm9yIHRoZSBhdXRoZW50aWNhdGVkIHN1YmplY3QgaWRlbnRpZmllci4gVGhl IHByb2JsZW0gd2l0aCBldmVudHMsIGlzIHRoYXQgaXQgbWlnaHQgbm90IGJlIHRoZSBBUyAob3Ig T1ApIHdoaWNoIGlzIGlzc3VpbmcgdGhlIGV2ZW50Lg0KDQpUbyBzdW1tYXJpemUgYSBmYWlyIGFt b3VudCBvZiBkaXNjdXNzaW9uLCB0aGUgZmVlbGluZyBzZWVtcyB0byBiZSB0aGUgZm9sbG93aW5n Og0KDQoqICBUaGUgRXZlbnQgVG9rZW4gdG9wIGxldmVsIGF0dHJpYnV0ZXMgc2hvdWxkIGJlIGZh aXJseSBsaW1pdGVkIGFuZCBub3QgaW5jbHVkZSB0aGUgc3ViIGF0dHJpYnV0ZS4NCiogIEZvciBl dmVudHMgdGhhdCBhcmUgYWJvdXQgYSB1c2VyLCB0aGUgcmVsZXZhbnQgZXZlbnQgc3BlY2lmaWNh dGlvbiBtYXkgaW5jbHVkZSBhIOKAnHN1YuKAnSBhdHRyaWJ1dGUgd2l0aGluIHRoZSBldmVudOKA mXMgc3ViLW9iamVjdCBhbmQgbm90IGluIHRoZSB0b3AtbGV2ZWwuIEZ1cnRoZXIgdGhhdCBzdWIt b2JqZWN0IGNhbiBhbHNvIGluY2x1ZGUgdGhlIGlzc3VlciBvZiB0aGUgdXNlci4NCiogVGhlIHRv cC1sZXZlbCDigJxpc3PigJ0gc2hhbGwgbWVhbiB0aGUgaXNzdWVyIG9mIHRoZSBldmVudCB3aGVy ZSB0aGUgc3RhdGUgY2hhbmdlIG9jY3VycmVkLg0KKiAg4oCcc3Vi4oCdIHNob3VsZCBub3QgYmUg cHJlc2VudCBpbiB0aGUgdG9wIGxldmVsIHN0cnVjdHVyZS4gIEFsc28sIOKAnGV2ZW50c+KAnSBt dXN0IGFsc28gYmUgcHJlc2VudC4NCg0KSGVyZSB3b3VsZCBiZSBhIG5ldyBleGFtcGxlIGxvZ291 dDoNCg0Kew0KDQogIDzigJQgdG9wIGxldmVsIGlzIGFib3V0IHRoZSBldmVudCBpdHNlbGYgLT4N Cg0KICAiaXNzIjogImh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tPGh0dHBzOi8vc2VydmVyLmV4 YW1wbGUuY29tLz4iLA0KDQogICJhdWQiOiAiczZCaGRSa3F0MyIsDQoNCiAgImp0aSI6ICIzZDBj M2NmNzk3NTg0YmQxOTNiZDBmYjFiZDRlN2QzMCIsDQoNCiAgImlhdCI6IDE0NTg2NjgxODAsDQoN CiAgImV4cCI6IDE0NTg2Njg1ODAsDQoNCiAgImV2ZW50cyI6IFsNCg0KICAgICJodHRwczovL3Nw ZWNzLm9wZW5pZC5uZXQvbG9nb3V0Ig0KDQogIF0sDQoNCiAgImh0dHBzOi8vc3BlY3Mub3Blbmlk Lm5ldC9sb2dvdXQiOiB7DQoNCiAgICA8LSBUaGlzIGxldmVsIGlzIGRlZmluZWQgZW50aXJlbHkg YnkgdGhlIGV2ZW50IFVSSS0+DQoNCiAgICAiaXNzIjogImh0dHBzOi8vb2lkYy5leGFtcGxlLmNv bTxodHRwczovL29pZGMuZXhhbXBsZS5jb20vPiIsDQoNCiAgICDigJxqdGkiOiAiMDhhNTAxOWMt MTdlMS00OTc3LThmNDItNjVhMTI4NDNlYTAy4oCdLA0KDQogICAgInN1YiI6ICIyNDgyODk3NjEw MDHigJ0sDQoNCiAgICDigJxleHDigJ06IDxJRCB0b2tlbiBleHBpcnk+DQoNCiAgfQ0KDQp9DQoN CkluIHRoZSBhYm92ZSBleGFtcGxlIG5vdGUgdGhhdCB0aGUg4oCcZXZlbnTigJ0gb2JqZWN0IGNh biBoYXZlIGl0cyBvd24gaXNzIGFuZCBzdWJqZWN0IChzdWIgb3IganRpKSB0aGF0IGhhdmUgbWVh bmluZyB3aXRoaW4gdGhlIGNvbnRleHQgb2YgYW4gT3BlbklEIE9QIHByb3ZpZGVyLiAgVGhlIGlz c3VlciBvZiB0aGUgZXZlbnQgY2FuIGJlIGRpZmZlcmVudCAodGhlIHRvcC1sZXZlbCkgYW5kIHJl cHJlc2VudHMgdGhlIGVudGl0eSB0aGF0IHNpZ25zIHRoZSBldmVudCAoaWYgaXQgaXMgc2lnbmVk KS4NCg0KVGhlIHRvcC1sZXZlbCBhdHRyaWJ1dGVzIGlkZW50aWZ5IGFuIGluZGl2aWR1YWwgZXZl bnQgYW5kIGFyZSB1c2VkIHRvIHZhbGlkYXRlIHRoZSBldmVudCAoc2lnbmluZyBldGMpLiAgV2hl cmUgYXMgdGhlIG5lc3RlZCBvYmplY3QgY29udGFpbnMgYWxsIG9mIHRoZSBkYXRhIGFib3V0IHRo ZSBldmVudCBhbmQgaXMgZGVmaW5lZCBieSB0aGUgcHJvZmlsaW5nIHNwZWNpZmljYXRpb24gKGUu Zy4gYSBwb3NzaWJsZSBPcGVuSUQgTG9nb3V0IEV2ZW50IHNwZWMpLiAgSW4gdGhpcyBjYXNlLCBp biBPcGVuSUQsIGxvZ2dpbmcgb3V0IHVzdWFsbHkgdHJhbnNsYXRlcyBpbnRvIHJldm9raW5nIGFu IElEIFRva2VuLiBUaHVzIHRoZSDigJxqdGnigJ0gZm9yIHRoZSBJRCB0b2tlbiAoMDhhNTAxOWMu Li44NDNlYTAyKSBpcyBpbmNsdWRlZCBpbiB0aGUgTG9nb3V0IG9iamVjdC4NCg0KU2lkZSBub3Rl LiAgUmVnYXJkaW5nIOKAnGxvZ291dOKAnSwgaXQgbWlnaHQgYmUgdXNlZnVsIHRvIGluY2x1ZGUg dGhlIGV4cGlyeSBvZiB0aGUgSUQgVG9rZW4gaW4gY2FzZSB0aGUgc3Vic2NyaWJlciBoYXMgbm90 IHlldCByZWNlaXZlZCBhbiBJRCBUb2tlbi4gVGhpcyB3b3VsZCBsZXQgdGhlIHN1YnNjcmliZXIg a25vdyBob3cgbG9uZyBpdCBuZWVkcyB0byBrZWVwIHRoZSByZXZvY2F0aW9uIGluZm9ybWF0aW9u IGZvci4gIElPV+KApmFmdGVyIHRoZSB0aGUgSUQgVG9rZW4gaXMgZXhwaXJlZCwgdGhlIHN1YnNj cmliZXIgd291bGQgbm8gbG9uZ2VyIG5lZWQgdG8gdHJhY2sgdGhlIHJldm9jYXRpb24gc3RhdGUu DQoNCkl0IGlzIGFsc28gZ29vZCB0byBvYnNlcnZlIHRoYXQgdGhlIOKAnGF1ZOKAnSBhdCB0aGUg dG9wIGxldmVsIGRlc2NyaWJlcyB0aGUgc3Vic2NyaWJlciBvZiB0aGUgZXZlbnQuICBUaGlzIG1h eSBhbHNvIGJlIGRpZmZlcmVudCB0aGVuIHRoZSBvcmlnaW5hbCBhdWRpZW5jZSBvZiB0aGUgSUQg VG9rZW4uDQoNClNvIHRvIGNvbmNsdWRlLiBCeSBtYWtpbmcgdG9wLWxldmVsIGF0dHJpYnV0ZXMg c3RyaWN0bHkgYWJvdXQgdGhlIGV2ZW50cyBvd24gdmFsaWRhdGlvbiwgYW5kIG5lc3RlZCBvYmpl Y3RzIGFib3V0IHRoZSBldmVudCwgd2UgYXZvaWQgY29sbGlzaW9ucyBpbiBkZWZpbml0aW9ucyBz dWNoIGFzIHRoZSBpc3N1ZXIgb2YgdGhlIGV2ZW50LCB2cy4gdGhlIG9yaWdpbmFsIGlzc3VlciBv ZiBhIHNlY3VyaXR5IGFzc2VydGlvbi4NCg0KSSBob3BlIEnigJl2ZSBnb3R0ZW4gZXZlcnlvbmXi gJlzIGZlZWRiYWNrIGNvcnJlY3QgaGVyZS4gTGV0cyBjb250aW51ZSB0byBkaXNjdXNzLiBJIHdp bGwgcmV2aXNlIHRoZSBkcmFmdCB0byBmb2xsb3cgdGhlIGdyb3VwcyB0aGlua2luZyBoZXJlLg0K DQpQaGlsDQoNCkBpbmRlcGVuZGVudGlkDQp3d3cuaW5kZXBlbmRlbnRpZC5jb208aHR0cDovL3d3 dy5pbmRlcGVuZGVudGlkLmNvbS8+DQpwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5o dW50QG9yYWNsZS5jb20+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpJZC1ldmVudCBtYWlsaW5nIGxpc3QNCklkLWV2ZW50QGlldGYub3JnPG1haWx0 bzpJZC1ldmVudEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vaWQtZXZlbnQNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KSWQtZXZlbnQgbWFpbGluZyBsaXN0DQpJZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86 SWQtZXZlbnRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2lkLWV2ZW50DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpJZC1ldmVudCBtYWlsaW5nIGxpc3QNCklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1l dmVudEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQt ZXZlbnQNCg== --_000_SN1PR0301MB164529CA9F3E68306F2F2EB2F51E0SN1PR0301MB1645_ 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 DQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4w cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToi Q291cmllciBOZXciO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1h bDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy Z2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUt bmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29s YXM7fQ0Kc3Bhbi5tLTY1MzQ0MzU1NzM2Mzk2NzM3ODZhcHBsZS1zdHlsZS1zcGFuDQoJe21zby1z dHlsZS1uYW1lOm1fLTY1MzQ0MzU1NzM2Mzk2NzM3ODZhcHBsZS1zdHlsZS1zcGFuO30NCnNwYW4u bS02NTM0NDM1NTczNjM5NjczNzg2YXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1u YW1lOm1fLTY1MzQ0MzU1NzM2Mzk2NzM3ODZhcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5F bWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzAwMjA2MDt9DQpzcGFuLkVtYWlsU3R5bGUyMw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMDAyMDYwO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzAwMjA2MCI+VGhlIHNpbXBsZSBydWxlIGlzIHRoYXQgaWYgdGhlIHBhcnRpY3VsYXIg ZXZlbnQgY2FsbHMgZm9yIHRoZSDigJxzdWLigJ0gY2xhaW0gdG8gYmUgYXQgdGhlIHRvcCBsZXZl bCwgdGhlbiBpdCBpcy4mbmJzcDsgVGhpcyBpcyBubyBkaWZmZXJlbnQgZnJvbSBhbnkgb3RoZXIg Y2xhaW0gdGhhdA0KIGFuIGV2ZW50IG1pZ2h0IHBsYWNlIGF0IHRoZSB0b3AgbGV2ZWwuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5UaGUgY29tcGxleGl0eSBhcmlz ZXMgaWYg4oCcc3Vi4oCdIGlzIHVubmVjZXNzYXJpbHkgc3BlY2lhbC1jYXNlZC4mbmJzcDsgV2Ug c2hvdWxkbuKAmXQgZG8gdGhhdCwgYmVjYXVzZSBpdCBsaW1pdHMgdGhlIGFwcGxpY2FiaWxpdHkg b2YgdGhlIHNwZWNpZmljYXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWls RW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvYT48L3A+DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29t cG9zZSI+PC9zcGFuPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+IFBoaWwgSHVudCAoSURNKSBbbWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tXQ0K PGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBBdWd1c3QgMTEsIDIwMTYgOTo0MCBBTTxicj4N CjxiPlRvOjwvYj4gTWlrZSBKb25lcyAmbHQ7TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tJmd0 Ozxicj4NCjxiPkNjOjwvYj4gTWFyaXVzIFNjdXJ0ZXNjdSAmbHQ7bXNjdXJ0ZXNjdUBnb29nbGUu Y29tJmd0OzsgaWQtZXZlbnRAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtJZC1l dmVudF0gU3VtbWFyaXppbmcgcmVjZW50IGRpc2N1c3Npb25zIG9uIElELUV2ZW50IHRva2VuIGRy YWZ0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkkgdGhpbmsgdXNpbmcgc3ViIGF0IHRoZSB0b3AgbGV2ZWwgbGVhZHMgdG8gY29tcGxleGl0eS4g RWcgQ2FuIHlvdSBwcm92aWRlIGEgcnVsZSBmb3Igd2hlbiB0b3AgbGV2ZWwgaXMgdXNlZCBvciBu b3QgYnkgYW4gaW5kaXZpZHVhbCBzcGVjPyAmbmJzcDtJTU8uIFRvcCBsZXZlbCBzaG91bGQgYWx3 YXlzIGJlIHVzZWQgdGhlIHNhbWUgd2F5IGJ5IGFsbCBpbXBsZW1lbnRlcnMuJm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iQXBw bGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJhc2VkIG9uIHRoZSBjYWxs cyBhdCByaXNjL2Nvbm5lY3QsIHdlIGRpc2N1c3NlZCB0aGF0IGl0IHdvdWxkIGJlIGJlc3QgdG8g bW92ZSBhbGwgZXZlbnQgc3BlY2lmaWNzIHRvIHRoZSBldmVudCBvYmplY3QgYXJlYS4gVGhpcyB3 YXkgZGlmZmVyZW50IGV2ZW50cyBjYW4gaGF2ZSBkaWZmZXJlbnQgZXZlbnQgYWRkcmVzc2luZyAo ZWcgc3ViL2lzcywgdXJpLCBqaXQvaXNzKS4gV2hlbiBpc3MgaXMgbmVlZGVkIHRvDQogdW5pcXVl bHkgcXVhbGlmeSBhIHN1YiwgaXQgY2FuIGJlIHByb3ZpZGVkIHdpdGhvdXQgY29uZmxpY3Rpbmcg d2l0aCB0aGUgaXNzdWVyIG9mIHRoZSBldmVudC4gU2ltaWxhcmx5IGp0aSBhbmQgaXNzIGNhbiBi ZSB1c2VkIGZvciBhIHJldm9rZWQgdG9rZW4gd2l0aG91dCBjb25mbGljdGluZyB3aXRoIHRoZSBl dmVudCBqdGkuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFp bFNpZ25hdHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkkgcGxhbiB0byBwb3N0IGEgbmV3IGRyYWZ0IHNob3J0bHkgdGhhdCB3aWxsIGdpdmUgc29t ZSBleGFtcGxlcyBiYXNlZCBvbiBmZWVkYmFjayBmcm9tIHRoZSBvcGVuaWQgcmlzYy9jb25uZWN0 IGRpc2N1c3Npb25zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxT aWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5XZSBjYW4gYWx3YXlzIGNoYW5nZSBhZ2Fpbi4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi cj4NClBoaWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KT24gQXVnIDExLCAyMDE2LCBh dCA0OjU0IEFNLCBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0Bt aWNyb3NvZnQuY29tIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPk5vLCBJ4oCZbSBub3Qgc2F5aW5nIHRoYXQg4oCc c3Vi4oCdIGNhbm5vdCBhcHBlYXIgYXQgdGhlIHRvcCBsZXZlbC4mbmJzcDsgSeKAmW0gc2F5aW5n IHRoYXQg4oCcc3Vi4oCdIHdpbGwgb25seSBvY2N1ciBhdCB0aGUgdG9wIGxldmVsIGlmIHRoZSBw YXJ0aWN1bGFyIGV2ZW50IGRlZmluZXMgdGhhdCDigJxzdWLigJ0NCiBpcyB1c2VkIGluIHRoYXQg d2F5IGZvciB0aGF0IGV2ZW50Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAw MjA2MCI+VGhlcmUgYXJlIHByb2JhYmx5IHVzZSBjYXNlcyBmb3IgbXVsdGlwbGUgZXZlbnRzIHBl ciBtZXNzYWdlIGJ1dCBJIGRvdWJ0IHRoZXJlIGFyZSB1c2UgY2FzZXMgZm9yIG11bHRpcGxlICo8 Yj51bnJlbGF0ZWQ8L2I+KiBldmVudHMgcGVyIG1lc3NhZ2UuJm5ic3A7IEJ5IGRlZmluaXRpb24s DQogcmVsYXRlZCBldmVudHMgdGhhdCB1c2UgdG9wLWxldmVsIGNsYWltcyB3b3VsZCBuZWVkIHRv IHVzZSB0aGVtIGluIGEgY29tcGF0aWJsZSB3YXkuJm5ic3A7IEkgZG9u4oCZdCBzZWUgdGhhdCBh cyBiZWluZyBhIHByb2JsZW0uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAy MDYwIj5UaGF0IGJlaW5nIHNhaWQsIHRoZSBwcmVkb21pbmFudCB1c2UgY2FzZSBpcyBsaWtlbHkg dG8gYmUgYSBzaW5nbGUgZXZlbnQgcGVyIEpXVC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IE1hcml1cyBTY3VydGVz Y3UgWzxhIGhyZWY9Im1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb20iPm1haWx0bzptc2N1cnRl c2N1QGdvb2dsZS5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEF1Z3VzdCA5 LCAyMDE2IDc6MTUgUE08YnI+DQo8Yj5Ubzo8L2I+IFBoaWwgSHVudCAmbHQ7PGEgaHJlZj0ibWFp bHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT4mZ3Q7PGJy Pg0KPGI+Q2M6PC9iPiBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25l c0BtaWNyb3NvZnQuY29tIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0OzsNCjxh IGhyZWY9Im1haWx0bzppZC1ldmVudEBpZXRmLm9yZyI+aWQtZXZlbnRAaWV0Zi5vcmc8L2E+PGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbSWQtZXZlbnRdIFN1bW1hcml6aW5nIHJlY2VudCBkaXNj dXNzaW9ucyBvbiBJRC1FdmVudCB0b2tlbiBkcmFmdDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk1pa2UsIGFyZSB5b3Ugc3VnZ2VzdGluZyB0aGF0IGEgc3ViIGNsYWltIGNh biBvbmx5IHNob3cgdXAgYXQgdGhlIGV2ZW50IGxldmVsIGFuZCBub3QgYXQgdGhlIHRvcCBsZXZl bDo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBwYXJ0aWN1bGFyLCB0aGUgb25s eSB0aGluZyB0aGF0IHRoZSBzcGVjIHNob3VsZCBzYXkgYWJvdXQgdGhlIOKAnHN1YuKAnSBjbGFp bSBpcyB0aGF0IOKAnExpa2UgYWxsIG90aGVyIGNsYWltcyBvdGhlciB0aGFuIOKAmGV2ZW50c+KA mSBhbmQg4oCYaXNz4oCZLCB3aGV0aGVyIHRoZSDigJhzdWLigJkgY2xhaW0gaXMgdG8gYmUgaW5j bHVkZWQgd2l0aCBhbiBldmVudCBpcyBlbnRpcmVseSBldmVudC1zcGVjaWZpYy48bzpwPjwvbzpw PjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkEgdG9w IGxldmVsIHN1YiBhbmQgbXVsdGlwbGUgZXZlbnRzIGFyZSBpbmNvbXBhdGlibGUgSU1PLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EbyB3ZSBo YXZlIGEgY29tcGVsbGluZyByZWFzb24gdG8gc3VwcG9ydCBtdWx0aXBsZSBldmVudHMgcGVyIG1l c3NhZ2U/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1hcml1czxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgQXVnIDksIDIwMTYgYXQgMTI6MzkgUE0sIFBo aWwgSHVudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9 Il9ibGFuayI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd2FzIHJlZmVycmluZyB0byB0aGlzIGluIHlvdXIg ZW1haWw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mcXVvdDs8 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+RGVmaW5lIHRoYXQgYW4gZXZlbnQgbmFtZSBj YW4gYmUgdXNlZCBhcyBhIHRvcC1sZXZlbCBjbGFpbeKAnTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXMgdGhpcyBk aWZmZXJlbnQgZnJvbSB0aGUgZXZlbnQgdXJpPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5QaGlsPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkBp bmRlcGVuZGVudGlkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YSBocmVmPSJodHRwOi8v d3d3LmluZGVwZW5kZW50aWQuY29tIiB0YXJnZXQ9Il9ibGFuayI+d3d3LmluZGVwZW5kZW50aWQu Y29tPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YSBo cmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5waGlsLmh1 bnRAb3JhY2xlLmNvbTwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g QXVnIDksIDIwMTYsIGF0IDEyOjEyIFBNLCBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86 TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+TWljaGFlbC5Kb25l c0BtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAi PknigJltIGdsYWQgdG8gaGVhciB0aGF0IHdlIGFncmVlIG9uIGtlZXBpbmcgaXQgYXMgc2ltcGxl IGFuZCBnZW5lcmFsLXB1cnBvc2UgYXMgcG9zc2libGUgYW5kIHRoYXQgeW91IGFncmVlIHdpdGgg bXkgd3JpdGUtdXAuJm5ic3A7IEkgdGhpbmsgd2UgdGhlbiBoYXZlIGEgZ29vZCBwYXRoDQogZm9y d2FyZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMwMDIwNjAiPknigJltIG5vdCBzdXJlIHdoYXQgeW91IG1lYW4gYnkg4oCc PC9zcGFuPknigJltIG5vdCBzdXJlIHRoYXQgd2UgbmVlZCBhIOKAnG5hbWXigJ0uIFdoYXQgaXMg eW91ciBpbnRlbnRpb24gdGhlcmUuPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPuKAnSZu YnNwOw0KIFRoZSBvbmx5IHBsYWNlIEkgdXNlZCB0aGUgd29yZCDigJxuYW1l4oCdIHdhcyBpbiBt eSBzdGF0ZW1lbnQg4oCcRGVmaW5lIHRoYXQgYW4gZXZlbnQgbmFtZSBjYW4gYmUgdXNlZCBhcyBh IHRvcC1sZXZlbCBjbGFpbeKAnS4mbmJzcDsgV2hhdCBJIHdhcyB0cnlpbmcgdG8gZ2V0IGF0IGlz IHdhcyB0aGF0IGlmIOKAnDxhIGhyZWY9Imh0dHA6Ly9zcGVjcy5vcGVuaWQubmV0L2xvZ291dCIg dGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHA6Ly9zcGVjcy5v cGVuaWQubmV0L2xvZ291dDwvc3Bhbj48L2E+4oCdDQogaXMgdXNlZCBhcyBhbiBldmVudCBuYW1l LCB0aGF0IGl0IGNhbiBhbHNvIGJlIHVzZWQgYXMgYSBjbGFpbSBuYW1lIGluIHRoZSBKV1QgY29u dGFpbmluZyBpbmZvcm1hdGlvbiBhYm91dCB0aGUgZXZlbnQuJm5ic3A7IChNYXliZSBJ4oCZbSBu b3QgdXNpbmcgdGhlIGNvcnJlY3QgdGVybWlub2xvZ3ksIGhlbmNlIHRoZSB1bmludGVuZGVkIGNv bmZ1c2lvbjxzcGFuIGNsYXNzPSJtLTY1MzQ0MzU1NzM2Mzk2NzM3ODZhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMwMDIwNjAiPko8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMwMDIwNjAiPi4pPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhhbmtzIGFnYWluLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlr ZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxhIG5hbWU9Im1fLTY1MzQ0MzU1NzM2Mzk2NzM3ODZfX01haWxFbmRDb21wb3NlIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3Bh biBjbGFzcz0ibS02NTM0NDM1NTczNjM5NjczNzg2YXBwbGUtY29udmVydGVkLXNwYWNlIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5QaGlsDQog SHVudCBbPGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFu ayI+bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPl08c3BhbiBjbGFzcz0ibS02NTM0NDM1 NTczNjM5NjczNzg2YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KPGI+ U2VudDo8L2I+PHNwYW4gY2xhc3M9Im0tNjUzNDQzNTU3MzYzOTY3Mzc4NmFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlR1ZXNkYXksIEF1Z3VzdCA5LCAyMDE2IDEyOjA3IFBNPGJy Pg0KPGI+VG86PC9iPjxzcGFuIGNsYXNzPSJtLTY1MzQ0MzU1NzM2Mzk2NzM3ODZhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5NaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86 TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+TWljaGFlbC5Kb25l c0BtaWNyb3NvZnQuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+PHNwYW4gY2xhc3M9Im0tNjUz NDQzNTU3MzYzOTY3Mzc4NmFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhy ZWY9Im1haWx0bzppZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmlkLWV2ZW50QGll dGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJtLTY1MzQ0MzU1NzM2 Mzk2NzM3ODZhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5SZTogW0lkLWV2ZW50 XSBTdW1tYXJpemluZyByZWNlbnQgZGlzY3Vzc2lvbnMgb24gSUQtRXZlbnQgdG9rZW4gZHJhZnQ8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZGlkbuKAmXQgY292ZXIgdGhpcyBh cyBJIGRpZG7igJl0IHdhbnQgdG8gY29uZnVzZSBwZW9wbGUgd2l0aCB0b28gbWFueSB0aGluZ3Mu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5CdXQgSSB0aGluayB3ZSBhZ3JlZSBvbiBhbGwgb2YgdGhlIGJl bG93LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J4oCZbSBub3Qgc3VyZSB0aGF0IHdlIG5l ZWQgYSDigJxuYW1l4oCdLiBXaGF0IGlzIHlvdXIgaW50ZW50aW9uIHRoZXJlLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlBoaWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QGluZGVwZW5kZW50aWQ8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxhIGhyZWY9Imh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20vIiB0YXJnZXQ9Il9ibGFuayI+ PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+d3d3LmluZGVwZW5kZW50aWQuY29tPC9zcGFuPjwv YT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBv cmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cGhp bC5odW50QG9yYWNsZS5jb208L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEF1 ZyA5LCAyMDE2LCBhdCAxMTo1NCBBTSwgTWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1p Y2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJj b2xvcjpwdXJwbGUiPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvc3Bhbj48L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5U aGFua3MgZm9yIHdyaXRpbmcgdGhpcywgUGhpbC4mbmJzcDsgVW5mb3J0dW5hdGVseSwgdGhlIHN1 bW1hcnkgYmVsb3cgZG9lcyBub3QgaW5jbHVkZSBteSBmZWVkYmFjaywgd2hpY2ggYXQgdGhlIGVz c2VuY2UsIGlzIHRvIGtlZXAgdGhlIElEIEV2ZW50cyBkYXRhIHN0cnVjdHVyZSBhcw0KIHNpbXBs ZSBhbmQgZ2VuZXJhbC1wdXJwb3NlIGFzIHBvc3NpYmxlLiAmbmJzcDsoSSBzdHJvbmdseSBiZWxp ZXZlIHRoYXQgSldUIGlzIHRoZSBzdWNjZXNzIGl0IGlzIGJlY2F1c2Ugd2UgbWFkZSBKV1QgYXMg c2ltcGxlIGFuZCBnZW5lcmFsLXB1cnBvc2UgYXMgcG9zc2libGUsIGFuZCB3ZSBzaG91bGQgZm9s bG93IHRoaXMgc3VjY2Vzc2Z1bCBleGFtcGxlIGFuZCBkbyB0aGUgc2FtZSBoZXJlLik8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPkkgYmVsaWV2ZSB0aGF0IHRo ZSBJRCBFdmVudHMgc3BlYyBuZWVkcyB0byBpbmNsdWRlIHRoZXNlIHRoaW5ncywgYW5kIHRoZXNl IHRoaW5ncyBvbmx5Ojwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6IzAw MjA2MCI+wrc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMDAyMDYw Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0ibS02NTM0 NDM1NTczNjM5NjczNzg2YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5EZWZpbmUNCiBvZiB0aGUg4oCcZXZlbnRz 4oCdIGNsYWltPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xvcjojMDAyMDYw Ij7Ctzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOiMwMDIwNjAiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJtLTY1MzQ0MzU1 NzM2Mzk2NzM3ODZhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPkRlZmluZQ0KIHRoYXQgYW4gZXZlbnQgbmFtZSBj YW4gYmUgdXNlZCBhcyBhIHRvcC1sZXZlbCBjbGFpbTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpTeW1ib2w7Y29sb3I6IzAwMjA2MCI+wrc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3 LjBwdDtjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8 c3BhbiBjbGFzcz0ibS02NTM0NDM1NTczNjM5NjczNzg2YXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5SZXF1aXJl DQogdGhhdCDigJxpc3PigJ0gYmUgaW5jbHVkZWQgYW5kIHRoYXQgdGhlIEpXVCBiZSBzaWduZWQg YnkgdGhlIGlzc3Vlcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6IzAw MjA2MCI+wrc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMDAyMDYw Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0ibS02NTM0 NDM1NTczNjM5NjczNzg2YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5JbmNsdWRlDQogYSBzdGF0ZW1lbnQgYWxv bmcgdGhlIGxpbmVzIG9mIOKAnFRoZSBjbGFpbXMgdG8gYmUgaW5jbHVkZWQgd2l0aCBhbnkgcGFy dGljdWxhciBldmVudCBhcmUgdG8gYmUgZGVmaW5lZCBieSB0aGUgZXZlbnTigJ08L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPkFuZCBJ4oCZZCBzdG9wIHRoZXJl Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+SXQgc2hvdWxk IGJlIGVudGlyZWx5IHVwIHRvIGFwcGxpY2F0aW9ucyB0byBzYXkgd2hhdCBjbGFpbXMgYXJlIGlu Y2x1ZGVkIHdpdGggZXZlbnRzIHRoZXkgZGVmaW5lIGFuZCB3aGF0IHRoZWlyIGZvcm1hdCBhbmQg bWVhbmluZ3MgYXJlLiZuYnNwOyBUaGVuIHRoZSBJRCBFdmVudHMgc3BlYw0KIHdpbGwgYmUgYXMg Z2VuZXJhbC1wdXJwb3NlIGFzIHBvc3NpYmxlLCB3aXRoIGl0IGJlaW5nIG5hdHVyYWwgZm9yIGl0 IHRvIGJlIHVzZWQgaW4gZXNzZW50aWFsbHkgYWxsIEpTT04gRXZlbnQgY29udGV4dHMuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5BcyBzb29uIGFzIHdlIHN0 YXJ0IHB1dHRpbmcgcmVzdHJpY3Rpb25zIG9uIHRoZSB1c2Ugb2YgcGFydGljdWxhciBjbGFpbXMg YnkgZXZlbnRzLCB3ZeKAmXJlIG1ha2luZyB0aGUgSUQgRXZlbnRzIHNwZWMgbGVzcyBnZW5lcmFs LXB1cnBvc2UgYW5kIGxlc3MgbmF0dXJhbCB0byB1c2UuJm5ic3A7DQogSW4gcGFydGljdWxhciwg dGhlIG9ubHkgdGhpbmcgdGhhdCB0aGUgc3BlYyBzaG91bGQgc2F5IGFib3V0IHRoZSDigJxzdWLi gJ0gY2xhaW0gaXMgdGhhdCDigJxMaWtlIGFsbCBvdGhlciBjbGFpbXMgb3RoZXIgdGhhbiDigJhl dmVudHPigJkgYW5kIOKAmGlzc+KAmSwgd2hldGhlciB0aGUg4oCYc3Vi4oCZIGNsYWltIGlzIHRv IGJlIGluY2x1ZGVkIHdpdGggYW4gZXZlbnQgaXMgZW50aXJlbHkgZXZlbnQtc3BlY2lmaWMuJm5i c3A7IFRoZSBjbGFpbXMgdG8gYmUgaW5jbHVkZWQgd2l0aCBhbnkNCiBwYXJ0aWN1bGFyIGV2ZW50 IGFyZSBleHBsaWNpdGx5IG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbi7i gJ08L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBjbGFzcz0ibS02NTM0NDM1NTczNjM5NjczNzg2YXBwbGUtY29udmVy dGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5JZC1ldmVudA0KIFs8YSBocmVmPSJtYWlsdG86aWQtZXZlbnQtYm91bmNlc0BpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1haWx0bzpp ZC1ldmVudC1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT5dPHNwYW4gY2xhc3M9Im0tNjUzNDQz NTU3MzYzOTY3Mzc4NmFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiPk9uIEJl aGFsZiBPZjxzcGFuIGNsYXNzPSJtLTY1MzQ0MzU1NzM2Mzk2NzM3ODZhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+UGhpbA0KIEh1bnQ8YnI+DQo8Yj5TZW50OjwvYj48c3Bh biBjbGFzcz0ibS02NTM0NDM1NTczNjM5NjczNzg2YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+VHVlc2RheSwgQXVndXN0IDksIDIwMTYgMTA6MTkgQU08YnI+DQo8Yj5Ubzo8L2I+ PHNwYW4gY2xhc3M9Im0tNjUzNDQzNTU3MzYzOTY3Mzc4NmFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzppZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmlkLWV2ZW50QGlldGYub3JnPC9zcGFu PjwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz0ibS02NTM0NDM1NTczNjM5Njcz Nzg2YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+W0lkLWV2ZW50XSBTdW1tYXJp emluZyByZWNlbnQgZGlzY3Vzc2lvbnMgb24gSUQtRXZlbnQgdG9rZW4gZHJhZnQ8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRob3VnaHQgSSB3b3Vs ZCB1cGRhdGUgdGhlIGxpc3Qgb24gc29tZSBkaXNjdXNzaW9ucyB0aGF0IGhhdmUgYmVlbiBoYXBw ZW5pbmcgb3ZlciBpbiB0aGUgT3BlbklEIENvbm5lY3QgYW5kIFJJU0Mgd29ya2luZyBncm91cHMg Y29uZmVyZW5jZSBjYWxscy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRoZXNlIGRpc2N1c3Npb25zIGhhdmUgYmVlbiBhYm91dCB0aGUgY29yZSBzcGVj IGFuZCB0aGUgcm9sZSBvZiDigJx0b3AtbGV2ZWzigJ0gYXR0cmlidXRlcyB2cy4gZXZlbnQg4oCc ZXh0ZW5zaW9u4oCdIGF0dHJpYnV0ZXMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5T ZWU6PHNwYW4gY2xhc3M9Im0tNjUzNDQzNTU3MzYzOTY3Mzc4NmFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1odW50LWlkZXZlbnQtdG9rZW4tMDEiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29s b3I6cHVycGxlIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaHVudC1pZGV2ZW50 LXRva2VuLTAxPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gcGFydGljdWxhciBzaG91bGQg4oCcc3Vi4oCdIGJlIHVz ZWQgaW4gdGhlIHRvcCBsZXZlbCB0byDigJxwb2ludOKAnSB0byB0aGUgc3ViamVjdCAoaW4gdGhl IGJyb2FkZXIgZW5nbGlzaCBzZW5zZSkgb2YgdGhlIGV2ZW50LCBvciBzaG91bGQgaXQgYmUgY29u c3RyYWluZWQgdG8gdGhlIFNBTUwvSUQgVG9rZW4gZGVmaW5pdGlvbiB3aGljaCBpcyB0aGUgYXV0 aGVudGljYXRlZCB1c2VyLiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGFrZW4gaW4gdGhlIG5hcnJvd2VyIGRlZmluaXRpb24s IGl0IGlzIGltcG9ydGFudCB0byBvYnNlcnZlIHRoYXQgaW4gYW4gSUQgVG9rZW4sIOKAnHN1YuKA nSBhbmQg4oCcaXNz4oCdIGdvIHRvZ2V0aGVyLiZuYnNwOyBUaGUgaXNzdWVyIHByb3ZpZGVzIHRo ZSBjb250ZXh0IGZvciB0aGUgYXV0aGVudGljYXRlZCBzdWJqZWN0IGlkZW50aWZpZXIuIFRoZSBw cm9ibGVtIHdpdGggZXZlbnRzLCBpcyB0aGF0IGl0IG1pZ2h0IG5vdCBiZSB0aGUNCiBBUyAob3Ig T1ApIHdoaWNoIGlzIGlzc3VpbmcgdGhlIGV2ZW50LiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VG8gc3VtbWFyaXplIGEgZmFp ciBhbW91bnQgb2YgZGlzY3Vzc2lvbiwgdGhlIGZlZWxpbmcgc2VlbXMgdG8gYmUgdGhlIGZvbGxv d2luZzo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+KiAmbmJzcDtUaGUgRXZlbnQgVG9rZW4gdG9wIGxldmVsIGF0dHJpYnV0ZXMgc2hvdWxk IGJlIGZhaXJseSBsaW1pdGVkIGFuZCBub3QgaW5jbHVkZSB0aGUgc3ViIGF0dHJpYnV0ZS4gJm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4qICZuYnNwO0ZvciBldmVudHMgdGhhdCBhcmUg YWJvdXQgYSB1c2VyLCB0aGUgcmVsZXZhbnQgZXZlbnQgc3BlY2lmaWNhdGlvbiBtYXkgaW5jbHVk ZSBhIOKAnHN1YuKAnSBhdHRyaWJ1dGUgd2l0aGluIHRoZSBldmVudOKAmXMgc3ViLW9iamVjdCBh bmQgbm90IGluIHRoZSB0b3AtbGV2ZWwuIEZ1cnRoZXIgdGhhdCBzdWItb2JqZWN0IGNhbiBhbHNv IGluY2x1ZGUgdGhlIGlzc3VlciBvZiB0aGUgdXNlci4gJm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4qIFRoZSB0b3AtbGV2ZWwg4oCcaXNz4oCdIHNoYWxsIG1lYW4gdGhlIGlzc3VlciBv ZiB0aGUgZXZlbnQgd2hlcmUgdGhlIHN0YXRlIGNoYW5nZSBvY2N1cnJlZC48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiogJm5ic3A74oCcc3Vi4oCdIHNob3VsZCBub3QgYmUgcHJlc2VudCBpbiB0 aGUgdG9wIGxldmVsIHN0cnVjdHVyZS4mbmJzcDsgQWxzbywg4oCcZXZlbnRz4oCdIG11c3QgYWxz byBiZSBwcmVzZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5IZXJlIHdvdWxkIGJlIGEgbmV3IGV4YW1wbGUgbG9nb3V0OjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwcmU+ezxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPiZuYnNwOyAmbHQ74oCUIHRvcCBsZXZlbCBpcyBhYm91dCB0aGUgZXZlbnQg aXRzZWxmIC0mZ3Q7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7IDxzcGFuIHN0eWxlPSJj b2xvcjojNUUzMEVCIj4mcXVvdDtpc3MmcXVvdDs6ICZxdW90OzxhIGhyZWY9Imh0dHBzOi8vc2Vy dmVyLmV4YW1wbGUuY29tLyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJw bGUiPmh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tPC9zcGFuPjwvYT4mcXVvdDssPC9zcGFuPjxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjojNUUzMEVCIj4mbmJzcDsg JnF1b3Q7YXVkJnF1b3Q7OiAmcXVvdDtzNkJoZFJrcXQzJnF1b3Q7LDwvc3Bhbj48bzpwPjwvbzpw PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6IzVFMzBFQiI+Jm5ic3A7ICZxdW90O2p0 aSZxdW90OzogJnF1b3Q7M2QwYzNjZjc5NzU4NGJkMTkzYmQwZmIxYmQ0ZTdkMzAmcXVvdDssPC9z cGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjojNUUzMEVCIj4m bmJzcDsgJnF1b3Q7aWF0JnF1b3Q7OiAxNDU4NjY4MTgwLDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6IzVFMzBFQiI+Jm5ic3A7ICZxdW90O2V4cCZxdW90 OzogMTQ1ODY2ODU4MCw8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9 ImNvbG9yOiM1RTMwRUIiPiZuYnNwOyAmcXVvdDtldmVudHMmcXVvdDs6IFs8L3NwYW4+PG86cD48 L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOiM1RTMwRUIiPiZuYnNwOyZuYnNw OyZuYnNwOyAmcXVvdDs8YSBocmVmPSJodHRwczovL3NwZWNzLm9wZW5pZC5uZXQvbG9nb3V0IiB0 YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly9zcGVjcy5v cGVuaWQubmV0L2xvZ291dDwvc3Bhbj48L2E+JnF1b3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjojNUUzMEVCIj4mbmJzcDsgXSw8L3NwYW4+PG86cD48 L286cD48L3ByZT4NCjxwcmU+IDxzcGFuIHN0eWxlPSJjb2xvcjojRTYzQjdBIj4mbmJzcDsmcXVv dDs8YSBocmVmPSJodHRwczovL3NwZWNzLm9wZW5pZC5uZXQvbG9nb3V0IiB0YXJnZXQ9Il9ibGFu ayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly9zcGVjcy5vcGVuaWQubmV0L2xv Z291dDwvc3Bhbj48L2E+JnF1b3Q7OiB7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxz cGFuIHN0eWxlPSJjb2xvcjojRTYzQjdBIj4mbmJzcDsmbmJzcDsmbmJzcDsgJmx0Oy0gVGhpcyBs ZXZlbCBpcyBkZWZpbmVkIGVudGlyZWx5IGJ5IHRoZSBldmVudCBVUkktJmd0Ozwvc3Bhbj48bzpw PjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6I0U2M0I3QSI+Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZxdW90O2lzcyZxdW90OzogJnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9vaWRjLmV4 YW1wbGUuY29tLyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0 dHBzOi8vb2lkYy5leGFtcGxlLmNvbTwvc3Bhbj48L2E+JnF1b3Q7LDwvc3Bhbj48bzpwPjwvbzpw PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6I0U2M0I3QSI+Jm5ic3A7Jm5ic3A7Jm5i c3A7IOKAnGp0aSZxdW90OzogJnF1b3Q7MDhhNTAxOWMtMTdlMS00OTc3LThmNDItNjVhMTI4NDNl YTAy4oCdLDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtjb2xvcjojRTYzQjdBIj4mbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7c3ViJnF1 b3Q7OiAmcXVvdDsyNDgyODk3NjEwMDHigJ0sPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOiNFNjNCN0EiPiZuYnNwOyZuYnNw OyZuYnNwOyDigJxleHDigJ06ICZsdDtJRCB0b2tlbiBleHBpcnkmZ3Q7PC9zcGFuPjxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOiNFNjNC N0EiPiZuYnNwOyB9PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0Ij59PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkluIHRoZSBhYm92ZSBleGFtcGxlIG5vdGUgdGhhdCB0aGUg4oCcZXZlbnTigJ0gb2JqZWN0 IGNhbiBoYXZlIGl0cyBvd24gaXNzIGFuZCBzdWJqZWN0IChzdWIgb3IganRpKSB0aGF0IGhhdmUg bWVhbmluZyB3aXRoaW4gdGhlIGNvbnRleHQgb2YgYW4gT3BlbklEIE9QIHByb3ZpZGVyLiZuYnNw OyBUaGUgaXNzdWVyIG9mIHRoZSBldmVudCBjYW4gYmUgZGlmZmVyZW50ICh0aGUgdG9wLWxldmVs KSBhbmQgcmVwcmVzZW50cyB0aGUNCiBlbnRpdHkgdGhhdCBzaWducyB0aGUgZXZlbnQgKGlmIGl0 IGlzIHNpZ25lZCkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRoZSB0b3AtbGV2ZWwgYXR0cmlidXRlcyBpZGVudGlmeSBhbiBpbmRpdmlk dWFsIGV2ZW50IGFuZCBhcmUgdXNlZCB0byB2YWxpZGF0ZSB0aGUgZXZlbnQgKHNpZ25pbmcgZXRj KS4mbmJzcDsgV2hlcmUgYXMgdGhlIG5lc3RlZCBvYmplY3QgY29udGFpbnMgYWxsIG9mIHRoZSBk YXRhIGFib3V0IHRoZSBldmVudCBhbmQgaXMgZGVmaW5lZCBieSB0aGUgcHJvZmlsaW5nIHNwZWNp ZmljYXRpb24gKGUuZy4gYSBwb3NzaWJsZQ0KIE9wZW5JRCBMb2dvdXQgRXZlbnQgc3BlYykuJm5i c3A7IEluIHRoaXMgY2FzZSwgaW4gT3BlbklELCBsb2dnaW5nIG91dCB1c3VhbGx5IHRyYW5zbGF0 ZXMgaW50byByZXZva2luZyBhbiBJRCBUb2tlbi4gVGh1cyB0aGUg4oCcanRp4oCdIGZvciB0aGUg SUQgdG9rZW4gKDA4YTUwMTljLi4uODQzZWEwMikgaXMgaW5jbHVkZWQgaW4gdGhlIExvZ291dCBv YmplY3QuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlNpZGUgbm90ZS4mbmJzcDsgUmVnYXJkaW5nIOKAnGxvZ291dOKAnSwgaXQgbWlnaHQg YmUgdXNlZnVsIHRvIGluY2x1ZGUgdGhlIGV4cGlyeSBvZiB0aGUgSUQgVG9rZW4gaW4gY2FzZSB0 aGUgc3Vic2NyaWJlciBoYXMgbm90IHlldCByZWNlaXZlZCBhbiBJRCBUb2tlbi4gVGhpcyB3b3Vs ZCBsZXQgdGhlIHN1YnNjcmliZXIga25vdyBob3cgbG9uZyBpdCBuZWVkcyB0byBrZWVwIHRoZSBy ZXZvY2F0aW9uIGluZm9ybWF0aW9uIGZvci4mbmJzcDsNCiBJT1figKZhZnRlciB0aGUgdGhlIElE IFRva2VuIGlzIGV4cGlyZWQsIHRoZSBzdWJzY3JpYmVyIHdvdWxkIG5vIGxvbmdlciBuZWVkIHRv IHRyYWNrIHRoZSByZXZvY2F0aW9uIHN0YXRlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBpcyBhbHNvIGdvb2QgdG8gb2JzZXJ2ZSB0 aGF0IHRoZSDigJxhdWTigJ0gYXQgdGhlIHRvcCBsZXZlbCBkZXNjcmliZXMgdGhlIHN1YnNjcmli ZXIgb2YgdGhlIGV2ZW50LiZuYnNwOyBUaGlzIG1heSBhbHNvIGJlIGRpZmZlcmVudCB0aGVuIHRo ZSBvcmlnaW5hbCBhdWRpZW5jZSBvZiB0aGUgSUQgVG9rZW4uPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvIHRvIGNvbmNsdWRlLiBCeSBt YWtpbmcgdG9wLWxldmVsIGF0dHJpYnV0ZXMgc3RyaWN0bHkgYWJvdXQgdGhlIGV2ZW50cyBvd24g dmFsaWRhdGlvbiwgYW5kIG5lc3RlZCBvYmplY3RzIGFib3V0IHRoZSBldmVudCwgd2UgYXZvaWQg Y29sbGlzaW9ucyBpbiBkZWZpbml0aW9ucyBzdWNoIGFzIHRoZSBpc3N1ZXIgb2YgdGhlIGV2ZW50 LCB2cy4gdGhlIG9yaWdpbmFsIGlzc3VlciBvZiBhIHNlY3VyaXR5IGFzc2VydGlvbi48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBob3Bl IEnigJl2ZSBnb3R0ZW4gZXZlcnlvbmXigJlzIGZlZWRiYWNrIGNvcnJlY3QgaGVyZS4gTGV0cyBj b250aW51ZSB0byBkaXNjdXNzLiBJIHdpbGwgcmV2aXNlIHRoZSBkcmFmdCB0byBmb2xsb3cgdGhl IGdyb3VwcyB0aGlua2luZyBoZXJlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+UGhpbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5AaW5kZXBlbmRlbnRpZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGEgaHJlZj0iaHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNvbS8iIHRhcmdldD0iX2JsYW5r Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj53d3cuaW5kZXBlbmRlbnRpZC5jb208L3NwYW4+ PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJt YWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0i Y29sb3I6cHVycGxlIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvc3Bhbj48L2E+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJZC1ldmVudCBt YWlsaW5nIGxpc3Q8YnI+DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpwdXJwbGUiPklkLWV2ZW50 QGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQo8L3NwYW4+PGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudCIgdGFyZ2V0 PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6cHVycGxlIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KSWQtZXZlbnQgbWFpbGluZyBsaXN0PGJyPg0K PGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYub3JnIj5JZC1ldmVudEBpZXRmLm9yZzwvYT48 YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2 ZW50IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9pZC1ldmVudDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJZC1ldmVudCBtYWlsaW5n IGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciPklkLWV2ZW50QGll dGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vaWQtZXZlbnQiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQt ZXZlbnQ8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_SN1PR0301MB164529CA9F3E68306F2F2EB2F51E0SN1PR0301MB1645_-- From nobody Thu Aug 11 08:26:27 2016 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 0994012D7AC for ; Thu, 11 Aug 2016 08:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.465 X-Spam-Level: X-Spam-Status: No, score=-5.465 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, 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 L_-Z1ca-zBWN for ; Thu, 11 Aug 2016 08:26:22 -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 E40F112D7BC for ; Thu, 11 Aug 2016 08:26:20 -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 u7BFQIpZ018979 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 11 Aug 2016 15:26:19 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 u7BFQI6d031326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 11 Aug 2016 15:26:18 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 u7BFQHAB029371; Thu, 11 Aug 2016 15:26:17 GMT Received: from [192.168.1.6] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 11 Aug 2016 08:26:16 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-526F1141-CDD4-490E-9D8C-7FD9EE9B7FA5 Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (13G34) In-Reply-To: Date: Thu, 11 Aug 2016 08:26:15 -0700 Content-Transfer-Encoding: 7bit Message-Id: <7CE1184A-2999-457D-B484-27216812F05A@oracle.com> References: <14E2EF51-7123-4E91-87DD-56AEA08202C1@oracle.com> <3F0DD3E6-46CD-4AA5-8F06-F79140F5D4BE@oracle.com> To: Mike Jones X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: "id-event@ietf.org" , Marius Scurtescu Subject: Re: [Id-event] Summarizing recent discussions on ID-Event token draft X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 11 Aug 2016 15:26:26 -0000 --Apple-Mail-526F1141-CDD4-490E-9D8C-7FD9EE9B7FA5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable How do you resolve the conflict that arises around iss since iss must be the= entity that signed the event and will often not be the one that issued the o= riginal idtoken in the case of openid(and which uniquely qualifies sub).=20 Phil > On Aug 11, 2016, at 8:03 AM, Mike Jones wrot= e: >=20 > The simple rule is that if the particular event calls for the =E2=80=9Csub= =E2=80=9D claim to be at the top level, then it is. This is no different fr= om any other claim that an event might place at the top level. > =20 > The complexity arises if =E2=80=9Csub=E2=80=9D is unnecessarily special-ca= sed. We shouldn=E2=80=99t do that, because it limits the applicability of t= he specification. > =20 > -- Mike > =20 > From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com]=20 > Sent: Thursday, August 11, 2016 9:40 AM > To: Mike Jones > Cc: Marius Scurtescu ; id-event@ietf.org > Subject: Re: [Id-event] Summarizing recent discussions on ID-Event token d= raft > =20 > I think using sub at the top level leads to complexity. Eg Can you provide= a rule for when top level is used or not by an individual spec? IMO. Top l= evel should always be used the same way by all implementers.=20 > =20 > Based on the calls at risc/connect, we discussed that it would be best to m= ove all event specifics to the event object area. This way different events c= an have different event addressing (eg sub/iss, uri, jit/iss). When iss is n= eeded to uniquely qualify a sub, it can be provided without conflicting with= the issuer of the event. Similarly jti and iss can be used for a revoked to= ken without conflicting with the event jti.=20 > =20 > I plan to post a new draft shortly that will give some examples based on f= eedback from the openid risc/connect discussions. > =20 > We can always change again.=20 >=20 > Phil >=20 > On Aug 11, 2016, at 4:54 AM, Mike Jones wrot= e: >=20 > No, I=E2=80=99m not saying that =E2=80=9Csub=E2=80=9D cannot appear at the= top level. I=E2=80=99m saying that =E2=80=9Csub=E2=80=9D will only occur a= t the top level if the particular event defines that =E2=80=9Csub=E2=80=9D i= s used in that way for that event. > =20 > There are probably use cases for multiple events per message but I doubt t= here are use cases for multiple *unrelated* events per message. By definiti= on, related events that use top-level claims would need to use them in a com= patible way. I don=E2=80=99t see that as being a problem. > =20 > That being said, the predominant use case is likely to be a single event p= er JWT. > =20 > -- Mi= ke > =20 > From: Marius Scurtescu [mailto:mscurtescu@google.com]=20 > Sent: Tuesday, August 9, 2016 7:15 PM > To: Phil Hunt > Cc: Mike Jones ; id-event@ietf.org > Subject: Re: [Id-event] Summarizing recent discussions on ID-Event token d= raft > =20 > Mike, are you suggesting that a sub claim can only show up at the event le= vel and not at the top level: > =20 > In particular, the only thing that the spec should say about the =E2=80=9C= sub=E2=80=9D claim is that =E2=80=9CLike all other claims other than =E2=80=98= events=E2=80=99 and =E2=80=98iss=E2=80=99, whether the =E2=80=98sub=E2=80=99= claim is to be included with an event is entirely event-specific. > =20 > A top level sub and multiple events are incompatible IMO. > =20 > Do we have a compelling reason to support multiple events per message? > =20 >=20 > Marius > =20 > On Tue, Aug 9, 2016 at 12:39 PM, Phil Hunt wrote: > I was referring to this in your email > "Define that an event name can be used as a top-level claim=E2=80=9D > =20 > =20 > Is this different from the event uri? > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > =20 > =20 >=20 > =20 > On Aug 9, 2016, at 12:12 PM, Mike Jones wrot= e: > =20 > I=E2=80=99m glad to hear that we agree on keeping it as simple and general= -purpose as possible and that you agree with my write-up. I think we then h= ave a good path forward. > =20 > I=E2=80=99m not sure what you mean by =E2=80=9CI=E2=80=99m not sure that w= e need a =E2=80=9Cname=E2=80=9D. What is your intention there.=E2=80=9D Th= e only place I used the word =E2=80=9Cname=E2=80=9D was in my statement =E2=80= =9CDefine that an event name can be used as a top-level claim=E2=80=9D. Wha= t I was trying to get at is was that if =E2=80=9Chttp://specs.openid.net/log= out=E2=80=9D is used as an event name, that it can also be used as a claim n= ame in the JWT containing information about the event. (Maybe I=E2=80=99m n= ot using the correct terminology, hence the unintended confusion J.) > =20 > Thanks again, > -- Mike > =20 > From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 > Sent: Tuesday, August 9, 2016 12:07 PM > To: Mike Jones > Cc: id-event@ietf.org > Subject: Re: [Id-event] Summarizing recent discussions on ID-Event token d= raft > =20 > I didn=E2=80=99t cover this as I didn=E2=80=99t want to confuse people wit= h too many things. > =20 > But I think we agree on all of the below. > =20 > I=E2=80=99m not sure that we need a =E2=80=9Cname=E2=80=9D. What is your i= ntention there. > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > =20 > =20 >=20 > =20 > On Aug 9, 2016, at 11:54 AM, Mike Jones wrot= e: > =20 > Thanks for writing this, Phil. Unfortunately, the summary below does not i= nclude my feedback, which at the essence, is to keep the ID Events data stru= cture as simple and general-purpose as possible. (I strongly believe that J= WT is the success it is because we made JWT as simple and general-purpose as= possible, and we should follow this successful example and do the same here= .) > =20 > I believe that the ID Events spec needs to include these things, and these= things only: > =C2=B7 Define of the =E2=80=9Cevents=E2=80=9D claim > =C2=B7 Define that an event name can be used as a top-level claim > =C2=B7 Require that =E2=80=9Ciss=E2=80=9D be included and that the J= WT be signed by the issuer > =C2=B7 Include a statement along the lines of =E2=80=9CThe claims to= be included with any particular event are to be defined by the event=E2=80=9D= > =20 > And I=E2=80=99d stop there. > =20 > It should be entirely up to applications to say what claims are included w= ith events they define and what their format and meanings are. Then the ID E= vents spec will be as general-purpose as possible, with it being natural for= it to be used in essentially all JSON Event contexts. > =20 > As soon as we start putting restrictions on the use of particular claims b= y events, we=E2=80=99re making the ID Events spec less general-purpose and l= ess natural to use. In particular, the only thing that the spec should say a= bout the =E2=80=9Csub=E2=80=9D claim is that =E2=80=9CLike all other claims o= ther than =E2=80=98events=E2=80=99 and =E2=80=98iss=E2=80=99, whether the =E2= =80=98sub=E2=80=99 claim is to be included with an event is entirely event-s= pecific. The claims to be included with any particular event are explicitly= outside the scope of this specification.=E2=80=9D > =20 > -- Mike > =20 > From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Phil Hunt > Sent: Tuesday, August 9, 2016 10:19 AM > To: id-event@ietf.org > Subject: [Id-event] Summarizing recent discussions on ID-Event token draft= > =20 > I thought I would update the list on some discussions that have been happe= ning over in the OpenID Connect and RISC working groups conference calls. > =20 > These discussions have been about the core spec and the role of =E2=80=9Ct= op-level=E2=80=9D attributes vs. event =E2=80=9Cextension=E2=80=9D attribute= s.=20 > See: https://tools.ietf.org/html/draft-hunt-idevent-token-01 > =20 > In particular should =E2=80=9Csub=E2=80=9D be used in the top level to =E2= =80=9Cpoint=E2=80=9D to the subject (in the broader english sense) of the ev= ent, or should it be constrained to the SAML/ID Token definition which is th= e authenticated user. =20 > =20 > Taken in the narrower definition, it is important to observe that in an ID= Token, =E2=80=9Csub=E2=80=9D and =E2=80=9Ciss=E2=80=9D go together. The is= suer provides the context for the authenticated subject identifier. The prob= lem with events, is that it might not be the AS (or OP) which is issuing the= event. =20 > =20 > To summarize a fair amount of discussion, the feeling seems to be the foll= owing: > =20 > * The Event Token top level attributes should be fairly limited and not i= nclude the sub attribute. =20 > * For events that are about a user, the relevant event specification may i= nclude a =E2=80=9Csub=E2=80=9D attribute within the event=E2=80=99s sub-obje= ct and not in the top-level. Further that sub-object can also include the is= suer of the user. =20 > * The top-level =E2=80=9Ciss=E2=80=9D shall mean the issuer of the event w= here the state change occurred. > * =E2=80=9Csub=E2=80=9D should not be present in the top level structure.= Also, =E2=80=9Cevents=E2=80=9D must also be present. > =20 > Here would be a new example logout: > { > <=E2=80=94 top level is about the event itself -> > "iss": "https://server.example.com", > "aud": "s6BhdRkqt3", > "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", > "iat": 1458668180, > "exp": 1458668580, > "events": [ > "https://specs.openid.net/logout" > ], > "https://specs.openid.net/logout": { > <- This level is defined entirely by the event URI-> > "iss": "https://oidc.example.com", > =E2=80=9Cjti": "08a5019c-17e1-4977-8f42-65a12843ea02=E2=80=9D, > "sub": "248289761001=E2=80=9D, > =E2=80=9Cexp=E2=80=9D: > } > } > =20 > In the above example note that the =E2=80=9Cevent=E2=80=9D object can have= its own iss and subject (sub or jti) that have meaning within the context o= f an OpenID OP provider. The issuer of the event can be different (the top-= level) and represents the entity that signs the event (if it is signed). > =20 > The top-level attributes identify an individual event and are used to vali= date the event (signing etc). Where as the nested object contains all of th= e data about the event and is defined by the profiling specification (e.g. a= possible OpenID Logout Event spec). In this case, in OpenID, logging out u= sually translates into revoking an ID Token. Thus the =E2=80=9Cjti=E2=80=9D f= or the ID token (08a5019c...843ea02) is included in the Logout object. > =20 > Side note. Regarding =E2=80=9Clogout=E2=80=9D, it might be useful to incl= ude the expiry of the ID Token in case the subscriber has not yet received a= n ID Token. This would let the subscriber know how long it needs to keep the= revocation information for. IOW=E2=80=A6after the the ID Token is expired,= the subscriber would no longer need to track the revocation state. > =20 > It is also good to observe that the =E2=80=9Caud=E2=80=9D at the top level= describes the subscriber of the event. This may also be different then the= original audience of the ID Token. > =20 > So to conclude. By making top-level attributes strictly about the events o= wn validation, and nested objects about the event, we avoid collisions in de= finitions such as the issuer of the event, vs. the original issuer of a secu= rity assertion. > =20 > I hope I=E2=80=99ve gotten everyone=E2=80=99s feedback correct here. Lets c= ontinue to discuss. I will revise the draft to follow the groups thinking he= re. > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =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://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-526F1141-CDD4-490E-9D8C-7FD9EE9B7FA5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
How do you resolve the conflict that a= rises around iss since iss must be the entity that signed the event and will= often not be the one that issued the original idtoken in the case of openid= (and which uniquely qualifies sub). 

Phil

On Aug 11, 2016, at 8:03 AM, Mike Jones <Michael.Jones@microsoft.com> w= rote:

The simple rule is that if the particul= ar event calls for the =E2=80=9Csub=E2=80=9D claim to be at the top level, t= hen it is.  This is no different from any other claim that an event might place at the top level.

 

The complexity arises if =E2=80=9Csub=E2= =80=9D is unnecessarily special-cased.  We shouldn=E2=80=99t do that, b= ecause it limits the applicability of the specification.

 

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

 =

From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com]
Sent: Thursday, August 11, 2016 9:40 AM
To: Mike Jones <Mic= hael.Jones@microsoft.com>
Cc: Marius Scurtescu <msc= urtescu@google.com>; id-event@ie= tf.org
Subject: Re: [Id-event] Summarizing recent discussions on ID-Event to= ken draft

 

I think using sub at the top level leads to complexit= y. Eg Can you provide a rule for when top level is used or not by an individ= ual spec?  IMO. Top level should always be used the same way by all imp= lementers. 

 

Based on the calls at risc/connect, we discussed that= it would be best to move all event specifics to the event object area. This= way different events can have different event addressing (eg sub/iss, uri, j= it/iss). When iss is needed to uniquely qualify a sub, it can be provided without conflicting with the iss= uer of the event. Similarly jti and iss can be used for a revoked token with= out conflicting with the event jti. 

 

I plan to post a new draft shortly that will give som= e examples based on feedback from the openid risc/connect discussions.<= /o:p>

 

We can always change again. 


Phil


On Aug 11, 2016, at 4:54 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

No, I=E2=80=99m not saying that =E2=80=9C= sub=E2=80=9D cannot appear at the top level.  I=E2=80=99m saying that =E2= =80=9Csub=E2=80=9D will only occur at the top level if the particular event d= efines that =E2=80=9Csub=E2=80=9D is used in that way for that event.

 

There are probably use cases for multip= le events per message but I doubt there are use cases for multiple *unrel= ated* events per message.  By definition, related events that use top-level claims would need to use them in a compat= ible way.  I don=E2=80=99t see that as being a problem.

 

That being said, the predominant use ca= se is likely to be a single event per JWT.

 

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

 

From: Marius Scurtescu [mailto:mscurtescu@google.com]
Sent: Tuesday, August 9, 2016 7:15 PM
To: Phil Hunt <phil.hunt@o= racle.com>
Cc: Mike Jones <Mic= hael.Jones@microsoft.com>; id-event@ietf.org
Subject: Re: [Id-event] Summarizing recent discussions on ID-Event to= ken draft

 

Mike, are you suggesting that a sub claim can only sh= ow up at the event level and not at the top level:

 

In particular, the only thing that the spec should sa= y about the =E2=80=9Csub=E2=80=9D claim is that =E2=80=9CLike all other clai= ms other than =E2=80=98events=E2=80=99 and =E2=80=98iss=E2=80=99, whether th= e =E2=80=98sub=E2=80=99 claim is to be included with an event is entirely ev= ent-specific.

 

A top level sub and multiple events are incompatible I= MO.

 

Do we have a compelling reason to support multiple ev= ents per message?

 


Marius

 

On Tue, Aug 9, 2016 at 12:39 PM, Phil Hunt <phil.hunt@oracle.com= > wrote:

I was referring to this in your email

"Define that an event name can be used a= s a top-level claim=E2=80=9D

 

 

Is this different from the event uri?

 

Phil

 <= /p>

@independentid

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

 <= /p>

 <= /p>

 

 

On Aug 9, 2016, at 12:12 PM, Mike Jones <Michael.Jones@microso= ft.com> wrote:

 

I=E2=80=99m glad to hear that we agree o= n keeping it as simple and general-purpose as possible and that you agree wi= th my write-up.  I think we then have a good path forward.

 

I=E2=80=99m not sure what you mean by =E2= =80=9CI=E2=80=99m not sure that we need a =E2=80=9Cname=E2=80=9D. Wha= t is your intention there.=E2=80=9D  The only place I used the word =E2=80=9Cname=E2=80=9D was in my statement =E2= =80=9CDefine that an event name can be used as a top-level claim=E2=80=9D.&n= bsp; What I was trying to get at is was that if =E2=80=9Chttp:= //specs.openid.net/logout=E2=80=9D is used as an event name, that it can also be used as a claim name in the J= WT containing information about the event.  (Maybe I=E2=80=99m not usin= g the correct terminology, hence the unintended confusion J.= )

 

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

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

 

From: Phil Hunt [mailto:phil= .hunt@oracle.com] 
Sent: = ;Tuesday, August 9, 2016 12:07 PM
To: <= /span>Mike Jones <Michael.Jones@microsoft.com>
Cc: <= /span>id-event@ietf.o= rg
Subject:&n= bsp;Re: [Id-event] Summarizing recent discussions on ID-Event token d= raft

 

I didn=E2=80=99t cover this as I didn=E2=80=99t want t= o confuse people with too many things.

 

But I think we agree on all of the below.<= /p>

 

I=E2=80=99m not sure that we need a =E2=80=9Cname=E2=80= =9D. What is your intention there.

 

 

 

 

 

On Aug 9, 2016, at 11:54 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

 

Thanks for writing this, Phil.  Un= fortunately, the summary below does not include my feedback, which at the es= sence, is to keep the ID Events data structure as simple and general-purpose as possible.  (I strongly believe that JWT i= s the success it is because we made JWT as simple and general-purpose as pos= sible, and we should follow this successful example and do the same here.)

 

I believe that the ID Events spec needs= to include these things, and these things only:

=C2=B7&nbs= p;      Define of the =E2=80=9Cevents=E2=80=9D claim

=C2=B7&nbs= p;      Define that an event name can be used as a top-level claim

=C2=B7&nbs= p;      Require that =E2=80=9Ciss=E2=80=9D be included and that the JWT be signed by the is= suer

=C2=B7&nbs= p;      Include a statement along the lines of =E2=80=9CThe claims to be included with any p= articular event are to be defined by the event=E2=80=9D

 

And I=E2=80=99d stop there.=

 

It should be entirely up to application= s to say what claims are included with events they define and what their for= mat and meanings are.  Then the ID Events spec will be as general-purpose as possible, with it being natural for it to be u= sed in essentially all JSON Event contexts.

 

As soon as we start putting restriction= s on the use of particular claims by events, we=E2=80=99re making the ID Eve= nts spec less general-purpose and less natural to use.  In particular, the only thing that the spec should say about the =E2=80=9Cs= ub=E2=80=9D claim is that =E2=80=9CLike all other claims other than =E2=80=98= events=E2=80=99 and =E2=80=98iss=E2=80=99, whether the =E2=80=98sub=E2=80=99= claim is to be included with an event is entirely event-specific.  The= claims to be included with any particular event are explicitly outside the scope of this specification.=E2= =80=9D

 

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

 

From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Phi= l Hunt
Sent: = ;Tuesday, August 9, 2016 10:19 AM
To: <= /span>id-event@ietf.org
Subject:&n= bsp;[Id-event] Summarizing recent discussions on ID-Event token draft=

 

I thought I would update the list on some discussions= that have been happening over in the OpenID Connect and RISC working groups= conference calls.

 

These discussions have been about the core spec and t= he role of =E2=80=9Ctop-level=E2=80=9D attributes vs. event =E2=80=9Cextensi= on=E2=80=9D attributes. 

 

In particular should =E2=80=9Csub=E2=80=9D be used in= the top level to =E2=80=9Cpoint=E2=80=9D to the subject (in the broader eng= lish sense) of the event, or should it be constrained to the SAML/ID Token d= efinition which is the authenticated user.  

 

Taken in the narrower definition, it is important to o= bserve that in an ID Token, =E2=80=9Csub=E2=80=9D and =E2=80=9Ciss=E2=80=9D g= o together.  The issuer provides the context for the authenticated subj= ect identifier. The problem with events, is that it might not be the AS (or OP) which is issuing the event.  

 

To summarize a fair amount of discussion, the feeling= seems to be the following:

 

*  The Event Token top level attributes should b= e fairly limited and not include the sub attribute.  

*  For events that are about a user, the relevan= t event specification may include a =E2=80=9Csub=E2=80=9D attribute within t= he event=E2=80=99s sub-object and not in the top-level. Further that sub-obj= ect can also include the issuer of the user.  

* The top-level =E2=80=9Ciss=E2=80=9D shall mean the i= ssuer of the event where the state change occurred.

*  =E2=80=9Csub=E2=80=9D should not be present i= n the top level structure.  Also, =E2=80=9Cevents=E2=80=9D must also be= present.

 

Here would be a new example logout:

{
  <=E2=80=94 top level is about the event itself ->
  "iss": "https://server.=
example.com",
  "aud": "s6BhdRkqt3",
  "jti": "3d0c3cf797584bd193bd0fb1bd=
4e7d30",
  "iat": 1458668180,
  "exp": 1458668580,
  "events": [

    "https:=
//specs.openid.net/logout"


  ],


  "https://specs.open=
id.net/logout": {


    <- This level is de=
fined entirely by the event URI->


    "iss": "https=
://oidc.example.com",


    =E2=80=9Cjti": "08a501=
9c-17e1-4977-8f42-65a12843ea02=E2=80=9D,


    "sub"=
: "248289761001=E2=80=9D,


    =E2=80=
=9Cexp=E2=80=9D: <ID token expiry>


  }


}








 














In the above example note that the =E2=80=9Cevent=E2=80=
=9D object can have its own iss and subject (sub or jti) that have meaning w=
ithin the context of an OpenID OP provider.  The issuer of the event ca=
n be different (the top-level) and represents the
 entity that signs the event (if it is signed).














 














The top-level attributes identify an individual event=
 and are used to validate the event (signing etc).  Where as the nested=
 object contains all of the data about the event and is defined by the profi=
ling specification (e.g. a possible
 OpenID Logout Event spec).  In this case, in OpenID, logging out usual=
ly translates into revoking an ID Token. Thus the =E2=80=9Cjti=E2=80=9D for t=
he ID token (08a5019c...843ea02) is included in the Logout object.














 














Side note.  Regarding =E2=80=9Clogout=E2=80=9D, i=
t might be useful to include the expiry of the ID Token in case the subscrib=
er has not yet received an ID Token. This would let the subscriber know how l=
ong it needs to keep the revocation information for. 
 IOW=E2=80=A6after the the ID Token is expired, the subscriber would no long=
er need to track the revocation state.














 














It is also good to observe that the =E2=80=9Caud=E2=80=
=9D at the top level describes the subscriber of the event.  This may a=
lso be different then the original audience of the ID Token.














 














So to conclude. By making top-level attributes strict=
ly about the events own validation, and nested objects about the event, we a=
void collisions in definitions such as the issuer of the event, vs. the orig=
inal issuer of a security assertion.














 














I hope I=E2=80=99ve gotten everyone=E2=80=99s feedbac=
k correct here. Lets continue to discuss. I will revise the draft to follow t=
he groups thinking here.














 

 

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

 


_______________________________________________
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
<= span>https://www.= ietf.org/mailman/listinfo/id-event
<= /html>= --Apple-Mail-526F1141-CDD4-490E-9D8C-7FD9EE9B7FA5-- From nobody Thu Aug 11 08:53:00 2016 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 5A5D012D7D5 for ; Thu, 11 Aug 2016 08:52:59 -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=[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_H2=-0.001, 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 WZOL7WIXmTYK for ; Thu, 11 Aug 2016 08:52:55 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0107.outbound.protection.outlook.com [104.47.32.107]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9273212D7C9 for ; Thu, 11 Aug 2016 08:52: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=qo8UOG0FN1dPDI30qj7bwu+gGlv+jY/LjzEhrrUCklA=; b=YTXBgbJtdDqradvHawCII6YuqnuYQhSHsXroRAZmnxkWkKpb1tgDcL8f+ohSr2w0wDR8exhsJ9jhVKMJRmRuXpjSQTqf1e0e/ugQ1kETS3l4T37/MzXlbY2st1yhJ+tQawvR1AF7I5Un57osWwjwUQVhNvATHIv0Lq6TpLpIji0= Received: from SN1PR0301MB1645.namprd03.prod.outlook.com (10.162.130.139) by SN1PR0301MB1648.namprd03.prod.outlook.com (10.162.130.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Thu, 11 Aug 2016 15:52:52 +0000 Received: from SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) by SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) with mapi id 15.01.0549.025; Thu, 11 Aug 2016 15:52:52 +0000 From: Mike Jones To: "Phil Hunt (IDM)" Thread-Topic: [Id-event] Summarizing recent discussions on ID-Event token draft Thread-Index: AQHR8mIWLvqeOEkcuEuQk5SeT4z/pKBA9pTwgAAG/gCAAABNAIAACP2AgAA8CICAAmTu0IAAHwwAgAAWu7CAAAcIgIAABdGQ Date: Thu, 11 Aug 2016 15:52:52 +0000 Message-ID: References: <14E2EF51-7123-4E91-87DD-56AEA08202C1@oracle.com> <3F0DD3E6-46CD-4AA5-8F06-F79140F5D4BE@oracle.com> <7CE1184A-2999-457D-B484-27216812F05A@oracle.com> In-Reply-To: <7CE1184A-2999-457D-B484-27216812F05A@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.201.94.142] x-ms-office365-filtering-correlation-id: 02635ec8-5903-4d20-0225-08d3c1ff8db1 x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1648; 6:f49nFggVNRah3eEAgxyEaOQCko75eSZEzqvQl9QJGDzaohx56XuRrj9Pws5Sx85a02nPXXkoSmEtMHu8hBy+nMo7aYWC9QbUxEnrGQiOrtsl9OE63LEO/hrj6yuetCrF7/bulbldPI8gxK4ln0hwdRwegUWxUBAH89T9DNYBKMb3S/1huv00pZxrt8yy/+FBJOeVosANQvSkg7wlPfR6m44/6/PvR+pzAY7aHc5h3cxnnxgE8ZGWnxFjfGoyL6BvT9mGF2FD+8+PrxJynZ7FBv02U2VFepPxL3KeReL5jvrl5qu/20O3OOzxRaTfdH8the3k+iASJ3vlShrnDtqCBw==; 5:ciBzrtusuk2YKRN7+F3ED2bXgvSafs/OuDMGdvWiZuqrrWhgwuxR7Rwd42yc5+PHpTDVpTdhmgrF1ugw/J02F4URc+jhAkLNxfB2gty9Yyd2nJq0K3oIwC4FNADHioeTp3ebtb/naZLWzx4aKpWzE70jk68KWn3oh3pJdZ4QNIk=; 24:crhtuZGo8+piGEIG1k/moJDpEg5F8KKgT443RMY7wBBNawRJNGKcrt4Xd/SuEaYn+2URQIbozs/t85M72x93DtqbbsY+qZs8OHo7XbvfTvw=; 7:kI/MsQHByGXRikyyNTecdgju/T4zwwspCu0Z1AXk+o/EwTfdY242kyL6cVWT3Q4cKZZcOaocKAl2NmpdMQC2XgxaJ3F290rNNux3UoasH5zIp1bdL97gTskuPMcBLcIiL0mPRBd9olDWUiI2PpvIBBD8lnoyj6GfdM3BQjePHwwTfa6qyx6fCGzS+CBV6D/ISCZll60xPMXNbLyYuyHzR7vCvLkgkcId4uxSlrEp70p72LrIxW2Wqm9OhuOM+Vbd x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1648; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(278428928389397)(192374486261705)(211936372134217)(21748063052155)(21532816269658)(146099531331640); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040171)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:SN1PR0301MB1648; BCL:0; PCL:0; RULEID:(304825118); SRVR:SN1PR0301MB1648; x-forefront-prvs: 0031A0FFAF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(43784003)(24454002)(199003)(377454003)(97736004)(19300405004)(2900100001)(110136002)(2950100001)(189998001)(11100500001)(81156014)(8936002)(7846002)(15975445007)(74316002)(8676002)(575784001)(86362001)(9686002)(7906003)(68736007)(106116001)(7736002)(66066001)(106356001)(7696003)(19617315012)(81166006)(76576001)(4326007)(1860700003)(2906002)(10290500002)(19609705001)(19580395003)(5002640100001)(50986999)(86612001)(105586002)(101416001)(10400500002)(19580405001)(586003)(16601075003)(122556002)(5005710100001)(77096005)(8990500004)(99286002)(16236675004)(10090500001)(54356999)(33656002)(790700001)(3280700002)(3660700001)(6116002)(87936001)(92566002)(19625215002)(93886004)(102836003)(3846002)(76176999); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0301MB1648; H:SN1PR0301MB1645.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB164598544F3C4579D120C4F5F51E0SN1PR0301MB1645_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Aug 2016 15:52:52.5699 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1648 Archived-At: Cc: "id-event@ietf.org" , Marius Scurtescu Subject: Re: [Id-event] Summarizing recent discussions on ID-Event token draft X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 11 Aug 2016 15:52:59 -0000 --_000_SN1PR0301MB164598544F3C4579D120C4F5F51E0SN1PR0301MB1645_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW4gdGhlIE9wZW5JRCBDb25uZWN0IEJhY2stQ2hhbm5lbCBMb2dvdXQgY2FzZSwgdGhpcyBjb25m bGljdCwgYnkgZGVmaW5pdGlvbiwgY2FuIG5ldmVyIG9jY3VyLiAgT25lIG9mIHRoZSB2YWxpZGF0 aW9uIHJ1bGVzIGZvciB0aGUgbG9nb3V0IGV2ZW50IGlzIHRoYXQgaXQgTVVTVCBiZSBzaWduZWQg YnkgdGhlIGlkZW50aXR5IHByb3ZpZGVyIOKAkyB0aGUgc2FtZSBwYXJ0eSB0aGF0IGlzc3VlZCB0 aGUgSUQgVG9rZW4gYXQgYXV0aGVudGljYXRpb24gdGltZS4gIE90aGVyd2lzZSwgaXTigJlzIGxp a2VseSBwYXJ0IG9mIGFuIGF0dGFjaywgYW5kIG11c3QgYmUgZGlzY2FyZGVkLg0KDQpZZXMsIHRo ZXJlIGFyZSBvdGhlciB1c2UgY2FzZXMgaW4gd2hpY2ggbXVsdGlwbGUgcGFydGllcyBtaWdodCBz aWduIGRpZmZlcmVudCBKV1RzIGluIGFuIGFwcGxpY2F0aW9uIGNvbnRleHQuICBZZXMsIGluIHRo b3NlIGNhc2VzLCBtb3JlIGNvbXBsZXggZXZlbnQgZGF0YSBzdHJ1Y3R1cmVzIG1pZ2h0IGJlIG5l ZWRlZC4gIEJ1dCBpbiB0aGUgYmFjay1jaGFubmVsIGxvZ291dCBjYXNlLCB0aGVyZeKAmXMgZXhh Y3RseSBvbmUgaXNzdWVyIGFuZCBvbmUgc3ViamVjdCwgd2hpY2ggTVVTVCBtYXRjaCB0aG9zZSBp biB0aGUgcHJldmlvdXNseSBpc3N1ZWQgSUQgVG9rZW4uDQoNCkl04oCZcyBhbiBpbnRlbnRpb25h bGx5IHZlcnkgc2ltcGxlIHVzZSBjYXNlLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBQaGlsIEh1bnQgKElE TSkgW21haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBBdWd1c3Qg MTEsIDIwMTYgMTE6MjYgQU0NClRvOiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29m dC5jb20+DQpDYzogaWQtZXZlbnRAaWV0Zi5vcmc7IE1hcml1cyBTY3VydGVzY3UgPG1zY3VydGVz Y3VAZ29vZ2xlLmNvbT4NClN1YmplY3Q6IFJlOiBbSWQtZXZlbnRdIFN1bW1hcml6aW5nIHJlY2Vu dCBkaXNjdXNzaW9ucyBvbiBJRC1FdmVudCB0b2tlbiBkcmFmdA0KDQpIb3cgZG8geW91IHJlc29s dmUgdGhlIGNvbmZsaWN0IHRoYXQgYXJpc2VzIGFyb3VuZCBpc3Mgc2luY2UgaXNzIG11c3QgYmUg dGhlIGVudGl0eSB0aGF0IHNpZ25lZCB0aGUgZXZlbnQgYW5kIHdpbGwgb2Z0ZW4gbm90IGJlIHRo ZSBvbmUgdGhhdCBpc3N1ZWQgdGhlIG9yaWdpbmFsIGlkdG9rZW4gaW4gdGhlIGNhc2Ugb2Ygb3Bl bmlkKGFuZCB3aGljaCB1bmlxdWVseSBxdWFsaWZpZXMgc3ViKS4NCg0KUGhpbA0KDQpPbiBBdWcg MTEsIDIwMTYsIGF0IDg6MDMgQU0sIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0 LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpUaGUgc2lt cGxlIHJ1bGUgaXMgdGhhdCBpZiB0aGUgcGFydGljdWxhciBldmVudCBjYWxscyBmb3IgdGhlIOKA nHN1YuKAnSBjbGFpbSB0byBiZSBhdCB0aGUgdG9wIGxldmVsLCB0aGVuIGl0IGlzLiAgVGhpcyBp cyBubyBkaWZmZXJlbnQgZnJvbSBhbnkgb3RoZXIgY2xhaW0gdGhhdCBhbiBldmVudCBtaWdodCBw bGFjZSBhdCB0aGUgdG9wIGxldmVsLg0KDQpUaGUgY29tcGxleGl0eSBhcmlzZXMgaWYg4oCcc3Vi 4oCdIGlzIHVubmVjZXNzYXJpbHkgc3BlY2lhbC1jYXNlZC4gIFdlIHNob3VsZG7igJl0IGRvIHRo YXQsIGJlY2F1c2UgaXQgbGltaXRzIHRoZSBhcHBsaWNhYmlsaXR5IG9mIHRoZSBzcGVjaWZpY2F0 aW9uLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBQaGlsIEh1bnQgKElETSkgW21haWx0bzpwaGlsLmh1bnRA b3JhY2xlLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMTEsIDIwMTYgOTo0MCBBTQ0KVG86 IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5K b25lc0BtaWNyb3NvZnQuY29tPj4NCkNjOiBNYXJpdXMgU2N1cnRlc2N1IDxtc2N1cnRlc2N1QGdv b2dsZS5jb208bWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbT4+OyBpZC1ldmVudEBpZXRmLm9y ZzxtYWlsdG86aWQtZXZlbnRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0lkLWV2ZW50XSBTdW1t YXJpemluZyByZWNlbnQgZGlzY3Vzc2lvbnMgb24gSUQtRXZlbnQgdG9rZW4gZHJhZnQNCg0KSSB0 aGluayB1c2luZyBzdWIgYXQgdGhlIHRvcCBsZXZlbCBsZWFkcyB0byBjb21wbGV4aXR5LiBFZyBD YW4geW91IHByb3ZpZGUgYSBydWxlIGZvciB3aGVuIHRvcCBsZXZlbCBpcyB1c2VkIG9yIG5vdCBi eSBhbiBpbmRpdmlkdWFsIHNwZWM/ICBJTU8uIFRvcCBsZXZlbCBzaG91bGQgYWx3YXlzIGJlIHVz ZWQgdGhlIHNhbWUgd2F5IGJ5IGFsbCBpbXBsZW1lbnRlcnMuDQoNCkJhc2VkIG9uIHRoZSBjYWxs cyBhdCByaXNjL2Nvbm5lY3QsIHdlIGRpc2N1c3NlZCB0aGF0IGl0IHdvdWxkIGJlIGJlc3QgdG8g bW92ZSBhbGwgZXZlbnQgc3BlY2lmaWNzIHRvIHRoZSBldmVudCBvYmplY3QgYXJlYS4gVGhpcyB3 YXkgZGlmZmVyZW50IGV2ZW50cyBjYW4gaGF2ZSBkaWZmZXJlbnQgZXZlbnQgYWRkcmVzc2luZyAo ZWcgc3ViL2lzcywgdXJpLCBqaXQvaXNzKS4gV2hlbiBpc3MgaXMgbmVlZGVkIHRvIHVuaXF1ZWx5 IHF1YWxpZnkgYSBzdWIsIGl0IGNhbiBiZSBwcm92aWRlZCB3aXRob3V0IGNvbmZsaWN0aW5nIHdp dGggdGhlIGlzc3VlciBvZiB0aGUgZXZlbnQuIFNpbWlsYXJseSBqdGkgYW5kIGlzcyBjYW4gYmUg dXNlZCBmb3IgYSByZXZva2VkIHRva2VuIHdpdGhvdXQgY29uZmxpY3Rpbmcgd2l0aCB0aGUgZXZl bnQganRpLg0KDQpJIHBsYW4gdG8gcG9zdCBhIG5ldyBkcmFmdCBzaG9ydGx5IHRoYXQgd2lsbCBn aXZlIHNvbWUgZXhhbXBsZXMgYmFzZWQgb24gZmVlZGJhY2sgZnJvbSB0aGUgb3BlbmlkIHJpc2Mv Y29ubmVjdCBkaXNjdXNzaW9ucy4NCg0KV2UgY2FuIGFsd2F5cyBjaGFuZ2UgYWdhaW4uDQoNClBo aWwNCg0KT24gQXVnIDExLCAyMDE2LCBhdCA0OjU0IEFNLCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpv bmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+IHdy b3RlOg0KTm8sIEnigJltIG5vdCBzYXlpbmcgdGhhdCDigJxzdWLigJ0gY2Fubm90IGFwcGVhciBh dCB0aGUgdG9wIGxldmVsLiAgSeKAmW0gc2F5aW5nIHRoYXQg4oCcc3Vi4oCdIHdpbGwgb25seSBv Y2N1ciBhdCB0aGUgdG9wIGxldmVsIGlmIHRoZSBwYXJ0aWN1bGFyIGV2ZW50IGRlZmluZXMgdGhh dCDigJxzdWLigJ0gaXMgdXNlZCBpbiB0aGF0IHdheSBmb3IgdGhhdCBldmVudC4NCg0KVGhlcmUg YXJlIHByb2JhYmx5IHVzZSBjYXNlcyBmb3IgbXVsdGlwbGUgZXZlbnRzIHBlciBtZXNzYWdlIGJ1 dCBJIGRvdWJ0IHRoZXJlIGFyZSB1c2UgY2FzZXMgZm9yIG11bHRpcGxlICp1bnJlbGF0ZWQqIGV2 ZW50cyBwZXIgbWVzc2FnZS4gIEJ5IGRlZmluaXRpb24sIHJlbGF0ZWQgZXZlbnRzIHRoYXQgdXNl IHRvcC1sZXZlbCBjbGFpbXMgd291bGQgbmVlZCB0byB1c2UgdGhlbSBpbiBhIGNvbXBhdGlibGUg d2F5LiAgSSBkb27igJl0IHNlZSB0aGF0IGFzIGJlaW5nIGEgcHJvYmxlbS4NCg0KVGhhdCBiZWlu ZyBzYWlkLCB0aGUgcHJlZG9taW5hbnQgdXNlIGNhc2UgaXMgbGlrZWx5IHRvIGJlIGEgc2luZ2xl IGV2ZW50IHBlciBKV1QuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogTWFyaXVzIFNj dXJ0ZXNjdSBbbWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbV0NClNlbnQ6IFR1ZXNkYXksIEF1 Z3VzdCA5LCAyMDE2IDc6MTUgUE0NClRvOiBQaGlsIEh1bnQgPHBoaWwuaHVudEBvcmFjbGUuY29t PG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+DQpDYzogTWlrZSBKb25lcyA8TWljaGFlbC5K b25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+Pjsg aWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOmlkLWV2ZW50QGlldGYub3JnPg0KU3ViamVjdDogUmU6 IFtJZC1ldmVudF0gU3VtbWFyaXppbmcgcmVjZW50IGRpc2N1c3Npb25zIG9uIElELUV2ZW50IHRv a2VuIGRyYWZ0DQoNCk1pa2UsIGFyZSB5b3Ugc3VnZ2VzdGluZyB0aGF0IGEgc3ViIGNsYWltIGNh biBvbmx5IHNob3cgdXAgYXQgdGhlIGV2ZW50IGxldmVsIGFuZCBub3QgYXQgdGhlIHRvcCBsZXZl bDoNCg0KSW4gcGFydGljdWxhciwgdGhlIG9ubHkgdGhpbmcgdGhhdCB0aGUgc3BlYyBzaG91bGQg c2F5IGFib3V0IHRoZSDigJxzdWLigJ0gY2xhaW0gaXMgdGhhdCDigJxMaWtlIGFsbCBvdGhlciBj bGFpbXMgb3RoZXIgdGhhbiDigJhldmVudHPigJkgYW5kIOKAmGlzc+KAmSwgd2hldGhlciB0aGUg 4oCYc3Vi4oCZIGNsYWltIGlzIHRvIGJlIGluY2x1ZGVkIHdpdGggYW4gZXZlbnQgaXMgZW50aXJl bHkgZXZlbnQtc3BlY2lmaWMuDQoNCkEgdG9wIGxldmVsIHN1YiBhbmQgbXVsdGlwbGUgZXZlbnRz IGFyZSBpbmNvbXBhdGlibGUgSU1PLg0KDQpEbyB3ZSBoYXZlIGEgY29tcGVsbGluZyByZWFzb24g dG8gc3VwcG9ydCBtdWx0aXBsZSBldmVudHMgcGVyIG1lc3NhZ2U/DQoNCg0KTWFyaXVzDQoNCk9u IFR1ZSwgQXVnIDksIDIwMTYgYXQgMTI6MzkgUE0sIFBoaWwgSHVudCA8cGhpbC5odW50QG9yYWNs ZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj4gd3JvdGU6DQpJIHdhcyByZWZlcnJp bmcgdG8gdGhpcyBpbiB5b3VyIGVtYWlsDQoiRGVmaW5lIHRoYXQgYW4gZXZlbnQgbmFtZSBjYW4g YmUgdXNlZCBhcyBhIHRvcC1sZXZlbCBjbGFpbeKAnQ0KDQoNCklzIHRoaXMgZGlmZmVyZW50IGZy b20gdGhlIGV2ZW50IHVyaT8NCg0KUGhpbA0KDQpAaW5kZXBlbmRlbnRpZA0Kd3d3LmluZGVwZW5k ZW50aWQuY29tPGh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20+DQpwaGlsLmh1bnRAb3JhY2xl LmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+DQoNCg0KDQoNCk9uIEF1ZyA5LCAyMDE2 LCBhdCAxMjoxMiBQTSwgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1h aWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PiB3cm90ZToNCg0KSeKAmW0gZ2xhZCB0 byBoZWFyIHRoYXQgd2UgYWdyZWUgb24ga2VlcGluZyBpdCBhcyBzaW1wbGUgYW5kIGdlbmVyYWwt cHVycG9zZSBhcyBwb3NzaWJsZSBhbmQgdGhhdCB5b3UgYWdyZWUgd2l0aCBteSB3cml0ZS11cC4g IEkgdGhpbmsgd2UgdGhlbiBoYXZlIGEgZ29vZCBwYXRoIGZvcndhcmQuDQoNCknigJltIG5vdCBz dXJlIHdoYXQgeW91IG1lYW4gYnkg4oCcSeKAmW0gbm90IHN1cmUgdGhhdCB3ZSBuZWVkIGEg4oCc bmFtZeKAnS4gV2hhdCBpcyB5b3VyIGludGVudGlvbiB0aGVyZS7igJ0gIFRoZSBvbmx5IHBsYWNl IEkgdXNlZCB0aGUgd29yZCDigJxuYW1l4oCdIHdhcyBpbiBteSBzdGF0ZW1lbnQg4oCcRGVmaW5l IHRoYXQgYW4gZXZlbnQgbmFtZSBjYW4gYmUgdXNlZCBhcyBhIHRvcC1sZXZlbCBjbGFpbeKAnS4g IFdoYXQgSSB3YXMgdHJ5aW5nIHRvIGdldCBhdCBpcyB3YXMgdGhhdCBpZiDigJxodHRwOi8vc3Bl Y3Mub3BlbmlkLm5ldC9sb2dvdXTigJ0gaXMgdXNlZCBhcyBhbiBldmVudCBuYW1lLCB0aGF0IGl0 IGNhbiBhbHNvIGJlIHVzZWQgYXMgYSBjbGFpbSBuYW1lIGluIHRoZSBKV1QgY29udGFpbmluZyBp bmZvcm1hdGlvbiBhYm91dCB0aGUgZXZlbnQuICAoTWF5YmUgSeKAmW0gbm90IHVzaW5nIHRoZSBj b3JyZWN0IHRlcm1pbm9sb2d5LCBoZW5jZSB0aGUgdW5pbnRlbmRlZCBjb25mdXNpb24g4pi6LikN Cg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IFRoYW5rcyBhZ2FpbiwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IFBoaWwgSHVudCBbbWFpbHRvOnBoaWwuaHVu dEBvcmFjbGUuY29tXQ0KU2VudDogVHVlc2RheSwgQXVndXN0IDksIDIwMTYgMTI6MDcgUE0NClRv OiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwu Sm9uZXNAbWljcm9zb2Z0LmNvbT4+DQpDYzogaWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOmlkLWV2 ZW50QGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtJZC1ldmVudF0gU3VtbWFyaXppbmcgcmVjZW50 IGRpc2N1c3Npb25zIG9uIElELUV2ZW50IHRva2VuIGRyYWZ0DQoNCkkgZGlkbuKAmXQgY292ZXIg dGhpcyBhcyBJIGRpZG7igJl0IHdhbnQgdG8gY29uZnVzZSBwZW9wbGUgd2l0aCB0b28gbWFueSB0 aGluZ3MuDQoNCkJ1dCBJIHRoaW5rIHdlIGFncmVlIG9uIGFsbCBvZiB0aGUgYmVsb3cuDQoNCkni gJltIG5vdCBzdXJlIHRoYXQgd2UgbmVlZCBhIOKAnG5hbWXigJ0uIFdoYXQgaXMgeW91ciBpbnRl bnRpb24gdGhlcmUuDQoNClBoaWwNCg0KQGluZGVwZW5kZW50aWQNCnd3dy5pbmRlcGVuZGVudGlk LmNvbTxodHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tLz4NCnBoaWwuaHVudEBvcmFjbGUuY29t PG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4NCg0KDQoNCg0KT24gQXVnIDksIDIwMTYsIGF0 IDExOjU0IEFNLCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRv Ok1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KDQpUaGFua3MgZm9yIHdyaXRp bmcgdGhpcywgUGhpbC4gIFVuZm9ydHVuYXRlbHksIHRoZSBzdW1tYXJ5IGJlbG93IGRvZXMgbm90 IGluY2x1ZGUgbXkgZmVlZGJhY2ssIHdoaWNoIGF0IHRoZSBlc3NlbmNlLCBpcyB0byBrZWVwIHRo ZSBJRCBFdmVudHMgZGF0YSBzdHJ1Y3R1cmUgYXMgc2ltcGxlIGFuZCBnZW5lcmFsLXB1cnBvc2Ug YXMgcG9zc2libGUuICAoSSBzdHJvbmdseSBiZWxpZXZlIHRoYXQgSldUIGlzIHRoZSBzdWNjZXNz IGl0IGlzIGJlY2F1c2Ugd2UgbWFkZSBKV1QgYXMgc2ltcGxlIGFuZCBnZW5lcmFsLXB1cnBvc2Ug YXMgcG9zc2libGUsIGFuZCB3ZSBzaG91bGQgZm9sbG93IHRoaXMgc3VjY2Vzc2Z1bCBleGFtcGxl IGFuZCBkbyB0aGUgc2FtZSBoZXJlLikNCg0KSSBiZWxpZXZlIHRoYXQgdGhlIElEIEV2ZW50cyBz cGVjIG5lZWRzIHRvIGluY2x1ZGUgdGhlc2UgdGhpbmdzLCBhbmQgdGhlc2UgdGhpbmdzIG9ubHk6 DQrigKIgICAgICAgRGVmaW5lIG9mIHRoZSDigJxldmVudHPigJ0gY2xhaW0NCuKAoiAgICAgICBE ZWZpbmUgdGhhdCBhbiBldmVudCBuYW1lIGNhbiBiZSB1c2VkIGFzIGEgdG9wLWxldmVsIGNsYWlt DQrigKIgICAgICAgUmVxdWlyZSB0aGF0IOKAnGlzc+KAnSBiZSBpbmNsdWRlZCBhbmQgdGhhdCB0 aGUgSldUIGJlIHNpZ25lZCBieSB0aGUgaXNzdWVyDQrigKIgICAgICAgSW5jbHVkZSBhIHN0YXRl bWVudCBhbG9uZyB0aGUgbGluZXMgb2Yg4oCcVGhlIGNsYWltcyB0byBiZSBpbmNsdWRlZCB3aXRo IGFueSBwYXJ0aWN1bGFyIGV2ZW50IGFyZSB0byBiZSBkZWZpbmVkIGJ5IHRoZSBldmVudOKAnQ0K DQpBbmQgSeKAmWQgc3RvcCB0aGVyZS4NCg0KSXQgc2hvdWxkIGJlIGVudGlyZWx5IHVwIHRvIGFw cGxpY2F0aW9ucyB0byBzYXkgd2hhdCBjbGFpbXMgYXJlIGluY2x1ZGVkIHdpdGggZXZlbnRzIHRo ZXkgZGVmaW5lIGFuZCB3aGF0IHRoZWlyIGZvcm1hdCBhbmQgbWVhbmluZ3MgYXJlLiAgVGhlbiB0 aGUgSUQgRXZlbnRzIHNwZWMgd2lsbCBiZSBhcyBnZW5lcmFsLXB1cnBvc2UgYXMgcG9zc2libGUs IHdpdGggaXQgYmVpbmcgbmF0dXJhbCBmb3IgaXQgdG8gYmUgdXNlZCBpbiBlc3NlbnRpYWxseSBh bGwgSlNPTiBFdmVudCBjb250ZXh0cy4NCg0KQXMgc29vbiBhcyB3ZSBzdGFydCBwdXR0aW5nIHJl c3RyaWN0aW9ucyBvbiB0aGUgdXNlIG9mIHBhcnRpY3VsYXIgY2xhaW1zIGJ5IGV2ZW50cywgd2Xi gJlyZSBtYWtpbmcgdGhlIElEIEV2ZW50cyBzcGVjIGxlc3MgZ2VuZXJhbC1wdXJwb3NlIGFuZCBs ZXNzIG5hdHVyYWwgdG8gdXNlLiAgSW4gcGFydGljdWxhciwgdGhlIG9ubHkgdGhpbmcgdGhhdCB0 aGUgc3BlYyBzaG91bGQgc2F5IGFib3V0IHRoZSDigJxzdWLigJ0gY2xhaW0gaXMgdGhhdCDigJxM aWtlIGFsbCBvdGhlciBjbGFpbXMgb3RoZXIgdGhhbiDigJhldmVudHPigJkgYW5kIOKAmGlzc+KA mSwgd2hldGhlciB0aGUg4oCYc3Vi4oCZIGNsYWltIGlzIHRvIGJlIGluY2x1ZGVkIHdpdGggYW4g ZXZlbnQgaXMgZW50aXJlbHkgZXZlbnQtc3BlY2lmaWMuICBUaGUgY2xhaW1zIHRvIGJlIGluY2x1 ZGVkIHdpdGggYW55IHBhcnRpY3VsYXIgZXZlbnQgYXJlIGV4cGxpY2l0bHkgb3V0c2lkZSB0aGUg c2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uLuKAnQ0KDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBJZC1ldmVu dCBbbWFpbHRvOmlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQaGlsIEh1 bnQNClNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCA5LCAyMDE2IDEwOjE5IEFNDQpUbzogaWQtZXZlbnRA aWV0Zi5vcmc8bWFpbHRvOmlkLWV2ZW50QGlldGYub3JnPg0KU3ViamVjdDogW0lkLWV2ZW50XSBT dW1tYXJpemluZyByZWNlbnQgZGlzY3Vzc2lvbnMgb24gSUQtRXZlbnQgdG9rZW4gZHJhZnQNCg0K SSB0aG91Z2h0IEkgd291bGQgdXBkYXRlIHRoZSBsaXN0IG9uIHNvbWUgZGlzY3Vzc2lvbnMgdGhh dCBoYXZlIGJlZW4gaGFwcGVuaW5nIG92ZXIgaW4gdGhlIE9wZW5JRCBDb25uZWN0IGFuZCBSSVND IHdvcmtpbmcgZ3JvdXBzIGNvbmZlcmVuY2UgY2FsbHMuDQoNClRoZXNlIGRpc2N1c3Npb25zIGhh dmUgYmVlbiBhYm91dCB0aGUgY29yZSBzcGVjIGFuZCB0aGUgcm9sZSBvZiDigJx0b3AtbGV2ZWzi gJ0gYXR0cmlidXRlcyB2cy4gZXZlbnQg4oCcZXh0ZW5zaW9u4oCdIGF0dHJpYnV0ZXMuDQpTZWU6 IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1odW50LWlkZXZlbnQtdG9rZW4tMDEN Cg0KSW4gcGFydGljdWxhciBzaG91bGQg4oCcc3Vi4oCdIGJlIHVzZWQgaW4gdGhlIHRvcCBsZXZl bCB0byDigJxwb2ludOKAnSB0byB0aGUgc3ViamVjdCAoaW4gdGhlIGJyb2FkZXIgZW5nbGlzaCBz ZW5zZSkgb2YgdGhlIGV2ZW50LCBvciBzaG91bGQgaXQgYmUgY29uc3RyYWluZWQgdG8gdGhlIFNB TUwvSUQgVG9rZW4gZGVmaW5pdGlvbiB3aGljaCBpcyB0aGUgYXV0aGVudGljYXRlZCB1c2VyLg0K DQpUYWtlbiBpbiB0aGUgbmFycm93ZXIgZGVmaW5pdGlvbiwgaXQgaXMgaW1wb3J0YW50IHRvIG9i c2VydmUgdGhhdCBpbiBhbiBJRCBUb2tlbiwg4oCcc3Vi4oCdIGFuZCDigJxpc3PigJ0gZ28gdG9n ZXRoZXIuICBUaGUgaXNzdWVyIHByb3ZpZGVzIHRoZSBjb250ZXh0IGZvciB0aGUgYXV0aGVudGlj YXRlZCBzdWJqZWN0IGlkZW50aWZpZXIuIFRoZSBwcm9ibGVtIHdpdGggZXZlbnRzLCBpcyB0aGF0 IGl0IG1pZ2h0IG5vdCBiZSB0aGUgQVMgKG9yIE9QKSB3aGljaCBpcyBpc3N1aW5nIHRoZSBldmVu dC4NCg0KVG8gc3VtbWFyaXplIGEgZmFpciBhbW91bnQgb2YgZGlzY3Vzc2lvbiwgdGhlIGZlZWxp bmcgc2VlbXMgdG8gYmUgdGhlIGZvbGxvd2luZzoNCg0KKiAgVGhlIEV2ZW50IFRva2VuIHRvcCBs ZXZlbCBhdHRyaWJ1dGVzIHNob3VsZCBiZSBmYWlybHkgbGltaXRlZCBhbmQgbm90IGluY2x1ZGUg dGhlIHN1YiBhdHRyaWJ1dGUuDQoqICBGb3IgZXZlbnRzIHRoYXQgYXJlIGFib3V0IGEgdXNlciwg dGhlIHJlbGV2YW50IGV2ZW50IHNwZWNpZmljYXRpb24gbWF5IGluY2x1ZGUgYSDigJxzdWLigJ0g YXR0cmlidXRlIHdpdGhpbiB0aGUgZXZlbnTigJlzIHN1Yi1vYmplY3QgYW5kIG5vdCBpbiB0aGUg dG9wLWxldmVsLiBGdXJ0aGVyIHRoYXQgc3ViLW9iamVjdCBjYW4gYWxzbyBpbmNsdWRlIHRoZSBp c3N1ZXIgb2YgdGhlIHVzZXIuDQoqIFRoZSB0b3AtbGV2ZWwg4oCcaXNz4oCdIHNoYWxsIG1lYW4g dGhlIGlzc3VlciBvZiB0aGUgZXZlbnQgd2hlcmUgdGhlIHN0YXRlIGNoYW5nZSBvY2N1cnJlZC4N CiogIOKAnHN1YuKAnSBzaG91bGQgbm90IGJlIHByZXNlbnQgaW4gdGhlIHRvcCBsZXZlbCBzdHJ1 Y3R1cmUuICBBbHNvLCDigJxldmVudHPigJ0gbXVzdCBhbHNvIGJlIHByZXNlbnQuDQoNCkhlcmUg d291bGQgYmUgYSBuZXcgZXhhbXBsZSBsb2dvdXQ6DQoNCnsNCg0KICA84oCUIHRvcCBsZXZlbCBp cyBhYm91dCB0aGUgZXZlbnQgaXRzZWxmIC0+DQoNCiAgImlzcyI6ICJodHRwczovL3NlcnZlci5l eGFtcGxlLmNvbTxodHRwczovL3NlcnZlci5leGFtcGxlLmNvbS8+IiwNCg0KICAiYXVkIjogInM2 QmhkUmtxdDMiLA0KDQogICJqdGkiOiAiM2QwYzNjZjc5NzU4NGJkMTkzYmQwZmIxYmQ0ZTdkMzAi LA0KDQogICJpYXQiOiAxNDU4NjY4MTgwLA0KDQogICJleHAiOiAxNDU4NjY4NTgwLA0KDQogICJl dmVudHMiOiBbDQoNCiAgICAiaHR0cHM6Ly9zcGVjcy5vcGVuaWQubmV0L2xvZ291dCINCg0KICBd LA0KDQogICJodHRwczovL3NwZWNzLm9wZW5pZC5uZXQvbG9nb3V0Ijogew0KDQogICAgPC0gVGhp cyBsZXZlbCBpcyBkZWZpbmVkIGVudGlyZWx5IGJ5IHRoZSBldmVudCBVUkktPg0KDQogICAgImlz cyI6ICJodHRwczovL29pZGMuZXhhbXBsZS5jb208aHR0cHM6Ly9vaWRjLmV4YW1wbGUuY29tLz4i LA0KDQogICAg4oCcanRpIjogIjA4YTUwMTljLTE3ZTEtNDk3Ny04ZjQyLTY1YTEyODQzZWEwMuKA nSwNCg0KICAgICJzdWIiOiAiMjQ4Mjg5NzYxMDAx4oCdLA0KDQogICAg4oCcZXhw4oCdOiA8SUQg dG9rZW4gZXhwaXJ5Pg0KDQogIH0NCg0KfQ0KDQpJbiB0aGUgYWJvdmUgZXhhbXBsZSBub3RlIHRo YXQgdGhlIOKAnGV2ZW504oCdIG9iamVjdCBjYW4gaGF2ZSBpdHMgb3duIGlzcyBhbmQgc3ViamVj dCAoc3ViIG9yIGp0aSkgdGhhdCBoYXZlIG1lYW5pbmcgd2l0aGluIHRoZSBjb250ZXh0IG9mIGFu IE9wZW5JRCBPUCBwcm92aWRlci4gIFRoZSBpc3N1ZXIgb2YgdGhlIGV2ZW50IGNhbiBiZSBkaWZm ZXJlbnQgKHRoZSB0b3AtbGV2ZWwpIGFuZCByZXByZXNlbnRzIHRoZSBlbnRpdHkgdGhhdCBzaWdu cyB0aGUgZXZlbnQgKGlmIGl0IGlzIHNpZ25lZCkuDQoNClRoZSB0b3AtbGV2ZWwgYXR0cmlidXRl cyBpZGVudGlmeSBhbiBpbmRpdmlkdWFsIGV2ZW50IGFuZCBhcmUgdXNlZCB0byB2YWxpZGF0ZSB0 aGUgZXZlbnQgKHNpZ25pbmcgZXRjKS4gIFdoZXJlIGFzIHRoZSBuZXN0ZWQgb2JqZWN0IGNvbnRh aW5zIGFsbCBvZiB0aGUgZGF0YSBhYm91dCB0aGUgZXZlbnQgYW5kIGlzIGRlZmluZWQgYnkgdGhl IHByb2ZpbGluZyBzcGVjaWZpY2F0aW9uIChlLmcuIGEgcG9zc2libGUgT3BlbklEIExvZ291dCBF dmVudCBzcGVjKS4gIEluIHRoaXMgY2FzZSwgaW4gT3BlbklELCBsb2dnaW5nIG91dCB1c3VhbGx5 IHRyYW5zbGF0ZXMgaW50byByZXZva2luZyBhbiBJRCBUb2tlbi4gVGh1cyB0aGUg4oCcanRp4oCd IGZvciB0aGUgSUQgdG9rZW4gKDA4YTUwMTljLi4uODQzZWEwMikgaXMgaW5jbHVkZWQgaW4gdGhl IExvZ291dCBvYmplY3QuDQoNClNpZGUgbm90ZS4gIFJlZ2FyZGluZyDigJxsb2dvdXTigJ0sIGl0 IG1pZ2h0IGJlIHVzZWZ1bCB0byBpbmNsdWRlIHRoZSBleHBpcnkgb2YgdGhlIElEIFRva2VuIGlu IGNhc2UgdGhlIHN1YnNjcmliZXIgaGFzIG5vdCB5ZXQgcmVjZWl2ZWQgYW4gSUQgVG9rZW4uIFRo aXMgd291bGQgbGV0IHRoZSBzdWJzY3JpYmVyIGtub3cgaG93IGxvbmcgaXQgbmVlZHMgdG8ga2Vl cCB0aGUgcmV2b2NhdGlvbiBpbmZvcm1hdGlvbiBmb3IuICBJT1figKZhZnRlciB0aGUgdGhlIElE IFRva2VuIGlzIGV4cGlyZWQsIHRoZSBzdWJzY3JpYmVyIHdvdWxkIG5vIGxvbmdlciBuZWVkIHRv IHRyYWNrIHRoZSByZXZvY2F0aW9uIHN0YXRlLg0KDQpJdCBpcyBhbHNvIGdvb2QgdG8gb2JzZXJ2 ZSB0aGF0IHRoZSDigJxhdWTigJ0gYXQgdGhlIHRvcCBsZXZlbCBkZXNjcmliZXMgdGhlIHN1YnNj cmliZXIgb2YgdGhlIGV2ZW50LiAgVGhpcyBtYXkgYWxzbyBiZSBkaWZmZXJlbnQgdGhlbiB0aGUg b3JpZ2luYWwgYXVkaWVuY2Ugb2YgdGhlIElEIFRva2VuLg0KDQpTbyB0byBjb25jbHVkZS4gQnkg bWFraW5nIHRvcC1sZXZlbCBhdHRyaWJ1dGVzIHN0cmljdGx5IGFib3V0IHRoZSBldmVudHMgb3du IHZhbGlkYXRpb24sIGFuZCBuZXN0ZWQgb2JqZWN0cyBhYm91dCB0aGUgZXZlbnQsIHdlIGF2b2lk IGNvbGxpc2lvbnMgaW4gZGVmaW5pdGlvbnMgc3VjaCBhcyB0aGUgaXNzdWVyIG9mIHRoZSBldmVu dCwgdnMuIHRoZSBvcmlnaW5hbCBpc3N1ZXIgb2YgYSBzZWN1cml0eSBhc3NlcnRpb24uDQoNCkkg aG9wZSBJ4oCZdmUgZ290dGVuIGV2ZXJ5b25l4oCZcyBmZWVkYmFjayBjb3JyZWN0IGhlcmUuIExl dHMgY29udGludWUgdG8gZGlzY3Vzcy4gSSB3aWxsIHJldmlzZSB0aGUgZHJhZnQgdG8gZm9sbG93 IHRoZSBncm91cHMgdGhpbmtpbmcgaGVyZS4NCg0KUGhpbA0KDQpAaW5kZXBlbmRlbnRpZA0Kd3d3 LmluZGVwZW5kZW50aWQuY29tPGh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20vPg0KcGhpbC5o dW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSWQtZXZlbnQgbWFpbGluZyBs aXN0DQpJZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc+DQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50DQoNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklkLWV2ZW50IG1haWxpbmcgbGlz dA0KSWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudA0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSWQtZXZlbnQgbWFpbGluZyBsaXN0DQpJ ZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KSWQtZXZlbnQgbWFpbGluZyBsaXN0DQpJZC1ldmVu dEBpZXRmLm9yZzxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50DQo= --_000_SN1PR0301MB164598544F3C4579D120C4F5F51E0SN1PR0301MB1645_ 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 DQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4w cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToi Q291cmllciBOZXciO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1h bDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy Z2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUt bmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29s YXM7fQ0Kc3Bhbi5tLTY1MzQ0MzU1NzM2Mzk2NzM3ODZhcHBsZS1zdHlsZS1zcGFuDQoJe21zby1z dHlsZS1uYW1lOm1fLTY1MzQ0MzU1NzM2Mzk2NzM3ODZhcHBsZS1zdHlsZS1zcGFuO30NCnNwYW4u bS02NTM0NDM1NTczNjM5NjczNzg2YXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1u YW1lOm1fLTY1MzQ0MzU1NzM2Mzk2NzM3ODZhcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5F bWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzAwMjA2MDt9DQpzcGFuLkVtYWlsU3R5bGUyMw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjojMDAyMDYwO30NCnNwYW4uRW1haWxTdHlsZTI0DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CWNvbG9yOiMwMDIwNjA7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4 LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0i RU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYw Ij5JbiB0aGUgT3BlbklEIENvbm5lY3QgQmFjay1DaGFubmVsIExvZ291dCBjYXNlLCB0aGlzIGNv bmZsaWN0LCBieSBkZWZpbml0aW9uLCBjYW4gbmV2ZXIgb2NjdXIuICZuYnNwO09uZSBvZiB0aGUg dmFsaWRhdGlvbiBydWxlcyBmb3IgdGhlIGxvZ291dCBldmVudCBpcyB0aGF0IGl0IE1VU1QNCiBi ZSBzaWduZWQgYnkgdGhlIGlkZW50aXR5IHByb3ZpZGVyIOKAkyB0aGUgc2FtZSBwYXJ0eSB0aGF0 IGlzc3VlZCB0aGUgSUQgVG9rZW4gYXQgYXV0aGVudGljYXRpb24gdGltZS4mbmJzcDsgT3RoZXJ3 aXNlLCBpdOKAmXMgbGlrZWx5IHBhcnQgb2YgYW4gYXR0YWNrLCBhbmQgbXVzdCBiZSBkaXNjYXJk ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5ZZXMsIHRoZXJl IGFyZSBvdGhlciB1c2UgY2FzZXMgaW4gd2hpY2ggbXVsdGlwbGUgcGFydGllcyBtaWdodCBzaWdu IGRpZmZlcmVudCBKV1RzIGluIGFuIGFwcGxpY2F0aW9uIGNvbnRleHQuJm5ic3A7IFllcywgaW4g dGhvc2UgY2FzZXMsIG1vcmUgY29tcGxleCBldmVudCBkYXRhIHN0cnVjdHVyZXMNCiBtaWdodCBi ZSBuZWVkZWQuJm5ic3A7IEJ1dCBpbiB0aGUgYmFjay1jaGFubmVsIGxvZ291dCBjYXNlLCB0aGVy ZeKAmXMgZXhhY3RseSBvbmUgaXNzdWVyIGFuZCBvbmUgc3ViamVjdCwgd2hpY2ggTVVTVCBtYXRj aCB0aG9zZSBpbiB0aGUgcHJldmlvdXNseSBpc3N1ZWQgSUQgVG9rZW4uPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIw NjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5JdOKAmXMgYW4gaW50ZW50aW9uYWxseSB2ZXJ5 IHNpbXBsZSB1c2UgY2FzZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIw NjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRD b21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9hPjwvcD4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3Nl Ij48L3NwYW4+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4gUGhpbCBIdW50IChJRE0pIFttYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb21dDQo8YnI+ DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEF1Z3VzdCAxMSwgMjAxNiAxMToyNiBBTTxicj4NCjxi PlRvOjwvYj4gTWlrZSBKb25lcyAmbHQ7TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tJmd0Ozxi cj4NCjxiPkNjOjwvYj4gaWQtZXZlbnRAaWV0Zi5vcmc7IE1hcml1cyBTY3VydGVzY3UgJmx0O21z Y3VydGVzY3VAZ29vZ2xlLmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtJZC1ldmVu dF0gU3VtbWFyaXppbmcgcmVjZW50IGRpc2N1c3Npb25zIG9uIElELUV2ZW50IHRva2VuIGRyYWZ0 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhv dyBkbyB5b3UgcmVzb2x2ZSB0aGUgY29uZmxpY3QgdGhhdCBhcmlzZXMgYXJvdW5kIGlzcyBzaW5j ZSBpc3MgbXVzdCBiZSB0aGUgZW50aXR5IHRoYXQgc2lnbmVkIHRoZSBldmVudCBhbmQgd2lsbCBv ZnRlbiBub3QgYmUgdGhlIG9uZSB0aGF0IGlzc3VlZCB0aGUgb3JpZ2luYWwgaWR0b2tlbiBpbiB0 aGUgY2FzZSBvZiBvcGVuaWQoYW5kIHdoaWNoIHVuaXF1ZWx5IHF1YWxpZmllcyBzdWIpLiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KUGhpbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48 YnI+DQpPbiBBdWcgMTEsIDIwMTYsIGF0IDg6MDMgQU0sIE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9 Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iPk1pY2hhZWwuSm9uZXNAbWljcm9z b2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+VGhlIHNp bXBsZSBydWxlIGlzIHRoYXQgaWYgdGhlIHBhcnRpY3VsYXIgZXZlbnQgY2FsbHMgZm9yIHRoZSDi gJxzdWLigJ0gY2xhaW0gdG8gYmUgYXQgdGhlIHRvcCBsZXZlbCwgdGhlbiBpdCBpcy4mbmJzcDsg VGhpcyBpcyBubyBkaWZmZXJlbnQgZnJvbSBhbnkgb3RoZXIgY2xhaW0gdGhhdA0KIGFuIGV2ZW50 IG1pZ2h0IHBsYWNlIGF0IHRoZSB0b3AgbGV2ZWwuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMDAyMDYwIj5UaGUgY29tcGxleGl0eSBhcmlzZXMgaWYg4oCcc3Vi4oCdIGlzIHVu bmVjZXNzYXJpbHkgc3BlY2lhbC1jYXNlZC4mbmJzcDsgV2Ugc2hvdWxkbuKAmXQgZG8gdGhhdCwg YmVjYXVzZSBpdCBsaW1pdHMgdGhlIGFwcGxpY2FiaWxpdHkgb2YgdGhlIHNwZWNpZmljYXRpb24u PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4gUGhpbCBIdW50IChJRE0pIFs8YSBocmVmPSJtYWlsdG86cGhp bC5odW50QG9yYWNsZS5jb20iPm1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbTwvYT5dDQo8YnI+ DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEF1Z3VzdCAxMSwgMjAxNiA5OjQwIEFNPGJyPg0KPGI+ VG86PC9iPiBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNy b3NvZnQuY29tIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0Ozxicj4NCjxiPkNj OjwvYj4gTWFyaXVzIFNjdXJ0ZXNjdSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1zY3VydGVzY3VAZ29v Z2xlLmNvbSI+bXNjdXJ0ZXNjdUBnb29nbGUuY29tPC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86 aWQtZXZlbnRAaWV0Zi5vcmciPmlkLWV2ZW50QGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW0lkLWV2ZW50XSBTdW1tYXJpemluZyByZWNlbnQgZGlzY3Vzc2lvbnMgb24gSUQt RXZlbnQgdG9rZW4gZHJhZnQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SSB0aGluayB1c2luZyBzdWIgYXQgdGhlIHRvcCBsZXZlbCBsZWFkcyB0 byBjb21wbGV4aXR5LiBFZyBDYW4geW91IHByb3ZpZGUgYSBydWxlIGZvciB3aGVuIHRvcCBsZXZl bCBpcyB1c2VkIG9yIG5vdCBieSBhbiBpbmRpdmlkdWFsIHNwZWM/ICZuYnNwO0lNTy4gVG9wIGxl dmVsIHNob3VsZCBhbHdheXMgYmUgdXNlZCB0aGUgc2FtZSB3YXkgYnkgYWxsIGltcGxlbWVudGVy cy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0 dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmFz ZWQgb24gdGhlIGNhbGxzIGF0IHJpc2MvY29ubmVjdCwgd2UgZGlzY3Vzc2VkIHRoYXQgaXQgd291 bGQgYmUgYmVzdCB0byBtb3ZlIGFsbCBldmVudCBzcGVjaWZpY3MgdG8gdGhlIGV2ZW50IG9iamVj dCBhcmVhLiBUaGlzIHdheSBkaWZmZXJlbnQgZXZlbnRzIGNhbiBoYXZlIGRpZmZlcmVudCBldmVu dCBhZGRyZXNzaW5nIChlZyBzdWIvaXNzLCB1cmksIGppdC9pc3MpLiBXaGVuIGlzcyBpcyBuZWVk ZWQgdG8NCiB1bmlxdWVseSBxdWFsaWZ5IGEgc3ViLCBpdCBjYW4gYmUgcHJvdmlkZWQgd2l0aG91 dCBjb25mbGljdGluZyB3aXRoIHRoZSBpc3N1ZXIgb2YgdGhlIGV2ZW50LiBTaW1pbGFybHkganRp IGFuZCBpc3MgY2FuIGJlIHVzZWQgZm9yIGEgcmV2b2tlZCB0b2tlbiB3aXRob3V0IGNvbmZsaWN0 aW5nIHdpdGggdGhlIGV2ZW50IGp0aS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp diBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SSBwbGFuIHRvIHBvc3QgYSBuZXcgZHJhZnQgc2hvcnRseSB0aGF0 IHdpbGwgZ2l2ZSBzb21lIGV4YW1wbGVzIGJhc2VkIG9uIGZlZWRiYWNrIGZyb20gdGhlIG9wZW5p ZCByaXNjL2Nvbm5lY3QgZGlzY3Vzc2lvbnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYg aWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPldlIGNhbiBhbHdheXMgY2hhbmdlIGFnYWluLiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGJyPg0KUGhpbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpPbiBB dWcgMTEsIDIwMTYsIGF0IDQ6NTQgQU0sIE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpN aWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Tm8sIEnigJltIG5vdCBz YXlpbmcgdGhhdCDigJxzdWLigJ0gY2Fubm90IGFwcGVhciBhdCB0aGUgdG9wIGxldmVsLiZuYnNw OyBJ4oCZbSBzYXlpbmcgdGhhdCDigJxzdWLigJ0gd2lsbCBvbmx5IG9jY3VyIGF0IHRoZSB0b3Ag bGV2ZWwgaWYgdGhlIHBhcnRpY3VsYXIgZXZlbnQgZGVmaW5lcyB0aGF0IOKAnHN1YuKAnQ0KIGlz IHVzZWQgaW4gdGhhdCB3YXkgZm9yIHRoYXQgZXZlbnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMDAyMDYwIj5UaGVyZSBhcmUgcHJvYmFibHkgdXNlIGNhc2VzIGZvciBtdWx0 aXBsZSBldmVudHMgcGVyIG1lc3NhZ2UgYnV0IEkgZG91YnQgdGhlcmUgYXJlIHVzZSBjYXNlcyBm b3IgbXVsdGlwbGUgKjxiPnVucmVsYXRlZDwvYj4qIGV2ZW50cyBwZXIgbWVzc2FnZS4mbmJzcDsg QnkgZGVmaW5pdGlvbiwNCiByZWxhdGVkIGV2ZW50cyB0aGF0IHVzZSB0b3AtbGV2ZWwgY2xhaW1z IHdvdWxkIG5lZWQgdG8gdXNlIHRoZW0gaW4gYSBjb21wYXRpYmxlIHdheS4mbmJzcDsgSSBkb27i gJl0IHNlZSB0aGF0IGFzIGJlaW5nIGEgcHJvYmxlbS48L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMwMDIwNjAiPlRoYXQgYmVpbmcgc2FpZCwgdGhlIHByZWRvbWluYW50IHVzZSBj YXNlIGlzIGxpa2VseSB0byBiZSBhIHNpbmdsZSBldmVudCBwZXIgSldULjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAy MDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4g TWFyaXVzIFNjdXJ0ZXNjdSBbPGEgaHJlZj0ibWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbSI+ bWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVl c2RheSwgQXVndXN0IDksIDIwMTYgNzoxNSBQTTxicj4NCjxiPlRvOjwvYj4gUGhpbCBIdW50ICZs dDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iPnBoaWwuaHVudEBvcmFjbGUu Y29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0 bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNv bTwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOmlkLWV2ZW50QGlldGYub3JnIj5pZC1ldmVudEBp ZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtJZC1ldmVudF0gU3VtbWFyaXpp bmcgcmVjZW50IGRpc2N1c3Npb25zIG9uIElELUV2ZW50IHRva2VuIGRyYWZ0PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWlrZSwgYXJlIHlvdSBzdWdnZXN0aW5nIHRoYXQg YSBzdWIgY2xhaW0gY2FuIG9ubHkgc2hvdyB1cCBhdCB0aGUgZXZlbnQgbGV2ZWwgYW5kIG5vdCBh dCB0aGUgdG9wIGxldmVsOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0 OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIHBhcnRp Y3VsYXIsIHRoZSBvbmx5IHRoaW5nIHRoYXQgdGhlIHNwZWMgc2hvdWxkIHNheSBhYm91dCB0aGUg 4oCcc3Vi4oCdIGNsYWltIGlzIHRoYXQg4oCcTGlrZSBhbGwgb3RoZXIgY2xhaW1zIG90aGVyIHRo YW4g4oCYZXZlbnRz4oCZIGFuZCDigJhpc3PigJksIHdoZXRoZXIgdGhlIOKAmHN1YuKAmSBjbGFp bSBpcyB0byBiZSBpbmNsdWRlZCB3aXRoIGFuIGV2ZW50IGlzIGVudGlyZWx5IGV2ZW50LXNwZWNp ZmljLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+QSB0b3AgbGV2ZWwgc3ViIGFuZCBtdWx0aXBsZSBldmVudHMgYXJlIGluY29tcGF0 aWJsZSBJTU8uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkRvIHdlIGhhdmUgYSBjb21wZWxsaW5nIHJlYXNvbiB0byBzdXBwb3J0IG11bHRpcGxl IGV2ZW50cyBwZXIgbWVzc2FnZT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWFyaXVzPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBBdWcgOSwgMjAxNiBh dCAxMjozOSBQTSwgUGhpbCBIdW50ICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNs ZS5jb20iIHRhcmdldD0iX2JsYW5rIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3YXMgcmVmZXJyaW5nIHRv IHRoaXMgaW4geW91ciBlbWFpbDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZxdW90OzxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5EZWZpbmUgdGhhdCBh biBldmVudCBuYW1lIGNhbiBiZSB1c2VkIGFzIGEgdG9wLWxldmVsIGNsYWlt4oCdPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JcyB0aGlzIGRpZmZlcmVudCBmcm9tIHRoZSBldmVudCB1cmk/PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PlBoaWw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+QGluZGVwZW5kZW50aWQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxh IGhyZWY9Imh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20iIHRhcmdldD0iX2JsYW5rIj53d3cu aW5kZXBlbmRlbnRpZC5jb208L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPjxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PbiBBdWcgOSwgMjAxNiwgYXQgMTI6MTIgUE0sIE1pa2UgSm9uZXMgJmx0Ozxh IGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5r Ij5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzAwMjA2MCI+SeKAmW0gZ2xhZCB0byBoZWFyIHRoYXQgd2UgYWdyZWUgb24ga2VlcGlu ZyBpdCBhcyBzaW1wbGUgYW5kIGdlbmVyYWwtcHVycG9zZSBhcyBwb3NzaWJsZSBhbmQgdGhhdCB5 b3UgYWdyZWUgd2l0aCBteSB3cml0ZS11cC4mbmJzcDsgSSB0aGluayB3ZSB0aGVuIGhhdmUgYSBn b29kIHBhdGgNCiBmb3J3YXJkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+SeKAmW0gbm90IHN1cmUgd2hhdCB5 b3UgbWVhbiBieSDigJw8L3NwYW4+SeKAmW0gbm90IHN1cmUgdGhhdCB3ZSBuZWVkIGEg4oCcbmFt ZeKAnS4gV2hhdCBpcyB5b3VyIGludGVudGlvbiB0aGVyZS48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzAwMjA2MCI+4oCdJm5ic3A7DQogVGhlIG9ubHkgcGxhY2UgSSB1c2VkIHRoZSB3b3JkIOKAnG5h bWXigJ0gd2FzIGluIG15IHN0YXRlbWVudCDigJxEZWZpbmUgdGhhdCBhbiBldmVudCBuYW1lIGNh biBiZSB1c2VkIGFzIGEgdG9wLWxldmVsIGNsYWlt4oCdLiZuYnNwOyBXaGF0IEkgd2FzIHRyeWlu ZyB0byBnZXQgYXQgaXMgd2FzIHRoYXQgaWYg4oCcPGEgaHJlZj0iaHR0cDovL3NwZWNzLm9wZW5p ZC5uZXQvbG9nb3V0IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ aHR0cDovL3NwZWNzLm9wZW5pZC5uZXQvbG9nb3V0PC9zcGFuPjwvYT7igJ0NCiBpcyB1c2VkIGFz IGFuIGV2ZW50IG5hbWUsIHRoYXQgaXQgY2FuIGFsc28gYmUgdXNlZCBhcyBhIGNsYWltIG5hbWUg aW4gdGhlIEpXVCBjb250YWluaW5nIGluZm9ybWF0aW9uIGFib3V0IHRoZSBldmVudC4mbmJzcDsg KE1heWJlIEnigJltIG5vdCB1c2luZyB0aGUgY29ycmVjdCB0ZXJtaW5vbG9neSwgaGVuY2UgdGhl IHVuaW50ZW5kZWQgY29uZnVzaW9uPHNwYW4gY2xhc3M9Im0tNjUzNDQzNTU3MzYzOTY3Mzc4NmFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6IzAwMjA2MCI+Sjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Lik8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGFua3MgYWdhaW4sPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAtLSBNaWtlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0ibV8tNjUzNDQzNTU3MzYzOTY3Mzc4Nl9fTWFpbEVu ZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PC9h PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJtLTY1MzQ0MzU1NzM2Mzk2NzM3ODZhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPlBoaWwNCiBIdW50IFs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20i IHRhcmdldD0iX2JsYW5rIj5tYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb208L2E+XTxzcGFuIGNs YXNzPSJtLTY1MzQ0MzU1NzM2Mzk2NzM3ODZhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj48YnI+DQo8Yj5TZW50OjwvYj48c3BhbiBjbGFzcz0ibS02NTM0NDM1NTczNjM5NjczNzg2 YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+VHVlc2RheSwgQXVndXN0IDksIDIw MTYgMTI6MDcgUE08YnI+DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9Im0tNjUzNDQzNTU3MzYzOTY3 Mzc4NmFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPk1pa2UgSm9uZXMgJmx0Ozxh IGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5r Ij5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj48c3Bh biBjbGFzcz0ibS02NTM0NDM1NTczNjM5NjczNzg2YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmlkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+aWQtZXZlbnRAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9 Im0tNjUzNDQzNTU3MzYzOTY3Mzc4NmFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PlJlOiBbSWQtZXZlbnRdIFN1bW1hcml6aW5nIHJlY2VudCBkaXNjdXNzaW9ucyBvbiBJRC1FdmVu dCB0b2tlbiBkcmFmdDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkaWRu4oCZ dCBjb3ZlciB0aGlzIGFzIEkgZGlkbuKAmXQgd2FudCB0byBjb25mdXNlIHBlb3BsZSB3aXRoIHRv byBtYW55IHRoaW5ncy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJ1dCBJIHRoaW5rIHdlIGFncmVlIG9u IGFsbCBvZiB0aGUgYmVsb3cuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPknigJltIG5vdCBz dXJlIHRoYXQgd2UgbmVlZCBhIOKAnG5hbWXigJ0uIFdoYXQgaXMgeW91ciBpbnRlbnRpb24gdGhl cmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+UGhpbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5AaW5kZXBlbmRl bnRpZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNvbS8iIHRh cmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj53d3cuaW5kZXBlbmRlbnRp ZC5jb208L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJtYWls dG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29s b3I6cHVycGxlIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvc3Bhbj48L2E+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T24gQXVnIDksIDIwMTYsIGF0IDExOjU0IEFNLCBNaWtlIEpvbmVzICZsdDs8YSBo cmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+ PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9z cGFuPjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMwMDIwNjAiPlRoYW5rcyBmb3Igd3JpdGluZyB0aGlzLCBQaGlsLiZuYnNwOyBVbmZvcnR1 bmF0ZWx5LCB0aGUgc3VtbWFyeSBiZWxvdyBkb2VzIG5vdCBpbmNsdWRlIG15IGZlZWRiYWNrLCB3 aGljaCBhdCB0aGUgZXNzZW5jZSwgaXMgdG8ga2VlcCB0aGUgSUQgRXZlbnRzIGRhdGEgc3RydWN0 dXJlIGFzDQogc2ltcGxlIGFuZCBnZW5lcmFsLXB1cnBvc2UgYXMgcG9zc2libGUuICZuYnNwOyhJ IHN0cm9uZ2x5IGJlbGlldmUgdGhhdCBKV1QgaXMgdGhlIHN1Y2Nlc3MgaXQgaXMgYmVjYXVzZSB3 ZSBtYWRlIEpXVCBhcyBzaW1wbGUgYW5kIGdlbmVyYWwtcHVycG9zZSBhcyBwb3NzaWJsZSwgYW5k IHdlIHNob3VsZCBmb2xsb3cgdGhpcyBzdWNjZXNzZnVsIGV4YW1wbGUgYW5kIGRvIHRoZSBzYW1l IGhlcmUuKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+SSBi ZWxpZXZlIHRoYXQgdGhlIElEIEV2ZW50cyBzcGVjIG5lZWRzIHRvIGluY2x1ZGUgdGhlc2UgdGhp bmdzLCBhbmQgdGhlc2UgdGhpbmdzIG9ubHk6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlN5 bWJvbDtjb2xvcjojMDAyMDYwIj7Ctzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0 O2NvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFu IGNsYXNzPSJtLTY1MzQ0MzU1NzM2Mzk2NzM3ODZhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPkRlZmluZQ0KIG9m IHRoZSDigJxldmVudHPigJ0gY2xhaW08L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9s O2NvbG9yOiMwMDIwNjAiPsK3PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29s b3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xh c3M9Im0tNjUzNDQzNTU3MzYzOTY3Mzc4NmFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+RGVmaW5lDQogdGhhdCBh biBldmVudCBuYW1lIGNhbiBiZSB1c2VkIGFzIGEgdG9wLWxldmVsIGNsYWltPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xvcjojMDAyMDYwIj7Ctzwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJtLTY1MzQ0MzU1NzM2Mzk2NzM3ODZhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMw MDIwNjAiPlJlcXVpcmUNCiB0aGF0IOKAnGlzc+KAnSBiZSBpbmNsdWRlZCBhbmQgdGhhdCB0aGUg SldUIGJlIHNpZ25lZCBieSB0aGUgaXNzdWVyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlN5 bWJvbDtjb2xvcjojMDAyMDYwIj7Ctzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0 O2NvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFu IGNsYXNzPSJtLTY1MzQ0MzU1NzM2Mzk2NzM3ODZhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPkluY2x1ZGUNCiBh IHN0YXRlbWVudCBhbG9uZyB0aGUgbGluZXMgb2Yg4oCcVGhlIGNsYWltcyB0byBiZSBpbmNsdWRl ZCB3aXRoIGFueSBwYXJ0aWN1bGFyIGV2ZW50IGFyZSB0byBiZSBkZWZpbmVkIGJ5IHRoZSBldmVu dOKAnTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+QW5kIEni gJlkIHN0b3AgdGhlcmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMw MDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAy MDYwIj5JdCBzaG91bGQgYmUgZW50aXJlbHkgdXAgdG8gYXBwbGljYXRpb25zIHRvIHNheSB3aGF0 IGNsYWltcyBhcmUgaW5jbHVkZWQgd2l0aCBldmVudHMgdGhleSBkZWZpbmUgYW5kIHdoYXQgdGhl aXIgZm9ybWF0IGFuZCBtZWFuaW5ncyBhcmUuJm5ic3A7IFRoZW4gdGhlIElEIEV2ZW50cyBzcGVj DQogd2lsbCBiZSBhcyBnZW5lcmFsLXB1cnBvc2UgYXMgcG9zc2libGUsIHdpdGggaXQgYmVpbmcg bmF0dXJhbCBmb3IgaXQgdG8gYmUgdXNlZCBpbiBlc3NlbnRpYWxseSBhbGwgSlNPTiBFdmVudCBj b250ZXh0cy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPkFz IHNvb24gYXMgd2Ugc3RhcnQgcHV0dGluZyByZXN0cmljdGlvbnMgb24gdGhlIHVzZSBvZiBwYXJ0 aWN1bGFyIGNsYWltcyBieSBldmVudHMsIHdl4oCZcmUgbWFraW5nIHRoZSBJRCBFdmVudHMgc3Bl YyBsZXNzIGdlbmVyYWwtcHVycG9zZSBhbmQgbGVzcyBuYXR1cmFsIHRvIHVzZS4mbmJzcDsNCiBJ biBwYXJ0aWN1bGFyLCB0aGUgb25seSB0aGluZyB0aGF0IHRoZSBzcGVjIHNob3VsZCBzYXkgYWJv dXQgdGhlIOKAnHN1YuKAnSBjbGFpbSBpcyB0aGF0IOKAnExpa2UgYWxsIG90aGVyIGNsYWltcyBv dGhlciB0aGFuIOKAmGV2ZW50c+KAmSBhbmQg4oCYaXNz4oCZLCB3aGV0aGVyIHRoZSDigJhzdWLi gJkgY2xhaW0gaXMgdG8gYmUgaW5jbHVkZWQgd2l0aCBhbiBldmVudCBpcyBlbnRpcmVseSBldmVu dC1zcGVjaWZpYy4mbmJzcDsgVGhlIGNsYWltcyB0byBiZSBpbmNsdWRlZCB3aXRoIGFueQ0KIHBh cnRpY3VsYXIgZXZlbnQgYXJlIGV4cGxpY2l0bHkgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBz cGVjaWZpY2F0aW9uLuKAnTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAw MjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJtLTY1MzQ0MzU1NzM2Mzk2NzM3 ODZhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPklkLWV2ZW50DQogWzxhIGhyZWY9Im1haWx0bzppZC1ldmVu dC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1 cnBsZSI+bWFpbHRvOmlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPl08c3BhbiBj bGFzcz0ibS02NTM0NDM1NTczNjM5NjczNzg2YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+PGI+T24gQmVoYWxmIE9mPHNwYW4gY2xhc3M9Im0tNjUzNDQzNTU3MzYzOTY3Mzc4NmFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5QaGlsDQogSHVudDxicj4NCjxi PlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJtLTY1MzQ0MzU1NzM2Mzk2NzM3ODZhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5UdWVzZGF5LCBBdWd1c3QgOSwgMjAxNiAxMDoxOSBBTTxi cj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0ibS02NTM0NDM1NTczNjM5NjczNzg2YXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmlkLWV2ZW50QGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aWQtZXZlbnRA aWV0Zi5vcmc8L3NwYW4+PC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJtLTY1 MzQ0MzU1NzM2Mzk2NzM3ODZhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5bSWQt ZXZlbnRdIFN1bW1hcml6aW5nIHJlY2VudCBkaXNjdXNzaW9ucyBvbiBJRC1FdmVudCB0b2tlbiBk cmFmdDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkg dGhvdWdodCBJIHdvdWxkIHVwZGF0ZSB0aGUgbGlzdCBvbiBzb21lIGRpc2N1c3Npb25zIHRoYXQg aGF2ZSBiZWVuIGhhcHBlbmluZyBvdmVyIGluIHRoZSBPcGVuSUQgQ29ubmVjdCBhbmQgUklTQyB3 b3JraW5nIGdyb3VwcyBjb25mZXJlbmNlIGNhbGxzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlc2UgZGlzY3Vzc2lvbnMgaGF2ZSBiZWVuIGFib3V0 IHRoZSBjb3JlIHNwZWMgYW5kIHRoZSByb2xlIG9mIOKAnHRvcC1sZXZlbOKAnSBhdHRyaWJ1dGVz IHZzLiBldmVudCDigJxleHRlbnNpb27igJ0gYXR0cmlidXRlcy4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlNlZTo8c3BhbiBjbGFzcz0ibS02NTM0NDM1NTczNjM5NjczNzg2YXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWh1bnQtaWRldmVudC10b2tlbi0wMSIgdGFyZ2V0PSJfYmxhbmsiPjxz cGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1odW50LWlkZXZlbnQtdG9rZW4tMDE8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBwYXJ0aWN1bGFyIHNob3VsZCDi gJxzdWLigJ0gYmUgdXNlZCBpbiB0aGUgdG9wIGxldmVsIHRvIOKAnHBvaW504oCdIHRvIHRoZSBz dWJqZWN0IChpbiB0aGUgYnJvYWRlciBlbmdsaXNoIHNlbnNlKSBvZiB0aGUgZXZlbnQsIG9yIHNo b3VsZCBpdCBiZSBjb25zdHJhaW5lZCB0byB0aGUgU0FNTC9JRCBUb2tlbiBkZWZpbml0aW9uIHdo aWNoIGlzIHRoZSBhdXRoZW50aWNhdGVkIHVzZXIuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UYWtlbiBpbiB0aGUgbmFycm93 ZXIgZGVmaW5pdGlvbiwgaXQgaXMgaW1wb3J0YW50IHRvIG9ic2VydmUgdGhhdCBpbiBhbiBJRCBU b2tlbiwg4oCcc3Vi4oCdIGFuZCDigJxpc3PigJ0gZ28gdG9nZXRoZXIuJm5ic3A7IFRoZSBpc3N1 ZXIgcHJvdmlkZXMgdGhlIGNvbnRleHQgZm9yIHRoZSBhdXRoZW50aWNhdGVkIHN1YmplY3QgaWRl bnRpZmllci4gVGhlIHByb2JsZW0gd2l0aCBldmVudHMsIGlzIHRoYXQgaXQgbWlnaHQgbm90IGJl IHRoZQ0KIEFTIChvciBPUCkgd2hpY2ggaXMgaXNzdWluZyB0aGUgZXZlbnQuICZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UbyBz dW1tYXJpemUgYSBmYWlyIGFtb3VudCBvZiBkaXNjdXNzaW9uLCB0aGUgZmVlbGluZyBzZWVtcyB0 byBiZSB0aGUgZm9sbG93aW5nOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4qICZuYnNwO1RoZSBFdmVudCBUb2tlbiB0b3AgbGV2ZWwgYXR0 cmlidXRlcyBzaG91bGQgYmUgZmFpcmx5IGxpbWl0ZWQgYW5kIG5vdCBpbmNsdWRlIHRoZSBzdWIg YXR0cmlidXRlLiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiogJm5ic3A7Rm9yIGV2 ZW50cyB0aGF0IGFyZSBhYm91dCBhIHVzZXIsIHRoZSByZWxldmFudCBldmVudCBzcGVjaWZpY2F0 aW9uIG1heSBpbmNsdWRlIGEg4oCcc3Vi4oCdIGF0dHJpYnV0ZSB3aXRoaW4gdGhlIGV2ZW504oCZ cyBzdWItb2JqZWN0IGFuZCBub3QgaW4gdGhlIHRvcC1sZXZlbC4gRnVydGhlciB0aGF0IHN1Yi1v YmplY3QgY2FuIGFsc28gaW5jbHVkZSB0aGUgaXNzdWVyIG9mIHRoZSB1c2VyLiAmbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiogVGhlIHRvcC1sZXZlbCDigJxpc3PigJ0gc2hhbGwgbWVh biB0aGUgaXNzdWVyIG9mIHRoZSBldmVudCB3aGVyZSB0aGUgc3RhdGUgY2hhbmdlIG9jY3VycmVk LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KiAmbmJzcDvigJxzdWLigJ0gc2hvdWxkIG5vdCBi ZSBwcmVzZW50IGluIHRoZSB0b3AgbGV2ZWwgc3RydWN0dXJlLiZuYnNwOyBBbHNvLCDigJxldmVu dHPigJ0gbXVzdCBhbHNvIGJlIHByZXNlbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhlcmUgd291bGQgYmUgYSBuZXcgZXhhbXBsZSBs b2dvdXQ6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHBy ZT57PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7ICZsdDvigJQgdG9wIGxldmVsIGlzIGFi b3V0IHRoZSBldmVudCBpdHNlbGYgLSZndDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsg PHNwYW4gc3R5bGU9ImNvbG9yOiM1RTMwRUIiPiZxdW90O2lzcyZxdW90OzogJnF1b3Q7PGEgaHJl Zj0iaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5 bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb208L3NwYW4+PC9hPiZx dW90Oyw8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOiM1 RTMwRUIiPiZuYnNwOyAmcXVvdDthdWQmcXVvdDs6ICZxdW90O3M2QmhkUmtxdDMmcXVvdDssPC9z cGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjojNUUzMEVCIj4m bmJzcDsgJnF1b3Q7anRpJnF1b3Q7OiAmcXVvdDszZDBjM2NmNzk3NTg0YmQxOTNiZDBmYjFiZDRl N2QzMCZxdW90Oyw8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNv bG9yOiM1RTMwRUIiPiZuYnNwOyAmcXVvdDtpYXQmcXVvdDs6IDE0NTg2NjgxODAsPC9zcGFuPjxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjojNUUzMEVCIj4mbmJzcDsg JnF1b3Q7ZXhwJnF1b3Q7OiAxNDU4NjY4NTgwLDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT48c3BhbiBzdHlsZT0iY29sb3I6IzVFMzBFQiI+Jm5ic3A7ICZxdW90O2V2ZW50cyZxdW90Ozog Wzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6IzVFMzBF QiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90OzxhIGhyZWY9Imh0dHBzOi8vc3BlY3Mub3Blbmlk Lm5ldC9sb2dvdXQiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5o dHRwczovL3NwZWNzLm9wZW5pZC5uZXQvbG9nb3V0PC9zcGFuPjwvYT4mcXVvdDs8L3NwYW4+PG86 cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOiM1RTMwRUIiPiZuYnNwOyBd LDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gPHNwYW4gc3R5bGU9ImNvbG9yOiNFNjNC N0EiPiZuYnNwOyZxdW90OzxhIGhyZWY9Imh0dHBzOi8vc3BlY3Mub3BlbmlkLm5ldC9sb2dvdXQi IHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3NwZWNz Lm9wZW5pZC5uZXQvbG9nb3V0PC9zcGFuPjwvYT4mcXVvdDs6IHs8L3NwYW4+PG86cD48L286cD48 L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOiNFNjNCN0EiPiZuYnNwOyZuYnNwOyZuYnNw OyAmbHQ7LSBUaGlzIGxldmVsIGlzIGRlZmluZWQgZW50aXJlbHkgYnkgdGhlIGV2ZW50IFVSSS0m Z3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjojRTYz QjdBIj4mbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7aXNzJnF1b3Q7OiAmcXVvdDs8YSBocmVmPSJo dHRwczovL29pZGMuZXhhbXBsZS5jb20vIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNv bG9yOnB1cnBsZSI+aHR0cHM6Ly9vaWRjLmV4YW1wbGUuY29tPC9zcGFuPjwvYT4mcXVvdDssPC9z cGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjojRTYzQjdBIj4m bmJzcDsmbmJzcDsmbmJzcDsg4oCcanRpJnF1b3Q7OiAmcXVvdDswOGE1MDE5Yy0xN2UxLTQ5Nzct OGY0Mi02NWExMjg0M2VhMDLigJ0sPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOiNFNjNCN0EiPiZuYnNwOyZuYnNwOyZuYnNw OyAmcXVvdDtzdWImcXVvdDs6ICZxdW90OzI0ODI4OTc2MTAwMeKAnSw8L3NwYW4+PG86cD48L286 cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6I0U2M0I3 QSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IOKAnGV4cOKAnTogJmx0O0lEIHRva2VuIGV4cGlyeSZndDs8 L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Y29sb3I6I0U2M0I3QSI+Jm5ic3A7IH08L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPn08L3NwYW4+PG86cD48L286cD48L3ByZT4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SW4gdGhlIGFib3ZlIGV4YW1wbGUgbm90ZSB0aGF0IHRoZSDigJxl dmVudOKAnSBvYmplY3QgY2FuIGhhdmUgaXRzIG93biBpc3MgYW5kIHN1YmplY3QgKHN1YiBvciBq dGkpIHRoYXQgaGF2ZSBtZWFuaW5nIHdpdGhpbiB0aGUgY29udGV4dCBvZiBhbiBPcGVuSUQgT1Ag cHJvdmlkZXIuJm5ic3A7IFRoZSBpc3N1ZXIgb2YgdGhlIGV2ZW50IGNhbiBiZSBkaWZmZXJlbnQg KHRoZSB0b3AtbGV2ZWwpIGFuZCByZXByZXNlbnRzIHRoZQ0KIGVudGl0eSB0aGF0IHNpZ25zIHRo ZSBldmVudCAoaWYgaXQgaXMgc2lnbmVkKS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHRvcC1sZXZlbCBhdHRyaWJ1dGVzIGlkZW50 aWZ5IGFuIGluZGl2aWR1YWwgZXZlbnQgYW5kIGFyZSB1c2VkIHRvIHZhbGlkYXRlIHRoZSBldmVu dCAoc2lnbmluZyBldGMpLiZuYnNwOyBXaGVyZSBhcyB0aGUgbmVzdGVkIG9iamVjdCBjb250YWlu cyBhbGwgb2YgdGhlIGRhdGEgYWJvdXQgdGhlIGV2ZW50IGFuZCBpcyBkZWZpbmVkIGJ5IHRoZSBw cm9maWxpbmcgc3BlY2lmaWNhdGlvbiAoZS5nLiBhIHBvc3NpYmxlDQogT3BlbklEIExvZ291dCBF dmVudCBzcGVjKS4mbmJzcDsgSW4gdGhpcyBjYXNlLCBpbiBPcGVuSUQsIGxvZ2dpbmcgb3V0IHVz dWFsbHkgdHJhbnNsYXRlcyBpbnRvIHJldm9raW5nIGFuIElEIFRva2VuLiBUaHVzIHRoZSDigJxq dGnigJ0gZm9yIHRoZSBJRCB0b2tlbiAoMDhhNTAxOWMuLi44NDNlYTAyKSBpcyBpbmNsdWRlZCBp biB0aGUgTG9nb3V0IG9iamVjdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+U2lkZSBub3RlLiZuYnNwOyBSZWdhcmRpbmcg4oCcbG9nb3V0 4oCdLCBpdCBtaWdodCBiZSB1c2VmdWwgdG8gaW5jbHVkZSB0aGUgZXhwaXJ5IG9mIHRoZSBJRCBU b2tlbiBpbiBjYXNlIHRoZSBzdWJzY3JpYmVyIGhhcyBub3QgeWV0IHJlY2VpdmVkIGFuIElEIFRv a2VuLiBUaGlzIHdvdWxkIGxldCB0aGUgc3Vic2NyaWJlciBrbm93IGhvdyBsb25nIGl0IG5lZWRz IHRvIGtlZXAgdGhlIHJldm9jYXRpb24gaW5mb3JtYXRpb24gZm9yLiZuYnNwOw0KIElPV+KApmFm dGVyIHRoZSB0aGUgSUQgVG9rZW4gaXMgZXhwaXJlZCwgdGhlIHN1YnNjcmliZXIgd291bGQgbm8g bG9uZ2VyIG5lZWQgdG8gdHJhY2sgdGhlIHJldm9jYXRpb24gc3RhdGUuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IGlzIGFsc28gZ29v ZCB0byBvYnNlcnZlIHRoYXQgdGhlIOKAnGF1ZOKAnSBhdCB0aGUgdG9wIGxldmVsIGRlc2NyaWJl cyB0aGUgc3Vic2NyaWJlciBvZiB0aGUgZXZlbnQuJm5ic3A7IFRoaXMgbWF5IGFsc28gYmUgZGlm ZmVyZW50IHRoZW4gdGhlIG9yaWdpbmFsIGF1ZGllbmNlIG9mIHRoZSBJRCBUb2tlbi48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U28gdG8g Y29uY2x1ZGUuIEJ5IG1ha2luZyB0b3AtbGV2ZWwgYXR0cmlidXRlcyBzdHJpY3RseSBhYm91dCB0 aGUgZXZlbnRzIG93biB2YWxpZGF0aW9uLCBhbmQgbmVzdGVkIG9iamVjdHMgYWJvdXQgdGhlIGV2 ZW50LCB3ZSBhdm9pZCBjb2xsaXNpb25zIGluIGRlZmluaXRpb25zIHN1Y2ggYXMgdGhlIGlzc3Vl ciBvZiB0aGUgZXZlbnQsIHZzLiB0aGUgb3JpZ2luYWwgaXNzdWVyIG9mIGEgc2VjdXJpdHkgYXNz ZXJ0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JIGhvcGUgSeKAmXZlIGdvdHRlbiBldmVyeW9uZeKAmXMgZmVlZGJhY2sgY29ycmVj dCBoZXJlLiBMZXRzIGNvbnRpbnVlIHRvIGRpc2N1c3MuIEkgd2lsbCByZXZpc2UgdGhlIGRyYWZ0 IHRvIGZvbGxvdyB0aGUgZ3JvdXBzIHRoaW5raW5nIGhlcmUuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QaGlsPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkBpbmRlcGVuZGVudGlkPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tLyIg dGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnd3dy5pbmRlcGVuZGVu dGlkLmNvbTwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9zcGFuPjwv YT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCklkLWV2ZW50IG1haWxpbmcgbGlzdDxicj4NCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86SWQt ZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOnB1 cnBsZSI+SWQtZXZlbnRAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4N Cjwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lk LWV2ZW50IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpwdXJwbGUiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ8L3NwYW4+PC9hPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJZC1ldmVudCBtYWls aW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciPklkLWV2ZW50 QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vaWQtZXZlbnQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCklk LWV2ZW50IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9y ZyI+SWQtZXZlbnRAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9pZC1ldmVudDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCklk LWV2ZW50IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9y ZyI+SWQtZXZlbnRAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9pZC1ldmVudDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_SN1PR0301MB164598544F3C4579D120C4F5F51E0SN1PR0301MB1645_-- From nobody Thu Aug 11 09:00:20 2016 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 8119412D7EB for ; Thu, 11 Aug 2016 09:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.465 X-Spam-Level: X-Spam-Status: No, score=-5.465 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, 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 Ung8vwCFrFvh for ; Thu, 11 Aug 2016 09:00:14 -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 26A5612D7E6 for ; Thu, 11 Aug 2016 09:00:14 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u7BG0B3k003954 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 11 Aug 2016 16:00:12 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u7BG0AtX025626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 11 Aug 2016 16:00:11 GMT Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u7BFxxX3001773; Thu, 11 Aug 2016 16:00:10 GMT Received: from [25.250.67.93] (/24.114.36.85) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 11 Aug 2016 08:59:59 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-859218DB-B0A2-42D0-990F-D63B10236493 Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (13G34) In-Reply-To: Date: Thu, 11 Aug 2016 08:59:55 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <14E2EF51-7123-4E91-87DD-56AEA08202C1@oracle.com> <3F0DD3E6-46CD-4AA5-8F06-F79140F5D4BE@oracle.com> To: Mike Jones X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: "id-event@ietf.org" , Marius Scurtescu Subject: Re: [Id-event] Summarizing recent discussions on ID-Event token draft X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 11 Aug 2016 16:00:18 -0000 --Apple-Mail-859218DB-B0A2-42D0-990F-D63B10236493 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable How do you resolve conflicts on iss then? The top level has to be the issue= r of the event as the issuer signs.=20 If one spec can use it all must be able to. I believe you previously objecte= d to that saying sub must be as how id tokens define them. But that isnt uni= que and requires iss. Now we would have sub at the top with an event issuer a= t the top and a sub issuer in the extension. That seems incredibly complex n= ot to mention awkward.=20 If we make sub a uri for all then it can work ass iss from id token would no= t be needed. But i can see many objecting to the change in format.=20 Why not have a logout be an event with an id token attached for example? Phil > On Aug 11, 2016, at 8:03 AM, Mike Jones wrot= e: >=20 > The simple rule is that if the particular event calls for the =E2=80=9Csub= =E2=80=9D claim to be at the top level, then it is. This is no different fr= om any other claim that an event might place at the top level. > =20 > The complexity arises if =E2=80=9Csub=E2=80=9D is unnecessarily special-ca= sed. We shouldn=E2=80=99t do that, because it limits the applicability of t= he specification. > =20 > -- Mike > =20 > From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com]=20 > Sent: Thursday, August 11, 2016 9:40 AM > To: Mike Jones > Cc: Marius Scurtescu ; id-event@ietf.org > Subject: Re: [Id-event] Summarizing recent discussions on ID-Event token d= raft > =20 > I think using sub at the top level leads to complexity. Eg Can you provide= a rule for when top level is used or not by an individual spec? IMO. Top l= evel should always be used the same way by all implementers.=20 > =20 > Based on the calls at risc/connect, we discussed that it would be best to m= ove all event specifics to the event object area. This way different events c= an have different event addressing (eg sub/iss, uri, jit/iss). When iss is n= eeded to uniquely qualify a sub, it can be provided without conflicting with= the issuer of the event. Similarly jti and iss can be used for a revoked to= ken without conflicting with the event jti.=20 > =20 > I plan to post a new draft shortly that will give some examples based on f= eedback from the openid risc/connect discussions. > =20 > We can always change again.=20 >=20 > Phil >=20 > On Aug 11, 2016, at 4:54 AM, Mike Jones wrot= e: >=20 > No, I=E2=80=99m not saying that =E2=80=9Csub=E2=80=9D cannot appear at the= top level. I=E2=80=99m saying that =E2=80=9Csub=E2=80=9D will only occur a= t the top level if the particular event defines that =E2=80=9Csub=E2=80=9D i= s used in that way for that event. > =20 > There are probably use cases for multiple events per message but I doubt t= here are use cases for multiple *unrelated* events per message. By definiti= on, related events that use top-level claims would need to use them in a com= patible way. I don=E2=80=99t see that as being a problem. > =20 > That being said, the predominant use case is likely to be a single event p= er JWT. > =20 > -- Mi= ke > =20 > From: Marius Scurtescu [mailto:mscurtescu@google.com]=20 > Sent: Tuesday, August 9, 2016 7:15 PM > To: Phil Hunt > Cc: Mike Jones ; id-event@ietf.org > Subject: Re: [Id-event] Summarizing recent discussions on ID-Event token d= raft > =20 > Mike, are you suggesting that a sub claim can only show up at the event le= vel and not at the top level: > =20 > In particular, the only thing that the spec should say about the =E2=80=9C= sub=E2=80=9D claim is that =E2=80=9CLike all other claims other than =E2=80=98= events=E2=80=99 and =E2=80=98iss=E2=80=99, whether the =E2=80=98sub=E2=80=99= claim is to be included with an event is entirely event-specific. > =20 > A top level sub and multiple events are incompatible IMO. > =20 > Do we have a compelling reason to support multiple events per message? > =20 >=20 > Marius > =20 > On Tue, Aug 9, 2016 at 12:39 PM, Phil Hunt wrote: > I was referring to this in your email > "Define that an event name can be used as a top-level claim=E2=80=9D > =20 > =20 > Is this different from the event uri? > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > =20 > =20 >=20 > =20 > On Aug 9, 2016, at 12:12 PM, Mike Jones wrot= e: > =20 > I=E2=80=99m glad to hear that we agree on keeping it as simple and general= -purpose as possible and that you agree with my write-up. I think we then h= ave a good path forward. > =20 > I=E2=80=99m not sure what you mean by =E2=80=9CI=E2=80=99m not sure that w= e need a =E2=80=9Cname=E2=80=9D. What is your intention there.=E2=80=9D Th= e only place I used the word =E2=80=9Cname=E2=80=9D was in my statement =E2=80= =9CDefine that an event name can be used as a top-level claim=E2=80=9D. Wha= t I was trying to get at is was that if =E2=80=9Chttp://specs.openid.net/log= out=E2=80=9D is used as an event name, that it can also be used as a claim n= ame in the JWT containing information about the event. (Maybe I=E2=80=99m n= ot using the correct terminology, hence the unintended confusion J.) > =20 > Thanks again, > -- Mike > =20 > From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 > Sent: Tuesday, August 9, 2016 12:07 PM > To: Mike Jones > Cc: id-event@ietf.org > Subject: Re: [Id-event] Summarizing recent discussions on ID-Event token d= raft > =20 > I didn=E2=80=99t cover this as I didn=E2=80=99t want to confuse people wit= h too many things. > =20 > But I think we agree on all of the below. > =20 > I=E2=80=99m not sure that we need a =E2=80=9Cname=E2=80=9D. What is your i= ntention there. > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > =20 > =20 >=20 > =20 > On Aug 9, 2016, at 11:54 AM, Mike Jones wrot= e: > =20 > Thanks for writing this, Phil. Unfortunately, the summary below does not i= nclude my feedback, which at the essence, is to keep the ID Events data stru= cture as simple and general-purpose as possible. (I strongly believe that J= WT is the success it is because we made JWT as simple and general-purpose as= possible, and we should follow this successful example and do the same here= .) > =20 > I believe that the ID Events spec needs to include these things, and these= things only: > =C2=B7 Define of the =E2=80=9Cevents=E2=80=9D claim > =C2=B7 Define that an event name can be used as a top-level claim > =C2=B7 Require that =E2=80=9Ciss=E2=80=9D be included and that the J= WT be signed by the issuer > =C2=B7 Include a statement along the lines of =E2=80=9CThe claims to= be included with any particular event are to be defined by the event=E2=80=9D= > =20 > And I=E2=80=99d stop there. > =20 > It should be entirely up to applications to say what claims are included w= ith events they define and what their format and meanings are. Then the ID E= vents spec will be as general-purpose as possible, with it being natural for= it to be used in essentially all JSON Event contexts. > =20 > As soon as we start putting restrictions on the use of particular claims b= y events, we=E2=80=99re making the ID Events spec less general-purpose and l= ess natural to use. In particular, the only thing that the spec should say a= bout the =E2=80=9Csub=E2=80=9D claim is that =E2=80=9CLike all other claims o= ther than =E2=80=98events=E2=80=99 and =E2=80=98iss=E2=80=99, whether the =E2= =80=98sub=E2=80=99 claim is to be included with an event is entirely event-s= pecific. The claims to be included with any particular event are explicitly= outside the scope of this specification.=E2=80=9D > =20 > -- Mike > =20 > From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Phil Hunt > Sent: Tuesday, August 9, 2016 10:19 AM > To: id-event@ietf.org > Subject: [Id-event] Summarizing recent discussions on ID-Event token draft= > =20 > I thought I would update the list on some discussions that have been happe= ning over in the OpenID Connect and RISC working groups conference calls. > =20 > These discussions have been about the core spec and the role of =E2=80=9Ct= op-level=E2=80=9D attributes vs. event =E2=80=9Cextension=E2=80=9D attribute= s.=20 > See: https://tools.ietf.org/html/draft-hunt-idevent-token-01 > =20 > In particular should =E2=80=9Csub=E2=80=9D be used in the top level to =E2= =80=9Cpoint=E2=80=9D to the subject (in the broader english sense) of the ev= ent, or should it be constrained to the SAML/ID Token definition which is th= e authenticated user. =20 > =20 > Taken in the narrower definition, it is important to observe that in an ID= Token, =E2=80=9Csub=E2=80=9D and =E2=80=9Ciss=E2=80=9D go together. The is= suer provides the context for the authenticated subject identifier. The prob= lem with events, is that it might not be the AS (or OP) which is issuing the= event. =20 > =20 > To summarize a fair amount of discussion, the feeling seems to be the foll= owing: > =20 > * The Event Token top level attributes should be fairly limited and not i= nclude the sub attribute. =20 > * For events that are about a user, the relevant event specification may i= nclude a =E2=80=9Csub=E2=80=9D attribute within the event=E2=80=99s sub-obje= ct and not in the top-level. Further that sub-object can also include the is= suer of the user. =20 > * The top-level =E2=80=9Ciss=E2=80=9D shall mean the issuer of the event w= here the state change occurred. > * =E2=80=9Csub=E2=80=9D should not be present in the top level structure.= Also, =E2=80=9Cevents=E2=80=9D must also be present. > =20 > Here would be a new example logout: > { > <=E2=80=94 top level is about the event itself -> > "iss": "https://server.example.com", > "aud": "s6BhdRkqt3", > "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", > "iat": 1458668180, > "exp": 1458668580, > "events": [ > "https://specs.openid.net/logout" > ], > "https://specs.openid.net/logout": { > <- This level is defined entirely by the event URI-> > "iss": "https://oidc.example.com", > =E2=80=9Cjti": "08a5019c-17e1-4977-8f42-65a12843ea02=E2=80=9D, > "sub": "248289761001=E2=80=9D, > =E2=80=9Cexp=E2=80=9D: > } > } > =20 > In the above example note that the =E2=80=9Cevent=E2=80=9D object can have= its own iss and subject (sub or jti) that have meaning within the context o= f an OpenID OP provider. The issuer of the event can be different (the top-= level) and represents the entity that signs the event (if it is signed). > =20 > The top-level attributes identify an individual event and are used to vali= date the event (signing etc). Where as the nested object contains all of th= e data about the event and is defined by the profiling specification (e.g. a= possible OpenID Logout Event spec). In this case, in OpenID, logging out u= sually translates into revoking an ID Token. Thus the =E2=80=9Cjti=E2=80=9D f= or the ID token (08a5019c...843ea02) is included in the Logout object. > =20 > Side note. Regarding =E2=80=9Clogout=E2=80=9D, it might be useful to incl= ude the expiry of the ID Token in case the subscriber has not yet received a= n ID Token. This would let the subscriber know how long it needs to keep the= revocation information for. IOW=E2=80=A6after the the ID Token is expired,= the subscriber would no longer need to track the revocation state. > =20 > It is also good to observe that the =E2=80=9Caud=E2=80=9D at the top level= describes the subscriber of the event. This may also be different then the= original audience of the ID Token. > =20 > So to conclude. By making top-level attributes strictly about the events o= wn validation, and nested objects about the event, we avoid collisions in de= finitions such as the issuer of the event, vs. the original issuer of a secu= rity assertion. > =20 > I hope I=E2=80=99ve gotten everyone=E2=80=99s feedback correct here. Lets c= ontinue to discuss. I will revise the draft to follow the groups thinking he= re. > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =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://www.ietf.org/mailman/listinfo/id-event --Apple-Mail-859218DB-B0A2-42D0-990F-D63B10236493 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
How do you resolve conflicts on iss th= en?  The top level has to be the issuer of the event as the issuer sign= s. 

If one spec can use it all must be able to. I believe you previous= ly objected to that saying sub must be as how id tokens define them. But tha= t isnt unique and requires iss. Now we would have sub at the top with an eve= nt issuer at the top and a sub issuer in the extension. That seems incredibl= y complex not to mention awkward. 
=
If we make sub a uri for all then i= t can work ass iss from id token would not be needed. But i can see many obj= ecting to the change in format. 
Why not have a logout be an event wit= h an id token attached for example?

= Phil

On Aug 11, 2016, at 8:03 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:=

The simple rule is that if the particul= ar event calls for the =E2=80=9Csub=E2=80=9D claim to be at the top level, t= hen it is.  This is no different from any other claim that an event might place at the top level.

 

The complexity arises if =E2=80=9Csub=E2= =80=9D is unnecessarily special-cased.  We shouldn=E2=80=99t do that, b= ecause it limits the applicability of the specification.

 

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

 =

From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com]
Sent: Thursday, August 11, 2016 9:40 AM
To: Mike Jones <Mic= hael.Jones@microsoft.com>
Cc: Marius Scurtescu <msc= urtescu@google.com>; id-event@ie= tf.org
Subject: Re: [Id-event] Summarizing recent discussions on ID-Event to= ken draft

 

I think using sub at the top level leads to complexit= y. Eg Can you provide a rule for when top level is used or not by an individ= ual spec?  IMO. Top level should always be used the same way by all imp= lementers. 

 

Based on the calls at risc/connect, we discussed that= it would be best to move all event specifics to the event object area. This= way different events can have different event addressing (eg sub/iss, uri, j= it/iss). When iss is needed to uniquely qualify a sub, it can be provided without conflicting with the iss= uer of the event. Similarly jti and iss can be used for a revoked token with= out conflicting with the event jti. 

 

I plan to post a new draft shortly that will give som= e examples based on feedback from the openid risc/connect discussions.<= /o:p>

 

We can always change again. 


Phil


On Aug 11, 2016, at 4:54 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

No, I=E2=80=99m not saying that =E2=80=9C= sub=E2=80=9D cannot appear at the top level.  I=E2=80=99m saying that =E2= =80=9Csub=E2=80=9D will only occur at the top level if the particular event d= efines that =E2=80=9Csub=E2=80=9D is used in that way for that event.

 

There are probably use cases for multip= le events per message but I doubt there are use cases for multiple *unrel= ated* events per message.  By definition, related events that use top-level claims would need to use them in a compat= ible way.  I don=E2=80=99t see that as being a problem.

 

That being said, the predominant use ca= se is likely to be a single event per JWT.

 

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

 

From: Marius Scurtescu [mailto:mscurtescu@google.com]
Sent: Tuesday, August 9, 2016 7:15 PM
To: Phil Hunt <phil.hunt@o= racle.com>
Cc: Mike Jones <Mic= hael.Jones@microsoft.com>; id-event@ietf.org
Subject: Re: [Id-event] Summarizing recent discussions on ID-Event to= ken draft

 

Mike, are you suggesting that a sub claim can only sh= ow up at the event level and not at the top level:

 

In particular, the only thing that the spec should sa= y about the =E2=80=9Csub=E2=80=9D claim is that =E2=80=9CLike all other clai= ms other than =E2=80=98events=E2=80=99 and =E2=80=98iss=E2=80=99, whether th= e =E2=80=98sub=E2=80=99 claim is to be included with an event is entirely ev= ent-specific.

 

A top level sub and multiple events are incompatible I= MO.

 

Do we have a compelling reason to support multiple ev= ents per message?

 


Marius

 

On Tue, Aug 9, 2016 at 12:39 PM, Phil Hunt <phil.hunt@oracle.com= > wrote:

I was referring to this in your email

"Define that an event name can be used a= s a top-level claim=E2=80=9D

 

 

Is this different from the event uri?

 

Phil

 <= /p>

@independentid

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

 <= /p>

 <= /p>

 

 

On Aug 9, 2016, at 12:12 PM, Mike Jones <Michael.Jones@microso= ft.com> wrote:

 

I=E2=80=99m glad to hear that we agree o= n keeping it as simple and general-purpose as possible and that you agree wi= th my write-up.  I think we then have a good path forward.

 

I=E2=80=99m not sure what you mean by =E2= =80=9CI=E2=80=99m not sure that we need a =E2=80=9Cname=E2=80=9D. Wha= t is your intention there.=E2=80=9D  The only place I used the word =E2=80=9Cname=E2=80=9D was in my statement =E2= =80=9CDefine that an event name can be used as a top-level claim=E2=80=9D.&n= bsp; What I was trying to get at is was that if =E2=80=9Chttp:= //specs.openid.net/logout=E2=80=9D is used as an event name, that it can also be used as a claim name in the J= WT containing information about the event.  (Maybe I=E2=80=99m not usin= g the correct terminology, hence the unintended confusion J.= )

 

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

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

 

From: Phil Hunt [mailto:phil= .hunt@oracle.com] 
Sent: = ;Tuesday, August 9, 2016 12:07 PM
To: <= /span>Mike Jones <Michael.Jones@microsoft.com>
Cc: <= /span>id-event@ietf.o= rg
Subject:&n= bsp;Re: [Id-event] Summarizing recent discussions on ID-Event token d= raft

 

I didn=E2=80=99t cover this as I didn=E2=80=99t want t= o confuse people with too many things.

 

But I think we agree on all of the below.<= /p>

 

I=E2=80=99m not sure that we need a =E2=80=9Cname=E2=80= =9D. What is your intention there.

 

 

 

 

 

On Aug 9, 2016, at 11:54 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

 

Thanks for writing this, Phil.  Un= fortunately, the summary below does not include my feedback, which at the es= sence, is to keep the ID Events data structure as simple and general-purpose as possible.  (I strongly believe that JWT i= s the success it is because we made JWT as simple and general-purpose as pos= sible, and we should follow this successful example and do the same here.)

 

I believe that the ID Events spec needs= to include these things, and these things only:

=C2=B7&nbs= p;      Define of the =E2=80=9Cevents=E2=80=9D claim

=C2=B7&nbs= p;      Define that an event name can be used as a top-level claim

=C2=B7&nbs= p;      Require that =E2=80=9Ciss=E2=80=9D be included and that the JWT be signed by the is= suer

=C2=B7&nbs= p;      Include a statement along the lines of =E2=80=9CThe claims to be included with any p= articular event are to be defined by the event=E2=80=9D

 

And I=E2=80=99d stop there.=

 

It should be entirely up to application= s to say what claims are included with events they define and what their for= mat and meanings are.  Then the ID Events spec will be as general-purpose as possible, with it being natural for it to be u= sed in essentially all JSON Event contexts.

 

As soon as we start putting restriction= s on the use of particular claims by events, we=E2=80=99re making the ID Eve= nts spec less general-purpose and less natural to use.  In particular, the only thing that the spec should say about the =E2=80=9Cs= ub=E2=80=9D claim is that =E2=80=9CLike all other claims other than =E2=80=98= events=E2=80=99 and =E2=80=98iss=E2=80=99, whether the =E2=80=98sub=E2=80=99= claim is to be included with an event is entirely event-specific.  The= claims to be included with any particular event are explicitly outside the scope of this specification.=E2= =80=9D

 

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

 

From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Phi= l Hunt
Sent: = ;Tuesday, August 9, 2016 10:19 AM
To: <= /span>id-event@ietf.org
Subject:&n= bsp;[Id-event] Summarizing recent discussions on ID-Event token draft=

 

I thought I would update the list on some discussions= that have been happening over in the OpenID Connect and RISC working groups= conference calls.

 

These discussions have been about the core spec and t= he role of =E2=80=9Ctop-level=E2=80=9D attributes vs. event =E2=80=9Cextensi= on=E2=80=9D attributes. 

 

In particular should =E2=80=9Csub=E2=80=9D be used in= the top level to =E2=80=9Cpoint=E2=80=9D to the subject (in the broader eng= lish sense) of the event, or should it be constrained to the SAML/ID Token d= efinition which is the authenticated user.  

 

Taken in the narrower definition, it is important to o= bserve that in an ID Token, =E2=80=9Csub=E2=80=9D and =E2=80=9Ciss=E2=80=9D g= o together.  The issuer provides the context for the authenticated subj= ect identifier. The problem with events, is that it might not be the AS (or OP) which is issuing the event.  

 

To summarize a fair amount of discussion, the feeling= seems to be the following:

 

*  The Event Token top level attributes should b= e fairly limited and not include the sub attribute.  

*  For events that are about a user, the relevan= t event specification may include a =E2=80=9Csub=E2=80=9D attribute within t= he event=E2=80=99s sub-object and not in the top-level. Further that sub-obj= ect can also include the issuer of the user.  

* The top-level =E2=80=9Ciss=E2=80=9D shall mean the i= ssuer of the event where the state change occurred.

*  =E2=80=9Csub=E2=80=9D should not be present i= n the top level structure.  Also, =E2=80=9Cevents=E2=80=9D must also be= present.

 

Here would be a new example logout:

{
  <=E2=80=94 top level is about the event itself ->
  "iss": "https://server.=
example.com",
  "aud": "s6BhdRkqt3",
  "jti": "3d0c3cf797584bd193bd0fb1bd=
4e7d30",
  "iat": 1458668180,
  "exp": 1458668580,
  "events": [

    "https:=
//specs.openid.net/logout"


  ],


  "https://specs.open=
id.net/logout": {


    <- This level is de=
fined entirely by the event URI->


    "iss": "https=
://oidc.example.com",


    =E2=80=9Cjti": "08a501=
9c-17e1-4977-8f42-65a12843ea02=E2=80=9D,


    "sub"=
: "248289761001=E2=80=9D,


    =E2=80=
=9Cexp=E2=80=9D: <ID token expiry>


  }


}








 














In the above example note that the =E2=80=9Cevent=E2=80=
=9D object can have its own iss and subject (sub or jti) that have meaning w=
ithin the context of an OpenID OP provider.  The issuer of the event ca=
n be different (the top-level) and represents the
 entity that signs the event (if it is signed).














 














The top-level attributes identify an individual event=
 and are used to validate the event (signing etc).  Where as the nested=
 object contains all of the data about the event and is defined by the profi=
ling specification (e.g. a possible
 OpenID Logout Event spec).  In this case, in OpenID, logging out usual=
ly translates into revoking an ID Token. Thus the =E2=80=9Cjti=E2=80=9D for t=
he ID token (08a5019c...843ea02) is included in the Logout object.














 














Side note.  Regarding =E2=80=9Clogout=E2=80=9D, i=
t might be useful to include the expiry of the ID Token in case the subscrib=
er has not yet received an ID Token. This would let the subscriber know how l=
ong it needs to keep the revocation information for. 
 IOW=E2=80=A6after the the ID Token is expired, the subscriber would no long=
er need to track the revocation state.














 














It is also good to observe that the =E2=80=9Caud=E2=80=
=9D at the top level describes the subscriber of the event.  This may a=
lso be different then the original audience of the ID Token.














 














So to conclude. By making top-level attributes strict=
ly about the events own validation, and nested objects about the event, we a=
void collisions in definitions such as the issuer of the event, vs. the orig=
inal issuer of a security assertion.














 














I hope I=E2=80=99ve gotten everyone=E2=80=99s feedbac=
k correct here. Lets continue to discuss. I will revise the draft to follow t=
he groups thinking here.














 

 

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

 


_______________________________________________
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-859218DB-B0A2-42D0-990F-D63B10236493-- From nobody Thu Aug 11 09:10:03 2016 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 3FAEE12D126 for ; Thu, 11 Aug 2016 09:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.447 X-Spam-Level: X-Spam-Status: No, score=-5.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247, 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 5EJ6-UXEHUPs for ; Thu, 11 Aug 2016 09:09:57 -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 0F3CA126D74 for ; Thu, 11 Aug 2016 09:09:56 -0700 (PDT) X-AuditID: 12074424-06bff700000036ad-8c-57aca352c017 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 (Symantec Messaging Gateway) with SMTP id 38.50.13997.253ACA75; Thu, 11 Aug 2016 12:09:55 -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 u7BG9sxM000844; Thu, 11 Aug 2016 12:09:54 -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 u7BG9mWV005395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 11 Aug 2016 12:09:50 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_F92E3305-617B-41A6-8048-B77B4A2FA35D" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Justin Richer In-Reply-To: Date: Thu, 11 Aug 2016 12:09:48 -0400 Message-Id: References: <14E2EF51-7123-4E91-87DD-56AEA08202C1@oracle.com> <3F0DD3E6-46CD-4AA5-8F06-F79140F5D4BE@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.3124) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDKsWRmVeSWpSXmKPExsUixG6nohu8eE24wYqPEhYdC7qZLPZO+8Ri cevsGiaLBfMb2R1YPBZsKvVYsuQnk0frjr/sHh+f3mIJYInisklJzcksSy3St0vgyjh46ihL waTprBWbXrUzNjAePMjSxcjJISFgIrFsz2umLkYuDiGBNiaJC/sWsUE4GxklGg8cgso8ZJK4 O+cyE0gLs0CCxJvZzWwgNq+AnsSm9W/B4sICfhKzz5xnBbHZBFQlpq9pAYtzCthJLDu4hxHE ZgGKd97vYAcZyiwwkVGi9dUtdohBVhIHV/RCbZvHKnH4/RKwDhEBFYlvV68zQhwrK/Hk5CKW CYz8s5AcMgvJIRBxbYllC18zQ9iaEvu7l7NgimtIdH6byLqAkW0Vo2xKbpVubmJmTnFqsm5x cmJeXmqRrrlebmaJXmpK6SZGcCS4qOxg7O7xPsQowMGoxMPrkbk6XIg1say4MvcQoyQHk5Io r3AMUIgvKT+lMiOxOCO+qDQntfgQowQHs5II75aFa8KFeFMSK6tSi/JhUtIcLErivNu/tYcL CaQnlqRmp6YWpBbBZGU4OJQkeP+ANAoWpaanVqRl5pQgpJk4OEGG8wAN/ww2vLggMbc4Mx0i f4pRUUqcV24RUEIAJJFRmgfXC0pUCW8Pm75iFAd6RZh3MkgVDzDJwXW/AhrMBDT4hBnY4JJE hJRUA+P6LaWmJlnPfGRn8AZ6zn4/JyjZLyt1Tt/XZCbz/wrnOC0uBVt/DXsncV2zvNNt68/n baGR5pa3Dy0oNfolXbB7i++GLSLVh31qP85w/L7RT6psVUukxzdn6//P718SNmrJf2zS4ZTJ 9YC/0O+WZJfyipra7ZPC1Hkyt2mGWd1Yssv7YnlvgRJLcUaioRZzUXEiAM6Gqy8vAwAA Archived-At: Cc: Mike Jones , "id-event@ietf.org" , Marius Scurtescu Subject: Re: [Id-event] Summarizing recent discussions on ID-Event token draft X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 11 Aug 2016 16:10:01 -0000 --Apple-Mail=_F92E3305-617B-41A6-8048-B77B4A2FA35D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I disagree with special-casing logout like this. The =E2=80=9Ciss=E2=80=9D= at the root of the event should be the issuer of the event itself, = always. The event sub-construct might also have that field, or it might = inherit the global field if another value doesn=E2=80=99t exist for the = sub-object if you want to get fancy. But in neither case is it putting a = value into the root of the object. If you want to attach a full ID token, you should do that as a data = member, in my opinion. You can do that either by using the JSON object = payload as a sub-object or by doing it as the serialized compact form as = a string (if for some reason you need to keep that signature as well). = I=E2=80=99d prefer the former case in most instances since the issuer of = the event should be authoritative for the event it=E2=80=99s describing. =E2=80=94 Justin > On Aug 11, 2016, at 11:59 AM, Phil Hunt (IDM) = wrote: >=20 > How do you resolve conflicts on iss then? The top level has to be the = issuer of the event as the issuer signs.=20 >=20 > If one spec can use it all must be able to. I believe you previously = objected to that saying sub must be as how id tokens define them. But = that isnt unique and requires iss. Now we would have sub at the top with = an event issuer at the top and a sub issuer in the extension. That seems = incredibly complex not to mention awkward.=20 >=20 > If we make sub a uri for all then it can work ass iss from id token = would not be needed. But i can see many objecting to the change in = format.=20 >=20 > Why not have a logout be an event with an id token attached for = example? >=20 > Phil >=20 > On Aug 11, 2016, at 8:03 AM, Mike Jones > wrote: >=20 >> The simple rule is that if the particular event calls for the = =E2=80=9Csub=E2=80=9D claim to be at the top level, then it is. This is = no different from any other claim that an event might place at the top = level. >> =20 >> The complexity arises if =E2=80=9Csub=E2=80=9D is unnecessarily = special-cased. We shouldn=E2=80=99t do that, because it limits the = applicability of the specification. >> =20 >> -- Mike >> =C2=A0 <> >> From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com = ]=20 >> Sent: Thursday, August 11, 2016 9:40 AM >> To: Mike Jones > >> Cc: Marius Scurtescu >; id-event@ietf.org = >> Subject: Re: [Id-event] Summarizing recent discussions on ID-Event = token draft >> =20 >> I think using sub at the top level leads to complexity. Eg Can you = provide a rule for when top level is used or not by an individual spec? = IMO. Top level should always be used the same way by all implementers.=20= >> =20 >> Based on the calls at risc/connect, we discussed that it would be = best to move all event specifics to the event object area. This way = different events can have different event addressing (eg sub/iss, uri, = jit/iss). When iss is needed to uniquely qualify a sub, it can be = provided without conflicting with the issuer of the event. Similarly jti = and iss can be used for a revoked token without conflicting with the = event jti.=20 >> =20 >> I plan to post a new draft shortly that will give some examples based = on feedback from the openid risc/connect discussions. >> =20 >> We can always change again.=20 >>=20 >> Phil >>=20 >> On Aug 11, 2016, at 4:54 AM, Mike Jones > wrote: >>=20 >> No, I=E2=80=99m not saying that =E2=80=9Csub=E2=80=9D cannot appear = at the top level. I=E2=80=99m saying that =E2=80=9Csub=E2=80=9D will = only occur at the top level if the particular event defines that = =E2=80=9Csub=E2=80=9D is used in that way for that event. >> =20 >> There are probably use cases for multiple events per message but I = doubt there are use cases for multiple *unrelated* events per message. = By definition, related events that use top-level claims would need to = use them in a compatible way. I don=E2=80=99t see that as being a = problem. >> =20 >> That being said, the predominant use case is likely to be a single = event per JWT. >> =20 >> = -- Mike >> =20 >> From: Marius Scurtescu [mailto:mscurtescu@google.com = ]=20 >> Sent: Tuesday, August 9, 2016 7:15 PM >> To: Phil Hunt > >> Cc: Mike Jones >; id-event@ietf.org = >> Subject: Re: [Id-event] Summarizing recent discussions on ID-Event = token draft >> =20 >> Mike, are you suggesting that a sub claim can only show up at the = event level and not at the top level: >> =20 >> In particular, the only thing that the spec should say about the = =E2=80=9Csub=E2=80=9D claim is that =E2=80=9CLike all other claims other = than =E2=80=98events=E2=80=99 and =E2=80=98iss=E2=80=99, whether the = =E2=80=98sub=E2=80=99 claim is to be included with an event is entirely = event-specific. >> =20 >> A top level sub and multiple events are incompatible IMO. >> =20 >> Do we have a compelling reason to support multiple events per = message? >> =20 >>=20 >> Marius >> =20 >> On Tue, Aug 9, 2016 at 12:39 PM, Phil Hunt > wrote: >> I was referring to this in your email >> "Define that an event name can be used as a top-level claim=E2=80=9D >> =20 >> =20 >> Is this different from the event uri? >> =20 >> Phil >> =20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> =20 >> =20 >> =20 >>=20 >> =20 >> On Aug 9, 2016, at 12:12 PM, Mike Jones > wrote: >> =20 >> I=E2=80=99m glad to hear that we agree on keeping it as simple and = general-purpose as possible and that you agree with my write-up. I = think we then have a good path forward. >> =20 >> I=E2=80=99m not sure what you mean by =E2=80=9CI=E2=80=99m not sure = that we need a =E2=80=9Cname=E2=80=9D. What is your intention there.=E2=80= =9D The only place I used the word =E2=80=9Cname=E2=80=9D was in my = statement =E2=80=9CDefine that an event name can be used as a top-level = claim=E2=80=9D. What I was trying to get at is was that if = =E2=80=9Chttp://specs.openid.net/logout = =E2=80=9D is used as an event name, that = it can also be used as a claim name in the JWT containing information = about the event. (Maybe I=E2=80=99m not using the correct terminology, = hence the unintended confusion J.) >> =20 >> Thanks again, >> -- Mike >> =C2=A0 <> >> From: Phil Hunt [mailto:phil.hunt@oracle.com = ]=20 >> Sent: Tuesday, August 9, 2016 12:07 PM >> To: Mike Jones > >> Cc: id-event@ietf.org >> Subject: Re: [Id-event] Summarizing recent discussions on ID-Event = token draft >> =20 >> I didn=E2=80=99t cover this as I didn=E2=80=99t want to confuse = people with too many things. >> =20 >> But I think we agree on all of the below. >> =20 >> I=E2=80=99m not sure that we need a =E2=80=9Cname=E2=80=9D. What is = your intention there. >> =20 >> Phil >> =20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> =20 >> =20 >> =20 >>=20 >> =20 >> On Aug 9, 2016, at 11:54 AM, Mike Jones > wrote: >> =20 >> Thanks for writing this, Phil. Unfortunately, the summary below does = not include my feedback, which at the essence, is to keep the ID Events = data structure as simple and general-purpose as possible. (I strongly = believe that JWT is the success it is because we made JWT as simple and = general-purpose as possible, and we should follow this successful = example and do the same here.) >> =20 >> I believe that the ID Events spec needs to include these things, and = these things only: >> =C2=B7 Define of the =E2=80=9Cevents=E2=80=9D claim >> =C2=B7 Define that an event name can be used as a top-level = claim >> =C2=B7 Require that =E2=80=9Ciss=E2=80=9D be included and that = the JWT be signed by the issuer >> =C2=B7 Include a statement along the lines of =E2=80=9CThe = claims to be included with any particular event are to be defined by the = event=E2=80=9D >> =20 >> And I=E2=80=99d stop there. >> =20 >> It should be entirely up to applications to say what claims are = included with events they define and what their format and meanings are. = Then the ID Events spec will be as general-purpose as possible, with it = being natural for it to be used in essentially all JSON Event contexts. >> =20 >> As soon as we start putting restrictions on the use of particular = claims by events, we=E2=80=99re making the ID Events spec less = general-purpose and less natural to use. In particular, the only thing = that the spec should say about the =E2=80=9Csub=E2=80=9D claim is that = =E2=80=9CLike all other claims other than =E2=80=98events=E2=80=99 and = =E2=80=98iss=E2=80=99, whether the =E2=80=98sub=E2=80=99 claim is to be = included with an event is entirely event-specific. The claims to be = included with any particular event are explicitly outside the scope of = this specification.=E2=80=9D >> =20 >> -- Mike >> =20 >> From: Id-event [mailto:id-event-bounces@ietf.org = ] On Behalf Of Phil Hunt >> Sent: Tuesday, August 9, 2016 10:19 AM >> To: id-event@ietf.org >> Subject: [Id-event] Summarizing recent discussions on ID-Event token = draft >> =20 >> I thought I would update the list on some discussions that have been = happening over in the OpenID Connect and RISC working groups conference = calls. >> =20 >> These discussions have been about the core spec and the role of = =E2=80=9Ctop-level=E2=80=9D attributes vs. event =E2=80=9Cextension=E2=80=9D= attributes.=20 >> See: https://tools.ietf.org/html/draft-hunt-idevent-token-01 = >> =20 >> In particular should =E2=80=9Csub=E2=80=9D be used in the top level = to =E2=80=9Cpoint=E2=80=9D to the subject (in the broader english sense) = of the event, or should it be constrained to the SAML/ID Token = definition which is the authenticated user. =20 >> =20 >> Taken in the narrower definition, it is important to observe that in = an ID Token, =E2=80=9Csub=E2=80=9D and =E2=80=9Ciss=E2=80=9D go = together. The issuer provides the context for the authenticated subject = identifier. The problem with events, is that it might not be the AS (or = OP) which is issuing the event. =20 >> =20 >> To summarize a fair amount of discussion, the feeling seems to be the = following: >> =20 >> * The Event Token top level attributes should be fairly limited and = not include the sub attribute. =20 >> * For events that are about a user, the relevant event specification = may include a =E2=80=9Csub=E2=80=9D attribute within the event=E2=80=99s = sub-object and not in the top-level. Further that sub-object can also = include the issuer of the user.=20 >> * The top-level =E2=80=9Ciss=E2=80=9D shall mean the issuer of the = event where the state change occurred. >> * =E2=80=9Csub=E2=80=9D should not be present in the top level = structure. Also, =E2=80=9Cevents=E2=80=9D must also be present. >> =20 >> Here would be a new example logout: >> { >> <=E2=80=94 top level is about the event itself -> >> "iss": "https://server.example.com ", >> "aud": "s6BhdRkqt3", >> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >> "iat": 1458668180, >> "exp": 1458668580, >> "events": [ >> "https://specs.openid.net/logout = " >> ], >> "https://specs.openid.net/logout = ": { >> <- This level is defined entirely by the event URI-> >> "iss": "https://oidc.example.com ", >> =E2=80=9Cjti": "08a5019c-17e1-4977-8f42-65a12843ea02=E2=80=9D, >> "sub": "248289761001=E2=80=9D, >> =E2=80=9Cexp=E2=80=9D: >> } >> } >> =20 >> In the above example note that the =E2=80=9Cevent=E2=80=9D object can = have its own iss and subject (sub or jti) that have meaning within the = context of an OpenID OP provider. The issuer of the event can be = different (the top-level) and represents the entity that signs the event = (if it is signed). >> =20 >> The top-level attributes identify an individual event and are used to = validate the event (signing etc). Where as the nested object contains = all of the data about the event and is defined by the profiling = specification (e.g. a possible OpenID Logout Event spec). In this case, = in OpenID, logging out usually translates into revoking an ID Token. = Thus the =E2=80=9Cjti=E2=80=9D for the ID token (08a5019c...843ea02) is = included in the Logout object. >> =20 >> Side note. Regarding =E2=80=9Clogout=E2=80=9D, it might be useful to = include the expiry of the ID Token in case the subscriber has not yet = received an ID Token. This would let the subscriber know how long it = needs to keep the revocation information for. IOW=E2=80=A6after the the = ID Token is expired, the subscriber would no longer need to track the = revocation state. >> =20 >> It is also good to observe that the =E2=80=9Caud=E2=80=9D at the top = level describes the subscriber of the event. This may also be different = then the original audience of the ID Token. >> =20 >> So to conclude. By making top-level attributes strictly about the = events own validation, and nested objects about the event, we avoid = collisions in definitions such as the issuer of the event, vs. the = original issuer of a security assertion. >> =20 >> I hope I=E2=80=99ve gotten everyone=E2=80=99s feedback correct here. = Lets continue to discuss. I will revise the draft to follow the groups = thinking here. >> =20 >> Phil >> =20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> =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://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=_F92E3305-617B-41A6-8048-B77B4A2FA35D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I disagree with special-casing logout like this. The = =E2=80=9Ciss=E2=80=9D at the root of the event should be the issuer of = the event itself, always. The event sub-construct might also have that = field, or it might inherit the global field if another value doesn=E2=80=99= t exist for the sub-object if you want to get fancy. But in neither case = is it putting a value into the root of the object.

If you want to attach a full ID token, = you should do that as a data member, in my opinion. You can do that = either by using the JSON object payload as a sub-object or by doing it = as the serialized compact form as a string (if for some reason you need = to keep that signature as well). I=E2=80=99d prefer the former case in = most instances since the issuer of the event should be authoritative for = the event it=E2=80=99s describing.

 =E2=80=94 Justin

On Aug 11, 2016, at 11:59 AM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:

How do you resolve conflicts = on iss then?  The top level has to be the issuer of the event as = the issuer signs. 

If one spec can use it all must be able to. I believe you = previously objected to that saying sub must be as how id tokens define = them. But that isnt unique and requires iss. Now we would have sub at = the top with an event issuer at the top and a sub issuer in the = extension. That seems incredibly complex not to mention = awkward. 

If we = make sub a uri for all then it can work ass iss from id token would not = be needed. But i can see many objecting to the change in = format. 

Why not = have a logout be an event with an id token attached for = example?

Phil

On Aug 11, 2016, at 8:03 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

The simple rule is that if the particular = event calls for the =E2=80=9Csub=E2=80=9D claim to be at the top level, = then it is.  This is no different from any other claim that an = event might place at the top level.
 
The complexity arises if = =E2=80=9Csub=E2=80=9D is unnecessarily special-cased.  We = shouldn=E2=80=99t do that, because it limits the applicability of the = specification.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;       -- Mike
 
From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com] 
Sent: Thursday, August 11, 2016 = 9:40 AM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: Marius Scurtescu <mscurtescu@google.com>; id-event@ietf.org
Subject: Re: [Id-event] Summarizing = recent discussions on ID-Event token draft
 
I think using sub at the top level leads = to complexity. Eg Can you provide a rule for when top level is used or = not by an individual spec?  IMO. Top level should always be used = the same way by all implementers. 
 
Based on the calls at risc/connect, we = discussed that it would be best to move all event specifics to the event = object area. This way different events can have different event = addressing (eg sub/iss, uri, jit/iss). When iss is needed to uniquely = qualify a sub, it can be provided without conflicting with the issuer of = the event. Similarly jti and iss can be used for a revoked token without = conflicting with the event jti. 
 
I plan to post a new draft shortly that = will give some examples based on feedback from the openid risc/connect = discussions.
 
We can always change again. 

Phil


On= Aug 11, 2016, at 4:54 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

No, I=E2=80=99m not = saying that =E2=80=9Csub=E2=80=9D cannot appear at the top level.  = I=E2=80=99m saying that =E2=80=9Csub=E2=80=9D will only occur at the top = level if the particular event defines that =E2=80=9Csub=E2=80=9D is used = in that way for that event.
 
There are probably use = cases for multiple events per message but I doubt there are use cases = for multiple *unrelated* events per message.  By = definition, related events that use top-level claims would need to use = them in a compatible way.  I don=E2=80=99t see that as being a = problem.
 
That being said, the predominant use case is = likely to be a single event per JWT.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;         -- Mike
 
From: Marius = Scurtescu [mailto:mscurtescu@google.com] 
Sent: Tuesday, August 9, 2016 = 7:15 PM
To: Phil Hunt <phil.hunt@oracle.com>
Cc: Mike Jones <Michael.Jones@microsoft.com>; id-event@ietf.org
Subject: Re: [Id-event] Summarizing = recent discussions on ID-Event token draft
 
Mike, are you suggesting that a sub claim = can only show up at the event level and not at the top level:
 
In = particular, the only thing that the spec should say about the =E2=80=9Csub= =E2=80=9D claim is that =E2=80=9CLike all other claims other than = =E2=80=98events=E2=80=99 and =E2=80=98iss=E2=80=99, whether the = =E2=80=98sub=E2=80=99 claim is to be included with an event is entirely = event-specific.
 
A top level sub and multiple events are incompatible IMO.
 
Do we have a compelling reason to support = multiple events per message?
 

Marius
 
On Tue, Aug 9, 2016 at 12:39 PM, Phil = Hunt <phil.hunt@oracle.com> wrote:
I was referring to = this in your email
"Define that an event name can be used as a top-level = claim=E2=80=9D
 
 
Is this different from the event uri?
 
Phil
 
@independentid
 
 

 

 
On Aug 9, 2016, at = 12:12 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
 
I=E2=80=99m glad to hear that we agree on = keeping it as simple and general-purpose as possible and that you agree = with my write-up.  I think we then have a good path = forward.
 
I=E2=80=99m not sure what you mean by = =E2=80=9CI=E2=80=99m not sure that we need a =E2=80=9Cname=E2=80=9D= . What is your intention there.=E2=80=9D  The only place I used the word =E2=80=9Cname=E2= =80=9D was in my statement =E2=80=9CDefine that an event name can be = used as a top-level claim=E2=80=9D.  What I was trying to get at is = was that if =E2=80=9Chttp://specs.openid.net/logout=E2=80=9D is used as = an event name, that it can also be used as a claim name in the JWT = containing information about the event.  (Maybe I=E2=80=99m not = using the correct terminology, hence the unintended confusion <= span style=3D"font-size: 11pt; font-family: Wingdings; color: rgb(0, 32, = 96);" class=3D"">J.)
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;       Thanks again,
          &nb= sp;            = ;            &= nbsp;           &nb= sp;       -- Mike
From: Phil Hunt [mailto:phil.hunt@oracle.com] 
Sent: Tuesday,= August 9, 2016 12:07 PM
To: Mike = Jones <Michael.Jones@microsoft.com>
Cc: id-event@ietf.org
Subject: Re: = [Id-event] Summarizing recent discussions on ID-Event token = draft
 
I didn=E2=80=99t cover this as I didn=E2=80= =99t want to confuse people with too many things.
 
But I think we agree on all of the = below.
 
I=E2=80=99m not sure that we need a = =E2=80=9Cname=E2=80=9D. What is your intention there.
 
Phil
 
@independentid
www.independentid.com
phil.hunt@oracle.com
 
 

 

 
On = Aug 9, 2016, at 11:54 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:
 
Thanks for writing this, = Phil.  Unfortunately, the summary below does not include my = feedback, which at the essence, is to keep the ID Events data structure = as simple and general-purpose as possible.  (I strongly believe = that JWT is the success it is because we made JWT as simple and = general-purpose as possible, and we should follow this successful = example and do the same here.)
 
I believe that the ID Events spec needs to = include these things, and these things only:
=C2=B7       <= span style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: = rgb(0, 32, 96);" class=3D"">Define of the =E2=80=9Cevents=E2=80=9D = claim
=C2=B7       <= span style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: = rgb(0, 32, 96);" class=3D"">Define that an event name can be used as a = top-level claim
=C2=B7       <= span style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: = rgb(0, 32, 96);" class=3D"">Require that =E2=80=9Ciss=E2=80=9D be = included and that the JWT be signed by the issuer
=C2=B7       <= span style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: = rgb(0, 32, 96);" class=3D"">Include a statement along the lines of = =E2=80=9CThe claims to be included with any particular event are to be = defined by the event=E2=80=9D
 
And I=E2=80=99d stop there.
 
It should be entirely up to applications to = say what claims are included with events they define and what their = format and meanings are.  Then the ID Events spec will be as = general-purpose as possible, with it being natural for it to be used in = essentially all JSON Event contexts.
 
As soon as we start putting restrictions on = the use of particular claims by events, we=E2=80=99re making the ID = Events spec less general-purpose and less natural to use.  In = particular, the only thing that the spec should say about the =E2=80=9Csub= =E2=80=9D claim is that =E2=80=9CLike all other claims other than = =E2=80=98events=E2=80=99 and =E2=80=98iss=E2=80=99, whether the = =E2=80=98sub=E2=80=99 claim is to be included with an event is entirely = event-specific.  The claims to be included with any particular = event are explicitly outside the scope of this = specification.=E2=80=9D
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;       -- Mike
 
From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Phil= Hunt
Sent: Tuesday,= August 9, 2016 10:19 AM
To: id-event@ietf.org
Subject: [Id-even= t] Summarizing recent discussions on ID-Event token draft
 
I thought I would update the list on some = discussions that have been happening over in the OpenID Connect and RISC = working groups conference calls.
 
These = discussions have been about the core spec and the role of = =E2=80=9Ctop-level=E2=80=9D attributes vs. event =E2=80=9Cextension=E2=80=9D= attributes. 
* =  For events that are about a user, the relevant event specification = may include a =E2=80=9Csub=E2=80=9D attribute within the event=E2=80=99s = sub-object and not in the top-level. Further that sub-object can also = include the issuer of the user.  
* = The top-level =E2=80=9Ciss=E2=80=9D shall mean the issuer of the event = where the state change occurred.
* =  =E2=80=9Csub=E2=80=9D should not be present in the top level = structure.  Also, =E2=80=9Cevents=E2=80=9D must also be = present.
 
{
  <=E2=80=94 top level is about the =
event itself ->
  "iss": "https://server.example.com",
  "aud": =
"s6BhdRkqt3",
  =
"jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
  "iat": =
1458668180,
  =
"exp": 1458668580,
  =
"events": [
    "https://specs.openid.net/logout"
  ],
  "https://specs.openid.net/logout": =
{
    <- =
This level is defined entirely by the event URI->
    "iss": =
"https://oidc.example.com",
    =
=E2=80=9Cjti": "08a5019c-17e1-4977-8f42-65a12843ea02=E2=80=9D,
    "sub": "248289761001=E2=80=9D,
    =E2=80=9Cexp=E2=80=9D: <ID token =
expiry>
  }
}
 
In the above example note that the =E2=80=9Cevent=E2=80=9D = object can have its own iss and subject (sub or jti) that have meaning = within the context of an OpenID OP provider.  The issuer of the = event can be different (the top-level) and represents the entity that = signs the event (if it is signed).
 
The top-level attributes identify an individual event and are = used to validate the event (signing etc).  Where as the nested = object contains all of the data about the event and is defined by the = profiling specification (e.g. a possible OpenID Logout Event = spec).  In this case, in OpenID, logging out usually translates = into revoking an ID Token. Thus the =E2=80=9Cjti=E2=80=9D for the ID = token (08a5019c...843ea02) is included in the Logout object.
 
Side note.  Regarding =E2=80=9Clogout=E2=80=9D, it might = be useful to include the expiry of the ID Token in case the subscriber = has not yet received an ID Token. This would let the subscriber know how = long it needs to keep the revocation information for.  IOW=E2=80=A6af= ter the the ID Token is expired, the subscriber would no longer need to = track the revocation state.
 
It is also good to observe that the =E2=80=9Caud=E2=80=9D at = the top level describes the subscriber of the event.  This may also = be different then the original audience of the ID Token.
 
So to conclude. By making top-level attributes strictly about = the events own validation, and nested objects about the event, we avoid = collisions in definitions such as the issuer of the event, vs. the = original issuer of a security assertion.
 
I hope I=E2=80=99ve gotten everyone=E2=80=99s feedback = correct here. Lets continue to discuss. I will revise the draft to = follow the groups thinking here.
 
Phil
 
@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

 
_______________________________________________
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=_F92E3305-617B-41A6-8048-B77B4A2FA35D-- From nobody Thu Aug 11 09:10:23 2016 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 25A6B12D0FA for ; Thu, 11 Aug 2016 09:10:11 -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 t2F44ClswyX9 for ; Thu, 11 Aug 2016 09:10:01 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0096.outbound.protection.outlook.com [104.47.34.96]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6BDA12D5D7 for ; Thu, 11 Aug 2016 09:10: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=lqNbNmEqzPKjBbjXNHcbXru6IFJX1sjW4dP/Je/F6Eo=; b=T0kOezLzqQzUjg9hgXeou9mZlod4KyYuhDjEtVNBueZV9g53HqXMD4xY/UmlZdhgh77PJRQoEnuWmWl0XIcS9HvKuRw8OkKNy9jCr/l9x7Adlsbim76yQ0qEf2b5M3HmZmrocPXZxfSc+Nr5nJWO3G51OY98SX5UPdJkj6gl9UI= Received: from SN1PR0301MB1645.namprd03.prod.outlook.com (10.162.130.139) by SN1PR0301MB1645.namprd03.prod.outlook.com (10.162.130.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Thu, 11 Aug 2016 16:09:58 +0000 Received: from SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) by SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) with mapi id 15.01.0549.025; Thu, 11 Aug 2016 16:09:58 +0000 From: Mike Jones To: "Phil Hunt (IDM)" Thread-Topic: [Id-event] Summarizing recent discussions on ID-Event token draft Thread-Index: AQHR8mIWLvqeOEkcuEuQk5SeT4z/pKBA9pTwgAAG/gCAAABNAIAACP2AgAA8CICAAmTu0IAAHwwAgAAWu7CAABBwgIAAAJkA Date: Thu, 11 Aug 2016 16:09:58 +0000 Message-ID: References: <14E2EF51-7123-4E91-87DD-56AEA08202C1@oracle.com> <3F0DD3E6-46CD-4AA5-8F06-F79140F5D4BE@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.201.94.142] x-ms-office365-filtering-correlation-id: 1df119d8-0396-4826-a87f-08d3c201f0f9 x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1645; 6:eewEPady4iygJoOpbiAN/Ka4OApv3UXtnJg3gLJ136SXohrNDgZ2Ru4jaxvWAMQdLtAGGMGX8iwVbdZoMMEKd+pThXwNZ0xA1CoOmXunyKzABUdxN/1VcVrAkibcBZ8Rswq9QccpAcB1Gsy+yJf8ZB4qvM84iJ/U7M89t3ld9IMxN42RvUibu2Iian4n9QO0jUbhSlFg6o5+Lf9Hw/bRUMpQkSBR1u4CZrijcaWK/JlvLK/E3lHR8ZZGqJn1zYLlh3XDnqWFzfjLKB/6YWK9PcMaqUIbG8FJNDiwz5AF9Y+W3R8RrlY45e7leOWd5UpzYfIqvF3zvxjVPHdCeUvYag==; 5:u3rVPgf/RUzuRCbeuTw47BCjLlcSKheYjpjy9UO6eeunlia+F/lvQs+Y6NLgtRT9J2wh4MvoWJVRmeTcqjBkW1piscj/KgWanK+Ua84Fvws4q8+Wmwg7jwiSKC+EifMF8vUYhEnAv+qfxuDtkJ0UfA==; 24:iQ9I4vN4WT0vcmCd7wd48+QkZlYaTGE/2arTwCEkxJ4QiaVF4ckc1YQQs7BwfT5w6Z0keeSn3Z5f3vz4T6lMMqLoWFQB8NK9uvQvkSud2u4=; 7:asxOpE3itGWRo+KYYKz5dGmRfCThwnQ2u5noGQmBnGOaNuC2tPLwl7ZCkzDsQenXuZMcOY0HAMG/+BoVWOwO5jaMofr9exBjZnt/DKQ95CjlWgFMiVGuNpIs98uJmYeKkENihY4H9KzQAUnIn281sjOj0NaBZl7yIlKwtnECHl/HNzB0bI2L3GQoCrq2l67Lf0PxS0bxndCGu+Uxc0sazmlnBbnUKZxc/3f0NqxAxhVAJ+g3009eRHWfw/zG4Li6 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1645; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(278428928389397)(192374486261705)(211936372134217)(21748063052155)(21532816269658)(146099531331640); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040171)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:SN1PR0301MB1645; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1645; x-forefront-prvs: 0031A0FFAF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(43784003)(24454002)(199003)(377454003)(189998001)(10290500002)(8990500004)(5005710100001)(5890100001)(10400500002)(11100500001)(10090500001)(66066001)(68736007)(575784001)(8676002)(81156014)(122556002)(3280700002)(7736002)(4326007)(110136002)(7846002)(3660700001)(81166006)(93886004)(87936001)(7906003)(105586002)(9686002)(7696003)(8936002)(86362001)(74316002)(5002640100001)(99286002)(19625215002)(19580405001)(19580395003)(19609705001)(33656002)(2900100001)(2906002)(97736004)(1860700003)(106116001)(76576001)(19300405004)(16236675004)(19617315012)(16601075003)(101416001)(3846002)(15975445007)(77096005)(6116002)(790700001)(102836003)(92566002)(586003)(86612001)(2950100001)(50986999)(54356999)(106356001)(76176999); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0301MB1645; H:SN1PR0301MB1645.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB16452E432CE19885506CB43EF51E0SN1PR0301MB1645_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Aug 2016 16:09:58.0699 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1645 Archived-At: Cc: "id-event@ietf.org" , Marius Scurtescu Subject: Re: [Id-event] Summarizing recent discussions on ID-Event token draft X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 11 Aug 2016 16:10:11 -0000 --_000_SN1PR0301MB16452E432CE19885506CB43EF51E0SN1PR0301MB1645_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBkb27igJl0IGtub3cgd2h5IHlvdeKAmXJlIHdyaXRpbmcgYWJvdXQgY29uZmxpY3RzIG9uIOKA nGlzc+KAnSBiZWNhdXNlLCBhcyBJIGV4cGxhaW5lZCBiZWxvdywgZm9yIHRoZSBldmVudCBpbiBx dWVzdGlvbiwg4oCcaXNz4oCdIGNvbmZsaWN0cywgYnkgZGVmaW5pdGlvbiwgbWF5IG5vdCBvY2N1 ci4gIEkgdGhpbmsgeW914oCZcmUgY29uZnVzZWQgYXMgdG8gd2hhdCBJ4oCZbSBkaXNjdXNzaW5n LCBiZWNhdXNlIHRoZXJlIGNlcnRhaW5seSB3b3VsZCBiZSBvbmx5IG9uZSDigJxpc3PigJ0gYW5k IG9uZSDigJxzdWLigJ0gaW4gdGhlIGV2ZW50IEpXVCDigJMgYm90aCBhdCB0aGUgdG9wIGxldmVs LiAgVGhlcmXigJlzIG5vIGR1cGxpY2F0aW9uIChhbmQgbm9uZSBuZWVkZWQhKS4gIFRvIHJlbW92 ZSBhbnkgYW1iaWd1aXR5IGZyb20gdGhlIGRpc2N1c3Npb24sIGFuIGV4YW1wbGUgb2Ygd2hhdCB0 aGlzIG1pZ2h0IGxvb2sgbGlrZSBpczoNCg0Kew0KICAiaXNzIjogImh0dHBzOi8vc2VydmVyLmV4 YW1wbGUuY29tIiwNCiAgImF1ZCI6ICJzNkJoZFJrcXQzIiwNCiAgImp0aSI6ICIzZDBjM2NmNzk3 NTg0YmQxOTNiZDBmYjFiZDRlN2QzMCIsDQogICJzdWIiOiAiMjQ4Mjg5NzYxMDAxIiwNCiAgImlh dCI6IDE0NTg2NjgxODAsDQogICJleHAiOiAxNDU4NjY4NTgwLA0KICAiZXZlbnRzIjogWw0KICAg ICJodHRwczovL3NwZWNzLm9wZW5pZC5uZXQvbG9nb3V0Ig0KICBdLA0KICAic2lkIjogIjA4YTUw MTljLTE3ZTEtNDk3Ny04ZjQyLTY1YTEyODQzZWEwMiINCn0NCg0KVGhpcyBjb250YWlucyBhbGwg aW5mb3JtYXRpb24gbmVlZGVkIGZvciB0aGUgSWRlbnRpdHkgUHJvdmlkZXIgdG8gdW5hbWJpZ3Vv dXNseSBhbmQgc2VjdXJlbHkgY29udmV5IHRoYXQgdGhlIFJQIGlzIHRvIGxvZyBvdXQgdGhlIHBh cnR5IGlkZW50aWZpZWQgYnkgdGhlIGlzc3VlciBhbmQgdGhlIHN1YmplY3QgKGFuZCBpbiB0aGlz IGNhc2UsIGFsc28gcXVhbGlmaWVkIHdpdGggdGhlIHNlc3Npb24gSUQpLiAgSXQgZG9lc27igJl0 IGhhdmUgdG8gZ2V0IGFueSBtb3JlIGNvbXBsaWNhdGVkIHRoYW4gdGhpcy4NCg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0K RnJvbTogUGhpbCBIdW50IChJRE0pIFttYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb21dDQpTZW50 OiBUaHVyc2RheSwgQXVndXN0IDExLCAyMDE2IDEyOjAwIFBNDQpUbzogTWlrZSBKb25lcyA8TWlj aGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPg0KQ2M6IE1hcml1cyBTY3VydGVzY3UgPG1zY3VydGVz Y3VAZ29vZ2xlLmNvbT47IGlkLWV2ZW50QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0lkLWV2ZW50 XSBTdW1tYXJpemluZyByZWNlbnQgZGlzY3Vzc2lvbnMgb24gSUQtRXZlbnQgdG9rZW4gZHJhZnQN Cg0KSG93IGRvIHlvdSByZXNvbHZlIGNvbmZsaWN0cyBvbiBpc3MgdGhlbj8gIFRoZSB0b3AgbGV2 ZWwgaGFzIHRvIGJlIHRoZSBpc3N1ZXIgb2YgdGhlIGV2ZW50IGFzIHRoZSBpc3N1ZXIgc2lnbnMu DQoNCklmIG9uZSBzcGVjIGNhbiB1c2UgaXQgYWxsIG11c3QgYmUgYWJsZSB0by4gSSBiZWxpZXZl IHlvdSBwcmV2aW91c2x5IG9iamVjdGVkIHRvIHRoYXQgc2F5aW5nIHN1YiBtdXN0IGJlIGFzIGhv dyBpZCB0b2tlbnMgZGVmaW5lIHRoZW0uIEJ1dCB0aGF0IGlzbnQgdW5pcXVlIGFuZCByZXF1aXJl cyBpc3MuIE5vdyB3ZSB3b3VsZCBoYXZlIHN1YiBhdCB0aGUgdG9wIHdpdGggYW4gZXZlbnQgaXNz dWVyIGF0IHRoZSB0b3AgYW5kIGEgc3ViIGlzc3VlciBpbiB0aGUgZXh0ZW5zaW9uLiBUaGF0IHNl ZW1zIGluY3JlZGlibHkgY29tcGxleCBub3QgdG8gbWVudGlvbiBhd2t3YXJkLg0KDQpJZiB3ZSBt YWtlIHN1YiBhIHVyaSBmb3IgYWxsIHRoZW4gaXQgY2FuIHdvcmsgYXNzIGlzcyBmcm9tIGlkIHRv a2VuIHdvdWxkIG5vdCBiZSBuZWVkZWQuIEJ1dCBpIGNhbiBzZWUgbWFueSBvYmplY3RpbmcgdG8g dGhlIGNoYW5nZSBpbiBmb3JtYXQuDQoNCldoeSBub3QgaGF2ZSBhIGxvZ291dCBiZSBhbiBldmVu dCB3aXRoIGFuIGlkIHRva2VuIGF0dGFjaGVkIGZvciBleGFtcGxlPw0KDQpQaGlsDQoNCk9uIEF1 ZyAxMSwgMjAxNiwgYXQgODowMyBBTSwgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3Nv ZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PiB3cm90ZToNClRoZSBz aW1wbGUgcnVsZSBpcyB0aGF0IGlmIHRoZSBwYXJ0aWN1bGFyIGV2ZW50IGNhbGxzIGZvciB0aGUg 4oCcc3Vi4oCdIGNsYWltIHRvIGJlIGF0IHRoZSB0b3AgbGV2ZWwsIHRoZW4gaXQgaXMuICBUaGlz IGlzIG5vIGRpZmZlcmVudCBmcm9tIGFueSBvdGhlciBjbGFpbSB0aGF0IGFuIGV2ZW50IG1pZ2h0 IHBsYWNlIGF0IHRoZSB0b3AgbGV2ZWwuDQoNClRoZSBjb21wbGV4aXR5IGFyaXNlcyBpZiDigJxz dWLigJ0gaXMgdW5uZWNlc3NhcmlseSBzcGVjaWFsLWNhc2VkLiAgV2Ugc2hvdWxkbuKAmXQgZG8g dGhhdCwgYmVjYXVzZSBpdCBsaW1pdHMgdGhlIGFwcGxpY2FiaWxpdHkgb2YgdGhlIHNwZWNpZmlj YXRpb24uDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAtLSBNaWtlDQoNCkZyb206IFBoaWwgSHVudCAoSURNKSBbbWFpbHRvOnBoaWwuaHVu dEBvcmFjbGUuY29tXQ0KU2VudDogVGh1cnNkYXksIEF1Z3VzdCAxMSwgMjAxNiA5OjQwIEFNDQpU bzogTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVs LkpvbmVzQG1pY3Jvc29mdC5jb20+Pg0KQ2M6IE1hcml1cyBTY3VydGVzY3UgPG1zY3VydGVzY3VA Z29vZ2xlLmNvbTxtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tPj47IGlkLWV2ZW50QGlldGYu b3JnPG1haWx0bzppZC1ldmVudEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbSWQtZXZlbnRdIFN1 bW1hcml6aW5nIHJlY2VudCBkaXNjdXNzaW9ucyBvbiBJRC1FdmVudCB0b2tlbiBkcmFmdA0KDQpJ IHRoaW5rIHVzaW5nIHN1YiBhdCB0aGUgdG9wIGxldmVsIGxlYWRzIHRvIGNvbXBsZXhpdHkuIEVn IENhbiB5b3UgcHJvdmlkZSBhIHJ1bGUgZm9yIHdoZW4gdG9wIGxldmVsIGlzIHVzZWQgb3Igbm90 IGJ5IGFuIGluZGl2aWR1YWwgc3BlYz8gIElNTy4gVG9wIGxldmVsIHNob3VsZCBhbHdheXMgYmUg dXNlZCB0aGUgc2FtZSB3YXkgYnkgYWxsIGltcGxlbWVudGVycy4NCg0KQmFzZWQgb24gdGhlIGNh bGxzIGF0IHJpc2MvY29ubmVjdCwgd2UgZGlzY3Vzc2VkIHRoYXQgaXQgd291bGQgYmUgYmVzdCB0 byBtb3ZlIGFsbCBldmVudCBzcGVjaWZpY3MgdG8gdGhlIGV2ZW50IG9iamVjdCBhcmVhLiBUaGlz IHdheSBkaWZmZXJlbnQgZXZlbnRzIGNhbiBoYXZlIGRpZmZlcmVudCBldmVudCBhZGRyZXNzaW5n IChlZyBzdWIvaXNzLCB1cmksIGppdC9pc3MpLiBXaGVuIGlzcyBpcyBuZWVkZWQgdG8gdW5pcXVl bHkgcXVhbGlmeSBhIHN1YiwgaXQgY2FuIGJlIHByb3ZpZGVkIHdpdGhvdXQgY29uZmxpY3Rpbmcg d2l0aCB0aGUgaXNzdWVyIG9mIHRoZSBldmVudC4gU2ltaWxhcmx5IGp0aSBhbmQgaXNzIGNhbiBi ZSB1c2VkIGZvciBhIHJldm9rZWQgdG9rZW4gd2l0aG91dCBjb25mbGljdGluZyB3aXRoIHRoZSBl dmVudCBqdGkuDQoNCkkgcGxhbiB0byBwb3N0IGEgbmV3IGRyYWZ0IHNob3J0bHkgdGhhdCB3aWxs IGdpdmUgc29tZSBleGFtcGxlcyBiYXNlZCBvbiBmZWVkYmFjayBmcm9tIHRoZSBvcGVuaWQgcmlz Yy9jb25uZWN0IGRpc2N1c3Npb25zLg0KDQpXZSBjYW4gYWx3YXlzIGNoYW5nZSBhZ2Fpbi4NCg0K UGhpbA0KDQpPbiBBdWcgMTEsIDIwMTYsIGF0IDQ6NTQgQU0sIE1pa2UgSm9uZXMgPE1pY2hhZWwu Sm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4g d3JvdGU6DQpObywgSeKAmW0gbm90IHNheWluZyB0aGF0IOKAnHN1YuKAnSBjYW5ub3QgYXBwZWFy IGF0IHRoZSB0b3AgbGV2ZWwuICBJ4oCZbSBzYXlpbmcgdGhhdCDigJxzdWLigJ0gd2lsbCBvbmx5 IG9jY3VyIGF0IHRoZSB0b3AgbGV2ZWwgaWYgdGhlIHBhcnRpY3VsYXIgZXZlbnQgZGVmaW5lcyB0 aGF0IOKAnHN1YuKAnSBpcyB1c2VkIGluIHRoYXQgd2F5IGZvciB0aGF0IGV2ZW50Lg0KDQpUaGVy ZSBhcmUgcHJvYmFibHkgdXNlIGNhc2VzIGZvciBtdWx0aXBsZSBldmVudHMgcGVyIG1lc3NhZ2Ug YnV0IEkgZG91YnQgdGhlcmUgYXJlIHVzZSBjYXNlcyBmb3IgbXVsdGlwbGUgKnVucmVsYXRlZCog ZXZlbnRzIHBlciBtZXNzYWdlLiAgQnkgZGVmaW5pdGlvbiwgcmVsYXRlZCBldmVudHMgdGhhdCB1 c2UgdG9wLWxldmVsIGNsYWltcyB3b3VsZCBuZWVkIHRvIHVzZSB0aGVtIGluIGEgY29tcGF0aWJs ZSB3YXkuICBJIGRvbuKAmXQgc2VlIHRoYXQgYXMgYmVpbmcgYSBwcm9ibGVtLg0KDQpUaGF0IGJl aW5nIHNhaWQsIHRoZSBwcmVkb21pbmFudCB1c2UgY2FzZSBpcyBsaWtlbHkgdG8gYmUgYSBzaW5n bGUgZXZlbnQgcGVyIEpXVC4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBNYXJpdXMg U2N1cnRlc2N1IFttYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tXQ0KU2VudDogVHVlc2RheSwg QXVndXN0IDksIDIwMTYgNzoxNSBQTQ0KVG86IFBoaWwgSHVudCA8cGhpbC5odW50QG9yYWNsZS5j b208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj4NCkNjOiBNaWtlIEpvbmVzIDxNaWNoYWVs LkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+ OyBpZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86aWQtZXZlbnRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBS ZTogW0lkLWV2ZW50XSBTdW1tYXJpemluZyByZWNlbnQgZGlzY3Vzc2lvbnMgb24gSUQtRXZlbnQg dG9rZW4gZHJhZnQNCg0KTWlrZSwgYXJlIHlvdSBzdWdnZXN0aW5nIHRoYXQgYSBzdWIgY2xhaW0g Y2FuIG9ubHkgc2hvdyB1cCBhdCB0aGUgZXZlbnQgbGV2ZWwgYW5kIG5vdCBhdCB0aGUgdG9wIGxl dmVsOg0KDQpJbiBwYXJ0aWN1bGFyLCB0aGUgb25seSB0aGluZyB0aGF0IHRoZSBzcGVjIHNob3Vs ZCBzYXkgYWJvdXQgdGhlIOKAnHN1YuKAnSBjbGFpbSBpcyB0aGF0IOKAnExpa2UgYWxsIG90aGVy IGNsYWltcyBvdGhlciB0aGFuIOKAmGV2ZW50c+KAmSBhbmQg4oCYaXNz4oCZLCB3aGV0aGVyIHRo ZSDigJhzdWLigJkgY2xhaW0gaXMgdG8gYmUgaW5jbHVkZWQgd2l0aCBhbiBldmVudCBpcyBlbnRp cmVseSBldmVudC1zcGVjaWZpYy4NCg0KQSB0b3AgbGV2ZWwgc3ViIGFuZCBtdWx0aXBsZSBldmVu dHMgYXJlIGluY29tcGF0aWJsZSBJTU8uDQoNCkRvIHdlIGhhdmUgYSBjb21wZWxsaW5nIHJlYXNv biB0byBzdXBwb3J0IG11bHRpcGxlIGV2ZW50cyBwZXIgbWVzc2FnZT8NCg0KDQpNYXJpdXMNCg0K T24gVHVlLCBBdWcgOSwgMjAxNiBhdCAxMjozOSBQTSwgUGhpbCBIdW50IDxwaGlsLmh1bnRAb3Jh Y2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+PiB3cm90ZToNCkkgd2FzIHJlZmVy cmluZyB0byB0aGlzIGluIHlvdXIgZW1haWwNCiJEZWZpbmUgdGhhdCBhbiBldmVudCBuYW1lIGNh biBiZSB1c2VkIGFzIGEgdG9wLWxldmVsIGNsYWlt4oCdDQoNCg0KSXMgdGhpcyBkaWZmZXJlbnQg ZnJvbSB0aGUgZXZlbnQgdXJpPw0KDQpQaGlsDQoNCkBpbmRlcGVuZGVudGlkDQp3d3cuaW5kZXBl bmRlbnRpZC5jb208aHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNvbT4NCnBoaWwuaHVudEBvcmFj bGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4NCg0KDQoNCg0KT24gQXVnIDksIDIw MTYsIGF0IDEyOjEyIFBNLCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208 bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KDQpJ4oCZbSBnbGFk IHRvIGhlYXIgdGhhdCB3ZSBhZ3JlZSBvbiBrZWVwaW5nIGl0IGFzIHNpbXBsZSBhbmQgZ2VuZXJh bC1wdXJwb3NlIGFzIHBvc3NpYmxlIGFuZCB0aGF0IHlvdSBhZ3JlZSB3aXRoIG15IHdyaXRlLXVw LiAgSSB0aGluayB3ZSB0aGVuIGhhdmUgYSBnb29kIHBhdGggZm9yd2FyZC4NCg0KSeKAmW0gbm90 IHN1cmUgd2hhdCB5b3UgbWVhbiBieSDigJxJ4oCZbSBub3Qgc3VyZSB0aGF0IHdlIG5lZWQgYSDi gJxuYW1l4oCdLiBXaGF0IGlzIHlvdXIgaW50ZW50aW9uIHRoZXJlLuKAnSAgVGhlIG9ubHkgcGxh Y2UgSSB1c2VkIHRoZSB3b3JkIOKAnG5hbWXigJ0gd2FzIGluIG15IHN0YXRlbWVudCDigJxEZWZp bmUgdGhhdCBhbiBldmVudCBuYW1lIGNhbiBiZSB1c2VkIGFzIGEgdG9wLWxldmVsIGNsYWlt4oCd LiAgV2hhdCBJIHdhcyB0cnlpbmcgdG8gZ2V0IGF0IGlzIHdhcyB0aGF0IGlmIOKAnGh0dHA6Ly9z cGVjcy5vcGVuaWQubmV0L2xvZ291dOKAnSBpcyB1c2VkIGFzIGFuIGV2ZW50IG5hbWUsIHRoYXQg aXQgY2FuIGFsc28gYmUgdXNlZCBhcyBhIGNsYWltIG5hbWUgaW4gdGhlIEpXVCBjb250YWluaW5n IGluZm9ybWF0aW9uIGFib3V0IHRoZSBldmVudC4gIChNYXliZSBJ4oCZbSBub3QgdXNpbmcgdGhl IGNvcnJlY3QgdGVybWlub2xvZ3ksIGhlbmNlIHRoZSB1bmludGVuZGVkIGNvbmZ1c2lvbiDimLou KQ0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgVGhhbmtzIGFnYWluLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogUGhpbCBIdW50IFttYWlsdG86cGhpbC5o dW50QG9yYWNsZS5jb21dDQpTZW50OiBUdWVzZGF5LCBBdWd1c3QgOSwgMjAxNiAxMjowNyBQTQ0K VG86IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFl bC5Kb25lc0BtaWNyb3NvZnQuY29tPj4NCkNjOiBpZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86aWQt ZXZlbnRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0lkLWV2ZW50XSBTdW1tYXJpemluZyByZWNl bnQgZGlzY3Vzc2lvbnMgb24gSUQtRXZlbnQgdG9rZW4gZHJhZnQNCg0KSSBkaWRu4oCZdCBjb3Zl ciB0aGlzIGFzIEkgZGlkbuKAmXQgd2FudCB0byBjb25mdXNlIHBlb3BsZSB3aXRoIHRvbyBtYW55 IHRoaW5ncy4NCg0KQnV0IEkgdGhpbmsgd2UgYWdyZWUgb24gYWxsIG9mIHRoZSBiZWxvdy4NCg0K SeKAmW0gbm90IHN1cmUgdGhhdCB3ZSBuZWVkIGEg4oCcbmFtZeKAnS4gV2hhdCBpcyB5b3VyIGlu dGVudGlvbiB0aGVyZS4NCg0KUGhpbA0KDQpAaW5kZXBlbmRlbnRpZA0Kd3d3LmluZGVwZW5kZW50 aWQuY29tPGh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20vPg0KcGhpbC5odW50QG9yYWNsZS5j b208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPg0KDQoNCg0KDQpPbiBBdWcgOSwgMjAxNiwg YXQgMTE6NTQgQU0sIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWls dG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQoNClRoYW5rcyBmb3Igd3Jp dGluZyB0aGlzLCBQaGlsLiAgVW5mb3J0dW5hdGVseSwgdGhlIHN1bW1hcnkgYmVsb3cgZG9lcyBu b3QgaW5jbHVkZSBteSBmZWVkYmFjaywgd2hpY2ggYXQgdGhlIGVzc2VuY2UsIGlzIHRvIGtlZXAg dGhlIElEIEV2ZW50cyBkYXRhIHN0cnVjdHVyZSBhcyBzaW1wbGUgYW5kIGdlbmVyYWwtcHVycG9z ZSBhcyBwb3NzaWJsZS4gIChJIHN0cm9uZ2x5IGJlbGlldmUgdGhhdCBKV1QgaXMgdGhlIHN1Y2Nl c3MgaXQgaXMgYmVjYXVzZSB3ZSBtYWRlIEpXVCBhcyBzaW1wbGUgYW5kIGdlbmVyYWwtcHVycG9z ZSBhcyBwb3NzaWJsZSwgYW5kIHdlIHNob3VsZCBmb2xsb3cgdGhpcyBzdWNjZXNzZnVsIGV4YW1w bGUgYW5kIGRvIHRoZSBzYW1lIGhlcmUuKQ0KDQpJIGJlbGlldmUgdGhhdCB0aGUgSUQgRXZlbnRz IHNwZWMgbmVlZHMgdG8gaW5jbHVkZSB0aGVzZSB0aGluZ3MsIGFuZCB0aGVzZSB0aGluZ3Mgb25s eToNCuKAoiAgICAgICBEZWZpbmUgb2YgdGhlIOKAnGV2ZW50c+KAnSBjbGFpbQ0K4oCiICAgICAg IERlZmluZSB0aGF0IGFuIGV2ZW50IG5hbWUgY2FuIGJlIHVzZWQgYXMgYSB0b3AtbGV2ZWwgY2xh aW0NCuKAoiAgICAgICBSZXF1aXJlIHRoYXQg4oCcaXNz4oCdIGJlIGluY2x1ZGVkIGFuZCB0aGF0 IHRoZSBKV1QgYmUgc2lnbmVkIGJ5IHRoZSBpc3N1ZXINCuKAoiAgICAgICBJbmNsdWRlIGEgc3Rh dGVtZW50IGFsb25nIHRoZSBsaW5lcyBvZiDigJxUaGUgY2xhaW1zIHRvIGJlIGluY2x1ZGVkIHdp dGggYW55IHBhcnRpY3VsYXIgZXZlbnQgYXJlIHRvIGJlIGRlZmluZWQgYnkgdGhlIGV2ZW504oCd DQoNCkFuZCBJ4oCZZCBzdG9wIHRoZXJlLg0KDQpJdCBzaG91bGQgYmUgZW50aXJlbHkgdXAgdG8g YXBwbGljYXRpb25zIHRvIHNheSB3aGF0IGNsYWltcyBhcmUgaW5jbHVkZWQgd2l0aCBldmVudHMg dGhleSBkZWZpbmUgYW5kIHdoYXQgdGhlaXIgZm9ybWF0IGFuZCBtZWFuaW5ncyBhcmUuICBUaGVu IHRoZSBJRCBFdmVudHMgc3BlYyB3aWxsIGJlIGFzIGdlbmVyYWwtcHVycG9zZSBhcyBwb3NzaWJs ZSwgd2l0aCBpdCBiZWluZyBuYXR1cmFsIGZvciBpdCB0byBiZSB1c2VkIGluIGVzc2VudGlhbGx5 IGFsbCBKU09OIEV2ZW50IGNvbnRleHRzLg0KDQpBcyBzb29uIGFzIHdlIHN0YXJ0IHB1dHRpbmcg cmVzdHJpY3Rpb25zIG9uIHRoZSB1c2Ugb2YgcGFydGljdWxhciBjbGFpbXMgYnkgZXZlbnRzLCB3 ZeKAmXJlIG1ha2luZyB0aGUgSUQgRXZlbnRzIHNwZWMgbGVzcyBnZW5lcmFsLXB1cnBvc2UgYW5k IGxlc3MgbmF0dXJhbCB0byB1c2UuICBJbiBwYXJ0aWN1bGFyLCB0aGUgb25seSB0aGluZyB0aGF0 IHRoZSBzcGVjIHNob3VsZCBzYXkgYWJvdXQgdGhlIOKAnHN1YuKAnSBjbGFpbSBpcyB0aGF0IOKA nExpa2UgYWxsIG90aGVyIGNsYWltcyBvdGhlciB0aGFuIOKAmGV2ZW50c+KAmSBhbmQg4oCYaXNz 4oCZLCB3aGV0aGVyIHRoZSDigJhzdWLigJkgY2xhaW0gaXMgdG8gYmUgaW5jbHVkZWQgd2l0aCBh biBldmVudCBpcyBlbnRpcmVseSBldmVudC1zcGVjaWZpYy4gIFRoZSBjbGFpbXMgdG8gYmUgaW5j bHVkZWQgd2l0aCBhbnkgcGFydGljdWxhciBldmVudCBhcmUgZXhwbGljaXRseSBvdXRzaWRlIHRo ZSBzY29wZSBvZiB0aGlzIHNwZWNpZmljYXRpb24u4oCdDQoNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IElkLWV2 ZW50IFttYWlsdG86aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFBoaWwg SHVudA0KU2VudDogVHVlc2RheSwgQXVndXN0IDksIDIwMTYgMTA6MTkgQU0NClRvOiBpZC1ldmVu dEBpZXRmLm9yZzxtYWlsdG86aWQtZXZlbnRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbSWQtZXZlbnRd IFN1bW1hcml6aW5nIHJlY2VudCBkaXNjdXNzaW9ucyBvbiBJRC1FdmVudCB0b2tlbiBkcmFmdA0K DQpJIHRob3VnaHQgSSB3b3VsZCB1cGRhdGUgdGhlIGxpc3Qgb24gc29tZSBkaXNjdXNzaW9ucyB0 aGF0IGhhdmUgYmVlbiBoYXBwZW5pbmcgb3ZlciBpbiB0aGUgT3BlbklEIENvbm5lY3QgYW5kIFJJ U0Mgd29ya2luZyBncm91cHMgY29uZmVyZW5jZSBjYWxscy4NCg0KVGhlc2UgZGlzY3Vzc2lvbnMg aGF2ZSBiZWVuIGFib3V0IHRoZSBjb3JlIHNwZWMgYW5kIHRoZSByb2xlIG9mIOKAnHRvcC1sZXZl bOKAnSBhdHRyaWJ1dGVzIHZzLiBldmVudCDigJxleHRlbnNpb27igJ0gYXR0cmlidXRlcy4NClNl ZTogaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWh1bnQtaWRldmVudC10b2tlbi0w MQ0KDQpJbiBwYXJ0aWN1bGFyIHNob3VsZCDigJxzdWLigJ0gYmUgdXNlZCBpbiB0aGUgdG9wIGxl dmVsIHRvIOKAnHBvaW504oCdIHRvIHRoZSBzdWJqZWN0IChpbiB0aGUgYnJvYWRlciBlbmdsaXNo IHNlbnNlKSBvZiB0aGUgZXZlbnQsIG9yIHNob3VsZCBpdCBiZSBjb25zdHJhaW5lZCB0byB0aGUg U0FNTC9JRCBUb2tlbiBkZWZpbml0aW9uIHdoaWNoIGlzIHRoZSBhdXRoZW50aWNhdGVkIHVzZXIu DQoNClRha2VuIGluIHRoZSBuYXJyb3dlciBkZWZpbml0aW9uLCBpdCBpcyBpbXBvcnRhbnQgdG8g b2JzZXJ2ZSB0aGF0IGluIGFuIElEIFRva2VuLCDigJxzdWLigJ0gYW5kIOKAnGlzc+KAnSBnbyB0 b2dldGhlci4gIFRoZSBpc3N1ZXIgcHJvdmlkZXMgdGhlIGNvbnRleHQgZm9yIHRoZSBhdXRoZW50 aWNhdGVkIHN1YmplY3QgaWRlbnRpZmllci4gVGhlIHByb2JsZW0gd2l0aCBldmVudHMsIGlzIHRo YXQgaXQgbWlnaHQgbm90IGJlIHRoZSBBUyAob3IgT1ApIHdoaWNoIGlzIGlzc3VpbmcgdGhlIGV2 ZW50Lg0KDQpUbyBzdW1tYXJpemUgYSBmYWlyIGFtb3VudCBvZiBkaXNjdXNzaW9uLCB0aGUgZmVl bGluZyBzZWVtcyB0byBiZSB0aGUgZm9sbG93aW5nOg0KDQoqICBUaGUgRXZlbnQgVG9rZW4gdG9w IGxldmVsIGF0dHJpYnV0ZXMgc2hvdWxkIGJlIGZhaXJseSBsaW1pdGVkIGFuZCBub3QgaW5jbHVk ZSB0aGUgc3ViIGF0dHJpYnV0ZS4NCiogIEZvciBldmVudHMgdGhhdCBhcmUgYWJvdXQgYSB1c2Vy LCB0aGUgcmVsZXZhbnQgZXZlbnQgc3BlY2lmaWNhdGlvbiBtYXkgaW5jbHVkZSBhIOKAnHN1YuKA nSBhdHRyaWJ1dGUgd2l0aGluIHRoZSBldmVudOKAmXMgc3ViLW9iamVjdCBhbmQgbm90IGluIHRo ZSB0b3AtbGV2ZWwuIEZ1cnRoZXIgdGhhdCBzdWItb2JqZWN0IGNhbiBhbHNvIGluY2x1ZGUgdGhl IGlzc3VlciBvZiB0aGUgdXNlci4NCiogVGhlIHRvcC1sZXZlbCDigJxpc3PigJ0gc2hhbGwgbWVh biB0aGUgaXNzdWVyIG9mIHRoZSBldmVudCB3aGVyZSB0aGUgc3RhdGUgY2hhbmdlIG9jY3VycmVk Lg0KKiAg4oCcc3Vi4oCdIHNob3VsZCBub3QgYmUgcHJlc2VudCBpbiB0aGUgdG9wIGxldmVsIHN0 cnVjdHVyZS4gIEFsc28sIOKAnGV2ZW50c+KAnSBtdXN0IGFsc28gYmUgcHJlc2VudC4NCg0KSGVy ZSB3b3VsZCBiZSBhIG5ldyBleGFtcGxlIGxvZ291dDoNCg0Kew0KDQogIDzigJQgdG9wIGxldmVs IGlzIGFib3V0IHRoZSBldmVudCBpdHNlbGYgLT4NCg0KICAiaXNzIjogImh0dHBzOi8vc2VydmVy LmV4YW1wbGUuY29tPGh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tLz4iLA0KDQogICJhdWQiOiAi czZCaGRSa3F0MyIsDQoNCiAgImp0aSI6ICIzZDBjM2NmNzk3NTg0YmQxOTNiZDBmYjFiZDRlN2Qz MCIsDQoNCiAgImlhdCI6IDE0NTg2NjgxODAsDQoNCiAgImV4cCI6IDE0NTg2Njg1ODAsDQoNCiAg ImV2ZW50cyI6IFsNCg0KICAgICJodHRwczovL3NwZWNzLm9wZW5pZC5uZXQvbG9nb3V0Ig0KDQog IF0sDQoNCiAgImh0dHBzOi8vc3BlY3Mub3BlbmlkLm5ldC9sb2dvdXQiOiB7DQoNCiAgICA8LSBU aGlzIGxldmVsIGlzIGRlZmluZWQgZW50aXJlbHkgYnkgdGhlIGV2ZW50IFVSSS0+DQoNCiAgICAi aXNzIjogImh0dHBzOi8vb2lkYy5leGFtcGxlLmNvbTxodHRwczovL29pZGMuZXhhbXBsZS5jb20v PiIsDQoNCiAgICDigJxqdGkiOiAiMDhhNTAxOWMtMTdlMS00OTc3LThmNDItNjVhMTI4NDNlYTAy 4oCdLA0KDQogICAgInN1YiI6ICIyNDgyODk3NjEwMDHigJ0sDQoNCiAgICDigJxleHDigJ06IDxJ RCB0b2tlbiBleHBpcnk+DQoNCiAgfQ0KDQp9DQoNCkluIHRoZSBhYm92ZSBleGFtcGxlIG5vdGUg dGhhdCB0aGUg4oCcZXZlbnTigJ0gb2JqZWN0IGNhbiBoYXZlIGl0cyBvd24gaXNzIGFuZCBzdWJq ZWN0IChzdWIgb3IganRpKSB0aGF0IGhhdmUgbWVhbmluZyB3aXRoaW4gdGhlIGNvbnRleHQgb2Yg YW4gT3BlbklEIE9QIHByb3ZpZGVyLiAgVGhlIGlzc3VlciBvZiB0aGUgZXZlbnQgY2FuIGJlIGRp ZmZlcmVudCAodGhlIHRvcC1sZXZlbCkgYW5kIHJlcHJlc2VudHMgdGhlIGVudGl0eSB0aGF0IHNp Z25zIHRoZSBldmVudCAoaWYgaXQgaXMgc2lnbmVkKS4NCg0KVGhlIHRvcC1sZXZlbCBhdHRyaWJ1 dGVzIGlkZW50aWZ5IGFuIGluZGl2aWR1YWwgZXZlbnQgYW5kIGFyZSB1c2VkIHRvIHZhbGlkYXRl IHRoZSBldmVudCAoc2lnbmluZyBldGMpLiAgV2hlcmUgYXMgdGhlIG5lc3RlZCBvYmplY3QgY29u dGFpbnMgYWxsIG9mIHRoZSBkYXRhIGFib3V0IHRoZSBldmVudCBhbmQgaXMgZGVmaW5lZCBieSB0 aGUgcHJvZmlsaW5nIHNwZWNpZmljYXRpb24gKGUuZy4gYSBwb3NzaWJsZSBPcGVuSUQgTG9nb3V0 IEV2ZW50IHNwZWMpLiAgSW4gdGhpcyBjYXNlLCBpbiBPcGVuSUQsIGxvZ2dpbmcgb3V0IHVzdWFs bHkgdHJhbnNsYXRlcyBpbnRvIHJldm9raW5nIGFuIElEIFRva2VuLiBUaHVzIHRoZSDigJxqdGni gJ0gZm9yIHRoZSBJRCB0b2tlbiAoMDhhNTAxOWMuLi44NDNlYTAyKSBpcyBpbmNsdWRlZCBpbiB0 aGUgTG9nb3V0IG9iamVjdC4NCg0KU2lkZSBub3RlLiAgUmVnYXJkaW5nIOKAnGxvZ291dOKAnSwg aXQgbWlnaHQgYmUgdXNlZnVsIHRvIGluY2x1ZGUgdGhlIGV4cGlyeSBvZiB0aGUgSUQgVG9rZW4g aW4gY2FzZSB0aGUgc3Vic2NyaWJlciBoYXMgbm90IHlldCByZWNlaXZlZCBhbiBJRCBUb2tlbi4g VGhpcyB3b3VsZCBsZXQgdGhlIHN1YnNjcmliZXIga25vdyBob3cgbG9uZyBpdCBuZWVkcyB0byBr ZWVwIHRoZSByZXZvY2F0aW9uIGluZm9ybWF0aW9uIGZvci4gIElPV+KApmFmdGVyIHRoZSB0aGUg SUQgVG9rZW4gaXMgZXhwaXJlZCwgdGhlIHN1YnNjcmliZXIgd291bGQgbm8gbG9uZ2VyIG5lZWQg dG8gdHJhY2sgdGhlIHJldm9jYXRpb24gc3RhdGUuDQoNCkl0IGlzIGFsc28gZ29vZCB0byBvYnNl cnZlIHRoYXQgdGhlIOKAnGF1ZOKAnSBhdCB0aGUgdG9wIGxldmVsIGRlc2NyaWJlcyB0aGUgc3Vi c2NyaWJlciBvZiB0aGUgZXZlbnQuICBUaGlzIG1heSBhbHNvIGJlIGRpZmZlcmVudCB0aGVuIHRo ZSBvcmlnaW5hbCBhdWRpZW5jZSBvZiB0aGUgSUQgVG9rZW4uDQoNClNvIHRvIGNvbmNsdWRlLiBC eSBtYWtpbmcgdG9wLWxldmVsIGF0dHJpYnV0ZXMgc3RyaWN0bHkgYWJvdXQgdGhlIGV2ZW50cyBv d24gdmFsaWRhdGlvbiwgYW5kIG5lc3RlZCBvYmplY3RzIGFib3V0IHRoZSBldmVudCwgd2UgYXZv aWQgY29sbGlzaW9ucyBpbiBkZWZpbml0aW9ucyBzdWNoIGFzIHRoZSBpc3N1ZXIgb2YgdGhlIGV2 ZW50LCB2cy4gdGhlIG9yaWdpbmFsIGlzc3VlciBvZiBhIHNlY3VyaXR5IGFzc2VydGlvbi4NCg0K SSBob3BlIEnigJl2ZSBnb3R0ZW4gZXZlcnlvbmXigJlzIGZlZWRiYWNrIGNvcnJlY3QgaGVyZS4g TGV0cyBjb250aW51ZSB0byBkaXNjdXNzLiBJIHdpbGwgcmV2aXNlIHRoZSBkcmFmdCB0byBmb2xs b3cgdGhlIGdyb3VwcyB0aGlua2luZyBoZXJlLg0KDQpQaGlsDQoNCkBpbmRlcGVuZGVudGlkDQp3 d3cuaW5kZXBlbmRlbnRpZC5jb208aHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNvbS8+DQpwaGls Lmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+DQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJZC1ldmVudCBtYWlsaW5n IGxpc3QNCklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZz4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQNCg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSWQtZXZlbnQgbWFpbGluZyBs aXN0DQpJZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc+DQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50DQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJZC1ldmVudCBtYWlsaW5nIGxpc3QN CklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQNCg== --_000_SN1PR0301MB16452E432CE19885506CB43EF51E0SN1PR0301MB1645_ 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 DQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4w cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToi Q291cmllciBOZXciO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1h bDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy Z2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUt bmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29s YXM7fQ0Kc3Bhbi5tLTY1MzQ0MzU1NzM2Mzk2NzM3ODZhcHBsZS1zdHlsZS1zcGFuDQoJe21zby1z dHlsZS1uYW1lOm1fLTY1MzQ0MzU1NzM2Mzk2NzM3ODZhcHBsZS1zdHlsZS1zcGFuO30NCnNwYW4u bS02NTM0NDM1NTczNjM5NjczNzg2YXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1u YW1lOm1fLTY1MzQ0MzU1NzM2Mzk2NzM3ODZhcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5F bWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzAwMjA2MDt9DQpzcGFuLkVtYWlsU3R5bGUyMw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjojMDAyMDYwO30NCnNwYW4uRW1haWxTdHlsZTI0DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CWNvbG9yOiMwMDIwNjA7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4 LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0i RU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYw Ij5JIGRvbuKAmXQga25vdyB3aHkgeW914oCZcmUgd3JpdGluZyBhYm91dCBjb25mbGljdHMgb24g 4oCcaXNz4oCdIGJlY2F1c2UsIGFzIEkgZXhwbGFpbmVkIGJlbG93LCBmb3IgdGhlIGV2ZW50IGlu IHF1ZXN0aW9uLCDigJxpc3PigJ0gY29uZmxpY3RzLCBieSBkZWZpbml0aW9uLCBtYXkgbm90IG9j Y3VyLiZuYnNwOw0KIEkgdGhpbmsgeW914oCZcmUgY29uZnVzZWQgYXMgdG8gd2hhdCBJ4oCZbSBk aXNjdXNzaW5nLCBiZWNhdXNlIHRoZXJlIGNlcnRhaW5seSB3b3VsZCBiZSBvbmx5IG9uZSDigJxp c3PigJ0gYW5kIG9uZSDigJxzdWLigJ0gaW4gdGhlIGV2ZW50IEpXVCDigJMgYm90aCBhdCB0aGUg dG9wIGxldmVsLiZuYnNwOyBUaGVyZeKAmXMgbm8gZHVwbGljYXRpb24gKGFuZCBub25lIG5lZWRl ZCEpLiZuYnNwOyBUbyByZW1vdmUgYW55IGFtYmlndWl0eSBmcm9tIHRoZSBkaXNjdXNzaW9uLCBh biBleGFtcGxlDQogb2Ygd2hhdCB0aGlzIG1pZ2h0IGxvb2sgbGlrZSBpczo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAw MjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ ezxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZxdW90O2lzcyZx dW90OzogJnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iPmh0dHBzOi8v c2VydmVyLmV4YW1wbGUuY29tPC9hPiZxdW90Oyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOyAmcXVvdDthdWQmcXVvdDs6ICZxdW90O3M2QmhkUmtxdDMmcXVvdDss PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJnF1b3Q7anRpJnF1 b3Q7OiAmcXVvdDszZDBjM2NmNzk3NTg0YmQxOTNiZDBmYjFiZDRlN2QzMCZxdW90Oyw8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmcXVvdDtzdWImcXVvdDs6ICZx dW90OzI0ODI4OTc2MTAwMSZxdW90Oyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOyAmcXVvdDtpYXQmcXVvdDs6IDE0NTg2NjgxODAsPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJnF1b3Q7ZXhwJnF1b3Q7OiAxNDU4NjY4NTgwLDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZxdW90O2V2ZW50cyZx dW90OzogWzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNw OyAmcXVvdDs8YSBocmVmPSJodHRwczovL3NwZWNzLm9wZW5pZC5uZXQvbG9nb3V0Ij5odHRwczov L3NwZWNzLm9wZW5pZC5uZXQvbG9nb3V0PC9hPiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7IF0sPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsgJnF1b3Q7c2lkJnF1b3Q7OiAmcXVvdDswOGE1MDE5Yy0xN2UxLTQ5NzctOGY0 Mi02NWExMjg0M2VhMDImcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pn08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+VGhpcyBjb250YWlucyBhbGwg aW5mb3JtYXRpb24gbmVlZGVkIGZvciB0aGUgSWRlbnRpdHkgUHJvdmlkZXIgdG8gdW5hbWJpZ3Vv dXNseSBhbmQgc2VjdXJlbHkgY29udmV5IHRoYXQgdGhlIFJQIGlzIHRvIGxvZyBvdXQgdGhlIHBh cnR5IGlkZW50aWZpZWQgYnkgdGhlIGlzc3Vlcg0KIGFuZCB0aGUgc3ViamVjdCAoYW5kIGluIHRo aXMgY2FzZSwgYWxzbyBxdWFsaWZpZWQgd2l0aCB0aGUgc2Vzc2lvbiBJRCkuJm5ic3A7IEl0IGRv ZXNu4oCZdCBoYXZlIHRvIGdldCBhbnkgbW9yZSBjb21wbGljYXRlZCB0aGFuIHRoaXMuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8c3BhbiBz dHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PC9zcGFuPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5n OjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFBoaWwgSHVudCAoSURNKSBb bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5 LCBBdWd1c3QgMTEsIDIwMTYgMTI6MDAgUE08YnI+DQo8Yj5Ubzo8L2I+IE1pa2UgSm9uZXMgJmx0 O01pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IE1hcml1cyBT Y3VydGVzY3UgJmx0O21zY3VydGVzY3VAZ29vZ2xlLmNvbSZndDs7IGlkLWV2ZW50QGlldGYub3Jn PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbSWQtZXZlbnRdIFN1bW1hcml6aW5nIHJlY2VudCBk aXNjdXNzaW9ucyBvbiBJRC1FdmVudCB0b2tlbiBkcmFmdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ib3cgZG8geW91IHJlc29sdmUgY29uZmxp Y3RzIG9uIGlzcyB0aGVuPyAmbmJzcDtUaGUgdG9wIGxldmVsIGhhcyB0byBiZSB0aGUgaXNzdWVy IG9mIHRoZSBldmVudCBhcyB0aGUgaXNzdWVyIHNpZ25zLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25h dHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiBvbmUgc3BlYyBjYW4gdXNlIGl0IGFsbCBt dXN0IGJlIGFibGUgdG8uIEkgYmVsaWV2ZSB5b3UgcHJldmlvdXNseSBvYmplY3RlZCB0byB0aGF0 IHNheWluZyBzdWIgbXVzdCBiZSBhcyBob3cgaWQgdG9rZW5zIGRlZmluZSB0aGVtLiBCdXQgdGhh dCBpc250IHVuaXF1ZSBhbmQgcmVxdWlyZXMgaXNzLiBOb3cgd2Ugd291bGQgaGF2ZSBzdWIgYXQg dGhlIHRvcCB3aXRoIGFuIGV2ZW50IGlzc3VlciBhdCB0aGUgdG9wDQogYW5kIGEgc3ViIGlzc3Vl ciBpbiB0aGUgZXh0ZW5zaW9uLiBUaGF0IHNlZW1zIGluY3JlZGlibHkgY29tcGxleCBub3QgdG8g bWVudGlvbiBhd2t3YXJkLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJB cHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JZiB3ZSBtYWtlIHN1YiBhIHVyaSBmb3IgYWxsIHRoZW4gaXQgY2FuIHdvcmsg YXNzIGlzcyBmcm9tIGlkIHRva2VuIHdvdWxkIG5vdCBiZSBuZWVkZWQuIEJ1dCBpIGNhbiBzZWUg bWFueSBvYmplY3RpbmcgdG8gdGhlIGNoYW5nZSBpbiBmb3JtYXQuJm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWls U2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoeSBub3QgaGF2ZSBhIGxvZ291dCBi ZSBhbiBldmVudCB3aXRoIGFuIGlkIHRva2VuIGF0dGFjaGVkIGZvciBleGFtcGxlPzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGJyPg0KUGhpbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpPbiBB dWcgMTEsIDIwMTYsIGF0IDg6MDMgQU0sIE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpN aWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+VGhlIHNpbXBsZSBydWxl IGlzIHRoYXQgaWYgdGhlIHBhcnRpY3VsYXIgZXZlbnQgY2FsbHMgZm9yIHRoZSDigJxzdWLigJ0g Y2xhaW0gdG8gYmUgYXQgdGhlIHRvcCBsZXZlbCwgdGhlbiBpdCBpcy4mbmJzcDsgVGhpcyBpcyBu byBkaWZmZXJlbnQgZnJvbSBhbnkgb3RoZXIgY2xhaW0gdGhhdA0KIGFuIGV2ZW50IG1pZ2h0IHBs YWNlIGF0IHRoZSB0b3AgbGV2ZWwuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MDAyMDYwIj5UaGUgY29tcGxleGl0eSBhcmlzZXMgaWYg4oCcc3Vi4oCdIGlzIHVubmVjZXNzYXJp bHkgc3BlY2lhbC1jYXNlZC4mbmJzcDsgV2Ugc2hvdWxkbuKAmXQgZG8gdGhhdCwgYmVjYXVzZSBp dCBsaW1pdHMgdGhlIGFwcGxpY2FiaWxpdHkgb2YgdGhlIHNwZWNpZmljYXRpb24uPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj4gUGhpbCBIdW50IChJRE0pIFs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9y YWNsZS5jb20iPm1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50 OjwvYj4gVGh1cnNkYXksIEF1Z3VzdCAxMSwgMjAxNiA5OjQwIEFNPGJyPg0KPGI+VG86PC9iPiBN aWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29t Ij5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gTWFy aXVzIFNjdXJ0ZXNjdSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbSI+ bXNjdXJ0ZXNjdUBnb29nbGUuY29tPC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86aWQtZXZlbnRA aWV0Zi5vcmciPmlkLWV2ZW50QGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog W0lkLWV2ZW50XSBTdW1tYXJpemluZyByZWNlbnQgZGlzY3Vzc2lvbnMgb24gSUQtRXZlbnQgdG9r ZW4gZHJhZnQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SSB0aGluayB1c2luZyBzdWIgYXQgdGhlIHRvcCBsZXZlbCBsZWFkcyB0byBjb21wbGV4 aXR5LiBFZyBDYW4geW91IHByb3ZpZGUgYSBydWxlIGZvciB3aGVuIHRvcCBsZXZlbCBpcyB1c2Vk IG9yIG5vdCBieSBhbiBpbmRpdmlkdWFsIHNwZWM/ICZuYnNwO0lNTy4gVG9wIGxldmVsIHNob3Vs ZCBhbHdheXMgYmUgdXNlZCB0aGUgc2FtZSB3YXkgYnkgYWxsIGltcGxlbWVudGVycy4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlk PSJBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmFzZWQgb24gdGhl IGNhbGxzIGF0IHJpc2MvY29ubmVjdCwgd2UgZGlzY3Vzc2VkIHRoYXQgaXQgd291bGQgYmUgYmVz dCB0byBtb3ZlIGFsbCBldmVudCBzcGVjaWZpY3MgdG8gdGhlIGV2ZW50IG9iamVjdCBhcmVhLiBU aGlzIHdheSBkaWZmZXJlbnQgZXZlbnRzIGNhbiBoYXZlIGRpZmZlcmVudCBldmVudCBhZGRyZXNz aW5nIChlZyBzdWIvaXNzLCB1cmksIGppdC9pc3MpLiBXaGVuIGlzcyBpcyBuZWVkZWQgdG8NCiB1 bmlxdWVseSBxdWFsaWZ5IGEgc3ViLCBpdCBjYW4gYmUgcHJvdmlkZWQgd2l0aG91dCBjb25mbGlj dGluZyB3aXRoIHRoZSBpc3N1ZXIgb2YgdGhlIGV2ZW50LiBTaW1pbGFybHkganRpIGFuZCBpc3Mg Y2FuIGJlIHVzZWQgZm9yIGEgcmV2b2tlZCB0b2tlbiB3aXRob3V0IGNvbmZsaWN0aW5nIHdpdGgg dGhlIGV2ZW50IGp0aS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iQXBw bGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SSBwbGFuIHRvIHBvc3QgYSBuZXcgZHJhZnQgc2hvcnRseSB0aGF0IHdpbGwgZ2l2 ZSBzb21lIGV4YW1wbGVzIGJhc2VkIG9uIGZlZWRiYWNrIGZyb20gdGhlIG9wZW5pZCByaXNjL2Nv bm5lY3QgZGlzY3Vzc2lvbnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxl TWFpbFNpZ25hdHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPldlIGNhbiBhbHdheXMgY2hhbmdlIGFnYWluLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGJyPg0KUGhpbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpPbiBBdWcgMTEsIDIw MTYsIGF0IDQ6NTQgQU0sIE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpv bmVzQG1pY3Jvc29mdC5jb20iPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Tm8sIEnigJltIG5vdCBzYXlpbmcgdGhh dCDigJxzdWLigJ0gY2Fubm90IGFwcGVhciBhdCB0aGUgdG9wIGxldmVsLiZuYnNwOyBJ4oCZbSBz YXlpbmcgdGhhdCDigJxzdWLigJ0gd2lsbCBvbmx5IG9jY3VyIGF0IHRoZSB0b3AgbGV2ZWwgaWYg dGhlIHBhcnRpY3VsYXIgZXZlbnQgZGVmaW5lcyB0aGF0IOKAnHN1YuKAnQ0KIGlzIHVzZWQgaW4g dGhhdCB3YXkgZm9yIHRoYXQgZXZlbnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMDAyMDYwIj5UaGVyZSBhcmUgcHJvYmFibHkgdXNlIGNhc2VzIGZvciBtdWx0aXBsZSBldmVu dHMgcGVyIG1lc3NhZ2UgYnV0IEkgZG91YnQgdGhlcmUgYXJlIHVzZSBjYXNlcyBmb3IgbXVsdGlw bGUgKjxiPnVucmVsYXRlZDwvYj4qIGV2ZW50cyBwZXIgbWVzc2FnZS4mbmJzcDsgQnkgZGVmaW5p dGlvbiwNCiByZWxhdGVkIGV2ZW50cyB0aGF0IHVzZSB0b3AtbGV2ZWwgY2xhaW1zIHdvdWxkIG5l ZWQgdG8gdXNlIHRoZW0gaW4gYSBjb21wYXRpYmxlIHdheS4mbmJzcDsgSSBkb27igJl0IHNlZSB0 aGF0IGFzIGJlaW5nIGEgcHJvYmxlbS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMwMDIwNjAiPlRoYXQgYmVpbmcgc2FpZCwgdGhlIHByZWRvbWluYW50IHVzZSBjYXNlIGlzIGxp a2VseSB0byBiZSBhIHNpbmdsZSBldmVudCBwZXIgSldULjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gTWFyaXVzIFNj dXJ0ZXNjdSBbPGEgaHJlZj0ibWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbSI+bWFpbHRvOm1z Y3VydGVzY3VAZ29vZ2xlLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgQXVn dXN0IDksIDIwMTYgNzoxNSBQTTxicj4NCjxiPlRvOjwvYj4gUGhpbCBIdW50ICZsdDs8YSBocmVm PSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPiZn dDs8YnI+DQo8Yj5DYzo8L2I+IE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVs LkpvbmVzQG1pY3Jvc29mdC5jb20iPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7 Ow0KPGEgaHJlZj0ibWFpbHRvOmlkLWV2ZW50QGlldGYub3JnIj5pZC1ldmVudEBpZXRmLm9yZzwv YT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtJZC1ldmVudF0gU3VtbWFyaXppbmcgcmVjZW50 IGRpc2N1c3Npb25zIG9uIElELUV2ZW50IHRva2VuIGRyYWZ0PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+TWlrZSwgYXJlIHlvdSBzdWdnZXN0aW5nIHRoYXQgYSBzdWIgY2xh aW0gY2FuIG9ubHkgc2hvdyB1cCBhdCB0aGUgZXZlbnQgbGV2ZWwgYW5kIG5vdCBhdCB0aGUgdG9w IGxldmVsOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIHBhcnRpY3VsYXIsIHRo ZSBvbmx5IHRoaW5nIHRoYXQgdGhlIHNwZWMgc2hvdWxkIHNheSBhYm91dCB0aGUg4oCcc3Vi4oCd IGNsYWltIGlzIHRoYXQg4oCcTGlrZSBhbGwgb3RoZXIgY2xhaW1zIG90aGVyIHRoYW4g4oCYZXZl bnRz4oCZIGFuZCDigJhpc3PigJksIHdoZXRoZXIgdGhlIOKAmHN1YuKAmSBjbGFpbSBpcyB0byBi ZSBpbmNsdWRlZCB3aXRoIGFuIGV2ZW50IGlzIGVudGlyZWx5IGV2ZW50LXNwZWNpZmljLjxvOnA+ PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ QSB0b3AgbGV2ZWwgc3ViIGFuZCBtdWx0aXBsZSBldmVudHMgYXJlIGluY29tcGF0aWJsZSBJTU8u PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRv IHdlIGhhdmUgYSBjb21wZWxsaW5nIHJlYXNvbiB0byBzdXBwb3J0IG11bHRpcGxlIGV2ZW50cyBw ZXIgbWVzc2FnZT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWFyaXVzPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBBdWcgOSwgMjAxNiBhdCAxMjozOSBQ TSwgUGhpbCBIdW50ICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRh cmdldD0iX2JsYW5rIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3YXMgcmVmZXJyaW5nIHRvIHRoaXMgaW4g eW91ciBlbWFpbDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZx dW90OzxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5EZWZpbmUgdGhhdCBhbiBldmVudCBu YW1lIGNhbiBiZSB1c2VkIGFzIGEgdG9wLWxldmVsIGNsYWlt4oCdPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JcyB0 aGlzIGRpZmZlcmVudCBmcm9tIHRoZSBldmVudCB1cmk/PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlBoaWw8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+QGluZGVwZW5kZW50aWQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxhIGhyZWY9Imh0 dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20iIHRhcmdldD0iX2JsYW5rIj53d3cuaW5kZXBlbmRl bnRpZC5jb208L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PjxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBo aWwuaHVudEBvcmFjbGUuY29tPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5PbiBBdWcgOSwgMjAxNiwgYXQgMTI6MTIgUE0sIE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1h aWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5NaWNoYWVs LkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAw MjA2MCI+SeKAmW0gZ2xhZCB0byBoZWFyIHRoYXQgd2UgYWdyZWUgb24ga2VlcGluZyBpdCBhcyBz aW1wbGUgYW5kIGdlbmVyYWwtcHVycG9zZSBhcyBwb3NzaWJsZSBhbmQgdGhhdCB5b3UgYWdyZWUg d2l0aCBteSB3cml0ZS11cC4mbmJzcDsgSSB0aGluayB3ZSB0aGVuIGhhdmUgYSBnb29kIHBhdGgN CiBmb3J3YXJkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+SeKAmW0gbm90IHN1cmUgd2hhdCB5b3UgbWVhbiBi eSDigJw8L3NwYW4+SeKAmW0gbm90IHN1cmUgdGhhdCB3ZSBuZWVkIGEg4oCcbmFtZeKAnS4gV2hh dCBpcyB5b3VyIGludGVudGlvbiB0aGVyZS48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+ 4oCdJm5ic3A7DQogVGhlIG9ubHkgcGxhY2UgSSB1c2VkIHRoZSB3b3JkIOKAnG5hbWXigJ0gd2Fz IGluIG15IHN0YXRlbWVudCDigJxEZWZpbmUgdGhhdCBhbiBldmVudCBuYW1lIGNhbiBiZSB1c2Vk IGFzIGEgdG9wLWxldmVsIGNsYWlt4oCdLiZuYnNwOyBXaGF0IEkgd2FzIHRyeWluZyB0byBnZXQg YXQgaXMgd2FzIHRoYXQgaWYg4oCcPGEgaHJlZj0iaHR0cDovL3NwZWNzLm9wZW5pZC5uZXQvbG9n b3V0IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cDovL3Nw ZWNzLm9wZW5pZC5uZXQvbG9nb3V0PC9zcGFuPjwvYT7igJ0NCiBpcyB1c2VkIGFzIGFuIGV2ZW50 IG5hbWUsIHRoYXQgaXQgY2FuIGFsc28gYmUgdXNlZCBhcyBhIGNsYWltIG5hbWUgaW4gdGhlIEpX VCBjb250YWluaW5nIGluZm9ybWF0aW9uIGFib3V0IHRoZSBldmVudC4mbmJzcDsgKE1heWJlIEni gJltIG5vdCB1c2luZyB0aGUgY29ycmVjdCB0ZXJtaW5vbG9neSwgaGVuY2UgdGhlIHVuaW50ZW5k ZWQgY29uZnVzaW9uPHNwYW4gY2xhc3M9Im0tNjUzNDQzNTU3MzYzOTY3Mzc4NmFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6IzAwMjA2MCI+Sjwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Lik8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2 MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGFua3MgYWdhaW4sPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAt LSBNaWtlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGEgbmFtZT0ibV8tNjUzNDQzNTU3MzYzOTY3Mzc4Nl9fTWFpbEVuZENvbXBvc2Ui PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PC9hPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIGNsYXNzPSJtLTY1MzQ0MzU1NzM2Mzk2NzM3ODZhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlBo aWwNCiBIdW50IFs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0i X2JsYW5rIj5tYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb208L2E+XTxzcGFuIGNsYXNzPSJtLTY1 MzQ0MzU1NzM2Mzk2NzM3ODZhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+ DQo8Yj5TZW50OjwvYj48c3BhbiBjbGFzcz0ibS02NTM0NDM1NTczNjM5NjczNzg2YXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+VHVlc2RheSwgQXVndXN0IDksIDIwMTYgMTI6MDcg UE08YnI+DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9Im0tNjUzNDQzNTU3MzYzOTY3Mzc4NmFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPk1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1h aWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5NaWNoYWVs LkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj48c3BhbiBjbGFzcz0i bS02NTM0NDM1NTczNjM5NjczNzg2YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PGEgaHJlZj0ibWFpbHRvOmlkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aWQtZXZl bnRAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9Im0tNjUzNDQz NTU3MzYzOTY3Mzc4NmFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBbSWQt ZXZlbnRdIFN1bW1hcml6aW5nIHJlY2VudCBkaXNjdXNzaW9ucyBvbiBJRC1FdmVudCB0b2tlbiBk cmFmdDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkaWRu4oCZdCBjb3ZlciB0 aGlzIGFzIEkgZGlkbuKAmXQgd2FudCB0byBjb25mdXNlIHBlb3BsZSB3aXRoIHRvbyBtYW55IHRo aW5ncy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJ1dCBJIHRoaW5rIHdlIGFncmVlIG9uIGFsbCBvZiB0 aGUgYmVsb3cuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPknigJltIG5vdCBzdXJlIHRoYXQg d2UgbmVlZCBhIOKAnG5hbWXigJ0uIFdoYXQgaXMgeW91ciBpbnRlbnRpb24gdGhlcmUuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+UGhpbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5AaW5kZXBlbmRlbnRpZDxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGEgaHJlZj0iaHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNvbS8iIHRhcmdldD0iX2Js YW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj53d3cuaW5kZXBlbmRlbnRpZC5jb208L3Nw YW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJtYWlsdG86cGhpbC5o dW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxl Ij5waGlsLmh1bnRAb3JhY2xlLmNvbTwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gQXVnIDksIDIwMTYsIGF0IDExOjU0IEFNLCBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWls dG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5 bGU9ImNvbG9yOnB1cnBsZSI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9zcGFuPjwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIw NjAiPlRoYW5rcyBmb3Igd3JpdGluZyB0aGlzLCBQaGlsLiZuYnNwOyBVbmZvcnR1bmF0ZWx5LCB0 aGUgc3VtbWFyeSBiZWxvdyBkb2VzIG5vdCBpbmNsdWRlIG15IGZlZWRiYWNrLCB3aGljaCBhdCB0 aGUgZXNzZW5jZSwgaXMgdG8ga2VlcCB0aGUgSUQgRXZlbnRzIGRhdGEgc3RydWN0dXJlIGFzDQog c2ltcGxlIGFuZCBnZW5lcmFsLXB1cnBvc2UgYXMgcG9zc2libGUuICZuYnNwOyhJIHN0cm9uZ2x5 IGJlbGlldmUgdGhhdCBKV1QgaXMgdGhlIHN1Y2Nlc3MgaXQgaXMgYmVjYXVzZSB3ZSBtYWRlIEpX VCBhcyBzaW1wbGUgYW5kIGdlbmVyYWwtcHVycG9zZSBhcyBwb3NzaWJsZSwgYW5kIHdlIHNob3Vs ZCBmb2xsb3cgdGhpcyBzdWNjZXNzZnVsIGV4YW1wbGUgYW5kIGRvIHRoZSBzYW1lIGhlcmUuKTwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+SSBiZWxpZXZlIHRo YXQgdGhlIElEIEV2ZW50cyBzcGVjIG5lZWRzIHRvIGluY2x1ZGUgdGhlc2UgdGhpbmdzLCBhbmQg dGhlc2UgdGhpbmdzIG9ubHk6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xv cjojMDAyMDYwIj7Ctzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOiMw MDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJt LTY1MzQ0MzU1NzM2Mzk2NzM3ODZhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPkRlZmluZQ0KIG9mIHRoZSDigJxl dmVudHPigJ0gY2xhaW08L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOiMw MDIwNjAiPsK3PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzAwMjA2 MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9Im0tNjUz NDQzNTU3MzYzOTY3Mzc4NmFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+RGVmaW5lDQogdGhhdCBhbiBldmVudCBu YW1lIGNhbiBiZSB1c2VkIGFzIGEgdG9wLWxldmVsIGNsYWltPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OlN5bWJvbDtjb2xvcjojMDAyMDYwIj7Ctzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjcuMHB0O2NvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOzxzcGFuIGNsYXNzPSJtLTY1MzQ0MzU1NzM2Mzk2NzM3ODZhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPlJl cXVpcmUNCiB0aGF0IOKAnGlzc+KAnSBiZSBpbmNsdWRlZCBhbmQgdGhhdCB0aGUgSldUIGJlIHNp Z25lZCBieSB0aGUgaXNzdWVyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xv cjojMDAyMDYwIj7Ctzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOiMw MDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJt LTY1MzQ0MzU1NzM2Mzk2NzM3ODZhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPkluY2x1ZGUNCiBhIHN0YXRlbWVu dCBhbG9uZyB0aGUgbGluZXMgb2Yg4oCcVGhlIGNsYWltcyB0byBiZSBpbmNsdWRlZCB3aXRoIGFu eSBwYXJ0aWN1bGFyIGV2ZW50IGFyZSB0byBiZSBkZWZpbmVkIGJ5IHRoZSBldmVudOKAnTwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+QW5kIEnigJlkIHN0b3Ag dGhlcmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5JdCBz aG91bGQgYmUgZW50aXJlbHkgdXAgdG8gYXBwbGljYXRpb25zIHRvIHNheSB3aGF0IGNsYWltcyBh cmUgaW5jbHVkZWQgd2l0aCBldmVudHMgdGhleSBkZWZpbmUgYW5kIHdoYXQgdGhlaXIgZm9ybWF0 IGFuZCBtZWFuaW5ncyBhcmUuJm5ic3A7IFRoZW4gdGhlIElEIEV2ZW50cyBzcGVjDQogd2lsbCBi ZSBhcyBnZW5lcmFsLXB1cnBvc2UgYXMgcG9zc2libGUsIHdpdGggaXQgYmVpbmcgbmF0dXJhbCBm b3IgaXQgdG8gYmUgdXNlZCBpbiBlc3NlbnRpYWxseSBhbGwgSlNPTiBFdmVudCBjb250ZXh0cy48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPkFzIHNvb24gYXMg d2Ugc3RhcnQgcHV0dGluZyByZXN0cmljdGlvbnMgb24gdGhlIHVzZSBvZiBwYXJ0aWN1bGFyIGNs YWltcyBieSBldmVudHMsIHdl4oCZcmUgbWFraW5nIHRoZSBJRCBFdmVudHMgc3BlYyBsZXNzIGdl bmVyYWwtcHVycG9zZSBhbmQgbGVzcyBuYXR1cmFsIHRvIHVzZS4mbmJzcDsNCiBJbiBwYXJ0aWN1 bGFyLCB0aGUgb25seSB0aGluZyB0aGF0IHRoZSBzcGVjIHNob3VsZCBzYXkgYWJvdXQgdGhlIOKA nHN1YuKAnSBjbGFpbSBpcyB0aGF0IOKAnExpa2UgYWxsIG90aGVyIGNsYWltcyBvdGhlciB0aGFu IOKAmGV2ZW50c+KAmSBhbmQg4oCYaXNz4oCZLCB3aGV0aGVyIHRoZSDigJhzdWLigJkgY2xhaW0g aXMgdG8gYmUgaW5jbHVkZWQgd2l0aCBhbiBldmVudCBpcyBlbnRpcmVseSBldmVudC1zcGVjaWZp Yy4mbmJzcDsgVGhlIGNsYWltcyB0byBiZSBpbmNsdWRlZCB3aXRoIGFueQ0KIHBhcnRpY3VsYXIg ZXZlbnQgYXJlIGV4cGxpY2l0bHkgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0 aW9uLuKAnTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJtLTY1MzQ0MzU1NzM2Mzk2NzM3ODZhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPklkLWV2ZW50DQogWzxhIGhyZWY9Im1haWx0bzppZC1ldmVudC1ib3VuY2Vz QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+bWFp bHRvOmlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPl08c3BhbiBjbGFzcz0ibS02 NTM0NDM1NTczNjM5NjczNzg2YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGI+ T24gQmVoYWxmIE9mPHNwYW4gY2xhc3M9Im0tNjUzNDQzNTU3MzYzOTY3Mzc4NmFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5QaGlsDQogSHVudDxicj4NCjxiPlNlbnQ6PC9i PjxzcGFuIGNsYXNzPSJtLTY1MzQ0MzU1NzM2Mzk2NzM3ODZhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj5UdWVzZGF5LCBBdWd1c3QgOSwgMjAxNiAxMDoxOSBBTTxicj4NCjxiPlRv OjwvYj48c3BhbiBjbGFzcz0ibS02NTM0NDM1NTczNjM5NjczNzg2YXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmlkLWV2ZW50QGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aWQtZXZlbnRAaWV0Zi5vcmc8 L3NwYW4+PC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJtLTY1MzQ0MzU1NzM2 Mzk2NzM3ODZhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5bSWQtZXZlbnRdIFN1 bW1hcml6aW5nIHJlY2VudCBkaXNjdXNzaW9ucyBvbiBJRC1FdmVudCB0b2tlbiBkcmFmdDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhvdWdodCBJ IHdvdWxkIHVwZGF0ZSB0aGUgbGlzdCBvbiBzb21lIGRpc2N1c3Npb25zIHRoYXQgaGF2ZSBiZWVu IGhhcHBlbmluZyBvdmVyIGluIHRoZSBPcGVuSUQgQ29ubmVjdCBhbmQgUklTQyB3b3JraW5nIGdy b3VwcyBjb25mZXJlbmNlIGNhbGxzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VGhlc2UgZGlzY3Vzc2lvbnMgaGF2ZSBiZWVuIGFib3V0IHRoZSBjb3Jl IHNwZWMgYW5kIHRoZSByb2xlIG9mIOKAnHRvcC1sZXZlbOKAnSBhdHRyaWJ1dGVzIHZzLiBldmVu dCDigJxleHRlbnNpb27igJ0gYXR0cmlidXRlcy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlNlZTo8c3BhbiBjbGFzcz0ibS02NTM0NDM1NTczNjM5NjczNzg2YXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWh1bnQtaWRldmVudC10b2tlbi0wMSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxl PSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1odW50LWlk ZXZlbnQtdG9rZW4tMDE8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBwYXJ0aWN1bGFyIHNob3VsZCDigJxzdWLigJ0g YmUgdXNlZCBpbiB0aGUgdG9wIGxldmVsIHRvIOKAnHBvaW504oCdIHRvIHRoZSBzdWJqZWN0IChp biB0aGUgYnJvYWRlciBlbmdsaXNoIHNlbnNlKSBvZiB0aGUgZXZlbnQsIG9yIHNob3VsZCBpdCBi ZSBjb25zdHJhaW5lZCB0byB0aGUgU0FNTC9JRCBUb2tlbiBkZWZpbml0aW9uIHdoaWNoIGlzIHRo ZSBhdXRoZW50aWNhdGVkIHVzZXIuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UYWtlbiBpbiB0aGUgbmFycm93ZXIgZGVmaW5p dGlvbiwgaXQgaXMgaW1wb3J0YW50IHRvIG9ic2VydmUgdGhhdCBpbiBhbiBJRCBUb2tlbiwg4oCc c3Vi4oCdIGFuZCDigJxpc3PigJ0gZ28gdG9nZXRoZXIuJm5ic3A7IFRoZSBpc3N1ZXIgcHJvdmlk ZXMgdGhlIGNvbnRleHQgZm9yIHRoZSBhdXRoZW50aWNhdGVkIHN1YmplY3QgaWRlbnRpZmllci4g VGhlIHByb2JsZW0gd2l0aCBldmVudHMsIGlzIHRoYXQgaXQgbWlnaHQgbm90IGJlIHRoZQ0KIEFT IChvciBPUCkgd2hpY2ggaXMgaXNzdWluZyB0aGUgZXZlbnQuICZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UbyBzdW1tYXJpemUg YSBmYWlyIGFtb3VudCBvZiBkaXNjdXNzaW9uLCB0aGUgZmVlbGluZyBzZWVtcyB0byBiZSB0aGUg Zm9sbG93aW5nOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4qICZuYnNwO1RoZSBFdmVudCBUb2tlbiB0b3AgbGV2ZWwgYXR0cmlidXRlcyBz aG91bGQgYmUgZmFpcmx5IGxpbWl0ZWQgYW5kIG5vdCBpbmNsdWRlIHRoZSBzdWIgYXR0cmlidXRl LiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiogJm5ic3A7Rm9yIGV2ZW50cyB0aGF0 IGFyZSBhYm91dCBhIHVzZXIsIHRoZSByZWxldmFudCBldmVudCBzcGVjaWZpY2F0aW9uIG1heSBp bmNsdWRlIGEg4oCcc3Vi4oCdIGF0dHJpYnV0ZSB3aXRoaW4gdGhlIGV2ZW504oCZcyBzdWItb2Jq ZWN0IGFuZCBub3QgaW4gdGhlIHRvcC1sZXZlbC4gRnVydGhlciB0aGF0IHN1Yi1vYmplY3QgY2Fu IGFsc28gaW5jbHVkZSB0aGUgaXNzdWVyIG9mIHRoZSB1c2VyLiAmbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiogVGhlIHRvcC1sZXZlbCDigJxpc3PigJ0gc2hhbGwgbWVhbiB0aGUgaXNz dWVyIG9mIHRoZSBldmVudCB3aGVyZSB0aGUgc3RhdGUgY2hhbmdlIG9jY3VycmVkLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+KiAmbmJzcDvigJxzdWLigJ0gc2hvdWxkIG5vdCBiZSBwcmVzZW50 IGluIHRoZSB0b3AgbGV2ZWwgc3RydWN0dXJlLiZuYnNwOyBBbHNvLCDigJxldmVudHPigJ0gbXVz dCBhbHNvIGJlIHByZXNlbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkhlcmUgd291bGQgYmUgYSBuZXcgZXhhbXBsZSBsb2dvdXQ6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHByZT57PG86cD48 L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7ICZsdDvigJQgdG9wIGxldmVsIGlzIGFib3V0IHRoZSBl dmVudCBpdHNlbGYgLSZndDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsgPHNwYW4gc3R5 bGU9ImNvbG9yOiM1RTMwRUIiPiZxdW90O2lzcyZxdW90OzogJnF1b3Q7PGEgaHJlZj0iaHR0cHM6 Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9y OnB1cnBsZSI+aHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb208L3NwYW4+PC9hPiZxdW90Oyw8L3Nw YW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOiM1RTMwRUIiPiZu YnNwOyAmcXVvdDthdWQmcXVvdDs6ICZxdW90O3M2QmhkUmtxdDMmcXVvdDssPC9zcGFuPjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjojNUUzMEVCIj4mbmJzcDsgJnF1 b3Q7anRpJnF1b3Q7OiAmcXVvdDszZDBjM2NmNzk3NTg0YmQxOTNiZDBmYjFiZDRlN2QzMCZxdW90 Oyw8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOiM1RTMw RUIiPiZuYnNwOyAmcXVvdDtpYXQmcXVvdDs6IDE0NTg2NjgxODAsPC9zcGFuPjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjojNUUzMEVCIj4mbmJzcDsgJnF1b3Q7ZXhw JnF1b3Q7OiAxNDU4NjY4NTgwLDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBz dHlsZT0iY29sb3I6IzVFMzBFQiI+Jm5ic3A7ICZxdW90O2V2ZW50cyZxdW90OzogWzwvc3Bhbj48 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6IzVFMzBFQiI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZxdW90OzxhIGhyZWY9Imh0dHBzOi8vc3BlY3Mub3BlbmlkLm5ldC9sb2dv dXQiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3Nw ZWNzLm9wZW5pZC5uZXQvbG9nb3V0PC9zcGFuPjwvYT4mcXVvdDs8L3NwYW4+PG86cD48L286cD48 L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOiM1RTMwRUIiPiZuYnNwOyBdLDwvc3Bhbj48 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gPHNwYW4gc3R5bGU9ImNvbG9yOiNFNjNCN0EiPiZuYnNw OyZxdW90OzxhIGhyZWY9Imh0dHBzOi8vc3BlY3Mub3BlbmlkLm5ldC9sb2dvdXQiIHRhcmdldD0i X2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3NwZWNzLm9wZW5pZC5u ZXQvbG9nb3V0PC9zcGFuPjwvYT4mcXVvdDs6IHs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxw cmU+PHNwYW4gc3R5bGU9ImNvbG9yOiNFNjNCN0EiPiZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7LSBU aGlzIGxldmVsIGlzIGRlZmluZWQgZW50aXJlbHkgYnkgdGhlIGV2ZW50IFVSSS0mZ3Q7PC9zcGFu PjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjojRTYzQjdBIj4mbmJz cDsmbmJzcDsmbmJzcDsgJnF1b3Q7aXNzJnF1b3Q7OiAmcXVvdDs8YSBocmVmPSJodHRwczovL29p ZGMuZXhhbXBsZS5jb20vIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBs ZSI+aHR0cHM6Ly9vaWRjLmV4YW1wbGUuY29tPC9zcGFuPjwvYT4mcXVvdDssPC9zcGFuPjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjojRTYzQjdBIj4mbmJzcDsmbmJz cDsmbmJzcDsg4oCcanRpJnF1b3Q7OiAmcXVvdDswOGE1MDE5Yy0xN2UxLTQ5NzctOGY0Mi02NWEx Mjg0M2VhMDLigJ0sPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2NvbG9yOiNFNjNCN0EiPiZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtz dWImcXVvdDs6ICZxdW90OzI0ODI4OTc2MTAwMeKAnSw8L3NwYW4+PG86cD48L286cD48L3ByZT4N CjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6I0U2M0I3QSI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7IOKAnGV4cOKAnTogJmx0O0lEIHRva2VuIGV4cGlyeSZndDs8L3NwYW4+PG86 cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6 I0U2M0I3QSI+Jm5ic3A7IH08L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQiPn08L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SW4gdGhlIGFib3ZlIGV4YW1wbGUgbm90ZSB0aGF0IHRoZSDigJxldmVudOKAnSBv YmplY3QgY2FuIGhhdmUgaXRzIG93biBpc3MgYW5kIHN1YmplY3QgKHN1YiBvciBqdGkpIHRoYXQg aGF2ZSBtZWFuaW5nIHdpdGhpbiB0aGUgY29udGV4dCBvZiBhbiBPcGVuSUQgT1AgcHJvdmlkZXIu Jm5ic3A7IFRoZSBpc3N1ZXIgb2YgdGhlIGV2ZW50IGNhbiBiZSBkaWZmZXJlbnQgKHRoZSB0b3At bGV2ZWwpIGFuZCByZXByZXNlbnRzIHRoZQ0KIGVudGl0eSB0aGF0IHNpZ25zIHRoZSBldmVudCAo aWYgaXQgaXMgc2lnbmVkKS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VGhlIHRvcC1sZXZlbCBhdHRyaWJ1dGVzIGlkZW50aWZ5IGFuIGlu ZGl2aWR1YWwgZXZlbnQgYW5kIGFyZSB1c2VkIHRvIHZhbGlkYXRlIHRoZSBldmVudCAoc2lnbmlu ZyBldGMpLiZuYnNwOyBXaGVyZSBhcyB0aGUgbmVzdGVkIG9iamVjdCBjb250YWlucyBhbGwgb2Yg dGhlIGRhdGEgYWJvdXQgdGhlIGV2ZW50IGFuZCBpcyBkZWZpbmVkIGJ5IHRoZSBwcm9maWxpbmcg c3BlY2lmaWNhdGlvbiAoZS5nLiBhIHBvc3NpYmxlDQogT3BlbklEIExvZ291dCBFdmVudCBzcGVj KS4mbmJzcDsgSW4gdGhpcyBjYXNlLCBpbiBPcGVuSUQsIGxvZ2dpbmcgb3V0IHVzdWFsbHkgdHJh bnNsYXRlcyBpbnRvIHJldm9raW5nIGFuIElEIFRva2VuLiBUaHVzIHRoZSDigJxqdGnigJ0gZm9y IHRoZSBJRCB0b2tlbiAoMDhhNTAxOWMuLi44NDNlYTAyKSBpcyBpbmNsdWRlZCBpbiB0aGUgTG9n b3V0IG9iamVjdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+U2lkZSBub3RlLiZuYnNwOyBSZWdhcmRpbmcg4oCcbG9nb3V04oCdLCBpdCBt aWdodCBiZSB1c2VmdWwgdG8gaW5jbHVkZSB0aGUgZXhwaXJ5IG9mIHRoZSBJRCBUb2tlbiBpbiBj YXNlIHRoZSBzdWJzY3JpYmVyIGhhcyBub3QgeWV0IHJlY2VpdmVkIGFuIElEIFRva2VuLiBUaGlz IHdvdWxkIGxldCB0aGUgc3Vic2NyaWJlciBrbm93IGhvdyBsb25nIGl0IG5lZWRzIHRvIGtlZXAg dGhlIHJldm9jYXRpb24gaW5mb3JtYXRpb24gZm9yLiZuYnNwOw0KIElPV+KApmFmdGVyIHRoZSB0 aGUgSUQgVG9rZW4gaXMgZXhwaXJlZCwgdGhlIHN1YnNjcmliZXIgd291bGQgbm8gbG9uZ2VyIG5l ZWQgdG8gdHJhY2sgdGhlIHJldm9jYXRpb24gc3RhdGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IGlzIGFsc28gZ29vZCB0byBvYnNl cnZlIHRoYXQgdGhlIOKAnGF1ZOKAnSBhdCB0aGUgdG9wIGxldmVsIGRlc2NyaWJlcyB0aGUgc3Vi c2NyaWJlciBvZiB0aGUgZXZlbnQuJm5ic3A7IFRoaXMgbWF5IGFsc28gYmUgZGlmZmVyZW50IHRo ZW4gdGhlIG9yaWdpbmFsIGF1ZGllbmNlIG9mIHRoZSBJRCBUb2tlbi48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U28gdG8gY29uY2x1ZGUu IEJ5IG1ha2luZyB0b3AtbGV2ZWwgYXR0cmlidXRlcyBzdHJpY3RseSBhYm91dCB0aGUgZXZlbnRz IG93biB2YWxpZGF0aW9uLCBhbmQgbmVzdGVkIG9iamVjdHMgYWJvdXQgdGhlIGV2ZW50LCB3ZSBh dm9pZCBjb2xsaXNpb25zIGluIGRlZmluaXRpb25zIHN1Y2ggYXMgdGhlIGlzc3VlciBvZiB0aGUg ZXZlbnQsIHZzLiB0aGUgb3JpZ2luYWwgaXNzdWVyIG9mIGEgc2VjdXJpdHkgYXNzZXJ0aW9uLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J IGhvcGUgSeKAmXZlIGdvdHRlbiBldmVyeW9uZeKAmXMgZmVlZGJhY2sgY29ycmVjdCBoZXJlLiBM ZXRzIGNvbnRpbnVlIHRvIGRpc2N1c3MuIEkgd2lsbCByZXZpc2UgdGhlIGRyYWZ0IHRvIGZvbGxv dyB0aGUgZ3JvdXBzIHRoaW5raW5nIGhlcmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5QaGlsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkBpbmRlcGVuZGVudGlkPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48YSBocmVmPSJodHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tLyIgdGFyZ2V0PSJf YmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnd3dy5pbmRlcGVuZGVudGlkLmNvbTwv c3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhy ZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0 eWxlPSJjb2xvcjpwdXJwbGUiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9zcGFuPjwvYT48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCklkLWV2 ZW50IG1haWxpbmcgbGlzdDxicj4NCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOnB1cnBsZSI+SWQt ZXZlbnRAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCjwvc3Bhbj48 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50IiB0 YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ8L3NwYW4+PC9hPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJZC1ldmVudCBtYWlsaW5nIGxpc3Q8 YnI+DQo8YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciPklkLWV2ZW50QGlldGYub3Jn PC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v aWQtZXZlbnQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2lkLWV2ZW50PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCklkLWV2ZW50IG1h aWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9yZyI+SWQtZXZl bnRAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9pZC1ldmVudCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9pZC1ldmVudDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_SN1PR0301MB16452E432CE19885506CB43EF51E0SN1PR0301MB1645_-- From nobody Thu Aug 11 09:22:35 2016 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 7725312D7C0 for ; Thu, 11 Aug 2016 09:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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] 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 GzPyE-e-BULA for ; Thu, 11 Aug 2016 09:22:30 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::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 785A112D5AD for ; Thu, 11 Aug 2016 09:22:30 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id l2so300229qkf.3 for ; Thu, 11 Aug 2016 09:22:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=e1tq342ubv5rRPNyw8T8ymxR0xgl12zP2KhNw/XNRIA=; b=lbRQ6ceJuSqgOEZis7UL5fnQAT2++ZDFwB0BhVko0O9rWymwHVkiLIWV+qxiMyrzyV SgkaZBM5wrZdEFtXlXBd5J/C3GKDhySwwYqxij72J4I1iWBuOPAN71VqkcSSUiH4i2Gm 7y0ZE77rYWbnx/6qhY4dasdY9B0UA4BFp7Bi4SXXpsfzgAl5cXK8ha3FhuDTOspDKJV/ QvRc7qvyX+pfPO3xYG0llUj1TlFegFGr2FDf0kiCDRhlvMi5vqWA+2U5CEioCkeEAIZv I3/tEYr9whbJecBbtoMxeZxcQTwtHqJ0V3ixaFsou3sL3GMWlNIXnKRm7dHYHEaG+kDQ sM+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=e1tq342ubv5rRPNyw8T8ymxR0xgl12zP2KhNw/XNRIA=; b=NcEBvB5i3TUYhQCkIufXEx8Jq8k4TgtU65CwSTRT3/CttEXRm0NMIyCZ6NMArO0khP IzX+KSEQspC36FIG+f3QtktQ67pnRj+V+eBAtNTW3Pg08tN7226+Drkdjp66B9Zm9r9M ZsRWRmu7IlSYnaFc9N1ufWxRpktHLJpf9X+tqAB83n2SV5qgUjeQVMdXT4hXtkfbVzxU nKi8r8zqRxhZ3Re7LghoYtBVEmkJenUCt6kZrqg0TkgNJQxfiNla87rO/q0oUKx9+lPG 4kdnbCRsC3bZgi6Y+nyRoQRSkncR9bJK4gHTsF3Dgm3sgqh144wfFwdS1zYeqcQTqdSq tHtA== X-Gm-Message-State: AEkooutG6Vp/yEdyciJadQrbgEiyhvqFOw5gpoSh42V1YOzm3p4Q2TPqAlKtuVk9+i7J0/c6 X-Received: by 10.55.154.22 with SMTP id c22mr11709605qke.36.1470932549390; Thu, 11 Aug 2016 09:22:29 -0700 (PDT) Received: from [192.168.1.49] ([191.115.111.163]) by smtp.gmail.com with ESMTPSA id n128sm633698qkc.36.2016.08.11.09.22.26 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 11 Aug 2016 09:22:28 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_8C359FC9-5C5D-4DBD-955B-35D9C5A0C379" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: John Bradley In-Reply-To: Date: Thu, 11 Aug 2016 12:22:24 -0400 Message-Id: <56E7DF06-EE77-4FD1-BF44-15A083AC5B5A@ve7jtb.com> References: <14E2EF51-7123-4E91-87DD-56AEA08202C1@oracle.com> <3F0DD3E6-46CD-4AA5-8F06-F79140F5D4BE@oracle.com> To: "Phil Hunt (IDM)" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Michael Jones , "openid-specs-ab@lists.openid.net Ab" , "id-event@ietf.org" , Marius Scurtescu Subject: Re: [Id-event] Summarizing recent discussions on ID-Event token draft X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 11 Aug 2016 16:22:34 -0000 --Apple-Mail=_8C359FC9-5C5D-4DBD-955B-35D9C5A0C379 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Not surprisingly a multipurpose message format will not be as optimized = as a single purpose one. Connect itself doesn=E2=80=99t really have a conflict around issuer the = same entity sending the logout message is always the one that created = the id_token that it refers to. Using the same format as id_token with the same semantics to identify = the thing to be terminated makes sense from a purely openID Connect = point of view. Oter messages that have different notions of subject and are issued by = different parties than the one that controls the subject cause issues = when you try and fit them into the same format as an ID_Token, I grant = you that. It was mentioned that we need to differentiate between these events and = id_tokens. Mostly we need to do that in cases where the token might be = presented in the front channel. To do that se do have mandatory claims for nonce and c_hash or at_hash = as well as the addition of events parameter to reduce confusion. Now I = admit that some people may still get that wrong, and the removal of sub = from the top level would remove any concern. However Mike has a point = that adoption may be hurt if we change the semantics too much. I don=E2=80=99t see backchannel single logout being used by many social = login RP, it is a lot of work to maintain server side state. It is = mostly an enterprise and large site sort of feature. That may or may not impact on if it is better to be simple and aligned = with connect=E2=80=99s id token or more general purpose to fit with = other enterprise to SaaS features like SCIM events. I think the two directions lead to different formats. =20 The compromise of special casing Connect SLO and bodging the formats = together is probably the worst option. John B. > On Aug 11, 2016, at 11:59 AM, Phil Hunt (IDM) = wrote: >=20 > How do you resolve conflicts on iss then? The top level has to be the = issuer of the event as the issuer signs.=20 >=20 > If one spec can use it all must be able to. I believe you previously = objected to that saying sub must be as how id tokens define them. But = that isnt unique and requires iss. Now we would have sub at the top with = an event issuer at the top and a sub issuer in the extension. That seems = incredibly complex not to mention awkward.=20 >=20 > If we make sub a uri for all then it can work ass iss from id token = would not be needed. But i can see many objecting to the change in = format.=20 >=20 > Why not have a logout be an event with an id token attached for = example? >=20 > Phil >=20 > On Aug 11, 2016, at 8:03 AM, Mike Jones > wrote: >=20 >> The simple rule is that if the particular event calls for the = =E2=80=9Csub=E2=80=9D claim to be at the top level, then it is. This is = no different from any other claim that an event might place at the top = level. >> =20 >> The complexity arises if =E2=80=9Csub=E2=80=9D is unnecessarily = special-cased. We shouldn=E2=80=99t do that, because it limits the = applicability of the specification. >> =20 >> -- Mike >> =C2=A0 <> >> From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com = ]=20 >> Sent: Thursday, August 11, 2016 9:40 AM >> To: Mike Jones > >> Cc: Marius Scurtescu >; id-event@ietf.org = >> Subject: Re: [Id-event] Summarizing recent discussions on ID-Event = token draft >> =20 >> I think using sub at the top level leads to complexity. Eg Can you = provide a rule for when top level is used or not by an individual spec? = IMO. Top level should always be used the same way by all implementers.=20= >> =20 >> Based on the calls at risc/connect, we discussed that it would be = best to move all event specifics to the event object area. This way = different events can have different event addressing (eg sub/iss, uri, = jit/iss). When iss is needed to uniquely qualify a sub, it can be = provided without conflicting with the issuer of the event. Similarly jti = and iss can be used for a revoked token without conflicting with the = event jti.=20 >> =20 >> I plan to post a new draft shortly that will give some examples based = on feedback from the openid risc/connect discussions. >> =20 >> We can always change again.=20 >>=20 >> Phil >>=20 >> On Aug 11, 2016, at 4:54 AM, Mike Jones > wrote: >>=20 >> No, I=E2=80=99m not saying that =E2=80=9Csub=E2=80=9D cannot appear = at the top level. I=E2=80=99m saying that =E2=80=9Csub=E2=80=9D will = only occur at the top level if the particular event defines that = =E2=80=9Csub=E2=80=9D is used in that way for that event. >> =20 >> There are probably use cases for multiple events per message but I = doubt there are use cases for multiple *unrelated* events per message. = By definition, related events that use top-level claims would need to = use them in a compatible way. I don=E2=80=99t see that as being a = problem. >> =20 >> That being said, the predominant use case is likely to be a single = event per JWT. >> =20 >> = -- Mike >> =20 >> From: Marius Scurtescu [mailto:mscurtescu@google.com = ]=20 >> Sent: Tuesday, August 9, 2016 7:15 PM >> To: Phil Hunt > >> Cc: Mike Jones >; id-event@ietf.org = >> Subject: Re: [Id-event] Summarizing recent discussions on ID-Event = token draft >> =20 >> Mike, are you suggesting that a sub claim can only show up at the = event level and not at the top level: >> =20 >> In particular, the only thing that the spec should say about the = =E2=80=9Csub=E2=80=9D claim is that =E2=80=9CLike all other claims other = than =E2=80=98events=E2=80=99 and =E2=80=98iss=E2=80=99, whether the = =E2=80=98sub=E2=80=99 claim is to be included with an event is entirely = event-specific. >> =20 >> A top level sub and multiple events are incompatible IMO. >> =20 >> Do we have a compelling reason to support multiple events per = message? >> =20 >>=20 >> Marius >> =20 >> On Tue, Aug 9, 2016 at 12:39 PM, Phil Hunt > wrote: >> I was referring to this in your email >> "Define that an event name can be used as a top-level claim=E2=80=9D >> =20 >> =20 >> Is this different from the event uri? >> =20 >> Phil >> =20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> =20 >> =20 >> =20 >>=20 >> =20 >> On Aug 9, 2016, at 12:12 PM, Mike Jones > wrote: >> =20 >> I=E2=80=99m glad to hear that we agree on keeping it as simple and = general-purpose as possible and that you agree with my write-up. I = think we then have a good path forward. >> =20 >> I=E2=80=99m not sure what you mean by =E2=80=9CI=E2=80=99m not sure = that we need a =E2=80=9Cname=E2=80=9D. What is your intention there.=E2=80= =9D The only place I used the word =E2=80=9Cname=E2=80=9D was in my = statement =E2=80=9CDefine that an event name can be used as a top-level = claim=E2=80=9D. What I was trying to get at is was that if = =E2=80=9Chttp://specs.openid.net/logout = =E2=80=9D is used as an event name, that = it can also be used as a claim name in the JWT containing information = about the event. (Maybe I=E2=80=99m not using the correct terminology, = hence the unintended confusion J.) >> =20 >> Thanks again, >> -- Mike >> =C2=A0 <> >> From: Phil Hunt [mailto:phil.hunt@oracle.com = ]=20 >> Sent: Tuesday, August 9, 2016 12:07 PM >> To: Mike Jones > >> Cc: id-event@ietf.org >> Subject: Re: [Id-event] Summarizing recent discussions on ID-Event = token draft >> =20 >> I didn=E2=80=99t cover this as I didn=E2=80=99t want to confuse = people with too many things. >> =20 >> But I think we agree on all of the below. >> =20 >> I=E2=80=99m not sure that we need a =E2=80=9Cname=E2=80=9D. What is = your intention there. >> =20 >> Phil >> =20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> =20 >> =20 >> =20 >>=20 >> =20 >> On Aug 9, 2016, at 11:54 AM, Mike Jones > wrote: >> =20 >> Thanks for writing this, Phil. Unfortunately, the summary below does = not include my feedback, which at the essence, is to keep the ID Events = data structure as simple and general-purpose as possible. (I strongly = believe that JWT is the success it is because we made JWT as simple and = general-purpose as possible, and we should follow this successful = example and do the same here.) >> =20 >> I believe that the ID Events spec needs to include these things, and = these things only: >> =C2=B7 Define of the =E2=80=9Cevents=E2=80=9D claim >> =C2=B7 Define that an event name can be used as a top-level = claim >> =C2=B7 Require that =E2=80=9Ciss=E2=80=9D be included and that = the JWT be signed by the issuer >> =C2=B7 Include a statement along the lines of =E2=80=9CThe = claims to be included with any particular event are to be defined by the = event=E2=80=9D >> =20 >> And I=E2=80=99d stop there. >> =20 >> It should be entirely up to applications to say what claims are = included with events they define and what their format and meanings are. = Then the ID Events spec will be as general-purpose as possible, with it = being natural for it to be used in essentially all JSON Event contexts. >> =20 >> As soon as we start putting restrictions on the use of particular = claims by events, we=E2=80=99re making the ID Events spec less = general-purpose and less natural to use. In particular, the only thing = that the spec should say about the =E2=80=9Csub=E2=80=9D claim is that = =E2=80=9CLike all other claims other than =E2=80=98events=E2=80=99 and = =E2=80=98iss=E2=80=99, whether the =E2=80=98sub=E2=80=99 claim is to be = included with an event is entirely event-specific. The claims to be = included with any particular event are explicitly outside the scope of = this specification.=E2=80=9D >> =20 >> -- Mike >> =20 >> From: Id-event [mailto:id-event-bounces@ietf.org = ] On Behalf Of Phil Hunt >> Sent: Tuesday, August 9, 2016 10:19 AM >> To: id-event@ietf.org >> Subject: [Id-event] Summarizing recent discussions on ID-Event token = draft >> =20 >> I thought I would update the list on some discussions that have been = happening over in the OpenID Connect and RISC working groups conference = calls. >> =20 >> These discussions have been about the core spec and the role of = =E2=80=9Ctop-level=E2=80=9D attributes vs. event =E2=80=9Cextension=E2=80=9D= attributes.=20 >> See: https://tools.ietf.org/html/draft-hunt-idevent-token-01 = >> =20 >> In particular should =E2=80=9Csub=E2=80=9D be used in the top level = to =E2=80=9Cpoint=E2=80=9D to the subject (in the broader english sense) = of the event, or should it be constrained to the SAML/ID Token = definition which is the authenticated user. =20 >> =20 >> Taken in the narrower definition, it is important to observe that in = an ID Token, =E2=80=9Csub=E2=80=9D and =E2=80=9Ciss=E2=80=9D go = together. The issuer provides the context for the authenticated subject = identifier. The problem with events, is that it might not be the AS (or = OP) which is issuing the event. =20 >> =20 >> To summarize a fair amount of discussion, the feeling seems to be the = following: >> =20 >> * The Event Token top level attributes should be fairly limited and = not include the sub attribute. =20 >> * For events that are about a user, the relevant event specification = may include a =E2=80=9Csub=E2=80=9D attribute within the event=E2=80=99s = sub-object and not in the top-level. Further that sub-object can also = include the issuer of the user. =20 >> * The top-level =E2=80=9Ciss=E2=80=9D shall mean the issuer of the = event where the state change occurred. >> * =E2=80=9Csub=E2=80=9D should not be present in the top level = structure. Also, =E2=80=9Cevents=E2=80=9D must also be present. >> =20 >> Here would be a new example logout: >> { >> <=E2=80=94 top level is about the event itself -> >> "iss": "https://server.example.com ", >> "aud": "s6BhdRkqt3", >> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >> "iat": 1458668180, >> "exp": 1458668580, >> "events": [ >> "https://specs.openid.net/logout = " >> ], >> "https://specs.openid.net/logout = ": { >> <- This level is defined entirely by the event URI-> >> "iss": "https://oidc.example.com ", >> =E2=80=9Cjti": "08a5019c-17e1-4977-8f42-65a12843ea02=E2=80=9D, >> "sub": "248289761001=E2=80=9D, >> =E2=80=9Cexp=E2=80=9D: >> } >> } >> =20 >> In the above example note that the =E2=80=9Cevent=E2=80=9D object can = have its own iss and subject (sub or jti) that have meaning within the = context of an OpenID OP provider. The issuer of the event can be = different (the top-level) and represents the entity that signs the event = (if it is signed). >> =20 >> The top-level attributes identify an individual event and are used to = validate the event (signing etc). Where as the nested object contains = all of the data about the event and is defined by the profiling = specification (e.g. a possible OpenID Logout Event spec). In this case, = in OpenID, logging out usually translates into revoking an ID Token. = Thus the =E2=80=9Cjti=E2=80=9D for the ID token (08a5019c...843ea02) is = included in the Logout object. >> =20 >> Side note. Regarding =E2=80=9Clogout=E2=80=9D, it might be useful to = include the expiry of the ID Token in case the subscriber has not yet = received an ID Token. This would let the subscriber know how long it = needs to keep the revocation information for. IOW=E2=80=A6after the the = ID Token is expired, the subscriber would no longer need to track the = revocation state. >> =20 >> It is also good to observe that the =E2=80=9Caud=E2=80=9D at the top = level describes the subscriber of the event. This may also be different = then the original audience of the ID Token. >> =20 >> So to conclude. By making top-level attributes strictly about the = events own validation, and nested objects about the event, we avoid = collisions in definitions such as the issuer of the event, vs. the = original issuer of a security assertion. >> =20 >> I hope I=E2=80=99ve gotten everyone=E2=80=99s feedback correct here. = Lets continue to discuss. I will revise the draft to follow the groups = thinking here. >> =20 >> Phil >> =20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> =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://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=_8C359FC9-5C5D-4DBD-955B-35D9C5A0C379 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Not surprisingly a multipurpose message format will not be as = optimized as a single purpose one.

Connect itself doesn=E2=80=99t really = have a conflict around issuer the same entity sending the logout message = is always the one that created the id_token that it refers to.

Using the same format as = id_token with the same semantics to identify the thing to be terminated = makes sense from a purely openID Connect point of view.

Oter messages that have = different notions of subject and are issued by different parties than = the one that controls the subject cause issues when you try and fit them = into the same format as an ID_Token, I grant you that.

It was mentioned that we = need to differentiate between these events and id_tokens.  Mostly = we need to do that in cases where the token might be presented in the = front channel.

To do that se do have mandatory claims for nonce and c_hash = or at_hash as well as the addition of events parameter to reduce = confusion.   Now I admit that some people may still get that wrong, =  and the removal of sub from the top level would remove any = concern.  However Mike has a point that adoption may be hurt if we = change the semantics too much.

I don=E2=80=99t see backchannel single = logout being used by many social login RP, it is a lot of work to = maintain server side state.   It is mostly an enterprise and large = site sort of feature.
That may or may not impact on = if it is better to be simple and aligned with connect=E2=80=99s id token = or more general purpose to fit with other enterprise to SaaS features = like SCIM events.

I think the two directions lead to different formats. =   

The= compromise of special casing Connect SLO and bodging the formats = together is probably the worst option.

John B.


On Aug 11, 2016, at 11:59 AM, = Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:

How do you resolve conflicts = on iss then?  The top level has to be the issuer of the event as = the issuer signs. 

If one spec can use it all must be able to. I believe you = previously objected to that saying sub must be as how id tokens define = them. But that isnt unique and requires iss. Now we would have sub at = the top with an event issuer at the top and a sub issuer in the = extension. That seems incredibly complex not to mention = awkward. 

If we = make sub a uri for all then it can work ass iss from id token would not = be needed. But i can see many objecting to the change in = format. 

Why not = have a logout be an event with an id token attached for = example?

Phil

On Aug 11, 2016, at 8:03 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

The simple rule is that if the particular = event calls for the =E2=80=9Csub=E2=80=9D claim to be at the top level, = then it is.  This is no different from any other claim that an = event might place at the top level.
 
The complexity arises if = =E2=80=9Csub=E2=80=9D is unnecessarily special-cased.  We = shouldn=E2=80=99t do that, because it limits the applicability of the = specification.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;       -- Mike
 
From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com] 
Sent: Thursday, August 11, 2016 = 9:40 AM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: Marius Scurtescu <mscurtescu@google.com>; id-event@ietf.org
Subject: Re: [Id-event] Summarizing = recent discussions on ID-Event token draft
 
I think using sub at the top level leads = to complexity. Eg Can you provide a rule for when top level is used or = not by an individual spec?  IMO. Top level should always be used = the same way by all implementers. 
 
Based on the calls at risc/connect, we = discussed that it would be best to move all event specifics to the event = object area. This way different events can have different event = addressing (eg sub/iss, uri, jit/iss). When iss is needed to uniquely = qualify a sub, it can be provided without conflicting with the issuer of = the event. Similarly jti and iss can be used for a revoked token without = conflicting with the event jti. 
 
I plan to post a new draft shortly that = will give some examples based on feedback from the openid risc/connect = discussions.
 
We can always change again. 

Phil


On= Aug 11, 2016, at 4:54 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

No, I=E2=80=99m not = saying that =E2=80=9Csub=E2=80=9D cannot appear at the top level.  = I=E2=80=99m saying that =E2=80=9Csub=E2=80=9D will only occur at the top = level if the particular event defines that =E2=80=9Csub=E2=80=9D is used = in that way for that event.
 
There are probably use = cases for multiple events per message but I doubt there are use cases = for multiple *unrelated* events per message.  By = definition, related events that use top-level claims would need to use = them in a compatible way.  I don=E2=80=99t see that as being a = problem.
 
That being said, the predominant use case is = likely to be a single event per JWT.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;         -- Mike
 
From: Marius = Scurtescu [mailto:mscurtescu@google.com] 
Sent: Tuesday, August 9, 2016 = 7:15 PM
To: Phil Hunt <phil.hunt@oracle.com>
Cc: Mike Jones <Michael.Jones@microsoft.com>; id-event@ietf.org
Subject: Re: [Id-event] Summarizing = recent discussions on ID-Event token draft
 
Mike, are you suggesting that a sub claim = can only show up at the event level and not at the top level:
 
In = particular, the only thing that the spec should say about the =E2=80=9Csub= =E2=80=9D claim is that =E2=80=9CLike all other claims other than = =E2=80=98events=E2=80=99 and =E2=80=98iss=E2=80=99, whether the = =E2=80=98sub=E2=80=99 claim is to be included with an event is entirely = event-specific.
 
A top level sub and multiple events are incompatible IMO.
 
Do we have a compelling reason to support = multiple events per message?
 

Marius
 
On Tue, Aug 9, 2016 at 12:39 PM, Phil = Hunt <phil.hunt@oracle.com> wrote:
I was referring to = this in your email
"Define that an event name can be used as a top-level = claim=E2=80=9D
 
 
Is this different from the event uri?
 
Phil
 
@independentid
 
 

 

 
On Aug 9, 2016, at = 12:12 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
 
I=E2=80=99m glad to hear that we agree on = keeping it as simple and general-purpose as possible and that you agree = with my write-up.  I think we then have a good path = forward.
 
I=E2=80=99m not sure what you mean by = =E2=80=9CI=E2=80=99m not sure that we need a =E2=80=9Cname=E2=80=9D= . What is your intention there.=E2=80=9D  The only place I used the word =E2=80=9Cname=E2= =80=9D was in my statement =E2=80=9CDefine that an event name can be = used as a top-level claim=E2=80=9D.  What I was trying to get at is = was that if =E2=80=9Chttp://specs.openid.net/logout=E2=80=9D is used as = an event name, that it can also be used as a claim name in the JWT = containing information about the event.  (Maybe I=E2=80=99m not = using the correct terminology, hence the unintended confusion <= span style=3D"font-size: 11pt; font-family: Wingdings; color: rgb(0, 32, = 96);" class=3D"">J.)
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;       Thanks again,
          &nb= sp;            = ;            &= nbsp;           &nb= sp;       -- Mike
From: Phil Hunt [mailto:phil.hunt@oracle.com] 
Sent: Tuesday,= August 9, 2016 12:07 PM
To: Mike = Jones <Michael.Jones@microsoft.com>
Cc: id-event@ietf.org
Subject: Re: = [Id-event] Summarizing recent discussions on ID-Event token = draft
 
I didn=E2=80=99t cover this as I didn=E2=80= =99t want to confuse people with too many things.
 
But I think we agree on all of the = below.
 
I=E2=80=99m not sure that we need a = =E2=80=9Cname=E2=80=9D. What is your intention there.
 
Phil
 
@independentid
www.independentid.com
phil.hunt@oracle.com
 
 

 

 
On = Aug 9, 2016, at 11:54 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:
 
Thanks for writing this, = Phil.  Unfortunately, the summary below does not include my = feedback, which at the essence, is to keep the ID Events data structure = as simple and general-purpose as possible.  (I strongly believe = that JWT is the success it is because we made JWT as simple and = general-purpose as possible, and we should follow this successful = example and do the same here.)
 
I believe that the ID Events spec needs to = include these things, and these things only:
=C2=B7       <= span style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: = rgb(0, 32, 96);" class=3D"">Define of the =E2=80=9Cevents=E2=80=9D = claim
=C2=B7       <= span style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: = rgb(0, 32, 96);" class=3D"">Define that an event name can be used as a = top-level claim
=C2=B7       <= span style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: = rgb(0, 32, 96);" class=3D"">Require that =E2=80=9Ciss=E2=80=9D be = included and that the JWT be signed by the issuer
=C2=B7       <= span style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: = rgb(0, 32, 96);" class=3D"">Include a statement along the lines of = =E2=80=9CThe claims to be included with any particular event are to be = defined by the event=E2=80=9D
 
And I=E2=80=99d stop there.
 
It should be entirely up to applications to = say what claims are included with events they define and what their = format and meanings are.  Then the ID Events spec will be as = general-purpose as possible, with it being natural for it to be used in = essentially all JSON Event contexts.
 
As soon as we start putting restrictions on = the use of particular claims by events, we=E2=80=99re making the ID = Events spec less general-purpose and less natural to use.  In = particular, the only thing that the spec should say about the =E2=80=9Csub= =E2=80=9D claim is that =E2=80=9CLike all other claims other than = =E2=80=98events=E2=80=99 and =E2=80=98iss=E2=80=99, whether the = =E2=80=98sub=E2=80=99 claim is to be included with an event is entirely = event-specific.  The claims to be included with any particular = event are explicitly outside the scope of this = specification.=E2=80=9D
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;       -- Mike
 
From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Phil= Hunt
Sent: Tuesday,= August 9, 2016 10:19 AM
To: id-event@ietf.org
Subject: [Id-even= t] Summarizing recent discussions on ID-Event token draft
 
I thought I would update the list on some = discussions that have been happening over in the OpenID Connect and RISC = working groups conference calls.
 
These = discussions have been about the core spec and the role of = =E2=80=9Ctop-level=E2=80=9D attributes vs. event =E2=80=9Cextension=E2=80=9D= attributes. 
* =  For events that are about a user, the relevant event specification = may include a =E2=80=9Csub=E2=80=9D attribute within the event=E2=80=99s = sub-object and not in the top-level. Further that sub-object can also = include the issuer of the user.  
* = The top-level =E2=80=9Ciss=E2=80=9D shall mean the issuer of the event = where the state change occurred.
* =  =E2=80=9Csub=E2=80=9D should not be present in the top level = structure.  Also, =E2=80=9Cevents=E2=80=9D must also be = present.
 
{
  <=E2=80=94 top level is about the =
event itself ->
  "iss": "https://server.example.com",
  "aud": =
"s6BhdRkqt3",
  =
"jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
  "iat": =
1458668180,
  =
"exp": 1458668580,
  =
"events": [
    "https://specs.openid.net/logout"
  ],
  "https://specs.openid.net/logout": =
{
    <- =
This level is defined entirely by the event URI->
    "iss": =
"https://oidc.example.com",
    =
=E2=80=9Cjti": "08a5019c-17e1-4977-8f42-65a12843ea02=E2=80=9D,
    "sub": "248289761001=E2=80=9D,
    =E2=80=9Cexp=E2=80=9D: <ID token =
expiry>
  }
}
 
In the above example note that the =E2=80=9Cevent=E2=80=9D = object can have its own iss and subject (sub or jti) that have meaning = within the context of an OpenID OP provider.  The issuer of the = event can be different (the top-level) and represents the entity that = signs the event (if it is signed).
 
The top-level attributes identify an individual event and are = used to validate the event (signing etc).  Where as the nested = object contains all of the data about the event and is defined by the = profiling specification (e.g. a possible OpenID Logout Event = spec).  In this case, in OpenID, logging out usually translates = into revoking an ID Token. Thus the =E2=80=9Cjti=E2=80=9D for the ID = token (08a5019c...843ea02) is included in the Logout object.
 
Side note.  Regarding =E2=80=9Clogout=E2=80=9D, it might = be useful to include the expiry of the ID Token in case the subscriber = has not yet received an ID Token. This would let the subscriber know how = long it needs to keep the revocation information for.  IOW=E2=80=A6af= ter the the ID Token is expired, the subscriber would no longer need to = track the revocation state.
 
It is also good to observe that the =E2=80=9Caud=E2=80=9D at = the top level describes the subscriber of the event.  This may also = be different then the original audience of the ID Token.
 
So to conclude. By making top-level attributes strictly about = the events own validation, and nested objects about the event, we avoid = collisions in definitions such as the issuer of the event, vs. the = original issuer of a security assertion.
 
I hope I=E2=80=99ve gotten everyone=E2=80=99s feedback = correct here. Lets continue to discuss. I will revise the draft to = follow the groups thinking here.
 
Phil
 
@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

 
_______________________________________________
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=_8C359FC9-5C5D-4DBD-955B-35D9C5A0C379-- From nobody Thu Aug 11 09:32:52 2016 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 8380312D7EB for ; Thu, 11 Aug 2016 09:32:50 -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 pVp6eqxOUPpc for ; Thu, 11 Aug 2016 09:32:47 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0138.outbound.protection.outlook.com [104.47.32.138]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B097126D74 for ; Thu, 11 Aug 2016 09:32:46 -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=kZ/NaKwE24RRhPZl4m5MxhqRRLhvNMGAx6gXkXb3TzM=; b=D7VSClDAQgbt6SmehzTIYphZIkCRnlS7UYWcCJf8ZbIUYNdSB4znHHDf79825rOwAkgfBj28zO9CSrUm7ph1TLOEwfRy7XB9A9m9tTL9oFbzi7v/WzKn0Kf0C8Odt0k3IYWPKTOR19XiXLdTeXH1zc5dBaIKdNeZ4dzLP6/JG0I= Received: from SN1PR0301MB1645.namprd03.prod.outlook.com (10.162.130.139) by SN1PR0301MB1645.namprd03.prod.outlook.com (10.162.130.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Thu, 11 Aug 2016 16:32:42 +0000 Received: from SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) by SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) with mapi id 15.01.0549.025; Thu, 11 Aug 2016 16:32:42 +0000 From: Mike Jones To: John Bradley , "Phil Hunt (IDM)" Thread-Topic: [Id-event] Summarizing recent discussions on ID-Event token draft Thread-Index: AQHR8mIWLvqeOEkcuEuQk5SeT4z/pKBA9pTwgAAG/gCAAABNAIAACP2AgAA8CICAAmTu0IAAHwwAgAAWu7CAABBwgIAABkgAgAAA3UA= Date: Thu, 11 Aug 2016 16:32:42 +0000 Message-ID: References: <14E2EF51-7123-4E91-87DD-56AEA08202C1@oracle.com> <3F0DD3E6-46CD-4AA5-8F06-F79140F5D4BE@oracle.com> <56E7DF06-EE77-4FD1-BF44-15A083AC5B5A@ve7jtb.com> In-Reply-To: <56E7DF06-EE77-4FD1-BF44-15A083AC5B5A@ve7jtb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.201.94.142] x-ms-office365-filtering-correlation-id: ab80eff6-ad0e-47c4-e7bc-08d3c2051e3d x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1645; 6:2KuwjRhJrdFyhEFDp9jfUU64rBgZ8niRaO6NvE9RVAk9QGVSuK78KzcU/iL2dpi20yvUu4I9Am4SceAqvH9NFWgrVPo+U+ZX4dDcbl1V5s4/OdPeQu8RJ3qU74jqY/SxqEFUEKEQRfwWYIOxha6uQEjlxOQya3an7tZG8wAjBJVGZf1rItBDFK6BJ0z2tQZccMCdAyZCLf7CKRvtrqyof0nveUT5269oitfjy4GYgKcQ+c57WKGFdvvWGEykg2dU9vnHNffMaaXxOjXg8Jq5rjj4y/8vOnzgecNDnNakdZlLGyCpu5GjkHzA+cPF4dG0JGugFSWPW1FOfANsrfsKNQ==; 5:PqjKAmYXy1s+u57XTpU64kqVAaODXVy1rsiMq4L7tKAauyQLyXxvPxKMyRcADHyI2bp6bQAH6TgpvNMX26fR5VAEk8HBnTaVYwyDZAUW3KC7XW7EX6DNU7qlH71Tw2RtWIAoQpO+4KniNeUm/lB9/w==; 24:j9T+lJKKaDmv0AoWr0+bdqkK6FcFwizEmX/0jLcxUWex2Mfg+Mko4tMhwEFTwI1BWFHDg0h2i8Q2ORMAF4Mhb+QoDRXHkA3MtRptjkZlSlE=; 7:XO4NA3w0Ze9vmR6NO7QgAzijIyZt2hsypZqIRYNmQvnWT7ZsBsLD59qUFWcReyIrC30JulpiLxfOdZwhCuCZbA0o10vjtSXGrv6eSoigvPXZowf6fUQV6/rgnNQj09ZF3V5+5qSZBi9OH1BdxH9jUurMtLNUgzKiXcvwTrWCwkl3SDwsS3XYch6HvX69Ua9tTnKYEFVOjLvb56qurqtbwj5hTfqlyOgThTMHHWriQpP2mYlSmZQBO/HqAO1ONeZS x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1645; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(278428928389397)(192374486261705)(211936372134217)(21748063052155)(21532816269658)(146099531331640); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040171)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:SN1PR0301MB1645; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1645; x-forefront-prvs: 0031A0FFAF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(43784003)(24454002)(199003)(377454003)(189998001)(10290500002)(8990500004)(5005710100001)(5890100001)(10400500002)(11100500001)(10090500001)(66066001)(68736007)(575784001)(8676002)(81156014)(122556002)(3280700002)(7736002)(4326007)(7846002)(3660700001)(81166006)(93886004)(87936001)(105586002)(9686002)(7696003)(7906003)(8936002)(86362001)(74316002)(5002640100001)(99286002)(19625215002)(19580405001)(19580395003)(19609705001)(33656002)(2906002)(2900100001)(97736004)(5001770100001)(1860700003)(106116001)(76576001)(19300405004)(16236675004)(19617315012)(101416001)(3846002)(15975445007)(77096005)(6116002)(790700001)(102836003)(92566002)(586003)(86612001)(2950100001)(50986999)(54356999)(106356001)(76176999)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0301MB1645; H:SN1PR0301MB1645.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB16459867074BFA03B5C401E4F51E0SN1PR0301MB1645_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Aug 2016 16:32:42.6439 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1645 Archived-At: Cc: "openid-specs-ab@lists.openid.net Ab" , "id-event@ietf.org" , Marius Scurtescu Subject: Re: [Id-event] Summarizing recent discussions on ID-Event token draft X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 11 Aug 2016 16:32:51 -0000 --_000_SN1PR0301MB16459867074BFA03B5C401E4F51E0SN1PR0301MB1645_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U2VlIG15IHByZXZpb3VzIG1lc3NhZ2UsIEpvaG4sIHdoaWNoIHdhcyBhIHJlcGx5IHRvIFBoaWzi gJlzIG1lc3NhZ2UgdGhhdCB5b3UgYWxzbyByZXBsaWVkIHRvLCB0aGF0IGNvbnRhaW5lZCBhIGxv Z291dCBjbGFpbXMgZXhhbXBsZS4gIEnigJltIG5vdCBwcm9wb3NpbmcgdG8gc3BlY2lhbC1jYXNl IHRoZSBDb25uZWN0IExvZ291dCBtZXNzYWdlIGluIGFueSB3YXkuICBUaGUg4oCcaXNz4oCdIGlz IHRoZSBldmVudCBpc3N1ZXIuICBUaGUgb3RoZXIgY2xhaW1zIGluIHRoZSBtZXNzYWdlIGFyZSB0 aG9zZSBkZWZpbmVkIGJ5IHRoZSBldmVudCB0byBiZSBpbmNsdWRlZCwganVzdCBsaWtlIHRob3Nl IGZvciBhbnkgb3RoZXIgZXZlbnQuICBZZXMsIHRoZSBsb2dvdXQgbWVzc2FnZSBkb2VzbuKAmXQg aW5jbHVkZSBhIHNlY29uZCBpc3N1ZXIsIGEgc2Vjb25kIHN1YmplY3QsIGFuIElEIFRva2VuIGFz IGEgY2xhaW0sIG9yIGFueXRoaW5nIGVsc2UgY29tcGxpY2F0ZWQgbGlrZSB0aGF0LCBiZWNhdXNl IHRob3NlIHRoaW5ncyBhcmVu4oCZdCBuZWVkZWQgZm9yIHRoZSBsb2dvdXQgdXNlIGNhc2UuDQoN CkFzIEnigJlkIHdyaXR0ZW4gcHJldmlvdXNseSwgdGhlIElEIEV2ZW50cyBzcGVjIHNob3VsZCBk ZWZpbmUgdGhlIOKAnGV2ZW50c+KAnSBjbGFpbSwgaG93IHRvIHVzZSBhbiBldmVudCBuYW1lIGFz IGEgY2xhaW0gKHdoZW4gbmVlZGVkKSwgYW5kIHNheSB0aGF0IHRoZSBldmVudCBKV1QgbXVzdCBi ZSBzaWduZWQgYnkgdGhlIGlzc3VlciwgYW5kIHN0b3AgdGhlcmUuICBUcnlpbmcgdG8gbWljcm8t bWFuYWdlIGNsYWltcyB1c2FnZSB3aXRoaW4gYW4gZXZlbnQgd2lsbCBvbmx5IHJlc3VsdCBpbiB0 aGUgSUQgRXZlbnRzIHNwZWMgYmVpbmcgaGFyZGVyIHRvIHVzZS4gIElmIHdl4oCZZCB0cmllZCB0 byBzaW1pbGFybHkgbWljcm8tbWFuYWdlIEpXVCBjbGFpbXMgdXNhZ2UsIEpXVCB3b3VsZCBsaWtl bHkgbm90IGhhdmUgYmVlbiB0aGUgc3VjY2VzcyB0aGF0IGl0IGlzLg0KDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9t OiBKb2huIEJyYWRsZXkgW21haWx0bzp2ZTdqdGJAdmU3anRiLmNvbV0NClNlbnQ6IFRodXJzZGF5 LCBBdWd1c3QgMTEsIDIwMTYgMTI6MjIgUE0NClRvOiBQaGlsIEh1bnQgKElETSkgPHBoaWwuaHVu dEBvcmFjbGUuY29tPg0KQ2M6IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNv bT47IGlkLWV2ZW50QGlldGYub3JnOyBNYXJpdXMgU2N1cnRlc2N1IDxtc2N1cnRlc2N1QGdvb2ds ZS5jb20+OyBvcGVuaWQtc3BlY3MtYWJAbGlzdHMub3BlbmlkLm5ldCBBYiA8b3BlbmlkLXNwZWNz LWFiQGxpc3RzLm9wZW5pZC5uZXQ+DQpTdWJqZWN0OiBSZTogW0lkLWV2ZW50XSBTdW1tYXJpemlu ZyByZWNlbnQgZGlzY3Vzc2lvbnMgb24gSUQtRXZlbnQgdG9rZW4gZHJhZnQNCg0KTm90IHN1cnBy aXNpbmdseSBhIG11bHRpcHVycG9zZSBtZXNzYWdlIGZvcm1hdCB3aWxsIG5vdCBiZSBhcyBvcHRp bWl6ZWQgYXMgYSBzaW5nbGUgcHVycG9zZSBvbmUuDQoNCkNvbm5lY3QgaXRzZWxmIGRvZXNu4oCZ dCByZWFsbHkgaGF2ZSBhIGNvbmZsaWN0IGFyb3VuZCBpc3N1ZXIgdGhlIHNhbWUgZW50aXR5IHNl bmRpbmcgdGhlIGxvZ291dCBtZXNzYWdlIGlzIGFsd2F5cyB0aGUgb25lIHRoYXQgY3JlYXRlZCB0 aGUgaWRfdG9rZW4gdGhhdCBpdCByZWZlcnMgdG8uDQoNClVzaW5nIHRoZSBzYW1lIGZvcm1hdCBh cyBpZF90b2tlbiB3aXRoIHRoZSBzYW1lIHNlbWFudGljcyB0byBpZGVudGlmeSB0aGUgdGhpbmcg dG8gYmUgdGVybWluYXRlZCBtYWtlcyBzZW5zZSBmcm9tIGEgcHVyZWx5IG9wZW5JRCBDb25uZWN0 IHBvaW50IG9mIHZpZXcuDQoNCk90ZXIgbWVzc2FnZXMgdGhhdCBoYXZlIGRpZmZlcmVudCBub3Rp b25zIG9mIHN1YmplY3QgYW5kIGFyZSBpc3N1ZWQgYnkgZGlmZmVyZW50IHBhcnRpZXMgdGhhbiB0 aGUgb25lIHRoYXQgY29udHJvbHMgdGhlIHN1YmplY3QgY2F1c2UgaXNzdWVzIHdoZW4geW91IHRy eSBhbmQgZml0IHRoZW0gaW50byB0aGUgc2FtZSBmb3JtYXQgYXMgYW4gSURfVG9rZW4sIEkgZ3Jh bnQgeW91IHRoYXQuDQoNCkl0IHdhcyBtZW50aW9uZWQgdGhhdCB3ZSBuZWVkIHRvIGRpZmZlcmVu dGlhdGUgYmV0d2VlbiB0aGVzZSBldmVudHMgYW5kIGlkX3Rva2Vucy4gIE1vc3RseSB3ZSBuZWVk IHRvIGRvIHRoYXQgaW4gY2FzZXMgd2hlcmUgdGhlIHRva2VuIG1pZ2h0IGJlIHByZXNlbnRlZCBp biB0aGUgZnJvbnQgY2hhbm5lbC4NCg0KVG8gZG8gdGhhdCBzZSBkbyBoYXZlIG1hbmRhdG9yeSBj bGFpbXMgZm9yIG5vbmNlIGFuZCBjX2hhc2ggb3IgYXRfaGFzaCBhcyB3ZWxsIGFzIHRoZSBhZGRp dGlvbiBvZiBldmVudHMgcGFyYW1ldGVyIHRvIHJlZHVjZSBjb25mdXNpb24uICAgTm93IEkgYWRt aXQgdGhhdCBzb21lIHBlb3BsZSBtYXkgc3RpbGwgZ2V0IHRoYXQgd3JvbmcsICBhbmQgdGhlIHJl bW92YWwgb2Ygc3ViIGZyb20gdGhlIHRvcCBsZXZlbCB3b3VsZCByZW1vdmUgYW55IGNvbmNlcm4u ICBIb3dldmVyIE1pa2UgaGFzIGEgcG9pbnQgdGhhdCBhZG9wdGlvbiBtYXkgYmUgaHVydCBpZiB3 ZSBjaGFuZ2UgdGhlIHNlbWFudGljcyB0b28gbXVjaC4NCg0KSSBkb27igJl0IHNlZSBiYWNrY2hh bm5lbCBzaW5nbGUgbG9nb3V0IGJlaW5nIHVzZWQgYnkgbWFueSBzb2NpYWwgbG9naW4gUlAsIGl0 IGlzIGEgbG90IG9mIHdvcmsgdG8gbWFpbnRhaW4gc2VydmVyIHNpZGUgc3RhdGUuICAgSXQgaXMg bW9zdGx5IGFuIGVudGVycHJpc2UgYW5kIGxhcmdlIHNpdGUgc29ydCBvZiBmZWF0dXJlLg0KVGhh dCBtYXkgb3IgbWF5IG5vdCBpbXBhY3Qgb24gaWYgaXQgaXMgYmV0dGVyIHRvIGJlIHNpbXBsZSBh bmQgYWxpZ25lZCB3aXRoIGNvbm5lY3TigJlzIGlkIHRva2VuIG9yIG1vcmUgZ2VuZXJhbCBwdXJw b3NlIHRvIGZpdCB3aXRoIG90aGVyIGVudGVycHJpc2UgdG8gU2FhUyBmZWF0dXJlcyBsaWtlIFND SU0gZXZlbnRzLg0KDQpJIHRoaW5rIHRoZSB0d28gZGlyZWN0aW9ucyBsZWFkIHRvIGRpZmZlcmVu dCBmb3JtYXRzLg0KDQpUaGUgY29tcHJvbWlzZSBvZiBzcGVjaWFsIGNhc2luZyBDb25uZWN0IFNM TyBhbmQgYm9kZ2luZyB0aGUgZm9ybWF0cyB0b2dldGhlciBpcyBwcm9iYWJseSB0aGUgd29yc3Qg b3B0aW9uLg0KDQpKb2huIEIuDQoNCg0KT24gQXVnIDExLCAyMDE2LCBhdCAxMTo1OSBBTSwgUGhp bCBIdW50IChJRE0pIDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNs ZS5jb20+PiB3cm90ZToNCg0KSG93IGRvIHlvdSByZXNvbHZlIGNvbmZsaWN0cyBvbiBpc3MgdGhl bj8gIFRoZSB0b3AgbGV2ZWwgaGFzIHRvIGJlIHRoZSBpc3N1ZXIgb2YgdGhlIGV2ZW50IGFzIHRo ZSBpc3N1ZXIgc2lnbnMuDQoNCklmIG9uZSBzcGVjIGNhbiB1c2UgaXQgYWxsIG11c3QgYmUgYWJs ZSB0by4gSSBiZWxpZXZlIHlvdSBwcmV2aW91c2x5IG9iamVjdGVkIHRvIHRoYXQgc2F5aW5nIHN1 YiBtdXN0IGJlIGFzIGhvdyBpZCB0b2tlbnMgZGVmaW5lIHRoZW0uIEJ1dCB0aGF0IGlzbnQgdW5p cXVlIGFuZCByZXF1aXJlcyBpc3MuIE5vdyB3ZSB3b3VsZCBoYXZlIHN1YiBhdCB0aGUgdG9wIHdp dGggYW4gZXZlbnQgaXNzdWVyIGF0IHRoZSB0b3AgYW5kIGEgc3ViIGlzc3VlciBpbiB0aGUgZXh0 ZW5zaW9uLiBUaGF0IHNlZW1zIGluY3JlZGlibHkgY29tcGxleCBub3QgdG8gbWVudGlvbiBhd2t3 YXJkLg0KDQpJZiB3ZSBtYWtlIHN1YiBhIHVyaSBmb3IgYWxsIHRoZW4gaXQgY2FuIHdvcmsgYXNz IGlzcyBmcm9tIGlkIHRva2VuIHdvdWxkIG5vdCBiZSBuZWVkZWQuIEJ1dCBpIGNhbiBzZWUgbWFu eSBvYmplY3RpbmcgdG8gdGhlIGNoYW5nZSBpbiBmb3JtYXQuDQoNCldoeSBub3QgaGF2ZSBhIGxv Z291dCBiZSBhbiBldmVudCB3aXRoIGFuIGlkIHRva2VuIGF0dGFjaGVkIGZvciBleGFtcGxlPw0K DQpQaGlsDQoNCk9uIEF1ZyAxMSwgMjAxNiwgYXQgODowMyBBTSwgTWlrZSBKb25lcyA8TWljaGFl bC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+ PiB3cm90ZToNClRoZSBzaW1wbGUgcnVsZSBpcyB0aGF0IGlmIHRoZSBwYXJ0aWN1bGFyIGV2ZW50 IGNhbGxzIGZvciB0aGUg4oCcc3Vi4oCdIGNsYWltIHRvIGJlIGF0IHRoZSB0b3AgbGV2ZWwsIHRo ZW4gaXQgaXMuICBUaGlzIGlzIG5vIGRpZmZlcmVudCBmcm9tIGFueSBvdGhlciBjbGFpbSB0aGF0 IGFuIGV2ZW50IG1pZ2h0IHBsYWNlIGF0IHRoZSB0b3AgbGV2ZWwuDQoNClRoZSBjb21wbGV4aXR5 IGFyaXNlcyBpZiDigJxzdWLigJ0gaXMgdW5uZWNlc3NhcmlseSBzcGVjaWFsLWNhc2VkLiAgV2Ug c2hvdWxkbuKAmXQgZG8gdGhhdCwgYmVjYXVzZSBpdCBsaW1pdHMgdGhlIGFwcGxpY2FiaWxpdHkg b2YgdGhlIHNwZWNpZmljYXRpb24uDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IFBoaWwgSHVudCAoSURNKSBb bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tXQ0KU2VudDogVGh1cnNkYXksIEF1Z3VzdCAxMSwg MjAxNiA5OjQwIEFNDQpUbzogTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29t PG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+Pg0KQ2M6IE1hcml1cyBTY3VydGVz Y3UgPG1zY3VydGVzY3VAZ29vZ2xlLmNvbTxtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tPj47 IGlkLWV2ZW50QGlldGYub3JnPG1haWx0bzppZC1ldmVudEBpZXRmLm9yZz4NClN1YmplY3Q6IFJl OiBbSWQtZXZlbnRdIFN1bW1hcml6aW5nIHJlY2VudCBkaXNjdXNzaW9ucyBvbiBJRC1FdmVudCB0 b2tlbiBkcmFmdA0KDQpJIHRoaW5rIHVzaW5nIHN1YiBhdCB0aGUgdG9wIGxldmVsIGxlYWRzIHRv IGNvbXBsZXhpdHkuIEVnIENhbiB5b3UgcHJvdmlkZSBhIHJ1bGUgZm9yIHdoZW4gdG9wIGxldmVs IGlzIHVzZWQgb3Igbm90IGJ5IGFuIGluZGl2aWR1YWwgc3BlYz8gIElNTy4gVG9wIGxldmVsIHNo b3VsZCBhbHdheXMgYmUgdXNlZCB0aGUgc2FtZSB3YXkgYnkgYWxsIGltcGxlbWVudGVycy4NCg0K QmFzZWQgb24gdGhlIGNhbGxzIGF0IHJpc2MvY29ubmVjdCwgd2UgZGlzY3Vzc2VkIHRoYXQgaXQg d291bGQgYmUgYmVzdCB0byBtb3ZlIGFsbCBldmVudCBzcGVjaWZpY3MgdG8gdGhlIGV2ZW50IG9i amVjdCBhcmVhLiBUaGlzIHdheSBkaWZmZXJlbnQgZXZlbnRzIGNhbiBoYXZlIGRpZmZlcmVudCBl dmVudCBhZGRyZXNzaW5nIChlZyBzdWIvaXNzLCB1cmksIGppdC9pc3MpLiBXaGVuIGlzcyBpcyBu ZWVkZWQgdG8gdW5pcXVlbHkgcXVhbGlmeSBhIHN1YiwgaXQgY2FuIGJlIHByb3ZpZGVkIHdpdGhv dXQgY29uZmxpY3Rpbmcgd2l0aCB0aGUgaXNzdWVyIG9mIHRoZSBldmVudC4gU2ltaWxhcmx5IGp0 aSBhbmQgaXNzIGNhbiBiZSB1c2VkIGZvciBhIHJldm9rZWQgdG9rZW4gd2l0aG91dCBjb25mbGlj dGluZyB3aXRoIHRoZSBldmVudCBqdGkuDQoNCkkgcGxhbiB0byBwb3N0IGEgbmV3IGRyYWZ0IHNo b3J0bHkgdGhhdCB3aWxsIGdpdmUgc29tZSBleGFtcGxlcyBiYXNlZCBvbiBmZWVkYmFjayBmcm9t IHRoZSBvcGVuaWQgcmlzYy9jb25uZWN0IGRpc2N1c3Npb25zLg0KDQpXZSBjYW4gYWx3YXlzIGNo YW5nZSBhZ2Fpbi4NCg0KUGhpbA0KDQpPbiBBdWcgMTEsIDIwMTYsIGF0IDQ6NTQgQU0sIE1pa2Ug Sm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0Bt aWNyb3NvZnQuY29tPj4gd3JvdGU6DQpObywgSeKAmW0gbm90IHNheWluZyB0aGF0IOKAnHN1YuKA nSBjYW5ub3QgYXBwZWFyIGF0IHRoZSB0b3AgbGV2ZWwuICBJ4oCZbSBzYXlpbmcgdGhhdCDigJxz dWLigJ0gd2lsbCBvbmx5IG9jY3VyIGF0IHRoZSB0b3AgbGV2ZWwgaWYgdGhlIHBhcnRpY3VsYXIg ZXZlbnQgZGVmaW5lcyB0aGF0IOKAnHN1YuKAnSBpcyB1c2VkIGluIHRoYXQgd2F5IGZvciB0aGF0 IGV2ZW50Lg0KDQpUaGVyZSBhcmUgcHJvYmFibHkgdXNlIGNhc2VzIGZvciBtdWx0aXBsZSBldmVu dHMgcGVyIG1lc3NhZ2UgYnV0IEkgZG91YnQgdGhlcmUgYXJlIHVzZSBjYXNlcyBmb3IgbXVsdGlw bGUgKnVucmVsYXRlZCogZXZlbnRzIHBlciBtZXNzYWdlLiAgQnkgZGVmaW5pdGlvbiwgcmVsYXRl ZCBldmVudHMgdGhhdCB1c2UgdG9wLWxldmVsIGNsYWltcyB3b3VsZCBuZWVkIHRvIHVzZSB0aGVt IGluIGEgY29tcGF0aWJsZSB3YXkuICBJIGRvbuKAmXQgc2VlIHRoYXQgYXMgYmVpbmcgYSBwcm9i bGVtLg0KDQpUaGF0IGJlaW5nIHNhaWQsIHRoZSBwcmVkb21pbmFudCB1c2UgY2FzZSBpcyBsaWtl bHkgdG8gYmUgYSBzaW5nbGUgZXZlbnQgcGVyIEpXVC4NCg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0K DQpGcm9tOiBNYXJpdXMgU2N1cnRlc2N1IFttYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tXQ0K U2VudDogVHVlc2RheSwgQXVndXN0IDksIDIwMTYgNzoxNSBQTQ0KVG86IFBoaWwgSHVudCA8cGhp bC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj4NCkNjOiBNaWtl IEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNA bWljcm9zb2Z0LmNvbT4+OyBpZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86aWQtZXZlbnRAaWV0Zi5v cmc+DQpTdWJqZWN0OiBSZTogW0lkLWV2ZW50XSBTdW1tYXJpemluZyByZWNlbnQgZGlzY3Vzc2lv bnMgb24gSUQtRXZlbnQgdG9rZW4gZHJhZnQNCg0KTWlrZSwgYXJlIHlvdSBzdWdnZXN0aW5nIHRo YXQgYSBzdWIgY2xhaW0gY2FuIG9ubHkgc2hvdyB1cCBhdCB0aGUgZXZlbnQgbGV2ZWwgYW5kIG5v dCBhdCB0aGUgdG9wIGxldmVsOg0KDQpJbiBwYXJ0aWN1bGFyLCB0aGUgb25seSB0aGluZyB0aGF0 IHRoZSBzcGVjIHNob3VsZCBzYXkgYWJvdXQgdGhlIOKAnHN1YuKAnSBjbGFpbSBpcyB0aGF0IOKA nExpa2UgYWxsIG90aGVyIGNsYWltcyBvdGhlciB0aGFuIOKAmGV2ZW50c+KAmSBhbmQg4oCYaXNz 4oCZLCB3aGV0aGVyIHRoZSDigJhzdWLigJkgY2xhaW0gaXMgdG8gYmUgaW5jbHVkZWQgd2l0aCBh biBldmVudCBpcyBlbnRpcmVseSBldmVudC1zcGVjaWZpYy4NCg0KQSB0b3AgbGV2ZWwgc3ViIGFu ZCBtdWx0aXBsZSBldmVudHMgYXJlIGluY29tcGF0aWJsZSBJTU8uDQoNCkRvIHdlIGhhdmUgYSBj b21wZWxsaW5nIHJlYXNvbiB0byBzdXBwb3J0IG11bHRpcGxlIGV2ZW50cyBwZXIgbWVzc2FnZT8N Cg0KDQpNYXJpdXMNCg0KT24gVHVlLCBBdWcgOSwgMjAxNiBhdCAxMjozOSBQTSwgUGhpbCBIdW50 IDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+PiB3cm90 ZToNCkkgd2FzIHJlZmVycmluZyB0byB0aGlzIGluIHlvdXIgZW1haWwNCiJEZWZpbmUgdGhhdCBh biBldmVudCBuYW1lIGNhbiBiZSB1c2VkIGFzIGEgdG9wLWxldmVsIGNsYWlt4oCdDQoNCg0KSXMg dGhpcyBkaWZmZXJlbnQgZnJvbSB0aGUgZXZlbnQgdXJpPw0KDQpQaGlsDQoNCkBpbmRlcGVuZGVu dGlkDQp3d3cuaW5kZXBlbmRlbnRpZC5jb208aHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNvbS8+ DQpwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+DQoNCg0K DQoNCk9uIEF1ZyA5LCAyMDE2LCBhdCAxMjoxMiBQTSwgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25l c0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PiB3cm90 ZToNCg0KSeKAmW0gZ2xhZCB0byBoZWFyIHRoYXQgd2UgYWdyZWUgb24ga2VlcGluZyBpdCBhcyBz aW1wbGUgYW5kIGdlbmVyYWwtcHVycG9zZSBhcyBwb3NzaWJsZSBhbmQgdGhhdCB5b3UgYWdyZWUg d2l0aCBteSB3cml0ZS11cC4gIEkgdGhpbmsgd2UgdGhlbiBoYXZlIGEgZ29vZCBwYXRoIGZvcndh cmQuDQoNCknigJltIG5vdCBzdXJlIHdoYXQgeW91IG1lYW4gYnkg4oCcSeKAmW0gbm90IHN1cmUg dGhhdCB3ZSBuZWVkIGEg4oCcbmFtZeKAnS4gV2hhdCBpcyB5b3VyIGludGVudGlvbiB0aGVyZS7i gJ0gIFRoZSBvbmx5IHBsYWNlIEkgdXNlZCB0aGUgd29yZCDigJxuYW1l4oCdIHdhcyBpbiBteSBz dGF0ZW1lbnQg4oCcRGVmaW5lIHRoYXQgYW4gZXZlbnQgbmFtZSBjYW4gYmUgdXNlZCBhcyBhIHRv cC1sZXZlbCBjbGFpbeKAnS4gIFdoYXQgSSB3YXMgdHJ5aW5nIHRvIGdldCBhdCBpcyB3YXMgdGhh dCBpZiDigJxodHRwOi8vc3BlY3Mub3BlbmlkLm5ldC9sb2dvdXTigJ0gaXMgdXNlZCBhcyBhbiBl dmVudCBuYW1lLCB0aGF0IGl0IGNhbiBhbHNvIGJlIHVzZWQgYXMgYSBjbGFpbSBuYW1lIGluIHRo ZSBKV1QgY29udGFpbmluZyBpbmZvcm1hdGlvbiBhYm91dCB0aGUgZXZlbnQuICAoTWF5YmUgSeKA mW0gbm90IHVzaW5nIHRoZSBjb3JyZWN0IHRlcm1pbm9sb2d5LCBoZW5jZSB0aGUgdW5pbnRlbmRl ZCBjb25mdXNpb24g4pi6LikNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIFRoYW5rcyBhZ2FpbiwNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IFBoaWwgSHVu dCBbbWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tXQ0KU2VudDogVHVlc2RheSwgQXVndXN0IDks IDIwMTYgMTI6MDcgUE0NClRvOiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5j b208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+DQpDYzogaWQtZXZlbnRAaWV0 Zi5vcmc8bWFpbHRvOmlkLWV2ZW50QGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtJZC1ldmVudF0g U3VtbWFyaXppbmcgcmVjZW50IGRpc2N1c3Npb25zIG9uIElELUV2ZW50IHRva2VuIGRyYWZ0DQoN CkkgZGlkbuKAmXQgY292ZXIgdGhpcyBhcyBJIGRpZG7igJl0IHdhbnQgdG8gY29uZnVzZSBwZW9w bGUgd2l0aCB0b28gbWFueSB0aGluZ3MuDQoNCkJ1dCBJIHRoaW5rIHdlIGFncmVlIG9uIGFsbCBv ZiB0aGUgYmVsb3cuDQoNCknigJltIG5vdCBzdXJlIHRoYXQgd2UgbmVlZCBhIOKAnG5hbWXigJ0u IFdoYXQgaXMgeW91ciBpbnRlbnRpb24gdGhlcmUuDQoNClBoaWwNCg0KQGluZGVwZW5kZW50aWQN Cnd3dy5pbmRlcGVuZGVudGlkLmNvbTxodHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tLz4NCnBo aWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4NCg0KDQoNCg0K T24gQXVnIDksIDIwMTYsIGF0IDExOjU0IEFNLCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1p Y3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0K DQpUaGFua3MgZm9yIHdyaXRpbmcgdGhpcywgUGhpbC4gIFVuZm9ydHVuYXRlbHksIHRoZSBzdW1t YXJ5IGJlbG93IGRvZXMgbm90IGluY2x1ZGUgbXkgZmVlZGJhY2ssIHdoaWNoIGF0IHRoZSBlc3Nl bmNlLCBpcyB0byBrZWVwIHRoZSBJRCBFdmVudHMgZGF0YSBzdHJ1Y3R1cmUgYXMgc2ltcGxlIGFu ZCBnZW5lcmFsLXB1cnBvc2UgYXMgcG9zc2libGUuICAoSSBzdHJvbmdseSBiZWxpZXZlIHRoYXQg SldUIGlzIHRoZSBzdWNjZXNzIGl0IGlzIGJlY2F1c2Ugd2UgbWFkZSBKV1QgYXMgc2ltcGxlIGFu ZCBnZW5lcmFsLXB1cnBvc2UgYXMgcG9zc2libGUsIGFuZCB3ZSBzaG91bGQgZm9sbG93IHRoaXMg c3VjY2Vzc2Z1bCBleGFtcGxlIGFuZCBkbyB0aGUgc2FtZSBoZXJlLikNCg0KSSBiZWxpZXZlIHRo YXQgdGhlIElEIEV2ZW50cyBzcGVjIG5lZWRzIHRvIGluY2x1ZGUgdGhlc2UgdGhpbmdzLCBhbmQg dGhlc2UgdGhpbmdzIG9ubHk6DQrigKIgICAgICAgRGVmaW5lIG9mIHRoZSDigJxldmVudHPigJ0g Y2xhaW0NCuKAoiAgICAgICBEZWZpbmUgdGhhdCBhbiBldmVudCBuYW1lIGNhbiBiZSB1c2VkIGFz IGEgdG9wLWxldmVsIGNsYWltDQrigKIgICAgICAgUmVxdWlyZSB0aGF0IOKAnGlzc+KAnSBiZSBp bmNsdWRlZCBhbmQgdGhhdCB0aGUgSldUIGJlIHNpZ25lZCBieSB0aGUgaXNzdWVyDQrigKIgICAg ICAgSW5jbHVkZSBhIHN0YXRlbWVudCBhbG9uZyB0aGUgbGluZXMgb2Yg4oCcVGhlIGNsYWltcyB0 byBiZSBpbmNsdWRlZCB3aXRoIGFueSBwYXJ0aWN1bGFyIGV2ZW50IGFyZSB0byBiZSBkZWZpbmVk IGJ5IHRoZSBldmVudOKAnQ0KDQpBbmQgSeKAmWQgc3RvcCB0aGVyZS4NCg0KSXQgc2hvdWxkIGJl IGVudGlyZWx5IHVwIHRvIGFwcGxpY2F0aW9ucyB0byBzYXkgd2hhdCBjbGFpbXMgYXJlIGluY2x1 ZGVkIHdpdGggZXZlbnRzIHRoZXkgZGVmaW5lIGFuZCB3aGF0IHRoZWlyIGZvcm1hdCBhbmQgbWVh bmluZ3MgYXJlLiAgVGhlbiB0aGUgSUQgRXZlbnRzIHNwZWMgd2lsbCBiZSBhcyBnZW5lcmFsLXB1 cnBvc2UgYXMgcG9zc2libGUsIHdpdGggaXQgYmVpbmcgbmF0dXJhbCBmb3IgaXQgdG8gYmUgdXNl ZCBpbiBlc3NlbnRpYWxseSBhbGwgSlNPTiBFdmVudCBjb250ZXh0cy4NCg0KQXMgc29vbiBhcyB3 ZSBzdGFydCBwdXR0aW5nIHJlc3RyaWN0aW9ucyBvbiB0aGUgdXNlIG9mIHBhcnRpY3VsYXIgY2xh aW1zIGJ5IGV2ZW50cywgd2XigJlyZSBtYWtpbmcgdGhlIElEIEV2ZW50cyBzcGVjIGxlc3MgZ2Vu ZXJhbC1wdXJwb3NlIGFuZCBsZXNzIG5hdHVyYWwgdG8gdXNlLiAgSW4gcGFydGljdWxhciwgdGhl IG9ubHkgdGhpbmcgdGhhdCB0aGUgc3BlYyBzaG91bGQgc2F5IGFib3V0IHRoZSDigJxzdWLigJ0g Y2xhaW0gaXMgdGhhdCDigJxMaWtlIGFsbCBvdGhlciBjbGFpbXMgb3RoZXIgdGhhbiDigJhldmVu dHPigJkgYW5kIOKAmGlzc+KAmSwgd2hldGhlciB0aGUg4oCYc3Vi4oCZIGNsYWltIGlzIHRvIGJl IGluY2x1ZGVkIHdpdGggYW4gZXZlbnQgaXMgZW50aXJlbHkgZXZlbnQtc3BlY2lmaWMuICBUaGUg Y2xhaW1zIHRvIGJlIGluY2x1ZGVkIHdpdGggYW55IHBhcnRpY3VsYXIgZXZlbnQgYXJlIGV4cGxp Y2l0bHkgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uLuKAnQ0KDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlr ZQ0KDQpGcm9tOiBJZC1ldmVudCBbbWFpbHRvOmlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBQaGlsIEh1bnQNClNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCA5LCAyMDE2IDEwOjE5 IEFNDQpUbzogaWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOmlkLWV2ZW50QGlldGYub3JnPg0KU3Vi amVjdDogW0lkLWV2ZW50XSBTdW1tYXJpemluZyByZWNlbnQgZGlzY3Vzc2lvbnMgb24gSUQtRXZl bnQgdG9rZW4gZHJhZnQNCg0KSSB0aG91Z2h0IEkgd291bGQgdXBkYXRlIHRoZSBsaXN0IG9uIHNv bWUgZGlzY3Vzc2lvbnMgdGhhdCBoYXZlIGJlZW4gaGFwcGVuaW5nIG92ZXIgaW4gdGhlIE9wZW5J RCBDb25uZWN0IGFuZCBSSVNDIHdvcmtpbmcgZ3JvdXBzIGNvbmZlcmVuY2UgY2FsbHMuDQoNClRo ZXNlIGRpc2N1c3Npb25zIGhhdmUgYmVlbiBhYm91dCB0aGUgY29yZSBzcGVjIGFuZCB0aGUgcm9s ZSBvZiDigJx0b3AtbGV2ZWzigJ0gYXR0cmlidXRlcyB2cy4gZXZlbnQg4oCcZXh0ZW5zaW9u4oCd IGF0dHJpYnV0ZXMuDQpTZWU6IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1odW50 LWlkZXZlbnQtdG9rZW4tMDENCg0KSW4gcGFydGljdWxhciBzaG91bGQg4oCcc3Vi4oCdIGJlIHVz ZWQgaW4gdGhlIHRvcCBsZXZlbCB0byDigJxwb2ludOKAnSB0byB0aGUgc3ViamVjdCAoaW4gdGhl IGJyb2FkZXIgZW5nbGlzaCBzZW5zZSkgb2YgdGhlIGV2ZW50LCBvciBzaG91bGQgaXQgYmUgY29u c3RyYWluZWQgdG8gdGhlIFNBTUwvSUQgVG9rZW4gZGVmaW5pdGlvbiB3aGljaCBpcyB0aGUgYXV0 aGVudGljYXRlZCB1c2VyLg0KDQpUYWtlbiBpbiB0aGUgbmFycm93ZXIgZGVmaW5pdGlvbiwgaXQg aXMgaW1wb3J0YW50IHRvIG9ic2VydmUgdGhhdCBpbiBhbiBJRCBUb2tlbiwg4oCcc3Vi4oCdIGFu ZCDigJxpc3PigJ0gZ28gdG9nZXRoZXIuICBUaGUgaXNzdWVyIHByb3ZpZGVzIHRoZSBjb250ZXh0 IGZvciB0aGUgYXV0aGVudGljYXRlZCBzdWJqZWN0IGlkZW50aWZpZXIuIFRoZSBwcm9ibGVtIHdp dGggZXZlbnRzLCBpcyB0aGF0IGl0IG1pZ2h0IG5vdCBiZSB0aGUgQVMgKG9yIE9QKSB3aGljaCBp cyBpc3N1aW5nIHRoZSBldmVudC4NCg0KVG8gc3VtbWFyaXplIGEgZmFpciBhbW91bnQgb2YgZGlz Y3Vzc2lvbiwgdGhlIGZlZWxpbmcgc2VlbXMgdG8gYmUgdGhlIGZvbGxvd2luZzoNCg0KKiAgVGhl IEV2ZW50IFRva2VuIHRvcCBsZXZlbCBhdHRyaWJ1dGVzIHNob3VsZCBiZSBmYWlybHkgbGltaXRl ZCBhbmQgbm90IGluY2x1ZGUgdGhlIHN1YiBhdHRyaWJ1dGUuDQoqICBGb3IgZXZlbnRzIHRoYXQg YXJlIGFib3V0IGEgdXNlciwgdGhlIHJlbGV2YW50IGV2ZW50IHNwZWNpZmljYXRpb24gbWF5IGlu Y2x1ZGUgYSDigJxzdWLigJ0gYXR0cmlidXRlIHdpdGhpbiB0aGUgZXZlbnTigJlzIHN1Yi1vYmpl Y3QgYW5kIG5vdCBpbiB0aGUgdG9wLWxldmVsLiBGdXJ0aGVyIHRoYXQgc3ViLW9iamVjdCBjYW4g YWxzbyBpbmNsdWRlIHRoZSBpc3N1ZXIgb2YgdGhlIHVzZXIuDQoqIFRoZSB0b3AtbGV2ZWwg4oCc aXNz4oCdIHNoYWxsIG1lYW4gdGhlIGlzc3VlciBvZiB0aGUgZXZlbnQgd2hlcmUgdGhlIHN0YXRl IGNoYW5nZSBvY2N1cnJlZC4NCiogIOKAnHN1YuKAnSBzaG91bGQgbm90IGJlIHByZXNlbnQgaW4g dGhlIHRvcCBsZXZlbCBzdHJ1Y3R1cmUuICBBbHNvLCDigJxldmVudHPigJ0gbXVzdCBhbHNvIGJl IHByZXNlbnQuDQoNCkhlcmUgd291bGQgYmUgYSBuZXcgZXhhbXBsZSBsb2dvdXQ6DQoNCnsNCg0K ICA84oCUIHRvcCBsZXZlbCBpcyBhYm91dCB0aGUgZXZlbnQgaXRzZWxmIC0+DQoNCiAgImlzcyI6 ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbTxodHRwczovL3NlcnZlci5leGFtcGxlLmNvbS8+ IiwNCg0KICAiYXVkIjogInM2QmhkUmtxdDMiLA0KDQogICJqdGkiOiAiM2QwYzNjZjc5NzU4NGJk MTkzYmQwZmIxYmQ0ZTdkMzAiLA0KDQogICJpYXQiOiAxNDU4NjY4MTgwLA0KDQogICJleHAiOiAx NDU4NjY4NTgwLA0KDQogICJldmVudHMiOiBbDQoNCiAgICAiaHR0cHM6Ly9zcGVjcy5vcGVuaWQu bmV0L2xvZ291dCINCg0KICBdLA0KDQogICJodHRwczovL3NwZWNzLm9wZW5pZC5uZXQvbG9nb3V0 Ijogew0KDQogICAgPC0gVGhpcyBsZXZlbCBpcyBkZWZpbmVkIGVudGlyZWx5IGJ5IHRoZSBldmVu dCBVUkktPg0KDQogICAgImlzcyI6ICJodHRwczovL29pZGMuZXhhbXBsZS5jb208aHR0cHM6Ly9v aWRjLmV4YW1wbGUuY29tLz4iLA0KDQogICAg4oCcanRpIjogIjA4YTUwMTljLTE3ZTEtNDk3Ny04 ZjQyLTY1YTEyODQzZWEwMuKAnSwNCg0KICAgICJzdWIiOiAiMjQ4Mjg5NzYxMDAx4oCdLA0KDQog ICAg4oCcZXhw4oCdOiA8SUQgdG9rZW4gZXhwaXJ5Pg0KDQogIH0NCg0KfQ0KDQpJbiB0aGUgYWJv dmUgZXhhbXBsZSBub3RlIHRoYXQgdGhlIOKAnGV2ZW504oCdIG9iamVjdCBjYW4gaGF2ZSBpdHMg b3duIGlzcyBhbmQgc3ViamVjdCAoc3ViIG9yIGp0aSkgdGhhdCBoYXZlIG1lYW5pbmcgd2l0aGlu IHRoZSBjb250ZXh0IG9mIGFuIE9wZW5JRCBPUCBwcm92aWRlci4gIFRoZSBpc3N1ZXIgb2YgdGhl IGV2ZW50IGNhbiBiZSBkaWZmZXJlbnQgKHRoZSB0b3AtbGV2ZWwpIGFuZCByZXByZXNlbnRzIHRo ZSBlbnRpdHkgdGhhdCBzaWducyB0aGUgZXZlbnQgKGlmIGl0IGlzIHNpZ25lZCkuDQoNClRoZSB0 b3AtbGV2ZWwgYXR0cmlidXRlcyBpZGVudGlmeSBhbiBpbmRpdmlkdWFsIGV2ZW50IGFuZCBhcmUg dXNlZCB0byB2YWxpZGF0ZSB0aGUgZXZlbnQgKHNpZ25pbmcgZXRjKS4gIFdoZXJlIGFzIHRoZSBu ZXN0ZWQgb2JqZWN0IGNvbnRhaW5zIGFsbCBvZiB0aGUgZGF0YSBhYm91dCB0aGUgZXZlbnQgYW5k IGlzIGRlZmluZWQgYnkgdGhlIHByb2ZpbGluZyBzcGVjaWZpY2F0aW9uIChlLmcuIGEgcG9zc2li bGUgT3BlbklEIExvZ291dCBFdmVudCBzcGVjKS4gIEluIHRoaXMgY2FzZSwgaW4gT3BlbklELCBs b2dnaW5nIG91dCB1c3VhbGx5IHRyYW5zbGF0ZXMgaW50byByZXZva2luZyBhbiBJRCBUb2tlbi4g VGh1cyB0aGUg4oCcanRp4oCdIGZvciB0aGUgSUQgdG9rZW4gKDA4YTUwMTljLi4uODQzZWEwMikg aXMgaW5jbHVkZWQgaW4gdGhlIExvZ291dCBvYmplY3QuDQoNClNpZGUgbm90ZS4gIFJlZ2FyZGlu ZyDigJxsb2dvdXTigJ0sIGl0IG1pZ2h0IGJlIHVzZWZ1bCB0byBpbmNsdWRlIHRoZSBleHBpcnkg b2YgdGhlIElEIFRva2VuIGluIGNhc2UgdGhlIHN1YnNjcmliZXIgaGFzIG5vdCB5ZXQgcmVjZWl2 ZWQgYW4gSUQgVG9rZW4uIFRoaXMgd291bGQgbGV0IHRoZSBzdWJzY3JpYmVyIGtub3cgaG93IGxv bmcgaXQgbmVlZHMgdG8ga2VlcCB0aGUgcmV2b2NhdGlvbiBpbmZvcm1hdGlvbiBmb3IuICBJT1fi gKZhZnRlciB0aGUgdGhlIElEIFRva2VuIGlzIGV4cGlyZWQsIHRoZSBzdWJzY3JpYmVyIHdvdWxk IG5vIGxvbmdlciBuZWVkIHRvIHRyYWNrIHRoZSByZXZvY2F0aW9uIHN0YXRlLg0KDQpJdCBpcyBh bHNvIGdvb2QgdG8gb2JzZXJ2ZSB0aGF0IHRoZSDigJxhdWTigJ0gYXQgdGhlIHRvcCBsZXZlbCBk ZXNjcmliZXMgdGhlIHN1YnNjcmliZXIgb2YgdGhlIGV2ZW50LiAgVGhpcyBtYXkgYWxzbyBiZSBk aWZmZXJlbnQgdGhlbiB0aGUgb3JpZ2luYWwgYXVkaWVuY2Ugb2YgdGhlIElEIFRva2VuLg0KDQpT byB0byBjb25jbHVkZS4gQnkgbWFraW5nIHRvcC1sZXZlbCBhdHRyaWJ1dGVzIHN0cmljdGx5IGFi b3V0IHRoZSBldmVudHMgb3duIHZhbGlkYXRpb24sIGFuZCBuZXN0ZWQgb2JqZWN0cyBhYm91dCB0 aGUgZXZlbnQsIHdlIGF2b2lkIGNvbGxpc2lvbnMgaW4gZGVmaW5pdGlvbnMgc3VjaCBhcyB0aGUg aXNzdWVyIG9mIHRoZSBldmVudCwgdnMuIHRoZSBvcmlnaW5hbCBpc3N1ZXIgb2YgYSBzZWN1cml0 eSBhc3NlcnRpb24uDQoNCkkgaG9wZSBJ4oCZdmUgZ290dGVuIGV2ZXJ5b25l4oCZcyBmZWVkYmFj ayBjb3JyZWN0IGhlcmUuIExldHMgY29udGludWUgdG8gZGlzY3Vzcy4gSSB3aWxsIHJldmlzZSB0 aGUgZHJhZnQgdG8gZm9sbG93IHRoZSBncm91cHMgdGhpbmtpbmcgaGVyZS4NCg0KUGhpbA0KDQpA aW5kZXBlbmRlbnRpZA0Kd3d3LmluZGVwZW5kZW50aWQuY29tPGh0dHA6Ly93d3cuaW5kZXBlbmRl bnRpZC5jb20vPg0KcGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUu Y29tPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K SWQtZXZlbnQgbWFpbGluZyBsaXN0DQpJZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86SWQtZXZlbnRA aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50 DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklk LWV2ZW50IG1haWxpbmcgbGlzdA0KSWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGll dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudA0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSWQtZXZl bnQgbWFpbGluZyBsaXN0DQpJZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86SWQtZXZlbnRAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50DQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSWQtZXZlbnQgbWFp bGluZyBsaXN0DQpJZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50DQoNCg== --_000_SN1PR0301MB16459867074BFA03B5C401E4F51E0SN1PR0301MB1645_ 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 DQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4w cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToi Q291cmllciBOZXciO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1h bDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy Z2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxl LW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4ubS02NTM0NDM1NTczNjM5NjczNzg2 YXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOm0tNjUzNDQzNTU3MzYzOTY3 Mzc4NmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJ e21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZh bWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjoj MDAyMDYwO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu MGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+U2VlIG15 IHByZXZpb3VzIG1lc3NhZ2UsIEpvaG4sIHdoaWNoIHdhcyBhIHJlcGx5IHRvIFBoaWzigJlzIG1l c3NhZ2UgdGhhdCB5b3UgYWxzbyByZXBsaWVkIHRvLCB0aGF0IGNvbnRhaW5lZCBhIGxvZ291dCBj bGFpbXMgZXhhbXBsZS4mbmJzcDsgSeKAmW0gbm90IHByb3Bvc2luZyB0byBzcGVjaWFsLWNhc2UN CiB0aGUgQ29ubmVjdCBMb2dvdXQgbWVzc2FnZSBpbiBhbnkgd2F5LiZuYnNwOyBUaGUg4oCcaXNz 4oCdIGlzIHRoZSBldmVudCBpc3N1ZXIuJm5ic3A7IFRoZSBvdGhlciBjbGFpbXMgaW4gdGhlIG1l c3NhZ2UgYXJlIHRob3NlIGRlZmluZWQgYnkgdGhlIGV2ZW50IHRvIGJlIGluY2x1ZGVkLCBqdXN0 IGxpa2UgdGhvc2UgZm9yIGFueSBvdGhlciBldmVudC4mbmJzcDsgWWVzLCB0aGUgbG9nb3V0IG1l c3NhZ2UgZG9lc27igJl0IGluY2x1ZGUgYSBzZWNvbmQgaXNzdWVyLCBhIHNlY29uZCBzdWJqZWN0 LA0KIGFuIElEIFRva2VuIGFzIGEgY2xhaW0sIG9yIGFueXRoaW5nIGVsc2UgY29tcGxpY2F0ZWQg bGlrZSB0aGF0LCBiZWNhdXNlIHRob3NlIHRoaW5ncyBhcmVu4oCZdCBuZWVkZWQgZm9yIHRoZSBs b2dvdXQgdXNlIGNhc2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYw Ij5BcyBJ4oCZZCB3cml0dGVuIHByZXZpb3VzbHksIHRoZSBJRCBFdmVudHMgc3BlYyBzaG91bGQg ZGVmaW5lIHRoZSDigJxldmVudHPigJ0gY2xhaW0sIGhvdyB0byB1c2UgYW4gZXZlbnQgbmFtZSBh cyBhIGNsYWltICh3aGVuIG5lZWRlZCksIGFuZCBzYXkgdGhhdCB0aGUgZXZlbnQgSldUDQogbXVz dCBiZSBzaWduZWQgYnkgdGhlIGlzc3VlciwgYW5kIHN0b3AgdGhlcmUuJm5ic3A7IFRyeWluZyB0 byBtaWNyby1tYW5hZ2UgY2xhaW1zIHVzYWdlIHdpdGhpbiBhbiBldmVudCB3aWxsIG9ubHkgcmVz dWx0IGluIHRoZSBJRCBFdmVudHMgc3BlYyBiZWluZyBoYXJkZXIgdG8gdXNlLiZuYnNwOyBJZiB3 ZeKAmWQgdHJpZWQgdG8gc2ltaWxhcmx5IG1pY3JvLW1hbmFnZSBKV1QgY2xhaW1zIHVzYWdlLCBK V1Qgd291bGQgbGlrZWx5IG5vdCBoYXZlIGJlZW4gdGhlIHN1Y2Nlc3MNCiB0aGF0IGl0IGlzLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHNw YW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjwvc3Bhbj4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBKb2huIEJyYWRsZXkg W21haWx0bzp2ZTdqdGJAdmU3anRiLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwg QXVndXN0IDExLCAyMDE2IDEyOjIyIFBNPGJyPg0KPGI+VG86PC9iPiBQaGlsIEh1bnQgKElETSkg Jmx0O3BoaWwuaHVudEBvcmFjbGUuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gTWlrZSBKb25lcyAm bHQ7TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tJmd0OzsgaWQtZXZlbnRAaWV0Zi5vcmc7IE1h cml1cyBTY3VydGVzY3UgJmx0O21zY3VydGVzY3VAZ29vZ2xlLmNvbSZndDs7IG9wZW5pZC1zcGVj cy1hYkBsaXN0cy5vcGVuaWQubmV0IEFiICZsdDtvcGVuaWQtc3BlY3MtYWJAbGlzdHMub3Blbmlk Lm5ldCZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtJZC1ldmVudF0gU3VtbWFyaXppbmcg cmVjZW50IGRpc2N1c3Npb25zIG9uIElELUV2ZW50IHRva2VuIGRyYWZ0PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm90IHN1cnByaXNpbmdseSBhIG11bHRp cHVycG9zZSBtZXNzYWdlIGZvcm1hdCB3aWxsIG5vdCBiZSBhcyBvcHRpbWl6ZWQgYXMgYSBzaW5n bGUgcHVycG9zZSBvbmUuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5Db25uZWN0IGl0c2VsZiBkb2VzbuKAmXQgcmVhbGx5IGhhdmUgYSBjb25mbGljdCBhcm91 bmQgaXNzdWVyIHRoZSBzYW1lIGVudGl0eSBzZW5kaW5nIHRoZSBsb2dvdXQgbWVzc2FnZSBpcyBh bHdheXMgdGhlIG9uZSB0aGF0IGNyZWF0ZWQgdGhlIGlkX3Rva2VuIHRoYXQgaXQgcmVmZXJzIHRv LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5V c2luZyB0aGUgc2FtZSBmb3JtYXQgYXMgaWRfdG9rZW4gd2l0aCB0aGUgc2FtZSBzZW1hbnRpY3Mg dG8gaWRlbnRpZnkgdGhlIHRoaW5nIHRvIGJlIHRlcm1pbmF0ZWQgbWFrZXMgc2Vuc2UgZnJvbSBh IHB1cmVseSBvcGVuSUQgQ29ubmVjdCBwb2ludCBvZiB2aWV3LjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PdGVyIG1lc3NhZ2VzIHRoYXQgaGF2 ZSBkaWZmZXJlbnQgbm90aW9ucyBvZiBzdWJqZWN0IGFuZCBhcmUgaXNzdWVkIGJ5IGRpZmZlcmVu dCBwYXJ0aWVzIHRoYW4gdGhlIG9uZSB0aGF0IGNvbnRyb2xzIHRoZSBzdWJqZWN0IGNhdXNlIGlz c3VlcyB3aGVuIHlvdSB0cnkgYW5kIGZpdCB0aGVtIGludG8gdGhlIHNhbWUgZm9ybWF0IGFzIGFu IElEX1Rva2VuLCBJIGdyYW50IHlvdSB0aGF0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCB3YXMgbWVudGlvbmVkIHRoYXQgd2UgbmVlZCB0 byBkaWZmZXJlbnRpYXRlIGJldHdlZW4gdGhlc2UgZXZlbnRzIGFuZCBpZF90b2tlbnMuICZuYnNw O01vc3RseSB3ZSBuZWVkIHRvIGRvIHRoYXQgaW4gY2FzZXMgd2hlcmUgdGhlIHRva2VuIG1pZ2h0 IGJlIHByZXNlbnRlZCBpbiB0aGUgZnJvbnQgY2hhbm5lbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VG8gZG8gdGhhdCBzZSBkbyBoYXZlIG1h bmRhdG9yeSBjbGFpbXMgZm9yIG5vbmNlIGFuZCBjX2hhc2ggb3IgYXRfaGFzaCBhcyB3ZWxsIGFz IHRoZSBhZGRpdGlvbiBvZiBldmVudHMgcGFyYW1ldGVyIHRvIHJlZHVjZSBjb25mdXNpb24uICZu YnNwOyBOb3cgSSBhZG1pdCB0aGF0IHNvbWUgcGVvcGxlIG1heSBzdGlsbCBnZXQgdGhhdCB3cm9u ZywgJm5ic3A7YW5kIHRoZSByZW1vdmFsIG9mIHN1YiBmcm9tIHRoZSB0b3AgbGV2ZWwNCiB3b3Vs ZCByZW1vdmUgYW55IGNvbmNlcm4uICZuYnNwO0hvd2V2ZXIgTWlrZSBoYXMgYSBwb2ludCB0aGF0 IGFkb3B0aW9uIG1heSBiZSBodXJ0IGlmIHdlIGNoYW5nZSB0aGUgc2VtYW50aWNzIHRvbyBtdWNo LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J IGRvbuKAmXQgc2VlIGJhY2tjaGFubmVsIHNpbmdsZSBsb2dvdXQgYmVpbmcgdXNlZCBieSBtYW55 IHNvY2lhbCBsb2dpbiBSUCwgaXQgaXMgYSBsb3Qgb2Ygd29yayB0byBtYWludGFpbiBzZXJ2ZXIg c2lkZSBzdGF0ZS4gJm5ic3A7IEl0IGlzIG1vc3RseSBhbiBlbnRlcnByaXNlIGFuZCBsYXJnZSBz aXRlIHNvcnQgb2YgZmVhdHVyZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRoYXQgbWF5IG9yIG1heSBub3QgaW1wYWN0IG9uIGlmIGl0IGlzIGJl dHRlciB0byBiZSBzaW1wbGUgYW5kIGFsaWduZWQgd2l0aCBjb25uZWN04oCZcyBpZCB0b2tlbiBv ciBtb3JlIGdlbmVyYWwgcHVycG9zZSB0byBmaXQgd2l0aCBvdGhlciBlbnRlcnByaXNlIHRvIFNh YVMgZmVhdHVyZXMgbGlrZSBTQ0lNIGV2ZW50cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayB0aGUgdHdvIGRpcmVjdGlvbnMgbGVh ZCB0byBkaWZmZXJlbnQgZm9ybWF0cy4gJm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBjb21wcm9taXNlIG9mIHNwZWNp YWwgY2FzaW5nIENvbm5lY3QgU0xPIGFuZCBib2RnaW5nIHRoZSBmb3JtYXRzIHRvZ2V0aGVyIGlz IHByb2JhYmx5IHRoZSB3b3JzdCBvcHRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkpvaG4gQi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gQXVnIDExLCAyMDE2LCBhdCAxMTo1 OSBBTSwgUGhpbCBIdW50IChJRE0pICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNs ZS5jb20iPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5Ib3cgZG8g eW91IHJlc29sdmUgY29uZmxpY3RzIG9uIGlzcyB0aGVuPyAmbmJzcDtUaGUgdG9wIGxldmVsIGhh cyB0byBiZSB0aGUgaXNzdWVyIG9mIHRoZSBldmVudCBhcyB0aGUgaXNzdWVyIHNpZ25zLiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPklmIG9uZSBz cGVjIGNhbiB1c2UgaXQgYWxsIG11c3QgYmUgYWJsZSB0by4gSSBiZWxpZXZlIHlvdSBwcmV2aW91 c2x5IG9iamVjdGVkIHRvIHRoYXQgc2F5aW5nIHN1YiBtdXN0IGJlIGFzIGhvdyBpZCB0b2tlbnMg ZGVmaW5lIHRoZW0uIEJ1dCB0aGF0IGlzbnQgdW5pcXVlIGFuZCByZXF1aXJlcyBpc3MuDQogTm93 IHdlIHdvdWxkIGhhdmUgc3ViIGF0IHRoZSB0b3Agd2l0aCBhbiBldmVudCBpc3N1ZXIgYXQgdGhl IHRvcCBhbmQgYSBzdWIgaXNzdWVyIGluIHRoZSBleHRlbnNpb24uIFRoYXQgc2VlbXMgaW5jcmVk aWJseSBjb21wbGV4IG5vdCB0byBtZW50aW9uIGF3a3dhcmQuJm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SWYgd2UgbWFrZSBzdWIgYSB1cmkgZm9y IGFsbCB0aGVuIGl0IGNhbiB3b3JrIGFzcyBpc3MgZnJvbSBpZCB0b2tlbiB3b3VsZCBub3QgYmUg bmVlZGVkLiBCdXQgaSBjYW4gc2VlIG1hbnkgb2JqZWN0aW5nIHRvIHRoZSBjaGFuZ2UgaW4gZm9y bWF0LiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi PldoeSBub3QgaGF2ZSBhIGxvZ291dCBiZSBhbiBldmVudCB3aXRoIGFuIGlkIHRva2VuIGF0dGFj aGVkIGZvciBleGFtcGxlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NClBoaWw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCk9uIEF1ZyAxMSwg MjAxNiwgYXQgODowMyBBTSwgTWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwu Sm9uZXNAbWljcm9zb2Z0LmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+TWljaGFlbC5K b25lc0BtaWNyb3NvZnQuY29tPC9zcGFuPjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdDtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4 dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4 O3dvcmQtc3BhY2luZzowcHgiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+VGhlIHNpbXBsZSBydWxlIGlzIHRoYXQgaWYg dGhlIHBhcnRpY3VsYXIgZXZlbnQgY2FsbHMgZm9yIHRoZSDigJxzdWLigJ0gY2xhaW0gdG8gYmUg YXQgdGhlIHRvcCBsZXZlbCwgdGhlbiBpdCBpcy4mbmJzcDsgVGhpcyBpcyBubyBkaWZmZXJlbnQg ZnJvbSBhbnkgb3RoZXIgY2xhaW0gdGhhdA0KIGFuIGV2ZW50IG1pZ2h0IHBsYWNlIGF0IHRoZSB0 b3AgbGV2ZWwuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5UaGUgY29tcGxleGl0eSBhcmlzZXMgaWYg4oCcc3Vi 4oCdIGlzIHVubmVjZXNzYXJpbHkgc3BlY2lhbC1jYXNlZC4mbmJzcDsgV2Ugc2hvdWxkbuKAmXQg ZG8gdGhhdCwgYmVjYXVzZSBpdCBsaW1pdHMgdGhlIGFwcGxpY2FiaWxpdHkgb2YgdGhlIHNwZWNp ZmljYXRpb24uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgLS0gTWlrZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu IDBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+UGhpbA0KIEh1 bnQgKElETSkgWzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSI+PHNwYW4gc3R5 bGU9ImNvbG9yOnB1cnBsZSI+bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPC9zcGFuPjwvYT5d PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxi PlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj5UaHVyc2RheSwgQXVndXN0IDExLCAyMDE2IDk6NDAgQU08YnI+DQo8Yj5Ubzo8L2I+PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPk1pa2UgSm9uZXMgJmx0 OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iPjxzcGFuIHN0eWxl PSJjb2xvcjpwdXJwbGUiPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvc3Bhbj48L2E+Jmd0 Ozxicj4NCjxiPkNjOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+TWFyaXVzIFNjdXJ0ZXNjdSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1zY3VydGVzY3VA Z29vZ2xlLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+bXNjdXJ0ZXNjdUBnb29nbGUu Y29tPC9zcGFuPjwvYT4mZ3Q7OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86aWQtZXZlbnRAaWV0Zi5vcmciPjxzcGFuIHN0eWxl PSJjb2xvcjpwdXJwbGUiPmlkLWV2ZW50QGlldGYub3JnPC9zcGFuPjwvYT48YnI+DQo8Yj5TdWJq ZWN0OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ UmU6IFtJZC1ldmVudF0gU3VtbWFyaXppbmcgcmVjZW50IGRpc2N1c3Npb25zIG9uIElELUV2ZW50 IHRva2VuIGRyYWZ0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgdXNpbmcgc3Vi IGF0IHRoZSB0b3AgbGV2ZWwgbGVhZHMgdG8gY29tcGxleGl0eS4gRWcgQ2FuIHlvdSBwcm92aWRl IGEgcnVsZSBmb3Igd2hlbiB0b3AgbGV2ZWwgaXMgdXNlZCBvciBub3QgYnkgYW4gaW5kaXZpZHVh bCBzcGVjPyAmbmJzcDtJTU8uIFRvcCBsZXZlbCBzaG91bGQgYWx3YXlzIGJlIHVzZWQgdGhlIHNh bWUgd2F5IGJ5IGFsbCBpbXBsZW1lbnRlcnMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkJhc2VkIG9uIHRoZSBjYWxscyBhdCByaXNjL2Nvbm5lY3QsIHdlIGRpc2N1c3NlZCB0aGF0 IGl0IHdvdWxkIGJlIGJlc3QgdG8gbW92ZSBhbGwgZXZlbnQgc3BlY2lmaWNzIHRvIHRoZSBldmVu dCBvYmplY3QgYXJlYS4gVGhpcyB3YXkgZGlmZmVyZW50IGV2ZW50cyBjYW4gaGF2ZSBkaWZmZXJl bnQgZXZlbnQgYWRkcmVzc2luZyAoZWcgc3ViL2lzcywgdXJpLCBqaXQvaXNzKS4gV2hlbiBpc3Mg aXMgbmVlZGVkIHRvDQogdW5pcXVlbHkgcXVhbGlmeSBhIHN1YiwgaXQgY2FuIGJlIHByb3ZpZGVk IHdpdGhvdXQgY29uZmxpY3Rpbmcgd2l0aCB0aGUgaXNzdWVyIG9mIHRoZSBldmVudC4gU2ltaWxh cmx5IGp0aSBhbmQgaXNzIGNhbiBiZSB1c2VkIGZvciBhIHJldm9rZWQgdG9rZW4gd2l0aG91dCBj b25mbGljdGluZyB3aXRoIHRoZSBldmVudCBqdGkuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkkgcGxhbiB0byBwb3N0IGEgbmV3IGRyYWZ0IHNob3J0bHkgdGhhdCB3aWxsIGdpdmUg c29tZSBleGFtcGxlcyBiYXNlZCBvbiBmZWVkYmFjayBmcm9tIHRoZSBvcGVuaWQgcmlzYy9jb25u ZWN0IGRpc2N1c3Npb25zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBjYW4gYWx3YXlz IGNoYW5nZSBhZ2Fpbi4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NClBoaWw8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij48YnI+DQpPbiBBdWcgMTEsIDIwMTYsIGF0IDQ6NTQgQU0sIE1pa2Ug Sm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iPjxz cGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvc3Bh bj48L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5Obywg SeKAmW0gbm90IHNheWluZyB0aGF0IOKAnHN1YuKAnSBjYW5ub3QgYXBwZWFyIGF0IHRoZSB0b3Ag bGV2ZWwuJm5ic3A7IEnigJltIHNheWluZyB0aGF0IOKAnHN1YuKAnSB3aWxsIG9ubHkgb2NjdXIg YXQgdGhlIHRvcCBsZXZlbCBpZiB0aGUgcGFydGljdWxhciBldmVudCBkZWZpbmVzIHRoYXQg4oCc c3Vi4oCdDQogaXMgdXNlZCBpbiB0aGF0IHdheSBmb3IgdGhhdCBldmVudC48L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIw NjAiPlRoZXJlIGFyZSBwcm9iYWJseSB1c2UgY2FzZXMgZm9yIG11bHRpcGxlIGV2ZW50cyBwZXIg bWVzc2FnZSBidXQgSSBkb3VidCB0aGVyZSBhcmUgdXNlIGNhc2VzIGZvciBtdWx0aXBsZSAqPGI+ dW5yZWxhdGVkPC9iPiogZXZlbnRzIHBlciBtZXNzYWdlLiZuYnNwOyBCeSBkZWZpbml0aW9uLA0K IHJlbGF0ZWQgZXZlbnRzIHRoYXQgdXNlIHRvcC1sZXZlbCBjbGFpbXMgd291bGQgbmVlZCB0byB1 c2UgdGhlbSBpbiBhIGNvbXBhdGlibGUgd2F5LiZuYnNwOyBJIGRvbuKAmXQgc2VlIHRoYXQgYXMg YmVpbmcgYSBwcm9ibGVtLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+VGhhdCBiZWluZyBzYWlkLCB0aGUgcHJl ZG9taW5hbnQgdXNlIGNhc2UgaXMgbGlrZWx5IHRvIGJlIGEgc2luZ2xlIGV2ZW50IHBlciBKV1Qu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNw Ozwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5NYXJpdXMNCiBTY3VydGVzY3UgWzxhIGhy ZWY9Im1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJw bGUiPm1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb208L3NwYW4+PC9hPl08c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KPGI+U2VudDo8L2I+PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlR1ZXNkYXksIEF1 Z3VzdCA5LCAyMDE2IDc6MTUgUE08YnI+DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlBoaWwgSHVudCAmbHQ7PGEgaHJlZj0ibWFpbHRv OnBoaWwuaHVudEBvcmFjbGUuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5waGlsLmh1 bnRAb3JhY2xlLmNvbTwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj48c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+TWlrZSBKb25lcyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9y OnB1cnBsZSI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9zcGFuPjwvYT4mZ3Q7OzxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWls dG86aWQtZXZlbnRAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmlkLWV2ZW50 QGlldGYub3JnPC9zcGFuPjwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UmU6IFtJZC1ldmVudF0gU3VtbWFyaXpp bmcgcmVjZW50IGRpc2N1c3Npb25zIG9uIElELUV2ZW50IHRva2VuIGRyYWZ0PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ TWlrZSwgYXJlIHlvdSBzdWdnZXN0aW5nIHRoYXQgYSBzdWIgY2xhaW0gY2FuIG9ubHkgc2hvdyB1 cCBhdCB0aGUgZXZlbnQgbGV2ZWwgYW5kIG5vdCBhdCB0aGUgdG9wIGxldmVsOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGlu O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIHBh cnRpY3VsYXIsIHRoZSBvbmx5IHRoaW5nIHRoYXQgdGhlIHNwZWMgc2hvdWxkIHNheSBhYm91dCB0 aGUg4oCcc3Vi4oCdIGNsYWltIGlzIHRoYXQg4oCcTGlrZSBhbGwgb3RoZXIgY2xhaW1zIG90aGVy IHRoYW4g4oCYZXZlbnRz4oCZIGFuZCDigJhpc3PigJksIHdoZXRoZXIgdGhlIOKAmHN1YuKAmSBj bGFpbSBpcyB0byBiZSBpbmNsdWRlZCB3aXRoIGFuIGV2ZW50IGlzIGVudGlyZWx5IGV2ZW50LXNw ZWNpZmljLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QSB0b3AgbGV2ZWwgc3Vi IGFuZCBtdWx0aXBsZSBldmVudHMgYXJlIGluY29tcGF0aWJsZSBJTU8uPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkRvIHdlIGhhdmUgYSBjb21wZWxsaW5nIHJlYXNvbiB0byBzdXBwb3J0IG11 bHRpcGxlIGV2ZW50cyBwZXIgbWVzc2FnZT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWFyaXVzPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T24gVHVlLCBBdWcgOSwgMjAxNiBhdCAxMjozOSBQTSwgUGhpbCBIdW50ICZsdDs8YSBocmVm PSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHls ZT0iY29sb3I6cHVycGxlIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvc3Bhbj48L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkg d2FzIHJlZmVycmluZyB0byB0aGlzIGluIHlvdXIgZW1haWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mcXVvdDs8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzAwMjA2MCI+RGVmaW5lIHRoYXQgYW4gZXZlbnQgbmFtZSBjYW4gYmUgdXNlZCBh cyBhIHRvcC1sZXZlbCBjbGFpbeKAnTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXMgdGhpcyBkaWZmZXJlbnQgZnJvbSB0aGUgZXZlbnQg dXJpPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGhpbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5A aW5kZXBlbmRlbnRpZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cDovL3d3dy5pbmRlcGVuZGVudGlk LmNvbS8iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj53d3cuaW5k ZXBlbmRlbnRpZC5jb208L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBo cmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBz dHlsZT0iY29sb3I6cHVycGxlIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvc3Bhbj48L2E+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gQXVnIDksIDIwMTYsIGF0IDEyOjEyIFBNLCBNaWtlIEpvbmVz ICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIiB0YXJnZXQ9 Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+TWljaGFlbC5Kb25lc0BtaWNyb3Nv ZnQuY29tPC9zcGFuPjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5J4oCZbSBnbGFkIHRvIGhlYXIgdGhhdCB3ZSBh Z3JlZSBvbiBrZWVwaW5nIGl0IGFzIHNpbXBsZSBhbmQgZ2VuZXJhbC1wdXJwb3NlIGFzIHBvc3Np YmxlIGFuZCB0aGF0IHlvdSBhZ3JlZSB3aXRoIG15IHdyaXRlLXVwLiZuYnNwOyBJIHRoaW5rIHdl IHRoZW4gaGF2ZSBhIGdvb2QgcGF0aA0KIGZvcndhcmQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMDAyMDYwIj5J4oCZbSBub3Qgc3VyZSB3aGF0IHlvdSBtZWFuIGJ5IOKA nDwvc3Bhbj5J4oCZbSBub3Qgc3VyZSB0aGF0IHdlIG5lZWQgYSDigJxuYW1l4oCdLiBXaGF0IGlz IHlvdXIgaW50ZW50aW9uIHRoZXJlLjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj7igJ0m bmJzcDsNCiBUaGUgb25seSBwbGFjZSBJIHVzZWQgdGhlIHdvcmQg4oCcbmFtZeKAnSB3YXMgaW4g bXkgc3RhdGVtZW50IOKAnERlZmluZSB0aGF0IGFuIGV2ZW50IG5hbWUgY2FuIGJlIHVzZWQgYXMg YSB0b3AtbGV2ZWwgY2xhaW3igJ0uJm5ic3A7IFdoYXQgSSB3YXMgdHJ5aW5nIHRvIGdldCBhdCBp cyB3YXMgdGhhdCBpZiDigJw8YSBocmVmPSJodHRwOi8vc3BlY3Mub3BlbmlkLm5ldC9sb2dvdXQi IHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwOi8vc3BlY3Mu b3BlbmlkLm5ldC9sb2dvdXQ8L3NwYW4+PC9hPuKAnQ0KIGlzIHVzZWQgYXMgYW4gZXZlbnQgbmFt ZSwgdGhhdCBpdCBjYW4gYWxzbyBiZSB1c2VkIGFzIGEgY2xhaW0gbmFtZSBpbiB0aGUgSldUIGNv bnRhaW5pbmcgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGV2ZW50LiZuYnNwOyAoTWF5YmUgSeKAmW0g bm90IHVzaW5nIHRoZSBjb3JyZWN0IHRlcm1pbm9sb2d5LCBoZW5jZSB0aGUgdW5pbnRlbmRlZCBj b25mdXNpb248c3BhbiBjbGFzcz0ibS02NTM0NDM1NTczNjM5NjczNzg2YXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMDAyMDYwIj5KPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMDAyMDYwIj4uKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoYW5r cyBhZ2Fpbiw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48YSBuYW1lPSJtXy02NTM0NDM1NTczNjM5NjczNzg2X19NYWlsRW5kQ29tcG9zZSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48L2E+PHNwYW4gc3R5 bGU9Im1zby1ib29rbWFyazptXy02NTM0NDM1NTczNjM5NjczNzg2X19NYWlsRW5kQ29tcG9zZSI+ PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJtLTY1MzQ0MzU1NzM2 Mzk2NzM3ODZhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9z cGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlBoaWwNCiBIdW50IFs8YSBocmVmPSJtYWlsdG86 cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6 cHVycGxlIj5tYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb208L3NwYW4+PC9hPl08c3BhbiBjbGFz cz0ibS02NTM0NDM1NTczNjM5NjczNzg2YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9Im0tNjUzNDQzNTU3MzYzOTY3Mzc4NmFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlR1ZXNkYXksIEF1Z3VzdCA5LCAyMDE2 IDEyOjA3IFBNPGJyPg0KPGI+VG86PC9iPjxzcGFuIGNsYXNzPSJtLTY1MzQ0MzU1NzM2Mzk2NzM3 ODZhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5NaWtlIEpvbmVzICZsdDs8YSBo cmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+ PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9z cGFuPjwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPjxzcGFuIGNsYXNzPSJtLTY1MzQ0MzU1NzM2Mzk2 NzM3ODZhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86 aWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVy cGxlIj5pZC1ldmVudEBpZXRmLm9yZzwvc3Bhbj48L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+PHNw YW4gY2xhc3M9Im0tNjUzNDQzNTU3MzYzOTY3Mzc4NmFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPlJlOiBbSWQtZXZlbnRdIFN1bW1hcml6aW5nIHJlY2VudCBkaXNjdXNzaW9ucyBv biBJRC1FdmVudCB0b2tlbiBkcmFmdDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkaWRu4oCZdCBjb3ZlciB0aGlzIGFzIEkg ZGlkbuKAmXQgd2FudCB0byBjb25mdXNlIHBlb3BsZSB3aXRoIHRvbyBtYW55IHRoaW5ncy48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJ1dCBJIHRoaW5r IHdlIGFncmVlIG9uIGFsbCBvZiB0aGUgYmVsb3cuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPknigJltIG5vdCBzdXJlIHRoYXQgd2UgbmVl ZCBhIOKAnG5hbWXigJ0uIFdoYXQgaXMgeW91ciBpbnRlbnRpb24gdGhlcmUuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGhpbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5AaW5kZXBlbmRlbnRpZDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNvbS8i IHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj53d3cuaW5kZXBlbmRl bnRpZC5jb208L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5r Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvc3Bhbj48 L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gQXVnIDksIDIwMTYsIGF0IDExOjU0IEFN LCBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQu Y29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+TWljaGFlbC5K b25lc0BtaWNyb3NvZnQuY29tPC9zcGFuPjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMw MDIwNjAiPlRoYW5rcyBmb3Igd3JpdGluZyB0aGlzLCBQaGlsLiZuYnNwOyBVbmZvcnR1bmF0ZWx5 LCB0aGUgc3VtbWFyeSBiZWxvdyBkb2VzIG5vdCBpbmNsdWRlIG15IGZlZWRiYWNrLCB3aGljaCBh dCB0aGUgZXNzZW5jZSwgaXMgdG8ga2VlcCB0aGUgSUQgRXZlbnRzIGRhdGEgc3RydWN0dXJlIGFz DQogc2ltcGxlIGFuZCBnZW5lcmFsLXB1cnBvc2UgYXMgcG9zc2libGUuICZuYnNwOyhJIHN0cm9u Z2x5IGJlbGlldmUgdGhhdCBKV1QgaXMgdGhlIHN1Y2Nlc3MgaXQgaXMgYmVjYXVzZSB3ZSBtYWRl IEpXVCBhcyBzaW1wbGUgYW5kIGdlbmVyYWwtcHVycG9zZSBhcyBwb3NzaWJsZSwgYW5kIHdlIHNo b3VsZCBmb2xsb3cgdGhpcyBzdWNjZXNzZnVsIGV4YW1wbGUgYW5kIGRvIHRoZSBzYW1lIGhlcmUu KTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzAwMjA2MCI+SSBiZWxpZXZlIHRoYXQgdGhlIElEIEV2ZW50cyBzcGVjIG5l ZWRzIHRvIGluY2x1ZGUgdGhlc2UgdGhpbmdzLCBhbmQgdGhlc2UgdGhpbmdzIG9ubHk6PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xvcjojMDAyMDYw Ij7Ctzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOiMwMDIwNjAiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJtLTY1MzQ0MzU1 NzM2Mzk2NzM3ODZhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPkRlZmluZQ0KIG9mIHRoZSDigJxldmVudHPigJ0g Y2xhaW08L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2Nv bG9yOiMwMDIwNjAiPsK3PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6 IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9 Im0tNjUzNDQzNTU3MzYzOTY3Mzc4NmFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu Pjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+RGVmaW5lDQogdGhhdCBhbiBl dmVudCBuYW1lIGNhbiBiZSB1c2VkIGFzIGEgdG9wLWxldmVsIGNsYWltPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xvcjojMDAyMDYwIj7Ctzwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJtLTY1MzQ0MzU1NzM2Mzk2NzM3 ODZhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMwMDIwNjAiPlJlcXVpcmUNCiB0aGF0IOKAnGlzc+KAnSBiZSBpbmNsdWRlZCBh bmQgdGhhdCB0aGUgSldUIGJlIHNpZ25lZCBieSB0aGUgaXNzdWVyPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xvcjojMDAyMDYwIj7Ctzwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJtLTY1MzQ0MzU1NzM2Mzk2NzM3ODZh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMwMDIwNjAiPkluY2x1ZGUNCiBhIHN0YXRlbWVudCBhbG9uZyB0aGUgbGluZXMgb2Yg 4oCcVGhlIGNsYWltcyB0byBiZSBpbmNsdWRlZCB3aXRoIGFueSBwYXJ0aWN1bGFyIGV2ZW50IGFy ZSB0byBiZSBkZWZpbmVkIGJ5IHRoZSBldmVudOKAnTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+QW5kIEni gJlkIHN0b3AgdGhlcmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5JdCBzaG91bGQgYmUgZW50aXJlbHkg dXAgdG8gYXBwbGljYXRpb25zIHRvIHNheSB3aGF0IGNsYWltcyBhcmUgaW5jbHVkZWQgd2l0aCBl dmVudHMgdGhleSBkZWZpbmUgYW5kIHdoYXQgdGhlaXIgZm9ybWF0IGFuZCBtZWFuaW5ncyBhcmUu Jm5ic3A7IFRoZW4gdGhlIElEIEV2ZW50cyBzcGVjDQogd2lsbCBiZSBhcyBnZW5lcmFsLXB1cnBv c2UgYXMgcG9zc2libGUsIHdpdGggaXQgYmVpbmcgbmF0dXJhbCBmb3IgaXQgdG8gYmUgdXNlZCBp biBlc3NlbnRpYWxseSBhbGwgSlNPTiBFdmVudCBjb250ZXh0cy48L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAi PkFzIHNvb24gYXMgd2Ugc3RhcnQgcHV0dGluZyByZXN0cmljdGlvbnMgb24gdGhlIHVzZSBvZiBw YXJ0aWN1bGFyIGNsYWltcyBieSBldmVudHMsIHdl4oCZcmUgbWFraW5nIHRoZSBJRCBFdmVudHMg c3BlYyBsZXNzIGdlbmVyYWwtcHVycG9zZSBhbmQgbGVzcyBuYXR1cmFsIHRvIHVzZS4mbmJzcDsN CiBJbiBwYXJ0aWN1bGFyLCB0aGUgb25seSB0aGluZyB0aGF0IHRoZSBzcGVjIHNob3VsZCBzYXkg YWJvdXQgdGhlIOKAnHN1YuKAnSBjbGFpbSBpcyB0aGF0IOKAnExpa2UgYWxsIG90aGVyIGNsYWlt cyBvdGhlciB0aGFuIOKAmGV2ZW50c+KAmSBhbmQg4oCYaXNz4oCZLCB3aGV0aGVyIHRoZSDigJhz dWLigJkgY2xhaW0gaXMgdG8gYmUgaW5jbHVkZWQgd2l0aCBhbiBldmVudCBpcyBlbnRpcmVseSBl dmVudC1zcGVjaWZpYy4mbmJzcDsgVGhlIGNsYWltcyB0byBiZSBpbmNsdWRlZCB3aXRoIGFueQ0K IHBhcnRpY3VsYXIgZXZlbnQgYXJlIGV4cGxpY2l0bHkgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhp cyBzcGVjaWZpY2F0aW9uLuKAnTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw aW4gMGluIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJtLTY1MzQ0MzU1NzM2 Mzk2NzM3ODZhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9z cGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPklkLWV2ZW50DQogWzxhIGhyZWY9Im1haWx0bzpp ZC1ldmVudC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNv bG9yOnB1cnBsZSI+bWFpbHRvOmlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPl08 c3BhbiBjbGFzcz0ibS02NTM0NDM1NTczNjM5NjczNzg2YXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+PGI+T24gQmVoYWxmIE9mPHNwYW4gY2xhc3M9Im0tNjUzNDQzNTU3MzYzOTY3 Mzc4NmFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5QaGlsDQogSHVudDxi cj4NCjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJtLTY1MzQ0MzU1NzM2Mzk2NzM3ODZhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5UdWVzZGF5LCBBdWd1c3QgOSwgMjAxNiAxMDox OSBBTTxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0ibS02NTM0NDM1NTczNjM5NjczNzg2YXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmlkLWV2ZW50 QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aWQt ZXZlbnRAaWV0Zi5vcmc8L3NwYW4+PC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNz PSJtLTY1MzQ0MzU1NzM2Mzk2NzM3ODZhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj5bSWQtZXZlbnRdIFN1bW1hcml6aW5nIHJlY2VudCBkaXNjdXNzaW9ucyBvbiBJRC1FdmVudCB0 b2tlbiBkcmFmdDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhvdWdodCBJIHdvdWxkIHVwZGF0 ZSB0aGUgbGlzdCBvbiBzb21lIGRpc2N1c3Npb25zIHRoYXQgaGF2ZSBiZWVuIGhhcHBlbmluZyBv dmVyIGluIHRoZSBPcGVuSUQgQ29ubmVjdCBhbmQgUklTQyB3b3JraW5nIGdyb3VwcyBjb25mZXJl bmNlIGNhbGxzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlc2UgZGlzY3Vzc2lvbnMgaGF2ZSBi ZWVuIGFib3V0IHRoZSBjb3JlIHNwZWMgYW5kIHRoZSByb2xlIG9mIOKAnHRvcC1sZXZlbOKAnSBh dHRyaWJ1dGVzIHZzLiBldmVudCDigJxleHRlbnNpb27igJ0gYXR0cmlidXRlcy4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNlZTo8c3BhbiBjbGFzcz0ibS02 NTM0NDM1NTczNjM5NjczNzg2YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEg aHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWh1bnQtaWRldmVudC10b2tl bi0wMSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1odW50LWlkZXZlbnQtdG9rZW4tMDE8L3NwYW4+PC9h PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBwYXJ0aWN1bGFyIHNob3VsZCDigJxz dWLigJ0gYmUgdXNlZCBpbiB0aGUgdG9wIGxldmVsIHRvIOKAnHBvaW504oCdIHRvIHRoZSBzdWJq ZWN0IChpbiB0aGUgYnJvYWRlciBlbmdsaXNoIHNlbnNlKSBvZiB0aGUgZXZlbnQsIG9yIHNob3Vs ZCBpdCBiZSBjb25zdHJhaW5lZCB0byB0aGUgU0FNTC9JRCBUb2tlbiBkZWZpbml0aW9uIHdoaWNo IGlzIHRoZSBhdXRoZW50aWNhdGVkIHVzZXIuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5UYWtlbiBpbiB0aGUgbmFycm93ZXIgZGVmaW5pdGlvbiwgaXQgaXMgaW1wb3J0YW50 IHRvIG9ic2VydmUgdGhhdCBpbiBhbiBJRCBUb2tlbiwg4oCcc3Vi4oCdIGFuZCDigJxpc3PigJ0g Z28gdG9nZXRoZXIuJm5ic3A7IFRoZSBpc3N1ZXIgcHJvdmlkZXMgdGhlIGNvbnRleHQgZm9yIHRo ZSBhdXRoZW50aWNhdGVkIHN1YmplY3QgaWRlbnRpZmllci4gVGhlIHByb2JsZW0gd2l0aCBldmVu dHMsIGlzIHRoYXQgaXQgbWlnaHQgbm90IGJlIHRoZQ0KIEFTIChvciBPUCkgd2hpY2ggaXMgaXNz dWluZyB0aGUgZXZlbnQuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UbyBz dW1tYXJpemUgYSBmYWlyIGFtb3VudCBvZiBkaXNjdXNzaW9uLCB0aGUgZmVlbGluZyBzZWVtcyB0 byBiZSB0aGUgZm9sbG93aW5nOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4qICZuYnNw O1RoZSBFdmVudCBUb2tlbiB0b3AgbGV2ZWwgYXR0cmlidXRlcyBzaG91bGQgYmUgZmFpcmx5IGxp bWl0ZWQgYW5kIG5vdCBpbmNsdWRlIHRoZSBzdWIgYXR0cmlidXRlLiAmbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiogJm5ic3A7Rm9yIGV2ZW50cyB0aGF0IGFy ZSBhYm91dCBhIHVzZXIsIHRoZSByZWxldmFudCBldmVudCBzcGVjaWZpY2F0aW9uIG1heSBpbmNs dWRlIGEg4oCcc3Vi4oCdIGF0dHJpYnV0ZSB3aXRoaW4gdGhlIGV2ZW504oCZcyBzdWItb2JqZWN0 IGFuZCBub3QgaW4gdGhlIHRvcC1sZXZlbC4gRnVydGhlciB0aGF0IHN1Yi1vYmplY3QgY2FuIGFs c28gaW5jbHVkZSB0aGUgaXNzdWVyIG9mIHRoZSB1c2VyLiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiogVGhlIHRvcC1sZXZlbCDigJxpc3PigJ0gc2hhbGwg bWVhbiB0aGUgaXNzdWVyIG9mIHRoZSBldmVudCB3aGVyZSB0aGUgc3RhdGUgY2hhbmdlIG9jY3Vy cmVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KiAmbmJzcDvigJxz dWLigJ0gc2hvdWxkIG5vdCBiZSBwcmVzZW50IGluIHRoZSB0b3AgbGV2ZWwgc3RydWN0dXJlLiZu YnNwOyBBbHNvLCDigJxldmVudHPigJ0gbXVzdCBhbHNvIGJlIHByZXNlbnQuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkhlcmUgd291bGQgYmUgYSBuZXcgZXhhbXBsZSBsb2dvdXQ6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cHJl Pns8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsgJmx0O+KAlCB0b3AgbGV2ZWwgaXMgYWJv dXQgdGhlIGV2ZW50IGl0c2VsZiAtJmd0OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyA8 c3BhbiBzdHlsZT0iY29sb3I6IzVFMzBFQiI+JnF1b3Q7aXNzJnF1b3Q7OiAmcXVvdDs8YSBocmVm PSJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbS8iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHls ZT0iY29sb3I6cHVycGxlIj5odHRwczovL3NlcnZlci5leGFtcGxlLmNvbTwvc3Bhbj48L2E+JnF1 b3Q7LDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6IzVF MzBFQiI+Jm5ic3A7ICZxdW90O2F1ZCZxdW90OzogJnF1b3Q7czZCaGRSa3F0MyZxdW90Oyw8L3Nw YW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOiM1RTMwRUIiPiZu YnNwOyAmcXVvdDtqdGkmcXVvdDs6ICZxdW90OzNkMGMzY2Y3OTc1ODRiZDE5M2JkMGZiMWJkNGU3 ZDMwJnF1b3Q7LDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29s b3I6IzVFMzBFQiI+Jm5ic3A7ICZxdW90O2lhdCZxdW90OzogMTQ1ODY2ODE4MCw8L3NwYW4+PG86 cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOiM1RTMwRUIiPiZuYnNwOyAm cXVvdDtleHAmcXVvdDs6IDE0NTg2Njg1ODAsPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PjxzcGFuIHN0eWxlPSJjb2xvcjojNUUzMEVCIj4mbmJzcDsgJnF1b3Q7ZXZlbnRzJnF1b3Q7OiBb PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjojNUUzMEVC Ij4mbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9zcGVjcy5vcGVuaWQu bmV0L2xvZ291dCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0 dHBzOi8vc3BlY3Mub3BlbmlkLm5ldC9sb2dvdXQ8L3NwYW4+PC9hPiZxdW90Ozwvc3Bhbj48bzpw PjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6IzVFMzBFQiI+Jm5ic3A7IF0s PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiA8c3BhbiBzdHlsZT0iY29sb3I6I0U2M0I3 QSI+Jm5ic3A7JnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9zcGVjcy5vcGVuaWQubmV0L2xvZ291dCIg dGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vc3BlY3Mu b3BlbmlkLm5ldC9sb2dvdXQ8L3NwYW4+PC9hPiZxdW90Ozogezwvc3Bhbj48bzpwPjwvbzpwPjwv cHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6I0U2M0I3QSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZsdDstIFRoaXMgbGV2ZWwgaXMgZGVmaW5lZCBlbnRpcmVseSBieSB0aGUgZXZlbnQgVVJJLSZn dDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOiNFNjNC N0EiPiZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtpc3MmcXVvdDs6ICZxdW90OzxhIGhyZWY9Imh0 dHBzOi8vb2lkYy5leGFtcGxlLmNvbS8iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29s b3I6cHVycGxlIj5odHRwczovL29pZGMuZXhhbXBsZS5jb208L3NwYW4+PC9hPiZxdW90Oyw8L3Nw YW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOiNFNjNCN0EiPiZu YnNwOyZuYnNwOyZuYnNwOyDigJxqdGkmcXVvdDs6ICZxdW90OzA4YTUwMTljLTE3ZTEtNDk3Ny04 ZjQyLTY1YTEyODQzZWEwMuKAnSw8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6I0U2M0I3QSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZxdW90O3N1YiZxdW90OzogJnF1b3Q7MjQ4Mjg5NzYxMDAx4oCdLDwvc3Bhbj48bzpwPjwvbzpw PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjojRTYzQjdB Ij4mbmJzcDsmbmJzcDsmbmJzcDsg4oCcZXhw4oCdOiAmbHQ7SUQgdG9rZW4gZXhwaXJ5Jmd0Ozwv c3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtjb2xvcjojRTYzQjdBIj4mbmJzcDsgfTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+fTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gdGhlIGFib3ZlIGV4YW1w bGUgbm90ZSB0aGF0IHRoZSDigJxldmVudOKAnSBvYmplY3QgY2FuIGhhdmUgaXRzIG93biBpc3Mg YW5kIHN1YmplY3QgKHN1YiBvciBqdGkpIHRoYXQgaGF2ZSBtZWFuaW5nIHdpdGhpbiB0aGUgY29u dGV4dCBvZiBhbiBPcGVuSUQgT1AgcHJvdmlkZXIuJm5ic3A7IFRoZSBpc3N1ZXIgb2YgdGhlIGV2 ZW50IGNhbiBiZSBkaWZmZXJlbnQgKHRoZSB0b3AtbGV2ZWwpIGFuZCByZXByZXNlbnRzIHRoZQ0K IGVudGl0eSB0aGF0IHNpZ25zIHRoZSBldmVudCAoaWYgaXQgaXMgc2lnbmVkKS48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHRvcC1sZXZlbCBhdHRyaWJ1dGVzIGlkZW50aWZ5IGFu IGluZGl2aWR1YWwgZXZlbnQgYW5kIGFyZSB1c2VkIHRvIHZhbGlkYXRlIHRoZSBldmVudCAoc2ln bmluZyBldGMpLiZuYnNwOyBXaGVyZSBhcyB0aGUgbmVzdGVkIG9iamVjdCBjb250YWlucyBhbGwg b2YgdGhlIGRhdGEgYWJvdXQgdGhlIGV2ZW50IGFuZCBpcyBkZWZpbmVkIGJ5IHRoZSBwcm9maWxp bmcgc3BlY2lmaWNhdGlvbiAoZS5nLiBhIHBvc3NpYmxlDQogT3BlbklEIExvZ291dCBFdmVudCBz cGVjKS4mbmJzcDsgSW4gdGhpcyBjYXNlLCBpbiBPcGVuSUQsIGxvZ2dpbmcgb3V0IHVzdWFsbHkg dHJhbnNsYXRlcyBpbnRvIHJldm9raW5nIGFuIElEIFRva2VuLiBUaHVzIHRoZSDigJxqdGnigJ0g Zm9yIHRoZSBJRCB0b2tlbiAoMDhhNTAxOWMuLi44NDNlYTAyKSBpcyBpbmNsdWRlZCBpbiB0aGUg TG9nb3V0IG9iamVjdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2lkZSBub3RlLiZu YnNwOyBSZWdhcmRpbmcg4oCcbG9nb3V04oCdLCBpdCBtaWdodCBiZSB1c2VmdWwgdG8gaW5jbHVk ZSB0aGUgZXhwaXJ5IG9mIHRoZSBJRCBUb2tlbiBpbiBjYXNlIHRoZSBzdWJzY3JpYmVyIGhhcyBu b3QgeWV0IHJlY2VpdmVkIGFuIElEIFRva2VuLiBUaGlzIHdvdWxkIGxldCB0aGUgc3Vic2NyaWJl ciBrbm93IGhvdyBsb25nIGl0IG5lZWRzIHRvIGtlZXAgdGhlIHJldm9jYXRpb24gaW5mb3JtYXRp b24gZm9yLiZuYnNwOw0KIElPV+KApmFmdGVyIHRoZSB0aGUgSUQgVG9rZW4gaXMgZXhwaXJlZCwg dGhlIHN1YnNjcmliZXIgd291bGQgbm8gbG9uZ2VyIG5lZWQgdG8gdHJhY2sgdGhlIHJldm9jYXRp b24gc3RhdGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IGlzIGFsc28gZ29vZCB0 byBvYnNlcnZlIHRoYXQgdGhlIOKAnGF1ZOKAnSBhdCB0aGUgdG9wIGxldmVsIGRlc2NyaWJlcyB0 aGUgc3Vic2NyaWJlciBvZiB0aGUgZXZlbnQuJm5ic3A7IFRoaXMgbWF5IGFsc28gYmUgZGlmZmVy ZW50IHRoZW4gdGhlIG9yaWdpbmFsIGF1ZGllbmNlIG9mIHRoZSBJRCBUb2tlbi48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+U28gdG8gY29uY2x1ZGUuIEJ5IG1ha2luZyB0b3AtbGV2ZWwg YXR0cmlidXRlcyBzdHJpY3RseSBhYm91dCB0aGUgZXZlbnRzIG93biB2YWxpZGF0aW9uLCBhbmQg bmVzdGVkIG9iamVjdHMgYWJvdXQgdGhlIGV2ZW50LCB3ZSBhdm9pZCBjb2xsaXNpb25zIGluIGRl ZmluaXRpb25zIHN1Y2ggYXMgdGhlIGlzc3VlciBvZiB0aGUgZXZlbnQsIHZzLiB0aGUgb3JpZ2lu YWwgaXNzdWVyIG9mIGEgc2VjdXJpdHkgYXNzZXJ0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JIGhvcGUgSeKAmXZlIGdvdHRlbiBldmVyeW9uZeKAmXMgZmVlZGJhY2sgY29ycmVj dCBoZXJlLiBMZXRzIGNvbnRpbnVlIHRvIGRpc2N1c3MuIEkgd2lsbCByZXZpc2UgdGhlIGRyYWZ0 IHRvIGZvbGxvdyB0aGUgZ3JvdXBzIHRoaW5raW5nIGhlcmUuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5QaGlsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkBpbmRlcGVuZGVudGlkPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwOi8vd3d3Lmlu ZGVwZW5kZW50aWQuY29tLyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJw bGUiPnd3dy5pbmRlcGVuZGVudGlkLmNvbTwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Im1haWx0bzpwaGls Lmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJw bGUiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCklkLWV2ZW50IG1haWxpbmcgbGlzdDxicj4NCjwvc3Bhbj48YSBocmVmPSJtYWls dG86SWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOnB1cnBsZSI+SWQtZXZlbnRAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi Pjxicj4NCjwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2lkLWV2ZW50IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpwdXJw bGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ8L3NwYW4+ PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NCklkLWV2ZW50IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0 bzpJZC1ldmVudEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+SWQtZXZlbnRA aWV0Zi5vcmc8L3NwYW4+PC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vaWQtZXZlbnQiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29s b3I6cHVycGxlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50 PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KSWQtZXZlbnQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGll dGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5JZC1ldmVudEBpZXRmLm9yZzwvc3Bh bj48L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9pZC1ldmVudCI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudDwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCklkLWV2ZW50IG1haWxpbmcgbGlzdDxicj4N CjxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9yZyI+SWQtZXZlbnRAaWV0Zi5vcmc8L2E+ PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1l dmVudCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudDwvYT48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_SN1PR0301MB16459867074BFA03B5C401E4F51E0SN1PR0301MB1645_-- From nobody Thu Aug 11 09:49:38 2016 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 197CB12D5CD for ; Thu, 11 Aug 2016 09:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.467 X-Spam-Level: X-Spam-Status: No, score=-5.467 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=-1.247, 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 y3b3I0Jfiwpc for ; Thu, 11 Aug 2016 09:49:33 -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 0CE2112D852 for ; Thu, 11 Aug 2016 09:49:33 -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 u7BGnTB7029566 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 11 Aug 2016 16:49:30 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 u7BGnSwY030864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 11 Aug 2016 16:49:29 GMT Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u7BGnMPZ027917; Thu, 11 Aug 2016 16:49:28 GMT Received: from [192.168.1.15] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 11 Aug 2016 09:49:22 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_5ABB8280-9425-43FD-B243-615D581BE6C8" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Phil Hunt In-Reply-To: Date: Thu, 11 Aug 2016 09:49:20 -0700 Message-Id: <12274564-507F-492B-94E8-C65C6A84FDB7@oracle.com> References: <14E2EF51-7123-4E91-87DD-56AEA08202C1@oracle.com> <3F0DD3E6-46CD-4AA5-8F06-F79140F5D4BE@oracle.com> <56E7DF06-EE77-4FD1-BF44-15A083AC5B5A@ve7jtb.com> To: Mike Jones X-Mailer: Apple Mail (2.3124) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: John Bradley , "openid-specs-ab@lists.openid.net Ab" , "id-event@ietf.org" , Marius Scurtescu Subject: Re: [Id-event] Summarizing recent discussions on ID-Event token draft X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 11 Aug 2016 16:49:36 -0000 --Apple-Mail=_5ABB8280-9425-43FD-B243-615D581BE6C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Mike,=20 Speaking as editor the format you propose ONLY works if =E2=80=9Csub=E2=80= =9D becomes a URI so that all event specs can use it. Otherwise, OIDC = becomes a special case which really kills the point of this work. It = also makes the specification much much more complex. Maybe it is just = me, but a complex spec generally implies complex implementation too. If you want sub at the top level, that would mean that the OIDC spec = format would have to look like: { "iss": "https://event.example.com ", "aud": "s6BhdRkqt3", "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", "sub": =E2=80=9Chttps://token.example.com/248289761001", "iat": 1458668180, "exp": 1458668580, "events": [ "https://specs.openid.net/logout " ], "sid": "08a5019c-17e1-4977-8f42-65a12843ea02" } Given that events are signed (or should be), I will object strongly = within the OIDF that the event issuer and the token issuer MUST be the = same or that OIDF adopt a different format. Yes having iss be the same = is a nice security convenience, but it imposes the architecture = restriction that it be the same server. At scale, delivery of events = may become a problem for large scale providers if they are also = delivering tokens to relying parties. The restriction isn=E2=80=99t = really justified given the crypto alternative =E2=80=94 which was the = whole point of using JWT in the first place. Per Justin=E2=80=99s comment, it seems elegant/trivial that a logout = event simply has logout at the top level and an ID Token attached = (though it might convey a lot of unneeded claims). IMO, the OIDC logout = spec should only convey the ID Token JTI. It is going to be rare that = you log out all devices for a user. To most users, it means clear SSO = within this browser only! One can argue that clearing all = devices/sessions is a different event entirely. It is an account reset = or lock-out action. Phil @independentid www.independentid.com = phil.hunt@oracle.com = > On Aug 11, 2016, at 9:32 AM, Mike Jones = wrote: >=20 > See my previous message, John, which was a reply to Phil=E2=80=99s = message that you also replied to, that contained a logout claims = example. I=E2=80=99m not proposing to special-case the Connect Logout = message in any way. The =E2=80=9Ciss=E2=80=9D is the event issuer. The = other claims in the message are those defined by the event to be = included, just like those for any other event. Yes, the logout message = doesn=E2=80=99t include a second issuer, a second subject, an ID Token = as a claim, or anything else complicated like that, because those things = aren=E2=80=99t needed for the logout use case. > =20 > As I=E2=80=99d written previously, the ID Events spec should define = the =E2=80=9Cevents=E2=80=9D claim, how to use an event name as a claim = (when needed), and say that the event JWT must be signed by the issuer, = and stop there. Trying to micro-manage claims usage within an event = will only result in the ID Events spec being harder to use. If we=E2=80=99= d tried to similarly micro-manage JWT claims usage, JWT would likely not = have been the success that it is. > =20 > -- Mike > =C2=A0 <> > From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20 > Sent: Thursday, August 11, 2016 12:22 PM > To: Phil Hunt (IDM) > Cc: Mike Jones ; id-event@ietf.org; = Marius Scurtescu ; = openid-specs-ab@lists.openid.net Ab > Subject: Re: [Id-event] Summarizing recent discussions on ID-Event = token draft > =20 > Not surprisingly a multipurpose message format will not be as = optimized as a single purpose one. > =20 > Connect itself doesn=E2=80=99t really have a conflict around issuer = the same entity sending the logout message is always the one that = created the id_token that it refers to. > =20 > Using the same format as id_token with the same semantics to identify = the thing to be terminated makes sense from a purely openID Connect = point of view. > =20 > Oter messages that have different notions of subject and are issued by = different parties than the one that controls the subject cause issues = when you try and fit them into the same format as an ID_Token, I grant = you that. > =20 > It was mentioned that we need to differentiate between these events = and id_tokens. Mostly we need to do that in cases where the token might = be presented in the front channel. > =20 > To do that se do have mandatory claims for nonce and c_hash or at_hash = as well as the addition of events parameter to reduce confusion. Now I = admit that some people may still get that wrong, and the removal of sub = from the top level would remove any concern. However Mike has a point = that adoption may be hurt if we change the semantics too much. > =20 > I don=E2=80=99t see backchannel single logout being used by many = social login RP, it is a lot of work to maintain server side state. It = is mostly an enterprise and large site sort of feature. > That may or may not impact on if it is better to be simple and aligned = with connect=E2=80=99s id token or more general purpose to fit with = other enterprise to SaaS features like SCIM events. > =20 > I think the two directions lead to different formats. =20 > =20 > The compromise of special casing Connect SLO and bodging the formats = together is probably the worst option. > =20 > John B. > =20 > =20 > On Aug 11, 2016, at 11:59 AM, Phil Hunt (IDM) > wrote: > =20 > How do you resolve conflicts on iss then? The top level has to be the = issuer of the event as the issuer signs.=20 > =20 > If one spec can use it all must be able to. I believe you previously = objected to that saying sub must be as how id tokens define them. But = that isnt unique and requires iss. Now we would have sub at the top with = an event issuer at the top and a sub issuer in the extension. That seems = incredibly complex not to mention awkward.=20 > =20 > If we make sub a uri for all then it can work ass iss from id token = would not be needed. But i can see many objecting to the change in = format.=20 > =20 > Why not have a logout be an event with an id token attached for = example? >=20 > Phil >=20 > On Aug 11, 2016, at 8:03 AM, Mike Jones > wrote: >=20 > The simple rule is that if the particular event calls for the = =E2=80=9Csub=E2=80=9D claim to be at the top level, then it is. This is = no different from any other claim that an event might place at the top = level. > =20 > The complexity arises if =E2=80=9Csub=E2=80=9D is unnecessarily = special-cased. We shouldn=E2=80=99t do that, because it limits the = applicability of the specification. > =20 > -- Mike > =20 > From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com = ]=20 > Sent: Thursday, August 11, 2016 9:40 AM > To: Mike Jones > > Cc: Marius Scurtescu >; id-event@ietf.org = > Subject: Re: [Id-event] Summarizing recent discussions on ID-Event = token draft > =20 > I think using sub at the top level leads to complexity. Eg Can you = provide a rule for when top level is used or not by an individual spec? = IMO. Top level should always be used the same way by all implementers.=20= > =20 > Based on the calls at risc/connect, we discussed that it would be best = to move all event specifics to the event object area. This way different = events can have different event addressing (eg sub/iss, uri, jit/iss). = When iss is needed to uniquely qualify a sub, it can be provided without = conflicting with the issuer of the event. Similarly jti and iss can be = used for a revoked token without conflicting with the event jti.=20 > =20 > I plan to post a new draft shortly that will give some examples based = on feedback from the openid risc/connect discussions. > =20 > We can always change again.=20 >=20 > Phil >=20 > On Aug 11, 2016, at 4:54 AM, Mike Jones > wrote: >=20 > No, I=E2=80=99m not saying that =E2=80=9Csub=E2=80=9D cannot appear at = the top level. I=E2=80=99m saying that =E2=80=9Csub=E2=80=9D will only = occur at the top level if the particular event defines that =E2=80=9Csub=E2= =80=9D is used in that way for that event. > =20 > There are probably use cases for multiple events per message but I = doubt there are use cases for multiple *unrelated* events per message. = By definition, related events that use top-level claims would need to = use them in a compatible way. I don=E2=80=99t see that as being a = problem. > =20 > That being said, the predominant use case is likely to be a single = event per JWT. > =20 > = -- Mike > =20 > From: Marius Scurtescu [mailto:mscurtescu@google.com = ]=20 > Sent: Tuesday, August 9, 2016 7:15 PM > To: Phil Hunt > > Cc: Mike Jones >; id-event@ietf.org = > Subject: Re: [Id-event] Summarizing recent discussions on ID-Event = token draft > =20 > Mike, are you suggesting that a sub claim can only show up at the = event level and not at the top level: > =20 > In particular, the only thing that the spec should say about the = =E2=80=9Csub=E2=80=9D claim is that =E2=80=9CLike all other claims other = than =E2=80=98events=E2=80=99 and =E2=80=98iss=E2=80=99, whether the = =E2=80=98sub=E2=80=99 claim is to be included with an event is entirely = event-specific. > =20 > A top level sub and multiple events are incompatible IMO. > =20 > Do we have a compelling reason to support multiple events per message? > =20 >=20 > Marius > =20 > On Tue, Aug 9, 2016 at 12:39 PM, Phil Hunt > wrote: > I was referring to this in your email > "Define that an event name can be used as a top-level claim=E2=80=9D > =20 > =20 > Is this different from the event uri? > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > =20 > =20 >=20 > =20 > On Aug 9, 2016, at 12:12 PM, Mike Jones > wrote: > =20 > I=E2=80=99m glad to hear that we agree on keeping it as simple and = general-purpose as possible and that you agree with my write-up. I = think we then have a good path forward. > =20 > I=E2=80=99m not sure what you mean by =E2=80=9CI=E2=80=99m not sure = that we need a =E2=80=9Cname=E2=80=9D. What is your intention there.=E2=80= =9D The only place I used the word =E2=80=9Cname=E2=80=9D was in my = statement =E2=80=9CDefine that an event name can be used as a top-level = claim=E2=80=9D. What I was trying to get at is was that if = =E2=80=9Chttp://specs.openid.net/logout = =E2=80=9D is used as an event name, that = it can also be used as a claim name in the JWT containing information = about the event. (Maybe I=E2=80=99m not using the correct terminology, = hence the unintended confusion J.) > =20 > Thanks again, > -- Mike > =C2=A0 <> > From: Phil Hunt [mailto:phil.hunt@oracle.com = ]=20 > Sent: Tuesday, August 9, 2016 12:07 PM > To: Mike Jones > > Cc: id-event@ietf.org > Subject: Re: [Id-event] Summarizing recent discussions on ID-Event = token draft > =20 > I didn=E2=80=99t cover this as I didn=E2=80=99t want to confuse people = with too many things. > =20 > But I think we agree on all of the below. > =20 > I=E2=80=99m not sure that we need a =E2=80=9Cname=E2=80=9D. What is = your intention there. > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > =20 > =20 >=20 > =20 > On Aug 9, 2016, at 11:54 AM, Mike Jones > wrote: > =20 > Thanks for writing this, Phil. Unfortunately, the summary below does = not include my feedback, which at the essence, is to keep the ID Events = data structure as simple and general-purpose as possible. (I strongly = believe that JWT is the success it is because we made JWT as simple and = general-purpose as possible, and we should follow this successful = example and do the same here.) > =20 > I believe that the ID Events spec needs to include these things, and = these things only: > =C2=B7 Define of the =E2=80=9Cevents=E2=80=9D claim > =C2=B7 Define that an event name can be used as a top-level = claim > =C2=B7 Require that =E2=80=9Ciss=E2=80=9D be included and that = the JWT be signed by the issuer > =C2=B7 Include a statement along the lines of =E2=80=9CThe = claims to be included with any particular event are to be defined by the = event=E2=80=9D > =20 > And I=E2=80=99d stop there. > =20 > It should be entirely up to applications to say what claims are = included with events they define and what their format and meanings are. = Then the ID Events spec will be as general-purpose as possible, with it = being natural for it to be used in essentially all JSON Event contexts. > =20 > As soon as we start putting restrictions on the use of particular = claims by events, we=E2=80=99re making the ID Events spec less = general-purpose and less natural to use. In particular, the only thing = that the spec should say about the =E2=80=9Csub=E2=80=9D claim is that = =E2=80=9CLike all other claims other than =E2=80=98events=E2=80=99 and = =E2=80=98iss=E2=80=99, whether the =E2=80=98sub=E2=80=99 claim is to be = included with an event is entirely event-specific. The claims to be = included with any particular event are explicitly outside the scope of = this specification.=E2=80=9D > =20 > -- Mike > =20 > From: Id-event [mailto:id-event-bounces@ietf.org = ] On Behalf Of Phil Hunt > Sent: Tuesday, August 9, 2016 10:19 AM > To: id-event@ietf.org > Subject: [Id-event] Summarizing recent discussions on ID-Event token = draft > =20 > I thought I would update the list on some discussions that have been = happening over in the OpenID Connect and RISC working groups conference = calls. > =20 > These discussions have been about the core spec and the role of = =E2=80=9Ctop-level=E2=80=9D attributes vs. event =E2=80=9Cextension=E2=80=9D= attributes.=20 > See: https://tools.ietf.org/html/draft-hunt-idevent-token-01 = > =20 > In particular should =E2=80=9Csub=E2=80=9D be used in the top level to = =E2=80=9Cpoint=E2=80=9D to the subject (in the broader english sense) of = the event, or should it be constrained to the SAML/ID Token definition = which is the authenticated user. =20 > =20 > Taken in the narrower definition, it is important to observe that in = an ID Token, =E2=80=9Csub=E2=80=9D and =E2=80=9Ciss=E2=80=9D go = together. The issuer provides the context for the authenticated subject = identifier. The problem with events, is that it might not be the AS (or = OP) which is issuing the event. =20 > =20 > To summarize a fair amount of discussion, the feeling seems to be the = following: > =20 > * The Event Token top level attributes should be fairly limited and = not include the sub attribute. =20 > * For events that are about a user, the relevant event specification = may include a =E2=80=9Csub=E2=80=9D attribute within the event=E2=80=99s = sub-object and not in the top-level. Further that sub-object can also = include the issuer of the user. =20 > * The top-level =E2=80=9Ciss=E2=80=9D shall mean the issuer of the = event where the state change occurred. > * =E2=80=9Csub=E2=80=9D should not be present in the top level = structure. Also, =E2=80=9Cevents=E2=80=9D must also be present. > =20 > Here would be a new example logout: > { > <=E2=80=94 top level is about the event itself -> > "iss": "https://server.example.com ", > "aud": "s6BhdRkqt3", > "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", > "iat": 1458668180, > "exp": 1458668580, > "events": [ > "https://specs.openid.net/logout = " > ], > "https://specs.openid.net/logout ": = { > <- This level is defined entirely by the event URI-> > "iss": "https://oidc.example.com ", > =E2=80=9Cjti": "08a5019c-17e1-4977-8f42-65a12843ea02=E2=80=9D, > "sub": "248289761001=E2=80=9D, > =E2=80=9Cexp=E2=80=9D: > } > } > =20 > In the above example note that the =E2=80=9Cevent=E2=80=9D object can = have its own iss and subject (sub or jti) that have meaning within the = context of an OpenID OP provider. The issuer of the event can be = different (the top-level) and represents the entity that signs the event = (if it is signed). > =20 > The top-level attributes identify an individual event and are used to = validate the event (signing etc). Where as the nested object contains = all of the data about the event and is defined by the profiling = specification (e.g. a possible OpenID Logout Event spec). In this case, = in OpenID, logging out usually translates into revoking an ID Token. = Thus the =E2=80=9Cjti=E2=80=9D for the ID token (08a5019c...843ea02) is = included in the Logout object. > =20 > Side note. Regarding =E2=80=9Clogout=E2=80=9D, it might be useful to = include the expiry of the ID Token in case the subscriber has not yet = received an ID Token. This would let the subscriber know how long it = needs to keep the revocation information for. IOW=E2=80=A6after the the = ID Token is expired, the subscriber would no longer need to track the = revocation state. > =20 > It is also good to observe that the =E2=80=9Caud=E2=80=9D at the top = level describes the subscriber of the event. This may also be different = then the original audience of the ID Token. > =20 > So to conclude. By making top-level attributes strictly about the = events own validation, and nested objects about the event, we avoid = collisions in definitions such as the issuer of the event, vs. the = original issuer of a security assertion. > =20 > I hope I=E2=80=99ve gotten everyone=E2=80=99s feedback correct here. = Lets continue to discuss. I will revise the draft to follow the groups = thinking here. > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =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://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://www.ietf.org/mailman/listinfo/id-event --Apple-Mail=_5ABB8280-9425-43FD-B243-615D581BE6C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Mike, 

Speaking as editor the format you propose ONLY works if = =E2=80=9Csub=E2=80=9D becomes a URI so that all event specs can use it. =  Otherwise, OIDC becomes a special case which really kills the = point of this work. It also makes the specification much much more = complex. Maybe it is just me, but a complex spec generally implies = complex implementation too.

If you want sub at the top level, that would mean that the = OIDC spec format would have to look like:
{
  "iss": "https://event.example.com",
  "aud": "s6BhdRkqt3",
 = "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
 = "sub": =E2=80=9Chttps://token.example.com/248289761001",
 = "iat": 1458668180,
  "exp": 1458668580,
  "events": [
 =   "https://specs.openid.net/logout"
 = ],
 = "sid": "08a5019c-17e1-4977-8f42-65a12843ea02"
}

Given that = events are signed (or should be), I will object strongly = within the OIDF that the event issuer and the token issuer MUST be the = same or that OIDF adopt a different format. Yes having iss be the = same is a nice security convenience, but it imposes the architecture = restriction that it be the same server.  At scale, delivery of = events may become a problem for large scale providers if they are also = delivering tokens to relying parties. The restriction isn=E2=80=99t = really justified given the crypto alternative =E2=80=94 which was the = whole point of using JWT in the first place.

Per Justin=E2=80=99s comment, it seems = elegant/trivial that a logout event simply has logout at the top level = and an ID Token attached (though it might convey a lot of unneeded = claims).  IMO, the OIDC logout spec should only convey the ID Token = JTI.  It is going to be rare that you log out all devices for a = user.  To most users, it means clear SSO within this browser only! =  One can argue that clearing all devices/sessions is a different = event entirely. It is an account reset or lock-out action.




On Aug 11, 2016, at 9:32 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

See my previous message, John, which was a = reply to Phil=E2=80=99s message that you also replied to, that contained = a logout claims example.  I=E2=80=99m not proposing to special-case = the Connect Logout message in any way.  The =E2=80=9Ciss=E2=80=9D = is the event issuer.  The other claims in the message are those = defined by the event to be included, just like those for any other = event.  Yes, the logout message doesn=E2=80=99t include a second = issuer, a second subject, an ID Token as a claim, or anything else = complicated like that, because those things aren=E2=80=99t needed for = the logout use case.
 
As I=E2=80=99d written = previously, the ID Events spec should define the =E2=80=9Cevents=E2=80=9D = claim, how to use an event name as a claim (when needed), and say that = the event JWT must be signed by the issuer, and stop there.  Trying = to micro-manage claims usage within an event will only result in the ID = Events spec being harder to use.  If we=E2=80=99d tried to = similarly micro-manage JWT claims usage, JWT would likely not have been = the success that it is.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;       -- Mike
 
From: John Bradley [mailto:ve7jtb@ve7jtb.com] 
Sent: Thursday, August 11, 2016 = 12:22 PM
To: Phil Hunt (IDM) <phil.hunt@oracle.com>
Cc: Mike = Jones <Michael.Jones@microsoft.com>; id-event@ietf.org; = Marius Scurtescu <mscurtescu@google.com>; openid-specs-ab@lists.openid.net Ab <openid-specs-ab@lists.openid.net>
Subject: Re: [Id-event] Summarizing = recent discussions on ID-Event token draft
 
Not surprisingly a multipurpose message format will not be as = optimized as a single purpose one.
 
Connect itself doesn=E2=80=99t really have a conflict = around issuer the same entity sending the logout message is always the = one that created the id_token that it refers to.
 
Using the same format as id_token with = the same semantics to identify the thing to be terminated makes sense = from a purely openID Connect point of view.
 
Oter messages that have different notions = of subject and are issued by different parties than the one that = controls the subject cause issues when you try and fit them into the = same format as an ID_Token, I grant you that.
 
It was mentioned that we need to = differentiate between these events and id_tokens.  Mostly we need = to do that in cases where the token might be presented in the front = channel.
 
To do that se do have mandatory claims for nonce and = c_hash or at_hash as well as the addition of events parameter to reduce = confusion.   Now I admit that some people may still get that wrong, =  and the removal of sub from the top level would remove any = concern.  However Mike has a point that adoption may be hurt if we = change the semantics too much.
 
I don=E2=80=99t see backchannel single logout being = used by many social login RP, it is a lot of work to maintain server = side state.   It is mostly an enterprise and large site sort of = feature.
That may or may not impact on if it is = better to be simple and aligned with connect=E2=80=99s id token or more = general purpose to fit with other enterprise to SaaS features like SCIM = events.
 
I think the two directions lead to different formats. =   
 
The compromise of special casing Connect SLO and = bodging the formats together is probably the worst option.
 
John B.
 
 
On = Aug 11, 2016, at 11:59 AM, Phil Hunt (IDM) <phil.hunt@oracle.com> = wrote:
 
How do you resolve conflicts on iss then?  The top level = has to be the issuer of the event as the issuer signs. 
 
If one spec can use it = all must be able to. I believe you previously objected to that saying = sub must be as how id tokens define them. But that isnt unique and = requires iss. Now we would have sub at the top with an event issuer at = the top and a sub issuer in the extension. That seems incredibly complex = not to mention awkward. 
 
If we make sub a uri for all then it can work ass iss from id = token would not be needed. But i can see many objecting to the change in = format. 
 
Why not have a logout be = an event with an id token attached for example?

Phil


On Aug 11, 2016, at 8:03 AM, Mike = Jones <Michael.Jones@microsoft.com> = wrote:

The simple rule is that if the particular = event calls for the =E2=80=9Csub=E2=80=9D claim to be at the top level, = then it is.  This is no different from any other claim that an = event might place at the top level.
 
The complexity arises if = =E2=80=9Csub=E2=80=9D is unnecessarily special-cased.  We = shouldn=E2=80=99t do that, because it limits the applicability of the = specification.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;       -- Mike
 
From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com] 
Sent: Thursday, August 11, 2016 = 9:40 AM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: Marius Scurtescu <mscurtescu@google.com>; id-event@ietf.org
Subject: Re: [Id-event] Summarizing = recent discussions on ID-Event token draft
 
I think using sub at the top level leads = to complexity. Eg Can you provide a rule for when top level is used or = not by an individual spec?  IMO. Top level should always be used = the same way by all implementers. 
 
Based on the calls at risc/connect, we = discussed that it would be best to move all event specifics to the event = object area. This way different events can have different event = addressing (eg sub/iss, uri, jit/iss). When iss is needed to uniquely = qualify a sub, it can be provided without conflicting with the issuer of = the event. Similarly jti and iss can be used for a revoked token without = conflicting with the event jti. 
 
I plan to post a new draft shortly that = will give some examples based on feedback from the openid risc/connect = discussions.
 
We can always change again. 

Phil


On Aug 11, 2016, at 4:54 AM, Mike Jones = <Michael.Jones@microsoft.com> = wrote:

No, = I=E2=80=99m not saying that =E2=80=9Csub=E2=80=9D cannot appear at the = top level.  I=E2=80=99m saying that =E2=80=9Csub=E2=80=9D will only = occur at the top level if the particular event defines that =E2=80=9Csub=E2= =80=9D is used in that way for that event.
 
There are probably use = cases for multiple events per message but I doubt there are use cases = for multiple *unrelated* events per message.  By = definition, related events that use top-level claims would need to use = them in a compatible way.  I don=E2=80=99t see that as being a = problem.
 
That being said, the predominant use case is = likely to be a single event per JWT.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;         -- Mike
 
From: Marius Scurtescu [mailto:mscurtescu@google.com] 
Sent: Tuesday, August 9, 2016 = 7:15 PM
To: Phil Hunt <phil.hunt@oracle.com>
Cc: Mike = Jones <Michael.Jones@microsoft.com>; id-event@ietf.org
Subject: Re: [Id-event] Summarizing = recent discussions on ID-Event token draft
 
Mike, are you = suggesting that a sub claim can only show up at the event level and not = at the top level:
 
In particular, the only thing that the spec should say about = the =E2=80=9Csub=E2=80=9D claim is that =E2=80=9CLike all other claims = other than =E2=80=98events=E2=80=99 and =E2=80=98iss=E2=80=99, whether = the =E2=80=98sub=E2=80=99 claim is to be included with an event is = entirely event-specific.
 
A top level sub and multiple events are = incompatible IMO.
 
Do = we have a compelling reason to support multiple events per message?
 

Marius
 
On Tue, Aug 9, 2016 at 12:39 PM, Phil = Hunt <phil.hunt@oracle.com> = wrote:
I was referring to this in your email
"Define that an event name can be used as a top-level = claim=E2=80=9D
 
 
Is = this different from the event uri?
 
Phil
 
@independentid
www.independentid.com
phil.hunt@oracle.com
 
 

 

 
On = Aug 9, 2016, at 12:12 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
 
I=E2=80= =99m glad to hear that we agree on keeping it as simple and = general-purpose as possible and that you agree with my write-up.  I = think we then have a good path forward.
 
I=E2=80=99m not sure what you mean by = =E2=80=9CI=E2=80=99m not sure that we need a =E2=80=9Cname=E2=80=9D= . What is your intention there.=E2=80=9D  The only place I used the word =E2=80=9Cname=E2= =80=9D was in my statement =E2=80=9CDefine that an event name can be = used as a top-level claim=E2=80=9D.  What I was trying to get at is = was that if =E2=80=9Chttp://specs.openid.net/logout=E2=80=9D is used as = an event name, that it can also be used as a claim name in the JWT = containing information about the event.  (Maybe I=E2=80=99m not = using the correct terminology, hence the unintended confusion <= span style=3D"font-size: 11pt; font-family: Wingdings; color: rgb(0, 32, = 96);" class=3D"">J.)
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;       Thanks again,
          &nb= sp;            = ;            &= nbsp;           &nb= sp;       -- Mike
 
From: Phil Hunt [mailto:phil.hunt@oracle.com] 
Sent: Tuesday,= August 9, 2016 12:07 PM
To: Mike = Jones <Michael.Jones@microsoft.com>
Cc: id-event@ietf.org
Subject: Re: = [Id-event] Summarizing recent discussions on ID-Event token = draft
 
I didn=E2=80=99t cover this as I didn=E2=80= =99t want to confuse people with too many things.
 
But = I think we agree on all of the below.
 
I=E2=80=99m not sure that we need a =E2=80=9Cname=E2=80=9D. = What is your intention there.
 
Phil
 
@independentid
www.independentid.com
phil.hunt@oracle.com
 
 

 

 
On Aug 9, 2016, at 11:54 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:
 
Thanks for writing this, Phil.  = Unfortunately, the summary below does not include my feedback, which at = the essence, is to keep the ID Events data structure as simple and = general-purpose as possible.  (I strongly believe that JWT is the = success it is because we made JWT as simple and general-purpose as = possible, and we should follow this successful example and do the same = here.)
 
I believe that the ID Events spec needs to = include these things, and these things only:
=C2=B7       <= span style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: = rgb(0, 32, 96);" class=3D"">Define of the =E2=80=9Cevents=E2=80=9D = claim
=C2=B7       <= span style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: = rgb(0, 32, 96);" class=3D"">Define that an event name can be used as a = top-level claim
=C2=B7       <= span style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: = rgb(0, 32, 96);" class=3D"">Require that =E2=80=9Ciss=E2=80=9D be = included and that the JWT be signed by the issuer
=C2=B7       <= span style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: = rgb(0, 32, 96);" class=3D"">Include a statement along the lines of = =E2=80=9CThe claims to be included with any particular event are to be = defined by the event=E2=80=9D
 
And I=E2=80=99d stop there.
 
It should be entirely up to applications to = say what claims are included with events they define and what their = format and meanings are.  Then the ID Events spec will be as = general-purpose as possible, with it being natural for it to be used in = essentially all JSON Event contexts.
 
As soon as we start putting restrictions on = the use of particular claims by events, we=E2=80=99re making the ID = Events spec less general-purpose and less natural to use.  In = particular, the only thing that the spec should say about the =E2=80=9Csub= =E2=80=9D claim is that =E2=80=9CLike all other claims other than = =E2=80=98events=E2=80=99 and =E2=80=98iss=E2=80=99, whether the = =E2=80=98sub=E2=80=99 claim is to be included with an event is entirely = event-specific.  The claims to be included with any particular = event are explicitly outside the scope of this = specification.=E2=80=9D
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;       -- Mike
 
From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Phil= Hunt
Sent: Tuesday,= August 9, 2016 10:19 AM
To: id-event@ietf.org
Subject: [Id-even= t] Summarizing recent discussions on ID-Event token draft
 
I thought I would update the list on some discussions that = have been happening over in the OpenID Connect and RISC working groups = conference calls.
 
These discussions have been about the core spec and the role = of =E2=80=9Ctop-level=E2=80=9D attributes vs. event =E2=80=9Cextension=E2=80= =9D attributes. 
 
Taken in the narrower definition, it is = important to observe that in an ID Token, =E2=80=9Csub=E2=80=9D and = =E2=80=9Ciss=E2=80=9D go together.  The issuer provides the context = for the authenticated subject identifier. The problem with events, is = that it might not be the AS (or OP) which is issuing the event. =  
 
*  The Event Token top level = attributes should be fairly limited and not include the sub attribute. =  
*  For events that are about a user, = the relevant event specification may include a =E2=80=9Csub=E2=80=9D = attribute within the event=E2=80=99s sub-object and not in the = top-level. Further that sub-object can also include the issuer of the = user.  
* The top-level =E2=80=9Ciss=E2=80=9D = shall mean the issuer of the event where the state change occurred.
 
{
  <=E2=80=94 top level is about the =
event itself ->
  "iss": "https://server.example.com",
  "aud": =
"s6BhdRkqt3",
  =
"jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
  "iat": =
1458668180,
  =
"exp": 1458668580,
  =
"events": [
    "https://specs.openid.net/logout"
  ],
  "https://specs.openid.net/logout": =
{
    <- =
This level is defined entirely by the event URI->
    "iss": =
"https://oidc.example.com",
    =
=E2=80=9Cjti": "08a5019c-17e1-4977-8f42-65a12843ea02=E2=80=9D,
    "sub": "248289761001=E2=80=9D,
    =E2=80=9Cexp=E2=80=9D: <ID token =
expiry>
  }
}
 
In the above example note that the = =E2=80=9Cevent=E2=80=9D object can have its own iss and subject (sub or = jti) that have meaning within the context of an OpenID OP = provider.  The issuer of the event can be different (the top-level) = and represents the entity that signs the event (if it is signed).
 
The top-level attributes identify an = individual event and are used to validate the event (signing etc).  = Where as the nested object contains all of the data about the event and = is defined by the profiling specification (e.g. a possible OpenID Logout = Event spec).  In this case, in OpenID, logging out usually = translates into revoking an ID Token. Thus the =E2=80=9Cjti=E2=80=9D for = the ID token (08a5019c...843ea02) is included in the Logout object.
 
Side note.  Regarding =E2=80=9Clogout=E2= =80=9D, it might be useful to include the expiry of the ID Token in case = the subscriber has not yet received an ID Token. This would let the = subscriber know how long it needs to keep the revocation information = for.  IOW=E2=80=A6after the the ID Token is expired, the subscriber = would no longer need to track the revocation state.
 
It is also good to observe that the = =E2=80=9Caud=E2=80=9D at the top level describes the subscriber of the = event.  This may also be different then the original audience of = the ID Token.
 
So to conclude. By making top-level attributes strictly about = the events own validation, and nested objects about the event, we avoid = collisions in definitions such as the issuer of the event, vs. the = original issuer of a security assertion.
 
I hope I=E2=80=99ve gotten everyone=E2=80=99= s feedback correct here. Lets continue to discuss. I will revise the = draft to follow the groups thinking here.
 
Phil
 
@independentid
 
_______________________________________________
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=
= --Apple-Mail=_5ABB8280-9425-43FD-B243-615D581BE6C8-- From nobody Thu Aug 11 10:02:07 2016 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 3BBF412D8A5 for ; Thu, 11 Aug 2016 10:02: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=[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 Y_ewkKiZBXyc for ; Thu, 11 Aug 2016 10:02:01 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0106.outbound.protection.outlook.com [104.47.37.106]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46BEE12D871 for ; Thu, 11 Aug 2016 10:02: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=JQEn92GrNUKAtb4ZUpWeL3yr8MYm70acEdj0eYL8Y+E=; b=gT4IHgbqwzC8MeF/lelg/Y9yzyt5bBX5vB1eFcOseOTTtbLPnmjE97HjyU1DGdzl0mtkjT//BGwxn+blpJk6H/o/hEOWWxW88k4Ud/x+5t8ebecgSgg9fN4qDS0rqC3TZnxVvnNcTqsOfm3cVks66QTymj5jbu4at0SaF+MrCbk= Received: from SN1PR0301MB1645.namprd03.prod.outlook.com (10.162.130.139) by SN1PR0301MB1647.namprd03.prod.outlook.com (10.162.130.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Thu, 11 Aug 2016 17:01:58 +0000 Received: from SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) by SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) with mapi id 15.01.0549.025; Thu, 11 Aug 2016 17:01:58 +0000 From: Mike Jones To: Phil Hunt Thread-Topic: [Id-event] Summarizing recent discussions on ID-Event token draft Thread-Index: AQHR8mIWLvqeOEkcuEuQk5SeT4z/pKBA9pTwgAAG/gCAAABNAIAACP2AgAA8CICAAmTu0IAAHwwAgAAWu7CAABBwgIAABkgAgAAA3UCAAAaqAIAAAJ3g Date: Thu, 11 Aug 2016 17:01:58 +0000 Message-ID: References: <14E2EF51-7123-4E91-87DD-56AEA08202C1@oracle.com> <3F0DD3E6-46CD-4AA5-8F06-F79140F5D4BE@oracle.com> <56E7DF06-EE77-4FD1-BF44-15A083AC5B5A@ve7jtb.com> <12274564-507F-492B-94E8-C65C6A84FDB7@oracle.com> In-Reply-To: <12274564-507F-492B-94E8-C65C6A84FDB7@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.201.94.142] x-ms-office365-filtering-correlation-id: 9fb73f52-7f38-4816-3460-08d3c209349d x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1647; 6:yUIt+f/PDPx2bjYT6C2/GJb/npaVaYHpzxWCUI/BMF2EZ5tlODC5AxQPgn/3m5WCVZF+hh7YfWdKXmpNKHFHOzIwxf3ot+26lJAmJntArcjWDNHzIJ/Qnw0FjVc51EwgYNnSOqcJ56bpVZf42Doct8RpNiJwhl0xXycRGBobqzevPO0KmG+QtIWBzXgoyzYnFIkBQXVAgaunbd82mAbqZjpKRR3gFa+u6i0wlPa4SV0NT5BnvvNHFJBnf19N+5JKS7gkTdszv+WeG7Ne75Ca5uXGyWtoBcjznmmROL19wepcGmkltcXhuRUurjRATTz8SECf7jSz1t9oUoKp3S6Fyw==; 5:eYuhON2asvxYTiNBO1dX6GCDpYEMyCCzrxTQ6Tp+FiDakx74vLtikbjh8k0/yIUM7cSBhVIA0g8ep3ypMOAC5gy7BN3JnRseoq5oLmAXQnrm7KY0Ol+vmuDcNfkv2jymSxGwCzE4zPdl6eTzhgaQDg==; 24:wW68E63xgP9Ph/DHzAPi4gg8J/X22OdgjBI0ozZG6O7VEOyPKqJvv6CXZOQ3I8VfKlnSq9AdILbCVY+viy8YIMMDzmdHoosidM4Wh5gfVzc=; 7:PDe74wyW66qmOZbAvtPH5mamVNFyjEXVB1PMzShekg+GdJgAFXaYcwA+MztesmoTVvnhyopy0ZXl8OnGZDZ/HkIb8fjHz2Bntn4YoOhr6A0OvCIzC7EOXyNxXrCB3k68AwaMTU4JLZjL2HDId4EyhpgKwr5Mckm6fMvh80A8NPQkbAtyLdislvZp+2wFEMnI7/xFiDQ/VfpHN6e53jsWmAlsaWLNE7I8zU7ALqdT/VsX26BM/ZHvinJn25HJ9JNA x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1647; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(278428928389397)(192374486261705)(211936372134217)(21748063052155)(21532816269658)(146099531331640); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:SN1PR0301MB1647; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1647; x-forefront-prvs: 0031A0FFAF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(43784003)(199003)(189002)(24454002)(377454003)(81166006)(586003)(92566002)(7846002)(97736004)(93886004)(2900100001)(74316002)(2950100001)(77096005)(7906003)(11100500001)(8676002)(15975445007)(110136002)(7696003)(6116002)(1860700003)(4326007)(5890100001)(790700001)(3846002)(189998001)(3280700002)(2906002)(1680700002)(8990500004)(122556002)(5005710100001)(10400500002)(7736002)(102836003)(10090500001)(10290500002)(8936002)(3660700001)(81156014)(9686002)(68736007)(54356999)(19625215002)(5002640100001)(50986999)(101416001)(76176999)(33656002)(99286002)(19580395003)(19300405004)(19617315012)(19580405001)(76576001)(106116001)(106356001)(86362001)(19609705001)(575784001)(87936001)(105586002)(16601075003)(66066001)(86612001)(16236675004)(579004)(559001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0301MB1647; H:SN1PR0301MB1645.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB164534BDE4F6485B1CAC4FACF51E0SN1PR0301MB1645_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Aug 2016 17:01:58.1052 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1647 Archived-At: Cc: John Bradley , "openid-specs-ab@lists.openid.net Ab" , "id-event@ietf.org" , Marius Scurtescu Subject: Re: [Id-event] Summarizing recent discussions on ID-Event token draft X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 11 Aug 2016 17:02:05 -0000 --_000_SN1PR0301MB164534BDE4F6485B1CAC4FACF51E0SN1PR0301MB1645_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WW914oCZcmUgYXdhcmUgdGhhdCBmb3JjaW5nIOKAnHN1YuKAnSB0byBiZSBhIFVSSSBpcyBhIGJy ZWFraW5nIGNoYW5nZSBmb3IgbW9zdCBpbXBsZW1lbnRhdGlvbnMsIHJpZ2h0PyAgVGhpcyBpcyBo YXJkbHkgYSB3YXkgdG8gZW5jb3VyYWdlIGFkb3B0aW9uIQ0KDQpUaGUgdGhpbmcgeW91IHdyb3Rl IGJlbG93IHRoYXQgbWFrZXMgbWUgdGhpbmsgdGhhdCB5b3XigJlyZSB0aGlua2luZyBhYm91dCB0 aGUgcHVycG9zZSBvZiB0aGUgSUQgRXZlbnRzIHNwZWMgZGlmZmVyZW50bHkgdGhhbiBtZSBpcyB0 aGlzOiDigJxzbyB0aGF0IGFsbCBldmVudCBzcGVjcyBjYW4gdXNlIGl04oCdLiAgVGhlIHB1cnBv c2Ugb2YgdGhlIGxvZ291dCBldmVudCAqaXNu4oCZdCogZm9yIGFsbCBldmVudCBzcGVjcyB0byB1 c2UgaXQuICBJdOKAmXMgZm9yIHRoZSBsb2dvdXQgdXNlIGNhc2UgdG8gdXNlIGl0LiAgVGhlcmXi gJlzIG5vIGV4cGVjdGF0aW9uIHRoYXQgZXZlbnRzIGludGVuZGVkIGZvciBvbmUgdXNlIGNhc2Ug d2lsbCBldmVuIGJlIGNvbXByZWhlbnNpYmxlIGluIG90aGVyIHVzZSBjYXNlcyBiZWNhdXNlIHRo ZXkgd29u4oCZdCB1bmRlcnN0YW5kIHRoZSBjb250ZW50cyBvZiB0aGUgZXZlbnQuICBXZSBzaG91 bGRu4oCZdCBkcml2ZSBhbnkgb2YgdGhlIGRlc2lnbiBieSB0cnlpbmcgdG8gYWNoaWV2ZSB0aGF0 IHVuYWNoaWV2YWJsZSBnb2FsLCBzaW5jZSBldmVudHMgd2lsbCAqYWx3YXlzKiBjb250YWluIGlu Zm9ybWF0aW9uIHRoYXTigJlzIHNwZWNpZmljIHRvIHRoZWlyIHVzZSBjYXNlLg0KDQpZb3XigJly ZSBtYWtpbmcgY29tcGxleGl0eSBhcmd1bWVudHMsIHdoZXJlYXMgeW914oCZcmUgYWxzbyBwcm9w b3NpbmcgbW9yZSBjb21wbGV4IHJ1bGVzIHRoYW4gSSBhbSAoYXQgbGVhc3QgYXMgSSBzZWUgaXQp LiAgVHJ5aW5nIHRvIHJlc3RyaWN0IHRoZSB1c2Ugb2Yg4oCcc3Vi4oCdIChvciBhbnkgb3RoZXIg Y2xhaW1zKSBpcyB1bm5lZWRlZCBjb21wbGV4aXR5Lg0KDQpJIHVuZGVyc3RhbmQgdGhhdCB5b3Ug c2VlIHRoaW5ncyBkaWZmZXJlbnRseS4gIEkgaG9wZSB5b3XigJlsbCBub25ldGhlbGVzcyB0aGlu ayBhYm91dCBteSBhcmd1bWVudCB0aGF0IGhhdmluZyBmZXdlciBydWxlcyBhYm91dCBjbGFpbXMg dXNhZ2UgaW4gZXZlbnRzIHdpbGwgbWFrZSB0aGVtIHNpbXBsZXIuICBJIHBhc3Npb25hdGVseSBj YXJlIGFib3V0IGtlZXBpbmcgdGhpcyBzaW1wbGUsIHdoaWNoIGlzIHdoeSBJ4oCZbSBpbnZlc3Rp bmcgbXkgdGltZSBpbiB0aGlzIGRpc2N1c3Npb24uICBJZiBpdOKAmXMgc2ltcGxlLCBpdCB3aWxs IGxpa2VseSBnZXQgd2lkZWx5IHVzZWQuDQoNCknigJltIGdvaW5nIHRvIHNpZ24gb3V0IG9mIHRo ZSBkaXNjdXNzaW9uIGZvciBub3cgYmVjYXVzZSBteSB3aWZlIGlzIGFib3V0IHRvIGdldCBvdXQg b2Ygc3VyZ2VyeS4gIEkgaG9wZSB5b3UgaGF2ZSBhIGdvb2QgZGF5Lg0KDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9t OiBQaGlsIEh1bnQgW21haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbV0NClNlbnQ6IFRodXJzZGF5 LCBBdWd1c3QgMTEsIDIwMTYgMTI6NDkgUE0NClRvOiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVz QG1pY3Jvc29mdC5jb20+DQpDYzogSm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3anRiLmNvbT47IG9w ZW5pZC1zcGVjcy1hYkBsaXN0cy5vcGVuaWQubmV0IEFiIDxvcGVuaWQtc3BlY3MtYWJAbGlzdHMu b3BlbmlkLm5ldD47IGlkLWV2ZW50QGlldGYub3JnOyBNYXJpdXMgU2N1cnRlc2N1IDxtc2N1cnRl c2N1QGdvb2dsZS5jb20+DQpTdWJqZWN0OiBSZTogW0lkLWV2ZW50XSBTdW1tYXJpemluZyByZWNl bnQgZGlzY3Vzc2lvbnMgb24gSUQtRXZlbnQgdG9rZW4gZHJhZnQNCg0KTWlrZSwNCg0KU3BlYWtp bmcgYXMgZWRpdG9yIHRoZSBmb3JtYXQgeW91IHByb3Bvc2UgT05MWSB3b3JrcyBpZiDigJxzdWLi gJ0gYmVjb21lcyBhIFVSSSBzbyB0aGF0IGFsbCBldmVudCBzcGVjcyBjYW4gdXNlIGl0LiAgT3Ro ZXJ3aXNlLCBPSURDIGJlY29tZXMgYSBzcGVjaWFsIGNhc2Ugd2hpY2ggcmVhbGx5IGtpbGxzIHRo ZSBwb2ludCBvZiB0aGlzIHdvcmsuIEl0IGFsc28gbWFrZXMgdGhlIHNwZWNpZmljYXRpb24gbXVj aCBtdWNoIG1vcmUgY29tcGxleC4gTWF5YmUgaXQgaXMganVzdCBtZSwgYnV0IGEgY29tcGxleCBz cGVjIGdlbmVyYWxseSBpbXBsaWVzIGNvbXBsZXggaW1wbGVtZW50YXRpb24gdG9vLg0KDQpJZiB5 b3Ugd2FudCBzdWIgYXQgdGhlIHRvcCBsZXZlbCwgdGhhdCB3b3VsZCBtZWFuIHRoYXQgdGhlIE9J REMgc3BlYyBmb3JtYXQgd291bGQgaGF2ZSB0byBsb29rIGxpa2U6DQp7DQogICJpc3MiOiAiaHR0 cHM6Ly9ldmVudC5leGFtcGxlLmNvbSIsDQogICJhdWQiOiAiczZCaGRSa3F0MyIsDQogICJqdGki OiAiM2QwYzNjZjc5NzU4NGJkMTkzYmQwZmIxYmQ0ZTdkMzAiLA0KICAic3ViIjog4oCcaHR0cHM6 Ly90b2tlbi5leGFtcGxlLmNvbS8yNDgyODk3NjEwMDEiLA0KICAiaWF0IjogMTQ1ODY2ODE4MCwN CiAgImV4cCI6IDE0NTg2Njg1ODAsDQogICJldmVudHMiOiBbDQogICAgImh0dHBzOi8vc3BlY3Mu b3BlbmlkLm5ldC9sb2dvdXQiDQogIF0sDQogICJzaWQiOiAiMDhhNTAxOWMtMTdlMS00OTc3LThm NDItNjVhMTI4NDNlYTAyIg0KfQ0KDQpHaXZlbiB0aGF0IGV2ZW50cyBhcmUgc2lnbmVkIChvciBz aG91bGQgYmUpLCBJIHdpbGwgb2JqZWN0IHN0cm9uZ2x5IHdpdGhpbiB0aGUgT0lERiB0aGF0IHRo ZSBldmVudCBpc3N1ZXIgYW5kIHRoZSB0b2tlbiBpc3N1ZXIgTVVTVCBiZSB0aGUgc2FtZSBvciB0 aGF0IE9JREYgYWRvcHQgYSBkaWZmZXJlbnQgZm9ybWF0LiBZZXMgaGF2aW5nIGlzcyBiZSB0aGUg c2FtZSBpcyBhIG5pY2Ugc2VjdXJpdHkgY29udmVuaWVuY2UsIGJ1dCBpdCBpbXBvc2VzIHRoZSBh cmNoaXRlY3R1cmUgcmVzdHJpY3Rpb24gdGhhdCBpdCBiZSB0aGUgc2FtZSBzZXJ2ZXIuICBBdCBz Y2FsZSwgZGVsaXZlcnkgb2YgZXZlbnRzIG1heSBiZWNvbWUgYSBwcm9ibGVtIGZvciBsYXJnZSBz Y2FsZSBwcm92aWRlcnMgaWYgdGhleSBhcmUgYWxzbyBkZWxpdmVyaW5nIHRva2VucyB0byByZWx5 aW5nIHBhcnRpZXMuIFRoZSByZXN0cmljdGlvbiBpc27igJl0IHJlYWxseSBqdXN0aWZpZWQgZ2l2 ZW4gdGhlIGNyeXB0byBhbHRlcm5hdGl2ZSDigJQgd2hpY2ggd2FzIHRoZSB3aG9sZSBwb2ludCBv ZiB1c2luZyBKV1QgaW4gdGhlIGZpcnN0IHBsYWNlLg0KDQpQZXIgSnVzdGlu4oCZcyBjb21tZW50 LCBpdCBzZWVtcyBlbGVnYW50L3RyaXZpYWwgdGhhdCBhIGxvZ291dCBldmVudCBzaW1wbHkgaGFz IGxvZ291dCBhdCB0aGUgdG9wIGxldmVsIGFuZCBhbiBJRCBUb2tlbiBhdHRhY2hlZCAodGhvdWdo IGl0IG1pZ2h0IGNvbnZleSBhIGxvdCBvZiB1bm5lZWRlZCBjbGFpbXMpLiAgSU1PLCB0aGUgT0lE QyBsb2dvdXQgc3BlYyBzaG91bGQgb25seSBjb252ZXkgdGhlIElEIFRva2VuIEpUSS4gIEl0IGlz IGdvaW5nIHRvIGJlIHJhcmUgdGhhdCB5b3UgbG9nIG91dCBhbGwgZGV2aWNlcyBmb3IgYSB1c2Vy LiAgVG8gbW9zdCB1c2VycywgaXQgbWVhbnMgY2xlYXIgU1NPIHdpdGhpbiB0aGlzIGJyb3dzZXIg b25seSEgIE9uZSBjYW4gYXJndWUgdGhhdCBjbGVhcmluZyBhbGwgZGV2aWNlcy9zZXNzaW9ucyBp cyBhIGRpZmZlcmVudCBldmVudCBlbnRpcmVseS4gSXQgaXMgYW4gYWNjb3VudCByZXNldCBvciBs b2NrLW91dCBhY3Rpb24uDQoNClBoaWwNCg0KQGluZGVwZW5kZW50aWQNCnd3dy5pbmRlcGVuZGVu dGlkLmNvbTxodHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tPg0KcGhpbC5odW50QG9yYWNsZS5j b208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPg0KDQoNCg0KDQpPbiBBdWcgMTEsIDIwMTYs IGF0IDk6MzIgQU0sIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWls dG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQoNClNlZSBteSBwcmV2aW91 cyBtZXNzYWdlLCBKb2huLCB3aGljaCB3YXMgYSByZXBseSB0byBQaGls4oCZcyBtZXNzYWdlIHRo YXQgeW91IGFsc28gcmVwbGllZCB0bywgdGhhdCBjb250YWluZWQgYSBsb2dvdXQgY2xhaW1zIGV4 YW1wbGUuICBJ4oCZbSBub3QgcHJvcG9zaW5nIHRvIHNwZWNpYWwtY2FzZSB0aGUgQ29ubmVjdCBM b2dvdXQgbWVzc2FnZSBpbiBhbnkgd2F5LiAgVGhlIOKAnGlzc+KAnSBpcyB0aGUgZXZlbnQgaXNz dWVyLiAgVGhlIG90aGVyIGNsYWltcyBpbiB0aGUgbWVzc2FnZSBhcmUgdGhvc2UgZGVmaW5lZCBi eSB0aGUgZXZlbnQgdG8gYmUgaW5jbHVkZWQsIGp1c3QgbGlrZSB0aG9zZSBmb3IgYW55IG90aGVy IGV2ZW50LiAgWWVzLCB0aGUgbG9nb3V0IG1lc3NhZ2UgZG9lc27igJl0IGluY2x1ZGUgYSBzZWNv bmQgaXNzdWVyLCBhIHNlY29uZCBzdWJqZWN0LCBhbiBJRCBUb2tlbiBhcyBhIGNsYWltLCBvciBh bnl0aGluZyBlbHNlIGNvbXBsaWNhdGVkIGxpa2UgdGhhdCwgYmVjYXVzZSB0aG9zZSB0aGluZ3Mg YXJlbuKAmXQgbmVlZGVkIGZvciB0aGUgbG9nb3V0IHVzZSBjYXNlLg0KDQpBcyBJ4oCZZCB3cml0 dGVuIHByZXZpb3VzbHksIHRoZSBJRCBFdmVudHMgc3BlYyBzaG91bGQgZGVmaW5lIHRoZSDigJxl dmVudHPigJ0gY2xhaW0sIGhvdyB0byB1c2UgYW4gZXZlbnQgbmFtZSBhcyBhIGNsYWltICh3aGVu IG5lZWRlZCksIGFuZCBzYXkgdGhhdCB0aGUgZXZlbnQgSldUIG11c3QgYmUgc2lnbmVkIGJ5IHRo ZSBpc3N1ZXIsIGFuZCBzdG9wIHRoZXJlLiAgVHJ5aW5nIHRvIG1pY3JvLW1hbmFnZSBjbGFpbXMg dXNhZ2Ugd2l0aGluIGFuIGV2ZW50IHdpbGwgb25seSByZXN1bHQgaW4gdGhlIElEIEV2ZW50cyBz cGVjIGJlaW5nIGhhcmRlciB0byB1c2UuICBJZiB3ZeKAmWQgdHJpZWQgdG8gc2ltaWxhcmx5IG1p Y3JvLW1hbmFnZSBKV1QgY2xhaW1zIHVzYWdlLCBKV1Qgd291bGQgbGlrZWx5IG5vdCBoYXZlIGJl ZW4gdGhlIHN1Y2Nlc3MgdGhhdCBpdCBpcy4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogSm9obiBCcmFkbGV5 IFttYWlsdG86dmU3anRiQHZlN2p0Yi5jb21dDQpTZW50OiBUaHVyc2RheSwgQXVndXN0IDExLCAy MDE2IDEyOjIyIFBNDQpUbzogUGhpbCBIdW50IChJRE0pIDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxt YWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+Pg0KQ2M6IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9u ZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj47IGlk LWV2ZW50QGlldGYub3JnPG1haWx0bzppZC1ldmVudEBpZXRmLm9yZz47IE1hcml1cyBTY3VydGVz Y3UgPG1zY3VydGVzY3VAZ29vZ2xlLmNvbTxtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tPj47 IG9wZW5pZC1zcGVjcy1hYkBsaXN0cy5vcGVuaWQubmV0PG1haWx0bzpvcGVuaWQtc3BlY3MtYWJA bGlzdHMub3BlbmlkLm5ldD4gQWIgPG9wZW5pZC1zcGVjcy1hYkBsaXN0cy5vcGVuaWQubmV0PG1h aWx0bzpvcGVuaWQtc3BlY3MtYWJAbGlzdHMub3BlbmlkLm5ldD4+DQpTdWJqZWN0OiBSZTogW0lk LWV2ZW50XSBTdW1tYXJpemluZyByZWNlbnQgZGlzY3Vzc2lvbnMgb24gSUQtRXZlbnQgdG9rZW4g ZHJhZnQNCg0KTm90IHN1cnByaXNpbmdseSBhIG11bHRpcHVycG9zZSBtZXNzYWdlIGZvcm1hdCB3 aWxsIG5vdCBiZSBhcyBvcHRpbWl6ZWQgYXMgYSBzaW5nbGUgcHVycG9zZSBvbmUuDQoNCkNvbm5l Y3QgaXRzZWxmIGRvZXNu4oCZdCByZWFsbHkgaGF2ZSBhIGNvbmZsaWN0IGFyb3VuZCBpc3N1ZXIg dGhlIHNhbWUgZW50aXR5IHNlbmRpbmcgdGhlIGxvZ291dCBtZXNzYWdlIGlzIGFsd2F5cyB0aGUg b25lIHRoYXQgY3JlYXRlZCB0aGUgaWRfdG9rZW4gdGhhdCBpdCByZWZlcnMgdG8uDQoNClVzaW5n IHRoZSBzYW1lIGZvcm1hdCBhcyBpZF90b2tlbiB3aXRoIHRoZSBzYW1lIHNlbWFudGljcyB0byBp ZGVudGlmeSB0aGUgdGhpbmcgdG8gYmUgdGVybWluYXRlZCBtYWtlcyBzZW5zZSBmcm9tIGEgcHVy ZWx5IG9wZW5JRCBDb25uZWN0IHBvaW50IG9mIHZpZXcuDQoNCk90ZXIgbWVzc2FnZXMgdGhhdCBo YXZlIGRpZmZlcmVudCBub3Rpb25zIG9mIHN1YmplY3QgYW5kIGFyZSBpc3N1ZWQgYnkgZGlmZmVy ZW50IHBhcnRpZXMgdGhhbiB0aGUgb25lIHRoYXQgY29udHJvbHMgdGhlIHN1YmplY3QgY2F1c2Ug aXNzdWVzIHdoZW4geW91IHRyeSBhbmQgZml0IHRoZW0gaW50byB0aGUgc2FtZSBmb3JtYXQgYXMg YW4gSURfVG9rZW4sIEkgZ3JhbnQgeW91IHRoYXQuDQoNCkl0IHdhcyBtZW50aW9uZWQgdGhhdCB3 ZSBuZWVkIHRvIGRpZmZlcmVudGlhdGUgYmV0d2VlbiB0aGVzZSBldmVudHMgYW5kIGlkX3Rva2Vu cy4gIE1vc3RseSB3ZSBuZWVkIHRvIGRvIHRoYXQgaW4gY2FzZXMgd2hlcmUgdGhlIHRva2VuIG1p Z2h0IGJlIHByZXNlbnRlZCBpbiB0aGUgZnJvbnQgY2hhbm5lbC4NCg0KVG8gZG8gdGhhdCBzZSBk byBoYXZlIG1hbmRhdG9yeSBjbGFpbXMgZm9yIG5vbmNlIGFuZCBjX2hhc2ggb3IgYXRfaGFzaCBh cyB3ZWxsIGFzIHRoZSBhZGRpdGlvbiBvZiBldmVudHMgcGFyYW1ldGVyIHRvIHJlZHVjZSBjb25m dXNpb24uICAgTm93IEkgYWRtaXQgdGhhdCBzb21lIHBlb3BsZSBtYXkgc3RpbGwgZ2V0IHRoYXQg d3JvbmcsICBhbmQgdGhlIHJlbW92YWwgb2Ygc3ViIGZyb20gdGhlIHRvcCBsZXZlbCB3b3VsZCBy ZW1vdmUgYW55IGNvbmNlcm4uICBIb3dldmVyIE1pa2UgaGFzIGEgcG9pbnQgdGhhdCBhZG9wdGlv biBtYXkgYmUgaHVydCBpZiB3ZSBjaGFuZ2UgdGhlIHNlbWFudGljcyB0b28gbXVjaC4NCg0KSSBk b27igJl0IHNlZSBiYWNrY2hhbm5lbCBzaW5nbGUgbG9nb3V0IGJlaW5nIHVzZWQgYnkgbWFueSBz b2NpYWwgbG9naW4gUlAsIGl0IGlzIGEgbG90IG9mIHdvcmsgdG8gbWFpbnRhaW4gc2VydmVyIHNp ZGUgc3RhdGUuICAgSXQgaXMgbW9zdGx5IGFuIGVudGVycHJpc2UgYW5kIGxhcmdlIHNpdGUgc29y dCBvZiBmZWF0dXJlLg0KVGhhdCBtYXkgb3IgbWF5IG5vdCBpbXBhY3Qgb24gaWYgaXQgaXMgYmV0 dGVyIHRvIGJlIHNpbXBsZSBhbmQgYWxpZ25lZCB3aXRoIGNvbm5lY3TigJlzIGlkIHRva2VuIG9y IG1vcmUgZ2VuZXJhbCBwdXJwb3NlIHRvIGZpdCB3aXRoIG90aGVyIGVudGVycHJpc2UgdG8gU2Fh UyBmZWF0dXJlcyBsaWtlIFNDSU0gZXZlbnRzLg0KDQpJIHRoaW5rIHRoZSB0d28gZGlyZWN0aW9u cyBsZWFkIHRvIGRpZmZlcmVudCBmb3JtYXRzLg0KDQpUaGUgY29tcHJvbWlzZSBvZiBzcGVjaWFs IGNhc2luZyBDb25uZWN0IFNMTyBhbmQgYm9kZ2luZyB0aGUgZm9ybWF0cyB0b2dldGhlciBpcyBw cm9iYWJseSB0aGUgd29yc3Qgb3B0aW9uLg0KDQpKb2huIEIuDQoNCg0KT24gQXVnIDExLCAyMDE2 LCBhdCAxMTo1OSBBTSwgUGhpbCBIdW50IChJRE0pIDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWls dG86cGhpbC5odW50QG9yYWNsZS5jb20+PiB3cm90ZToNCg0KSG93IGRvIHlvdSByZXNvbHZlIGNv bmZsaWN0cyBvbiBpc3MgdGhlbj8gIFRoZSB0b3AgbGV2ZWwgaGFzIHRvIGJlIHRoZSBpc3N1ZXIg b2YgdGhlIGV2ZW50IGFzIHRoZSBpc3N1ZXIgc2lnbnMuDQoNCklmIG9uZSBzcGVjIGNhbiB1c2Ug aXQgYWxsIG11c3QgYmUgYWJsZSB0by4gSSBiZWxpZXZlIHlvdSBwcmV2aW91c2x5IG9iamVjdGVk IHRvIHRoYXQgc2F5aW5nIHN1YiBtdXN0IGJlIGFzIGhvdyBpZCB0b2tlbnMgZGVmaW5lIHRoZW0u IEJ1dCB0aGF0IGlzbnQgdW5pcXVlIGFuZCByZXF1aXJlcyBpc3MuIE5vdyB3ZSB3b3VsZCBoYXZl IHN1YiBhdCB0aGUgdG9wIHdpdGggYW4gZXZlbnQgaXNzdWVyIGF0IHRoZSB0b3AgYW5kIGEgc3Vi IGlzc3VlciBpbiB0aGUgZXh0ZW5zaW9uLiBUaGF0IHNlZW1zIGluY3JlZGlibHkgY29tcGxleCBu b3QgdG8gbWVudGlvbiBhd2t3YXJkLg0KDQpJZiB3ZSBtYWtlIHN1YiBhIHVyaSBmb3IgYWxsIHRo ZW4gaXQgY2FuIHdvcmsgYXNzIGlzcyBmcm9tIGlkIHRva2VuIHdvdWxkIG5vdCBiZSBuZWVkZWQu IEJ1dCBpIGNhbiBzZWUgbWFueSBvYmplY3RpbmcgdG8gdGhlIGNoYW5nZSBpbiBmb3JtYXQuDQoN CldoeSBub3QgaGF2ZSBhIGxvZ291dCBiZSBhbiBldmVudCB3aXRoIGFuIGlkIHRva2VuIGF0dGFj aGVkIGZvciBleGFtcGxlPw0KDQpQaGlsDQoNCk9uIEF1ZyAxMSwgMjAxNiwgYXQgODowMyBBTSwg TWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpv bmVzQG1pY3Jvc29mdC5jb20+PiB3cm90ZToNClRoZSBzaW1wbGUgcnVsZSBpcyB0aGF0IGlmIHRo ZSBwYXJ0aWN1bGFyIGV2ZW50IGNhbGxzIGZvciB0aGUg4oCcc3Vi4oCdIGNsYWltIHRvIGJlIGF0 IHRoZSB0b3AgbGV2ZWwsIHRoZW4gaXQgaXMuICBUaGlzIGlzIG5vIGRpZmZlcmVudCBmcm9tIGFu eSBvdGhlciBjbGFpbSB0aGF0IGFuIGV2ZW50IG1pZ2h0IHBsYWNlIGF0IHRoZSB0b3AgbGV2ZWwu DQoNClRoZSBjb21wbGV4aXR5IGFyaXNlcyBpZiDigJxzdWLigJ0gaXMgdW5uZWNlc3NhcmlseSBz cGVjaWFsLWNhc2VkLiAgV2Ugc2hvdWxkbuKAmXQgZG8gdGhhdCwgYmVjYXVzZSBpdCBsaW1pdHMg dGhlIGFwcGxpY2FiaWxpdHkgb2YgdGhlIHNwZWNpZmljYXRpb24uDQoNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206 IFBoaWwgSHVudCAoSURNKSBbbWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tXQ0KU2VudDogVGh1 cnNkYXksIEF1Z3VzdCAxMSwgMjAxNiA5OjQwIEFNDQpUbzogTWlrZSBKb25lcyA8TWljaGFlbC5K b25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+Pg0K Q2M6IE1hcml1cyBTY3VydGVzY3UgPG1zY3VydGVzY3VAZ29vZ2xlLmNvbTxtYWlsdG86bXNjdXJ0 ZXNjdUBnb29nbGUuY29tPj47IGlkLWV2ZW50QGlldGYub3JnPG1haWx0bzppZC1ldmVudEBpZXRm Lm9yZz4NClN1YmplY3Q6IFJlOiBbSWQtZXZlbnRdIFN1bW1hcml6aW5nIHJlY2VudCBkaXNjdXNz aW9ucyBvbiBJRC1FdmVudCB0b2tlbiBkcmFmdA0KDQpJIHRoaW5rIHVzaW5nIHN1YiBhdCB0aGUg dG9wIGxldmVsIGxlYWRzIHRvIGNvbXBsZXhpdHkuIEVnIENhbiB5b3UgcHJvdmlkZSBhIHJ1bGUg Zm9yIHdoZW4gdG9wIGxldmVsIGlzIHVzZWQgb3Igbm90IGJ5IGFuIGluZGl2aWR1YWwgc3BlYz8g IElNTy4gVG9wIGxldmVsIHNob3VsZCBhbHdheXMgYmUgdXNlZCB0aGUgc2FtZSB3YXkgYnkgYWxs IGltcGxlbWVudGVycy4NCg0KQmFzZWQgb24gdGhlIGNhbGxzIGF0IHJpc2MvY29ubmVjdCwgd2Ug ZGlzY3Vzc2VkIHRoYXQgaXQgd291bGQgYmUgYmVzdCB0byBtb3ZlIGFsbCBldmVudCBzcGVjaWZp Y3MgdG8gdGhlIGV2ZW50IG9iamVjdCBhcmVhLiBUaGlzIHdheSBkaWZmZXJlbnQgZXZlbnRzIGNh biBoYXZlIGRpZmZlcmVudCBldmVudCBhZGRyZXNzaW5nIChlZyBzdWIvaXNzLCB1cmksIGppdC9p c3MpLiBXaGVuIGlzcyBpcyBuZWVkZWQgdG8gdW5pcXVlbHkgcXVhbGlmeSBhIHN1YiwgaXQgY2Fu IGJlIHByb3ZpZGVkIHdpdGhvdXQgY29uZmxpY3Rpbmcgd2l0aCB0aGUgaXNzdWVyIG9mIHRoZSBl dmVudC4gU2ltaWxhcmx5IGp0aSBhbmQgaXNzIGNhbiBiZSB1c2VkIGZvciBhIHJldm9rZWQgdG9r ZW4gd2l0aG91dCBjb25mbGljdGluZyB3aXRoIHRoZSBldmVudCBqdGkuDQoNCkkgcGxhbiB0byBw b3N0IGEgbmV3IGRyYWZ0IHNob3J0bHkgdGhhdCB3aWxsIGdpdmUgc29tZSBleGFtcGxlcyBiYXNl ZCBvbiBmZWVkYmFjayBmcm9tIHRoZSBvcGVuaWQgcmlzYy9jb25uZWN0IGRpc2N1c3Npb25zLg0K DQpXZSBjYW4gYWx3YXlzIGNoYW5nZSBhZ2Fpbi4NCg0KUGhpbA0KDQpPbiBBdWcgMTEsIDIwMTYs IGF0IDQ6NTQgQU0sIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWls dG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpObywgSeKAmW0gbm90IHNh eWluZyB0aGF0IOKAnHN1YuKAnSBjYW5ub3QgYXBwZWFyIGF0IHRoZSB0b3AgbGV2ZWwuICBJ4oCZ bSBzYXlpbmcgdGhhdCDigJxzdWLigJ0gd2lsbCBvbmx5IG9jY3VyIGF0IHRoZSB0b3AgbGV2ZWwg aWYgdGhlIHBhcnRpY3VsYXIgZXZlbnQgZGVmaW5lcyB0aGF0IOKAnHN1YuKAnSBpcyB1c2VkIGlu IHRoYXQgd2F5IGZvciB0aGF0IGV2ZW50Lg0KDQpUaGVyZSBhcmUgcHJvYmFibHkgdXNlIGNhc2Vz IGZvciBtdWx0aXBsZSBldmVudHMgcGVyIG1lc3NhZ2UgYnV0IEkgZG91YnQgdGhlcmUgYXJlIHVz ZSBjYXNlcyBmb3IgbXVsdGlwbGUgKnVucmVsYXRlZCogZXZlbnRzIHBlciBtZXNzYWdlLiAgQnkg ZGVmaW5pdGlvbiwgcmVsYXRlZCBldmVudHMgdGhhdCB1c2UgdG9wLWxldmVsIGNsYWltcyB3b3Vs ZCBuZWVkIHRvIHVzZSB0aGVtIGluIGEgY29tcGF0aWJsZSB3YXkuICBJIGRvbuKAmXQgc2VlIHRo YXQgYXMgYmVpbmcgYSBwcm9ibGVtLg0KDQpUaGF0IGJlaW5nIHNhaWQsIHRoZSBwcmVkb21pbmFu dCB1c2UgY2FzZSBpcyBsaWtlbHkgdG8gYmUgYSBzaW5nbGUgZXZlbnQgcGVyIEpXVC4NCg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBNYXJpdXMgU2N1cnRlc2N1IFttYWlsdG86bXNjdXJ0 ZXNjdUBnb29nbGUuY29tXQ0KU2VudDogVHVlc2RheSwgQXVndXN0IDksIDIwMTYgNzoxNSBQTQ0K VG86IFBoaWwgSHVudCA8cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFj bGUuY29tPj4NCkNjOiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFp bHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+OyBpZC1ldmVudEBpZXRmLm9yZzxtYWls dG86aWQtZXZlbnRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0lkLWV2ZW50XSBTdW1tYXJpemlu ZyByZWNlbnQgZGlzY3Vzc2lvbnMgb24gSUQtRXZlbnQgdG9rZW4gZHJhZnQNCg0KTWlrZSwgYXJl IHlvdSBzdWdnZXN0aW5nIHRoYXQgYSBzdWIgY2xhaW0gY2FuIG9ubHkgc2hvdyB1cCBhdCB0aGUg ZXZlbnQgbGV2ZWwgYW5kIG5vdCBhdCB0aGUgdG9wIGxldmVsOg0KDQpJbiBwYXJ0aWN1bGFyLCB0 aGUgb25seSB0aGluZyB0aGF0IHRoZSBzcGVjIHNob3VsZCBzYXkgYWJvdXQgdGhlIOKAnHN1YuKA nSBjbGFpbSBpcyB0aGF0IOKAnExpa2UgYWxsIG90aGVyIGNsYWltcyBvdGhlciB0aGFuIOKAmGV2 ZW50c+KAmSBhbmQg4oCYaXNz4oCZLCB3aGV0aGVyIHRoZSDigJhzdWLigJkgY2xhaW0gaXMgdG8g YmUgaW5jbHVkZWQgd2l0aCBhbiBldmVudCBpcyBlbnRpcmVseSBldmVudC1zcGVjaWZpYy4NCg0K QSB0b3AgbGV2ZWwgc3ViIGFuZCBtdWx0aXBsZSBldmVudHMgYXJlIGluY29tcGF0aWJsZSBJTU8u DQoNCkRvIHdlIGhhdmUgYSBjb21wZWxsaW5nIHJlYXNvbiB0byBzdXBwb3J0IG11bHRpcGxlIGV2 ZW50cyBwZXIgbWVzc2FnZT8NCg0KDQpNYXJpdXMNCg0KT24gVHVlLCBBdWcgOSwgMjAxNiBhdCAx MjozOSBQTSwgUGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50 QG9yYWNsZS5jb20+PiB3cm90ZToNCkkgd2FzIHJlZmVycmluZyB0byB0aGlzIGluIHlvdXIgZW1h aWwNCiJEZWZpbmUgdGhhdCBhbiBldmVudCBuYW1lIGNhbiBiZSB1c2VkIGFzIGEgdG9wLWxldmVs IGNsYWlt4oCdDQoNCg0KSXMgdGhpcyBkaWZmZXJlbnQgZnJvbSB0aGUgZXZlbnQgdXJpPw0KDQpQ aGlsDQoNCkBpbmRlcGVuZGVudGlkDQp3d3cuaW5kZXBlbmRlbnRpZC5jb208aHR0cDovL3d3dy5p bmRlcGVuZGVudGlkLmNvbS8+DQpwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50 QG9yYWNsZS5jb20+DQoNCg0KDQoNCk9uIEF1ZyA5LCAyMDE2LCBhdCAxMjoxMiBQTSwgTWlrZSBK b25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1p Y3Jvc29mdC5jb20+PiB3cm90ZToNCg0KSeKAmW0gZ2xhZCB0byBoZWFyIHRoYXQgd2UgYWdyZWUg b24ga2VlcGluZyBpdCBhcyBzaW1wbGUgYW5kIGdlbmVyYWwtcHVycG9zZSBhcyBwb3NzaWJsZSBh bmQgdGhhdCB5b3UgYWdyZWUgd2l0aCBteSB3cml0ZS11cC4gIEkgdGhpbmsgd2UgdGhlbiBoYXZl IGEgZ29vZCBwYXRoIGZvcndhcmQuDQoNCknigJltIG5vdCBzdXJlIHdoYXQgeW91IG1lYW4gYnkg 4oCcSeKAmW0gbm90IHN1cmUgdGhhdCB3ZSBuZWVkIGEg4oCcbmFtZeKAnS4gV2hhdCBpcyB5b3Vy IGludGVudGlvbiB0aGVyZS7igJ0gIFRoZSBvbmx5IHBsYWNlIEkgdXNlZCB0aGUgd29yZCDigJxu YW1l4oCdIHdhcyBpbiBteSBzdGF0ZW1lbnQg4oCcRGVmaW5lIHRoYXQgYW4gZXZlbnQgbmFtZSBj YW4gYmUgdXNlZCBhcyBhIHRvcC1sZXZlbCBjbGFpbeKAnS4gIFdoYXQgSSB3YXMgdHJ5aW5nIHRv IGdldCBhdCBpcyB3YXMgdGhhdCBpZiDigJxodHRwOi8vc3BlY3Mub3BlbmlkLm5ldC9sb2dvdXTi gJ0gaXMgdXNlZCBhcyBhbiBldmVudCBuYW1lLCB0aGF0IGl0IGNhbiBhbHNvIGJlIHVzZWQgYXMg YSBjbGFpbSBuYW1lIGluIHRoZSBKV1QgY29udGFpbmluZyBpbmZvcm1hdGlvbiBhYm91dCB0aGUg ZXZlbnQuICAoTWF5YmUgSeKAmW0gbm90IHVzaW5nIHRoZSBjb3JyZWN0IHRlcm1pbm9sb2d5LCBo ZW5jZSB0aGUgdW5pbnRlbmRlZCBjb25mdXNpb24g4pi6LikNCg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRoYW5rcyBhZ2FpbiwNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtl DQoNCkZyb206IFBoaWwgSHVudCBbbWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tXQ0KU2VudDog VHVlc2RheSwgQXVndXN0IDksIDIwMTYgMTI6MDcgUE0NClRvOiBNaWtlIEpvbmVzIDxNaWNoYWVs LkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+ DQpDYzogaWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOmlkLWV2ZW50QGlldGYub3JnPg0KU3ViamVj dDogUmU6IFtJZC1ldmVudF0gU3VtbWFyaXppbmcgcmVjZW50IGRpc2N1c3Npb25zIG9uIElELUV2 ZW50IHRva2VuIGRyYWZ0DQoNCkkgZGlkbuKAmXQgY292ZXIgdGhpcyBhcyBJIGRpZG7igJl0IHdh bnQgdG8gY29uZnVzZSBwZW9wbGUgd2l0aCB0b28gbWFueSB0aGluZ3MuDQoNCkJ1dCBJIHRoaW5r IHdlIGFncmVlIG9uIGFsbCBvZiB0aGUgYmVsb3cuDQoNCknigJltIG5vdCBzdXJlIHRoYXQgd2Ug bmVlZCBhIOKAnG5hbWXigJ0uIFdoYXQgaXMgeW91ciBpbnRlbnRpb24gdGhlcmUuDQoNClBoaWwN Cg0KQGluZGVwZW5kZW50aWQNCnd3dy5pbmRlcGVuZGVudGlkLmNvbTxodHRwOi8vd3d3LmluZGVw ZW5kZW50aWQuY29tLz4NCnBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3Jh Y2xlLmNvbT4NCg0KDQoNCg0KT24gQXVnIDksIDIwMTYsIGF0IDExOjU0IEFNLCBNaWtlIEpvbmVz IDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9z b2Z0LmNvbT4+IHdyb3RlOg0KDQpUaGFua3MgZm9yIHdyaXRpbmcgdGhpcywgUGhpbC4gIFVuZm9y dHVuYXRlbHksIHRoZSBzdW1tYXJ5IGJlbG93IGRvZXMgbm90IGluY2x1ZGUgbXkgZmVlZGJhY2ss IHdoaWNoIGF0IHRoZSBlc3NlbmNlLCBpcyB0byBrZWVwIHRoZSBJRCBFdmVudHMgZGF0YSBzdHJ1 Y3R1cmUgYXMgc2ltcGxlIGFuZCBnZW5lcmFsLXB1cnBvc2UgYXMgcG9zc2libGUuICAoSSBzdHJv bmdseSBiZWxpZXZlIHRoYXQgSldUIGlzIHRoZSBzdWNjZXNzIGl0IGlzIGJlY2F1c2Ugd2UgbWFk ZSBKV1QgYXMgc2ltcGxlIGFuZCBnZW5lcmFsLXB1cnBvc2UgYXMgcG9zc2libGUsIGFuZCB3ZSBz aG91bGQgZm9sbG93IHRoaXMgc3VjY2Vzc2Z1bCBleGFtcGxlIGFuZCBkbyB0aGUgc2FtZSBoZXJl LikNCg0KSSBiZWxpZXZlIHRoYXQgdGhlIElEIEV2ZW50cyBzcGVjIG5lZWRzIHRvIGluY2x1ZGUg dGhlc2UgdGhpbmdzLCBhbmQgdGhlc2UgdGhpbmdzIG9ubHk6DQrigKIgICAgICAgRGVmaW5lIG9m IHRoZSDigJxldmVudHPigJ0gY2xhaW0NCuKAoiAgICAgICBEZWZpbmUgdGhhdCBhbiBldmVudCBu YW1lIGNhbiBiZSB1c2VkIGFzIGEgdG9wLWxldmVsIGNsYWltDQrigKIgICAgICAgUmVxdWlyZSB0 aGF0IOKAnGlzc+KAnSBiZSBpbmNsdWRlZCBhbmQgdGhhdCB0aGUgSldUIGJlIHNpZ25lZCBieSB0 aGUgaXNzdWVyDQrigKIgICAgICAgSW5jbHVkZSBhIHN0YXRlbWVudCBhbG9uZyB0aGUgbGluZXMg b2Yg4oCcVGhlIGNsYWltcyB0byBiZSBpbmNsdWRlZCB3aXRoIGFueSBwYXJ0aWN1bGFyIGV2ZW50 IGFyZSB0byBiZSBkZWZpbmVkIGJ5IHRoZSBldmVudOKAnQ0KDQpBbmQgSeKAmWQgc3RvcCB0aGVy ZS4NCg0KSXQgc2hvdWxkIGJlIGVudGlyZWx5IHVwIHRvIGFwcGxpY2F0aW9ucyB0byBzYXkgd2hh dCBjbGFpbXMgYXJlIGluY2x1ZGVkIHdpdGggZXZlbnRzIHRoZXkgZGVmaW5lIGFuZCB3aGF0IHRo ZWlyIGZvcm1hdCBhbmQgbWVhbmluZ3MgYXJlLiAgVGhlbiB0aGUgSUQgRXZlbnRzIHNwZWMgd2ls bCBiZSBhcyBnZW5lcmFsLXB1cnBvc2UgYXMgcG9zc2libGUsIHdpdGggaXQgYmVpbmcgbmF0dXJh bCBmb3IgaXQgdG8gYmUgdXNlZCBpbiBlc3NlbnRpYWxseSBhbGwgSlNPTiBFdmVudCBjb250ZXh0 cy4NCg0KQXMgc29vbiBhcyB3ZSBzdGFydCBwdXR0aW5nIHJlc3RyaWN0aW9ucyBvbiB0aGUgdXNl IG9mIHBhcnRpY3VsYXIgY2xhaW1zIGJ5IGV2ZW50cywgd2XigJlyZSBtYWtpbmcgdGhlIElEIEV2 ZW50cyBzcGVjIGxlc3MgZ2VuZXJhbC1wdXJwb3NlIGFuZCBsZXNzIG5hdHVyYWwgdG8gdXNlLiAg SW4gcGFydGljdWxhciwgdGhlIG9ubHkgdGhpbmcgdGhhdCB0aGUgc3BlYyBzaG91bGQgc2F5IGFi b3V0IHRoZSDigJxzdWLigJ0gY2xhaW0gaXMgdGhhdCDigJxMaWtlIGFsbCBvdGhlciBjbGFpbXMg b3RoZXIgdGhhbiDigJhldmVudHPigJkgYW5kIOKAmGlzc+KAmSwgd2hldGhlciB0aGUg4oCYc3Vi 4oCZIGNsYWltIGlzIHRvIGJlIGluY2x1ZGVkIHdpdGggYW4gZXZlbnQgaXMgZW50aXJlbHkgZXZl bnQtc3BlY2lmaWMuICBUaGUgY2xhaW1zIHRvIGJlIGluY2x1ZGVkIHdpdGggYW55IHBhcnRpY3Vs YXIgZXZlbnQgYXJlIGV4cGxpY2l0bHkgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBzcGVjaWZp Y2F0aW9uLuKAnQ0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBJZC1ldmVudCBbbWFpbHRvOmlkLWV2ZW50LWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQaGlsIEh1bnQNClNlbnQ6IFR1ZXNkYXksIEF1 Z3VzdCA5LCAyMDE2IDEwOjE5IEFNDQpUbzogaWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOmlkLWV2 ZW50QGlldGYub3JnPg0KU3ViamVjdDogW0lkLWV2ZW50XSBTdW1tYXJpemluZyByZWNlbnQgZGlz Y3Vzc2lvbnMgb24gSUQtRXZlbnQgdG9rZW4gZHJhZnQNCg0KSSB0aG91Z2h0IEkgd291bGQgdXBk YXRlIHRoZSBsaXN0IG9uIHNvbWUgZGlzY3Vzc2lvbnMgdGhhdCBoYXZlIGJlZW4gaGFwcGVuaW5n IG92ZXIgaW4gdGhlIE9wZW5JRCBDb25uZWN0IGFuZCBSSVNDIHdvcmtpbmcgZ3JvdXBzIGNvbmZl cmVuY2UgY2FsbHMuDQoNClRoZXNlIGRpc2N1c3Npb25zIGhhdmUgYmVlbiBhYm91dCB0aGUgY29y ZSBzcGVjIGFuZCB0aGUgcm9sZSBvZiDigJx0b3AtbGV2ZWzigJ0gYXR0cmlidXRlcyB2cy4gZXZl bnQg4oCcZXh0ZW5zaW9u4oCdIGF0dHJpYnV0ZXMuDQpTZWU6IGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1odW50LWlkZXZlbnQtdG9rZW4tMDENCg0KSW4gcGFydGljdWxhciBzaG91 bGQg4oCcc3Vi4oCdIGJlIHVzZWQgaW4gdGhlIHRvcCBsZXZlbCB0byDigJxwb2ludOKAnSB0byB0 aGUgc3ViamVjdCAoaW4gdGhlIGJyb2FkZXIgZW5nbGlzaCBzZW5zZSkgb2YgdGhlIGV2ZW50LCBv ciBzaG91bGQgaXQgYmUgY29uc3RyYWluZWQgdG8gdGhlIFNBTUwvSUQgVG9rZW4gZGVmaW5pdGlv biB3aGljaCBpcyB0aGUgYXV0aGVudGljYXRlZCB1c2VyLg0KDQpUYWtlbiBpbiB0aGUgbmFycm93 ZXIgZGVmaW5pdGlvbiwgaXQgaXMgaW1wb3J0YW50IHRvIG9ic2VydmUgdGhhdCBpbiBhbiBJRCBU b2tlbiwg4oCcc3Vi4oCdIGFuZCDigJxpc3PigJ0gZ28gdG9nZXRoZXIuICBUaGUgaXNzdWVyIHBy b3ZpZGVzIHRoZSBjb250ZXh0IGZvciB0aGUgYXV0aGVudGljYXRlZCBzdWJqZWN0IGlkZW50aWZp ZXIuIFRoZSBwcm9ibGVtIHdpdGggZXZlbnRzLCBpcyB0aGF0IGl0IG1pZ2h0IG5vdCBiZSB0aGUg QVMgKG9yIE9QKSB3aGljaCBpcyBpc3N1aW5nIHRoZSBldmVudC4NCg0KVG8gc3VtbWFyaXplIGEg ZmFpciBhbW91bnQgb2YgZGlzY3Vzc2lvbiwgdGhlIGZlZWxpbmcgc2VlbXMgdG8gYmUgdGhlIGZv bGxvd2luZzoNCg0KKiAgVGhlIEV2ZW50IFRva2VuIHRvcCBsZXZlbCBhdHRyaWJ1dGVzIHNob3Vs ZCBiZSBmYWlybHkgbGltaXRlZCBhbmQgbm90IGluY2x1ZGUgdGhlIHN1YiBhdHRyaWJ1dGUuDQoq ICBGb3IgZXZlbnRzIHRoYXQgYXJlIGFib3V0IGEgdXNlciwgdGhlIHJlbGV2YW50IGV2ZW50IHNw ZWNpZmljYXRpb24gbWF5IGluY2x1ZGUgYSDigJxzdWLigJ0gYXR0cmlidXRlIHdpdGhpbiB0aGUg ZXZlbnTigJlzIHN1Yi1vYmplY3QgYW5kIG5vdCBpbiB0aGUgdG9wLWxldmVsLiBGdXJ0aGVyIHRo YXQgc3ViLW9iamVjdCBjYW4gYWxzbyBpbmNsdWRlIHRoZSBpc3N1ZXIgb2YgdGhlIHVzZXIuDQoq IFRoZSB0b3AtbGV2ZWwg4oCcaXNz4oCdIHNoYWxsIG1lYW4gdGhlIGlzc3VlciBvZiB0aGUgZXZl bnQgd2hlcmUgdGhlIHN0YXRlIGNoYW5nZSBvY2N1cnJlZC4NCiogIOKAnHN1YuKAnSBzaG91bGQg bm90IGJlIHByZXNlbnQgaW4gdGhlIHRvcCBsZXZlbCBzdHJ1Y3R1cmUuICBBbHNvLCDigJxldmVu dHPigJ0gbXVzdCBhbHNvIGJlIHByZXNlbnQuDQoNCkhlcmUgd291bGQgYmUgYSBuZXcgZXhhbXBs ZSBsb2dvdXQ6DQoNCnsNCg0KICA84oCUIHRvcCBsZXZlbCBpcyBhYm91dCB0aGUgZXZlbnQgaXRz ZWxmIC0+DQoNCiAgImlzcyI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbTxodHRwczovL3Nl cnZlci5leGFtcGxlLmNvbS8+IiwNCg0KICAiYXVkIjogInM2QmhkUmtxdDMiLA0KDQogICJqdGki OiAiM2QwYzNjZjc5NzU4NGJkMTkzYmQwZmIxYmQ0ZTdkMzAiLA0KDQogICJpYXQiOiAxNDU4NjY4 MTgwLA0KDQogICJleHAiOiAxNDU4NjY4NTgwLA0KDQogICJldmVudHMiOiBbDQoNCiAgICAiaHR0 cHM6Ly9zcGVjcy5vcGVuaWQubmV0L2xvZ291dCINCg0KICBdLA0KDQogICJodHRwczovL3NwZWNz Lm9wZW5pZC5uZXQvbG9nb3V0Ijogew0KDQogICAgPC0gVGhpcyBsZXZlbCBpcyBkZWZpbmVkIGVu dGlyZWx5IGJ5IHRoZSBldmVudCBVUkktPg0KDQogICAgImlzcyI6ICJodHRwczovL29pZGMuZXhh bXBsZS5jb208aHR0cHM6Ly9vaWRjLmV4YW1wbGUuY29tLz4iLA0KDQogICAg4oCcanRpIjogIjA4 YTUwMTljLTE3ZTEtNDk3Ny04ZjQyLTY1YTEyODQzZWEwMuKAnSwNCg0KICAgICJzdWIiOiAiMjQ4 Mjg5NzYxMDAx4oCdLA0KDQogICAg4oCcZXhw4oCdOiA8SUQgdG9rZW4gZXhwaXJ5Pg0KDQogIH0N Cg0KfQ0KDQpJbiB0aGUgYWJvdmUgZXhhbXBsZSBub3RlIHRoYXQgdGhlIOKAnGV2ZW504oCdIG9i amVjdCBjYW4gaGF2ZSBpdHMgb3duIGlzcyBhbmQgc3ViamVjdCAoc3ViIG9yIGp0aSkgdGhhdCBo YXZlIG1lYW5pbmcgd2l0aGluIHRoZSBjb250ZXh0IG9mIGFuIE9wZW5JRCBPUCBwcm92aWRlci4g IFRoZSBpc3N1ZXIgb2YgdGhlIGV2ZW50IGNhbiBiZSBkaWZmZXJlbnQgKHRoZSB0b3AtbGV2ZWwp IGFuZCByZXByZXNlbnRzIHRoZSBlbnRpdHkgdGhhdCBzaWducyB0aGUgZXZlbnQgKGlmIGl0IGlz IHNpZ25lZCkuDQoNClRoZSB0b3AtbGV2ZWwgYXR0cmlidXRlcyBpZGVudGlmeSBhbiBpbmRpdmlk dWFsIGV2ZW50IGFuZCBhcmUgdXNlZCB0byB2YWxpZGF0ZSB0aGUgZXZlbnQgKHNpZ25pbmcgZXRj KS4gIFdoZXJlIGFzIHRoZSBuZXN0ZWQgb2JqZWN0IGNvbnRhaW5zIGFsbCBvZiB0aGUgZGF0YSBh Ym91dCB0aGUgZXZlbnQgYW5kIGlzIGRlZmluZWQgYnkgdGhlIHByb2ZpbGluZyBzcGVjaWZpY2F0 aW9uIChlLmcuIGEgcG9zc2libGUgT3BlbklEIExvZ291dCBFdmVudCBzcGVjKS4gIEluIHRoaXMg Y2FzZSwgaW4gT3BlbklELCBsb2dnaW5nIG91dCB1c3VhbGx5IHRyYW5zbGF0ZXMgaW50byByZXZv a2luZyBhbiBJRCBUb2tlbi4gVGh1cyB0aGUg4oCcanRp4oCdIGZvciB0aGUgSUQgdG9rZW4gKDA4 YTUwMTljLi4uODQzZWEwMikgaXMgaW5jbHVkZWQgaW4gdGhlIExvZ291dCBvYmplY3QuDQoNClNp ZGUgbm90ZS4gIFJlZ2FyZGluZyDigJxsb2dvdXTigJ0sIGl0IG1pZ2h0IGJlIHVzZWZ1bCB0byBp bmNsdWRlIHRoZSBleHBpcnkgb2YgdGhlIElEIFRva2VuIGluIGNhc2UgdGhlIHN1YnNjcmliZXIg aGFzIG5vdCB5ZXQgcmVjZWl2ZWQgYW4gSUQgVG9rZW4uIFRoaXMgd291bGQgbGV0IHRoZSBzdWJz Y3JpYmVyIGtub3cgaG93IGxvbmcgaXQgbmVlZHMgdG8ga2VlcCB0aGUgcmV2b2NhdGlvbiBpbmZv cm1hdGlvbiBmb3IuICBJT1figKZhZnRlciB0aGUgdGhlIElEIFRva2VuIGlzIGV4cGlyZWQsIHRo ZSBzdWJzY3JpYmVyIHdvdWxkIG5vIGxvbmdlciBuZWVkIHRvIHRyYWNrIHRoZSByZXZvY2F0aW9u IHN0YXRlLg0KDQpJdCBpcyBhbHNvIGdvb2QgdG8gb2JzZXJ2ZSB0aGF0IHRoZSDigJxhdWTigJ0g YXQgdGhlIHRvcCBsZXZlbCBkZXNjcmliZXMgdGhlIHN1YnNjcmliZXIgb2YgdGhlIGV2ZW50LiAg VGhpcyBtYXkgYWxzbyBiZSBkaWZmZXJlbnQgdGhlbiB0aGUgb3JpZ2luYWwgYXVkaWVuY2Ugb2Yg dGhlIElEIFRva2VuLg0KDQpTbyB0byBjb25jbHVkZS4gQnkgbWFraW5nIHRvcC1sZXZlbCBhdHRy aWJ1dGVzIHN0cmljdGx5IGFib3V0IHRoZSBldmVudHMgb3duIHZhbGlkYXRpb24sIGFuZCBuZXN0 ZWQgb2JqZWN0cyBhYm91dCB0aGUgZXZlbnQsIHdlIGF2b2lkIGNvbGxpc2lvbnMgaW4gZGVmaW5p dGlvbnMgc3VjaCBhcyB0aGUgaXNzdWVyIG9mIHRoZSBldmVudCwgdnMuIHRoZSBvcmlnaW5hbCBp c3N1ZXIgb2YgYSBzZWN1cml0eSBhc3NlcnRpb24uDQoNCkkgaG9wZSBJ4oCZdmUgZ290dGVuIGV2 ZXJ5b25l4oCZcyBmZWVkYmFjayBjb3JyZWN0IGhlcmUuIExldHMgY29udGludWUgdG8gZGlzY3Vz cy4gSSB3aWxsIHJldmlzZSB0aGUgZHJhZnQgdG8gZm9sbG93IHRoZSBncm91cHMgdGhpbmtpbmcg aGVyZS4NCg0KUGhpbA0KDQpAaW5kZXBlbmRlbnRpZA0Kd3d3LmluZGVwZW5kZW50aWQuY29tPGh0 dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20vPg0KcGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRv OnBoaWwuaHVudEBvcmFjbGUuY29tPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KSWQtZXZlbnQgbWFpbGluZyBsaXN0DQpJZC1ldmVudEBpZXRmLm9y ZzxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2lkLWV2ZW50DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCklkLWV2ZW50IG1haWxpbmcgbGlzdA0KSWQtZXZlbnRAaWV0Zi5vcmc8 bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9pZC1ldmVudA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KSWQtZXZlbnQgbWFpbGluZyBsaXN0DQpJZC1ldmVudEBpZXRmLm9yZzxtYWls dG86SWQtZXZlbnRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2lkLWV2ZW50DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KSWQtZXZlbnQgbWFpbGluZyBsaXN0DQpJZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86SWQt ZXZlbnRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lk LWV2ZW50DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpJZC1ldmVudCBtYWlsaW5nIGxpc3QNCklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVu dEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZl bnQNCg0K --_000_SN1PR0301MB164534BDE4F6485B1CAC4FACF51E0SN1PR0301MB1645_ 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 DQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4w cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToi Q291cmllciBOZXciO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1h bDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy Z2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5hcHBsZS1zdHlsZS1zcGFuDQoJe21zby1zdHlsZS1uYW1l OmFwcGxlLXN0eWxlLXNwYW47fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0 eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4ubS02NTM0NDM1NTczNjM5Njcz Nzg2YXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOm0tNjUzNDQzNTU3MzYz OTY3Mzc4NmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250 LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjojMDAyMDYwO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVT IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+WW91 4oCZcmUgYXdhcmUgdGhhdCBmb3JjaW5nIOKAnHN1YuKAnSB0byBiZSBhIFVSSSBpcyBhIGJyZWFr aW5nIGNoYW5nZSBmb3IgbW9zdCBpbXBsZW1lbnRhdGlvbnMsIHJpZ2h0PyZuYnNwOyBUaGlzIGlz IGhhcmRseSBhIHdheSB0byBlbmNvdXJhZ2UgYWRvcHRpb24hPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMDAyMDYwIj5UaGUgdGhpbmcgeW91IHdyb3RlIGJlbG93IHRoYXQgbWFr ZXMgbWUgdGhpbmsgdGhhdCB5b3XigJlyZSB0aGlua2luZyBhYm91dCB0aGUgcHVycG9zZSBvZiB0 aGUgSUQgRXZlbnRzIHNwZWMgZGlmZmVyZW50bHkgdGhhbiBtZSBpcyB0aGlzOiDigJw8L3NwYW4+ c28gdGhhdCBhbGwgZXZlbnQNCiBzcGVjcyBjYW4gdXNlIGl0PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMwMDIwNjAiPuKAnS4mbmJzcDsgVGhlIHB1cnBvc2Ugb2YgdGhlIGxvZ291dCBldmVudCAqPGI+ aXNu4oCZdDwvYj4qIGZvciBhbGwgZXZlbnQgc3BlY3MgdG8gdXNlIGl0LiZuYnNwOyBJdOKAmXMg Zm9yIHRoZSBsb2dvdXQgdXNlIGNhc2UgdG8gdXNlIGl0LiZuYnNwOyBUaGVyZeKAmXMgbm8gZXhw ZWN0YXRpb24gdGhhdCBldmVudHMgaW50ZW5kZWQNCiBmb3Igb25lIHVzZSBjYXNlIHdpbGwgZXZl biBiZSBjb21wcmVoZW5zaWJsZSBpbiBvdGhlciB1c2UgY2FzZXMgYmVjYXVzZSB0aGV5IHdvbuKA mXQgdW5kZXJzdGFuZCB0aGUgY29udGVudHMgb2YgdGhlIGV2ZW50LiZuYnNwOyBXZSBzaG91bGRu 4oCZdCBkcml2ZSBhbnkgb2YgdGhlIGRlc2lnbiBieSB0cnlpbmcgdG8gYWNoaWV2ZSB0aGF0IHVu YWNoaWV2YWJsZSBnb2FsLCBzaW5jZSBldmVudHMgd2lsbCAqPGI+YWx3YXlzPC9iPiogY29udGFp biBpbmZvcm1hdGlvbg0KIHRoYXTigJlzIHNwZWNpZmljIHRvIHRoZWlyIHVzZSBjYXNlLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+WW914oCZcmUgbWFraW5nIGNv bXBsZXhpdHkgYXJndW1lbnRzLCB3aGVyZWFzIHlvdeKAmXJlIGFsc28gcHJvcG9zaW5nIG1vcmUg Y29tcGxleCBydWxlcyB0aGFuIEkgYW0gKGF0IGxlYXN0IGFzIEkgc2VlIGl0KS4mbmJzcDsgVHJ5 aW5nIHRvIHJlc3RyaWN0IHRoZSB1c2Ugb2Yg4oCcc3Vi4oCdIChvcg0KIGFueSBvdGhlciBjbGFp bXMpIGlzIHVubmVlZGVkIGNvbXBsZXhpdHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMDAyMDYwIj5JIHVuZGVyc3RhbmQgdGhhdCB5b3Ugc2VlIHRoaW5ncyBkaWZmZXJlbnRs eS4mbmJzcDsgSSBob3BlIHlvdeKAmWxsIG5vbmV0aGVsZXNzIHRoaW5rIGFib3V0IG15IGFyZ3Vt ZW50IHRoYXQgaGF2aW5nIGZld2VyIHJ1bGVzIGFib3V0IGNsYWltcyB1c2FnZSBpbiBldmVudHMg d2lsbCBtYWtlDQogdGhlbSBzaW1wbGVyLiZuYnNwOyBJIHBhc3Npb25hdGVseSBjYXJlIGFib3V0 IGtlZXBpbmcgdGhpcyBzaW1wbGUsIHdoaWNoIGlzIHdoeSBJ4oCZbSBpbnZlc3RpbmcgbXkgdGlt ZSBpbiB0aGlzIGRpc2N1c3Npb24uJm5ic3A7IElmIGl04oCZcyBzaW1wbGUsIGl0IHdpbGwgbGlr ZWx5IGdldCB3aWRlbHkgdXNlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMw MDIwNjAiPknigJltIGdvaW5nIHRvIHNpZ24gb3V0IG9mIHRoZSBkaXNjdXNzaW9uIGZvciBub3cg YmVjYXVzZSBteSB3aWZlIGlzIGFib3V0IHRvIGdldCBvdXQgb2Ygc3VyZ2VyeS4mbmJzcDsgSSBo b3BlIHlvdSBoYXZlIGEgZ29vZCBkYXkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlr ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9N YWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5k Q29tcG9zZSI+PC9zcGFuPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+IFBoaWwgSHVudCBbbWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tXQ0KPGJy Pg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBBdWd1c3QgMTEsIDIwMTYgMTI6NDkgUE08YnI+DQo8 Yj5Ubzo8L2I+IE1pa2UgSm9uZXMgJmx0O01pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSZndDs8 YnI+DQo8Yj5DYzo8L2I+IEpvaG4gQnJhZGxleSAmbHQ7dmU3anRiQHZlN2p0Yi5jb20mZ3Q7OyBv cGVuaWQtc3BlY3MtYWJAbGlzdHMub3BlbmlkLm5ldCBBYiAmbHQ7b3BlbmlkLXNwZWNzLWFiQGxp c3RzLm9wZW5pZC5uZXQmZ3Q7OyBpZC1ldmVudEBpZXRmLm9yZzsgTWFyaXVzIFNjdXJ0ZXNjdSAm bHQ7bXNjdXJ0ZXNjdUBnb29nbGUuY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0lk LWV2ZW50XSBTdW1tYXJpemluZyByZWNlbnQgZGlzY3Vzc2lvbnMgb24gSUQtRXZlbnQgdG9rZW4g ZHJhZnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NaWtl LCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3Bl YWtpbmcgYXMgZWRpdG9yIHRoZSBmb3JtYXQgeW91IHByb3Bvc2UgT05MWSB3b3JrcyBpZiDigJxz dWLigJ0gYmVjb21lcyBhIFVSSSBzbyB0aGF0IGFsbCBldmVudCBzcGVjcyBjYW4gdXNlIGl0LiAm bmJzcDtPdGhlcndpc2UsIE9JREMgYmVjb21lcyBhIHNwZWNpYWwgY2FzZSB3aGljaCByZWFsbHkg a2lsbHMgdGhlIHBvaW50IG9mIHRoaXMgd29yay4gSXQgYWxzbyBtYWtlcyB0aGUgc3BlY2lmaWNh dGlvbiBtdWNoIG11Y2gNCiBtb3JlIGNvbXBsZXguIE1heWJlIGl0IGlzIGp1c3QgbWUsIGJ1dCBh IGNvbXBsZXggc3BlYyBnZW5lcmFsbHkgaW1wbGllcyBjb21wbGV4IGltcGxlbWVudGF0aW9uIHRv by48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SWYgeW91IHdhbnQgc3ViIGF0IHRoZSB0b3AgbGV2ZWwsIHRoYXQgd291bGQgbWVhbiB0aGF0IHRo ZSBPSURDIHNwZWMgZm9ybWF0IHdvdWxkIGhhdmUgdG8gbG9vayBsaWtlOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPns8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmcXVvdDtp c3MmcXVvdDs6ICZxdW90OzxhIGhyZWY9Imh0dHBzOi8vZXZlbnQuZXhhbXBsZS5jb20iPjxzcGFu IHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vZXZlbnQuZXhhbXBsZS5jb208L3NwYW4+PC9h PiZxdW90Oyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOyAmcXVvdDthdWQmcXVvdDs6ICZxdW90O3M2QmhkUmtxdDMmcXVvdDssPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJnF1 b3Q7anRpJnF1b3Q7OiAmcXVvdDszZDBjM2NmNzk3NTg0YmQxOTNiZDBmYjFiZDRlN2QzMCZxdW90 Oyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOyA8c3BhbiBzdHlsZT0iY29sb3I6I0I1MUEwMCI+JnF1b3Q7c3ViJnF1b3Q7OiDigJw8YSBo cmVmPSJodHRwczovL3Rva2VuLmV4YW1wbGUuY29tLzI0ODI4OTc2MTAwMSI+aHR0cHM6Ly90b2tl bi5leGFtcGxlLmNvbS8yNDgyODk3NjEwMDE8L2E+JnF1b3Q7LDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmcXVvdDtpYXQm cXVvdDs6IDE0NTg2NjgxODAsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDsgJnF1b3Q7ZXhwJnF1b3Q7OiAxNDU4NjY4NTgwLDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZxdW90 O2V2ZW50cyZxdW90OzogWzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmcXVvdDs8YSBocmVmPSJodHRwczovL3NwZWNzLm9w ZW5pZC5uZXQvbG9nb3V0Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3NwZWNz Lm9wZW5pZC5uZXQvbG9nb3V0PC9zcGFuPjwvYT4mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyBdLDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZxdW90O3NpZCZxdW90 OzogJnF1b3Q7MDhhNTAxOWMtMTdlMS00OTc3LThmNDItNjVhMTI4NDNlYTAyJnF1b3Q7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj59PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkdpdmVuIHRoYXQg ZXZlbnRzIGFyZSBzaWduZWQgKG9yIHNob3VsZCBiZSksIDx1Pkkgd2lsbCBvYmplY3Qgc3Ryb25n bHkgd2l0aGluIHRoZSBPSURGIHRoYXQgdGhlIGV2ZW50IGlzc3VlciBhbmQgdGhlIHRva2VuIGlz c3VlciBNVVNUIGJlIHRoZSBzYW1lIG9yIHRoYXQgT0lERiBhZG9wdCBhIGRpZmZlcmVudCBmb3Jt YXQ8L3U+LiBZZXMgaGF2aW5nIGlzcyBiZSB0aGUgc2FtZSBpcyBhIG5pY2Ugc2VjdXJpdHkNCiBj b252ZW5pZW5jZSwgYnV0IGl0IGltcG9zZXMgdGhlIGFyY2hpdGVjdHVyZSByZXN0cmljdGlvbiB0 aGF0IGl0IGJlIHRoZSBzYW1lIHNlcnZlci4gJm5ic3A7QXQgc2NhbGUsIGRlbGl2ZXJ5IG9mIGV2 ZW50cyBtYXkgYmVjb21lIGEgcHJvYmxlbSBmb3IgbGFyZ2Ugc2NhbGUgcHJvdmlkZXJzIGlmIHRo ZXkgYXJlIGFsc28gZGVsaXZlcmluZyB0b2tlbnMgdG8gcmVseWluZyBwYXJ0aWVzLiBUaGUgcmVz dHJpY3Rpb24gaXNu4oCZdCByZWFsbHkganVzdGlmaWVkDQogZ2l2ZW4gdGhlIGNyeXB0byBhbHRl cm5hdGl2ZSDigJQgd2hpY2ggd2FzIHRoZSB3aG9sZSBwb2ludCBvZiB1c2luZyBKV1QgaW4gdGhl IGZpcnN0IHBsYWNlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5QZXIgSnVzdGlu4oCZcyBjb21tZW50LCBpdCBzZWVtcyBlbGVnYW50L3RyaXZp YWwgdGhhdCBhIGxvZ291dCBldmVudCBzaW1wbHkgaGFzIGxvZ291dCBhdCB0aGUgdG9wIGxldmVs IGFuZCBhbiBJRCBUb2tlbiBhdHRhY2hlZCAodGhvdWdoIGl0IG1pZ2h0IGNvbnZleSBhIGxvdCBv ZiB1bm5lZWRlZCBjbGFpbXMpLiAmbmJzcDtJTU8sIHRoZSBPSURDIGxvZ291dCBzcGVjIHNob3Vs ZCBvbmx5IGNvbnZleSB0aGUgSUQgVG9rZW4NCiBKVEkuICZuYnNwO0l0IGlzIGdvaW5nIHRvIGJl IHJhcmUgdGhhdCB5b3UgbG9nIG91dCBhbGwgZGV2aWNlcyBmb3IgYSB1c2VyLiAmbmJzcDtUbyBt b3N0IHVzZXJzLCBpdCBtZWFucyBjbGVhciBTU08gd2l0aGluIHRoaXMgYnJvd3NlciBvbmx5ISAm bmJzcDtPbmUgY2FuIGFyZ3VlIHRoYXQgY2xlYXJpbmcgYWxsIGRldmljZXMvc2Vzc2lvbnMgaXMg YSBkaWZmZXJlbnQgZXZlbnQgZW50aXJlbHkuIEl0IGlzIGFuIGFjY291bnQgcmVzZXQgb3IgbG9j ay1vdXQgYWN0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5QaGlsPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkBpbmRlcGVuZGVudGlkPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YSBocmVmPSJodHRwOi8vd3d3LmluZGVwZW5kZW50 aWQuY29tIj53d3cuaW5kZXBlbmRlbnRpZC5jb208L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNv bSI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk9uIEF1ZyAxMSwgMjAxNiwgYXQgOTozMiBBTSwgTWlrZSBKb25lcyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSI+TWljaGFlbC5Kb25lc0BtaWNy b3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+U2VlIG15IHByZXZp b3VzIG1lc3NhZ2UsIEpvaG4sIHdoaWNoIHdhcyBhIHJlcGx5IHRvIFBoaWzigJlzIG1lc3NhZ2Ug dGhhdCB5b3UgYWxzbyByZXBsaWVkIHRvLCB0aGF0IGNvbnRhaW5lZCBhIGxvZ291dCBjbGFpbXMg ZXhhbXBsZS4mbmJzcDsgSeKAmW0gbm90IHByb3Bvc2luZyB0byBzcGVjaWFsLWNhc2UNCiB0aGUg Q29ubmVjdCBMb2dvdXQgbWVzc2FnZSBpbiBhbnkgd2F5LiZuYnNwOyBUaGUg4oCcaXNz4oCdIGlz IHRoZSBldmVudCBpc3N1ZXIuJm5ic3A7IFRoZSBvdGhlciBjbGFpbXMgaW4gdGhlIG1lc3NhZ2Ug YXJlIHRob3NlIGRlZmluZWQgYnkgdGhlIGV2ZW50IHRvIGJlIGluY2x1ZGVkLCBqdXN0IGxpa2Ug dGhvc2UgZm9yIGFueSBvdGhlciBldmVudC4mbmJzcDsgWWVzLCB0aGUgbG9nb3V0IG1lc3NhZ2Ug ZG9lc27igJl0IGluY2x1ZGUgYSBzZWNvbmQgaXNzdWVyLCBhIHNlY29uZCBzdWJqZWN0LA0KIGFu IElEIFRva2VuIGFzIGEgY2xhaW0sIG9yIGFueXRoaW5nIGVsc2UgY29tcGxpY2F0ZWQgbGlrZSB0 aGF0LCBiZWNhdXNlIHRob3NlIHRoaW5ncyBhcmVu4oCZdCBuZWVkZWQgZm9yIHRoZSBsb2dvdXQg dXNlIGNhc2UuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5BcyBJ4oCZZCB3cml0dGVuIHByZXZpb3VzbHksIHRo ZSBJRCBFdmVudHMgc3BlYyBzaG91bGQgZGVmaW5lIHRoZSDigJxldmVudHPigJ0gY2xhaW0sIGhv dyB0byB1c2UgYW4gZXZlbnQgbmFtZSBhcyBhIGNsYWltICh3aGVuIG5lZWRlZCksIGFuZCBzYXkg dGhhdCB0aGUgZXZlbnQgSldUDQogbXVzdCBiZSBzaWduZWQgYnkgdGhlIGlzc3VlciwgYW5kIHN0 b3AgdGhlcmUuJm5ic3A7IFRyeWluZyB0byBtaWNyby1tYW5hZ2UgY2xhaW1zIHVzYWdlIHdpdGhp biBhbiBldmVudCB3aWxsIG9ubHkgcmVzdWx0IGluIHRoZSBJRCBFdmVudHMgc3BlYyBiZWluZyBo YXJkZXIgdG8gdXNlLiZuYnNwOyBJZiB3ZeKAmWQgdHJpZWQgdG8gc2ltaWxhcmx5IG1pY3JvLW1h bmFnZSBKV1QgY2xhaW1zIHVzYWdlLCBKV1Qgd291bGQgbGlrZWx5IG5vdCBoYXZlIGJlZW4gdGhl IHN1Y2Nlc3MNCiB0aGF0IGl0IGlzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAw MjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPkpvaG4NCiBCcmFkbGV5IFs8YSBocmVmPSJtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20iPm1h aWx0bzp2ZTdqdGJAdmU3anRiLmNvbTwvYT5dPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5UaHVyc2RheSwgQXVndXN0IDExLCAyMDE2IDEy OjIyIFBNPGJyPg0KPGI+VG86PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj5QaGlsIEh1bnQgKElETSkgJmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1 bnRAb3JhY2xlLmNvbSI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwv Yj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+TWlrZSBK b25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSI+TWlj aGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86aWQtZXZl bnRAaWV0Zi5vcmciPmlkLWV2ZW50QGlldGYub3JnPC9hPjsgTWFyaXVzIFNjdXJ0ZXNjdSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbSI+bXNjdXJ0ZXNjdUBnb29nbGUu Y29tPC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86b3BlbmlkLXNwZWNzLWFiQGxpc3RzLm9wZW5p ZC5uZXQiPm9wZW5pZC1zcGVjcy1hYkBsaXN0cy5vcGVuaWQubmV0PC9hPiBBYiAmbHQ7PGEgaHJl Zj0ibWFpbHRvOm9wZW5pZC1zcGVjcy1hYkBsaXN0cy5vcGVuaWQubmV0Ij5vcGVuaWQtc3BlY3Mt YWJAbGlzdHMub3BlbmlkLm5ldDwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBbSWQtZXZlbnRdIFN1 bW1hcml6aW5nIHJlY2VudCBkaXNjdXNzaW9ucyBvbiBJRC1FdmVudCB0b2tlbiBkcmFmdDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk5vdCBzdXJwcmlzaW5nbHkgYSBtdWx0aXB1cnBvc2UgbWVzc2FnZSBm b3JtYXQgd2lsbCBub3QgYmUgYXMgb3B0aW1pemVkIGFzIGEgc2luZ2xlIHB1cnBvc2Ugb25lLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Q29ubmVjdCBpdHNlbGYgZG9lc27igJl0IHJlYWxseSBoYXZlIGEg Y29uZmxpY3QgYXJvdW5kIGlzc3VlciB0aGUgc2FtZSBlbnRpdHkgc2VuZGluZyB0aGUgbG9nb3V0 IG1lc3NhZ2UgaXMgYWx3YXlzIHRoZSBvbmUgdGhhdCBjcmVhdGVkIHRoZSBpZF90b2tlbiB0aGF0 IGl0IHJlZmVycyB0by48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VXNpbmcgdGhlIHNhbWUg Zm9ybWF0IGFzIGlkX3Rva2VuIHdpdGggdGhlIHNhbWUgc2VtYW50aWNzIHRvIGlkZW50aWZ5IHRo ZSB0aGluZyB0byBiZSB0ZXJtaW5hdGVkIG1ha2VzIHNlbnNlIGZyb20gYSBwdXJlbHkgb3BlbklE IENvbm5lY3QgcG9pbnQgb2Ygdmlldy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T3RlciBt ZXNzYWdlcyB0aGF0IGhhdmUgZGlmZmVyZW50IG5vdGlvbnMgb2Ygc3ViamVjdCBhbmQgYXJlIGlz c3VlZCBieSBkaWZmZXJlbnQgcGFydGllcyB0aGFuIHRoZSBvbmUgdGhhdCBjb250cm9scyB0aGUg c3ViamVjdCBjYXVzZSBpc3N1ZXMgd2hlbiB5b3UgdHJ5IGFuZCBmaXQgdGhlbSBpbnRvIHRoZSBz YW1lIGZvcm1hdCBhcyBhbiBJRF9Ub2tlbiwgSSBncmFudCB5b3UgdGhhdC48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SXQgd2FzIG1lbnRpb25lZCB0aGF0IHdlIG5lZWQgdG8gZGlmZmVyZW50 aWF0ZSBiZXR3ZWVuIHRoZXNlIGV2ZW50cyBhbmQgaWRfdG9rZW5zLiAmbmJzcDtNb3N0bHkgd2Ug bmVlZCB0byBkbyB0aGF0IGluIGNhc2VzIHdoZXJlIHRoZSB0b2tlbiBtaWdodCBiZSBwcmVzZW50 ZWQgaW4gdGhlIGZyb250IGNoYW5uZWwuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRvIGRv IHRoYXQgc2UgZG8gaGF2ZSBtYW5kYXRvcnkgY2xhaW1zIGZvciBub25jZSBhbmQgY19oYXNoIG9y IGF0X2hhc2ggYXMgd2VsbCBhcyB0aGUgYWRkaXRpb24gb2YgZXZlbnRzIHBhcmFtZXRlciB0byBy ZWR1Y2UgY29uZnVzaW9uLiAmbmJzcDsgTm93IEkgYWRtaXQgdGhhdCBzb21lIHBlb3BsZSBtYXkg c3RpbGwgZ2V0IHRoYXQgd3JvbmcsICZuYnNwO2FuZCB0aGUgcmVtb3ZhbCBvZiBzdWIgZnJvbSB0 aGUgdG9wIGxldmVsDQogd291bGQgcmVtb3ZlIGFueSBjb25jZXJuLiAmbmJzcDtIb3dldmVyIE1p a2UgaGFzIGEgcG9pbnQgdGhhdCBhZG9wdGlvbiBtYXkgYmUgaHVydCBpZiB3ZSBjaGFuZ2UgdGhl IHNlbWFudGljcyB0b28gbXVjaC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkb27igJl0 IHNlZSBiYWNrY2hhbm5lbCBzaW5nbGUgbG9nb3V0IGJlaW5nIHVzZWQgYnkgbWFueSBzb2NpYWwg bG9naW4gUlAsIGl0IGlzIGEgbG90IG9mIHdvcmsgdG8gbWFpbnRhaW4gc2VydmVyIHNpZGUgc3Rh dGUuICZuYnNwOyBJdCBpcyBtb3N0bHkgYW4gZW50ZXJwcmlzZSBhbmQgbGFyZ2Ugc2l0ZSBzb3J0 IG9mIGZlYXR1cmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGF0IG1heSBvciBtYXkgbm90IGltcGFjdCBvbiBpZiBp dCBpcyBiZXR0ZXIgdG8gYmUgc2ltcGxlIGFuZCBhbGlnbmVkIHdpdGggY29ubmVjdOKAmXMgaWQg dG9rZW4gb3IgbW9yZSBnZW5lcmFsIHB1cnBvc2UgdG8gZml0IHdpdGggb3RoZXIgZW50ZXJwcmlz ZSB0byBTYWFTIGZlYXR1cmVzIGxpa2UgU0NJTSBldmVudHMuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkkgdGhpbmsgdGhlIHR3byBkaXJlY3Rpb25zIGxlYWQgdG8gZGlmZmVyZW50IGZvcm1h dHMuICZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgY29tcHJvbWlz ZSBvZiBzcGVjaWFsIGNhc2luZyBDb25uZWN0IFNMTyBhbmQgYm9kZ2luZyB0aGUgZm9ybWF0cyB0 b2dldGhlciBpcyBwcm9iYWJseSB0aGUgd29yc3Qgb3B0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5Kb2huIEIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIEF1ZyAxMSwgMjAxNiwgYXQgMTE6NTkgQU0sIFBoaWwgSHVudCAoSURNKSAmbHQ7PGEg aHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVy cGxlIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvc3Bhbj48L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkhvdyBkbyB5b3UgcmVzb2x2ZSBjb25mbGljdHMg b24gaXNzIHRoZW4/ICZuYnNwO1RoZSB0b3AgbGV2ZWwgaGFzIHRvIGJlIHRoZSBpc3N1ZXIgb2Yg dGhlIGV2ZW50IGFzIHRoZSBpc3N1ZXIgc2lnbnMuJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ SWYgb25lIHNwZWMgY2FuIHVzZSBpdCBhbGwgbXVzdCBiZSBhYmxlIHRvLiBJIGJlbGlldmUgeW91 IHByZXZpb3VzbHkgb2JqZWN0ZWQgdG8gdGhhdCBzYXlpbmcgc3ViIG11c3QgYmUgYXMgaG93IGlk IHRva2VucyBkZWZpbmUgdGhlbS4gQnV0IHRoYXQgaXNudCB1bmlxdWUgYW5kIHJlcXVpcmVzIGlz cy4NCiBOb3cgd2Ugd291bGQgaGF2ZSBzdWIgYXQgdGhlIHRvcCB3aXRoIGFuIGV2ZW50IGlzc3Vl ciBhdCB0aGUgdG9wIGFuZCBhIHN1YiBpc3N1ZXIgaW4gdGhlIGV4dGVuc2lvbi4gVGhhdCBzZWVt cyBpbmNyZWRpYmx5IGNvbXBsZXggbm90IHRvIG1lbnRpb24gYXdrd2FyZC4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj5JZiB3ZSBtYWtlIHN1YiBhIHVyaSBmb3IgYWxsIHRoZW4gaXQgY2FuIHdv cmsgYXNzIGlzcyBmcm9tIGlkIHRva2VuIHdvdWxkIG5vdCBiZSBuZWVkZWQuIEJ1dCBpIGNhbiBz ZWUgbWFueSBvYmplY3RpbmcgdG8gdGhlIGNoYW5nZSBpbiBmb3JtYXQuJm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+V2h5IG5vdCBoYXZlIGEgbG9nb3V0IGJlIGFuIGV2ZW50IHdpdGggYW4gaWQg dG9rZW4gYXR0YWNoZWQgZm9yIGV4YW1wbGU/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZiI+PGJyPg0KUGhpbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj48YnI+DQpPbiBBdWcgMTEsIDIwMTYsIGF0IDg6MDMgQU0sIE1pa2Ug Sm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iPjxz cGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvc3Bh bj48L2E+Jmd0OyB3cm90ZTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQ7Zm9udC12YXJp YW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBh dXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMDAyMDYwIj5UaGUgc2ltcGxlIHJ1bGUgaXMgdGhhdCBpZiB0aGUgcGFydGljdWxhciBl dmVudCBjYWxscyBmb3IgdGhlIOKAnHN1YuKAnSBjbGFpbSB0byBiZSBhdCB0aGUgdG9wIGxldmVs LCB0aGVuIGl0IGlzLiZuYnNwOyBUaGlzIGlzIG5vIGRpZmZlcmVudCBmcm9tIGFueSBvdGhlciBj bGFpbSB0aGF0DQogYW4gZXZlbnQgbWlnaHQgcGxhY2UgYXQgdGhlIHRvcCBsZXZlbC48L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPlRoZSBjb21wbGV4aXR5IGFy aXNlcyBpZiDigJxzdWLigJ0gaXMgdW5uZWNlc3NhcmlseSBzcGVjaWFsLWNhc2VkLiZuYnNwOyBX ZSBzaG91bGRu4oCZdCBkbyB0aGF0LCBiZWNhdXNlIGl0IGxpbWl0cyB0aGUgYXBwbGljYWJpbGl0 eSBvZiB0aGUgc3BlY2lmaWNhdGlvbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBN aWtlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5QaGlsDQogSHVudCAoSURNKSBbPGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFj bGUuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5tYWlsdG86cGhpbC5odW50QG9yYWNs ZS5jb208L3NwYW4+PC9hPl08c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPlRodXJzZGF5LCBBdWd1c3QgMTEsIDIwMTYgOTo0MCBBTTxicj4N CjxiPlRvOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+TWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0 LmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQu Y29tPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5NYXJpdXMgU2N1cnRlc2N1ICZsdDs8YSBocmVmPSJt YWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5t c2N1cnRlc2N1QGdvb2dsZS5jb208L3NwYW4+PC9hPiZndDs7PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzppZC1ldmVudEBpZXRm Lm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aWQtZXZlbnRAaWV0Zi5vcmc8L3NwYW4+ PC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj5SZTogW0lkLWV2ZW50XSBTdW1tYXJpemluZyByZWNlbnQgZGlzY3Vz c2lvbnMgb24gSUQtRXZlbnQgdG9rZW4gZHJhZnQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayB1c2luZyBzdWIgYXQgdGhlIHRv cCBsZXZlbCBsZWFkcyB0byBjb21wbGV4aXR5LiBFZyBDYW4geW91IHByb3ZpZGUgYSBydWxlIGZv ciB3aGVuIHRvcCBsZXZlbCBpcyB1c2VkIG9yIG5vdCBieSBhbiBpbmRpdmlkdWFsIHNwZWM/ICZu YnNwO0lNTy4gVG9wIGxldmVsIHNob3VsZCBhbHdheXMgYmUgdXNlZCB0aGUgc2FtZSB3YXkgYnkg YWxsIGltcGxlbWVudGVycy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmFzZWQgb24gdGhlIGNhbGxzIGF0IHJpc2MvY29ubmVj dCwgd2UgZGlzY3Vzc2VkIHRoYXQgaXQgd291bGQgYmUgYmVzdCB0byBtb3ZlIGFsbCBldmVudCBz cGVjaWZpY3MgdG8gdGhlIGV2ZW50IG9iamVjdCBhcmVhLiBUaGlzIHdheSBkaWZmZXJlbnQgZXZl bnRzIGNhbiBoYXZlIGRpZmZlcmVudCBldmVudCBhZGRyZXNzaW5nIChlZyBzdWIvaXNzLCB1cmks IGppdC9pc3MpLiBXaGVuIGlzcyBpcyBuZWVkZWQgdG8NCiB1bmlxdWVseSBxdWFsaWZ5IGEgc3Vi LCBpdCBjYW4gYmUgcHJvdmlkZWQgd2l0aG91dCBjb25mbGljdGluZyB3aXRoIHRoZSBpc3N1ZXIg b2YgdGhlIGV2ZW50LiBTaW1pbGFybHkganRpIGFuZCBpc3MgY2FuIGJlIHVzZWQgZm9yIGEgcmV2 b2tlZCB0b2tlbiB3aXRob3V0IGNvbmZsaWN0aW5nIHdpdGggdGhlIGV2ZW50IGp0aS4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SSBwbGFuIHRvIHBvc3QgYSBuZXcgZHJhZnQgc2hvcnRseSB0aGF0IHdpbGwgZ2l2ZSBzb21lIGV4 YW1wbGVzIGJhc2VkIG9uIGZlZWRiYWNrIGZyb20gdGhlIG9wZW5pZCByaXNjL2Nvbm5lY3QgZGlz Y3Vzc2lvbnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPldlIGNhbiBhbHdheXMgY2hhbmdlIGFnYWluLiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGJyPg0KUGhpbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+PGJyPg0KT24gQXVnIDExLCAyMDE2LCBhdCA0OjU0IEFNLCBNaWtlIEpvbmVzICZsdDs8 YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIj48c3BhbiBzdHlsZT0i Y29sb3I6cHVycGxlIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L3NwYW4+PC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPk5vLCBJ4oCZ bSBub3Qgc2F5aW5nIHRoYXQg4oCcc3Vi4oCdIGNhbm5vdCBhcHBlYXIgYXQgdGhlIHRvcCBsZXZl bC4mbmJzcDsgSeKAmW0gc2F5aW5nIHRoYXQg4oCcc3Vi4oCdIHdpbGwgb25seSBvY2N1ciBhdCB0 aGUgdG9wIGxldmVsIGlmIHRoZSBwYXJ0aWN1bGFyIGV2ZW50IGRlZmluZXMgdGhhdCDigJxzdWLi gJ0NCiBpcyB1c2VkIGluIHRoYXQgd2F5IGZvciB0aGF0IGV2ZW50Ljwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+VGhlcmUgYXJlIHByb2JhYmx5IHVzZSBjYXNl cyBmb3IgbXVsdGlwbGUgZXZlbnRzIHBlciBtZXNzYWdlIGJ1dCBJIGRvdWJ0IHRoZXJlIGFyZSB1 c2UgY2FzZXMgZm9yIG11bHRpcGxlICo8Yj51bnJlbGF0ZWQ8L2I+KiBldmVudHMgcGVyIG1lc3Nh Z2UuJm5ic3A7IEJ5IGRlZmluaXRpb24sDQogcmVsYXRlZCBldmVudHMgdGhhdCB1c2UgdG9wLWxl dmVsIGNsYWltcyB3b3VsZCBuZWVkIHRvIHVzZSB0aGVtIGluIGEgY29tcGF0aWJsZSB3YXkuJm5i c3A7IEkgZG9u4oCZdCBzZWUgdGhhdCBhcyBiZWluZyBhIHByb2JsZW0uPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5UaGF0IGJlaW5nIHNhaWQsIHRoZSBwcmVk b21pbmFudCB1c2UgY2FzZSBpcyBsaWtlbHkgdG8gYmUgYSBzaW5nbGUgZXZlbnQgcGVyIEpXVC48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAt LSBNaWtlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5i c3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPk1hcml1cw0KIFNjdXJ0ZXNjdSBbPGEg aHJlZj0ibWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1 cnBsZSI+bWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbTwvc3Bhbj48L2E+XTxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8Yj5TZW50OjwvYj48 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+VHVlc2RheSwg QXVndXN0IDksIDIwMTYgNzoxNSBQTTxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UGhpbCBIdW50ICZsdDs8YSBocmVmPSJtYWls dG86cGhpbC5odW50QG9yYWNsZS5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnBoaWwu aHVudEBvcmFjbGUuY29tPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPjxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5NaWtlIEpvbmVzICZsdDs8YSBo cmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIj48c3BhbiBzdHlsZT0iY29s b3I6cHVycGxlIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L3NwYW4+PC9hPiZndDs7PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1h aWx0bzppZC1ldmVudEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aWQtZXZl bnRAaWV0Zi5vcmc8L3NwYW4+PC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5SZTogW0lkLWV2ZW50XSBTdW1tYXJp emluZyByZWNlbnQgZGlzY3Vzc2lvbnMgb24gSUQtRXZlbnQgdG9rZW4gZHJhZnQ8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NaWtlLCBhcmUgeW91IHN1Z2dlc3Rpbmcg dGhhdCBhIHN1YiBjbGFpbSBjYW4gb25seSBzaG93IHVwIGF0IHRoZSBldmVudCBsZXZlbCBhbmQg bm90IGF0IHRoZSB0b3AgbGV2ZWw6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SW4gcGFydGljdWxhciwgdGhlIG9ubHkgdGhpbmcgdGhhdCB0aGUgc3BlYyBzaG91bGQgc2F5IGFi b3V0IHRoZSDigJxzdWLigJ0gY2xhaW0gaXMgdGhhdCDigJxMaWtlIGFsbCBvdGhlciBjbGFpbXMg b3RoZXIgdGhhbiDigJhldmVudHPigJkgYW5kIOKAmGlzc+KAmSwgd2hldGhlciB0aGUg4oCYc3Vi 4oCZIGNsYWltIGlzIHRvIGJlIGluY2x1ZGVkIHdpdGggYW4gZXZlbnQgaXMgZW50aXJlbHkgZXZl bnQtc3BlY2lmaWMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5BIHRvcCBsZXZlbCBzdWIgYW5kIG11bHRpcGxlIGV2ZW50cyBh cmUgaW5jb21wYXRpYmxlIElNTy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+RG8gd2UgaGF2ZSBhIGNvbXBlbGxpbmcgcmVhc29uIHRvIHN1 cHBvcnQgbXVsdGlwbGUgZXZlbnRzIHBlciBtZXNzYWdlPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiciBjbGVhcj0iYWxs Ij4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NYXJpdXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIEF1ZyA5LCAyMDE2IGF0IDEyOjM5 IFBNLCBQaGlsIEh1bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnBoaWwuaHVudEBvcmFj bGUuY29tPC9zcGFuPjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3YXMgcmVmZXJyaW5nIHRv IHRoaXMgaW4geW91ciBlbWFpbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZxdW90OzxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMDAyMDYwIj5EZWZpbmUgdGhhdCBhbiBldmVudCBuYW1lIGNhbiBiZSB1c2VkIGFz IGEgdG9wLWxldmVsIGNsYWlt4oCdPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JcyB0aGlzIGRpZmZlcmVudCBmcm9tIHRoZSBldmVudCB1cmk/PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QaGlsPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkBpbmRlcGVuZGVu dGlkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwOi8vd3d3LmluZGVwZW5k ZW50aWQuY29tLyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnd3 dy5pbmRlcGVuZGVudGlkLmNvbTwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnBoaWwuaHVudEBvcmFjbGUu Y29tPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBBdWcgOSwgMjAxNiwg YXQgMTI6MTIgUE0sIE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVz QG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxl Ij5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPknigJltIGdsYWQgdG8gaGVhciB0aGF0IHdlIGFncmVl IG9uIGtlZXBpbmcgaXQgYXMgc2ltcGxlIGFuZCBnZW5lcmFsLXB1cnBvc2UgYXMgcG9zc2libGUg YW5kIHRoYXQgeW91IGFncmVlIHdpdGggbXkgd3JpdGUtdXAuJm5ic3A7IEkgdGhpbmsgd2UgdGhl biBoYXZlIGEgZ29vZCBwYXRoDQogZm9yd2FyZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPknigJltIG5v dCBzdXJlIHdoYXQgeW91IG1lYW4gYnkg4oCcPC9zcGFuPknigJltIG5vdCBzdXJlIHRoYXQgd2Ug bmVlZCBhIOKAnG5hbWXigJ0uIFdoYXQgaXMgeW91ciBpbnRlbnRpb24gdGhlcmUuPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMwMDIwNjAiPuKAnSZuYnNwOw0KIFRoZSBvbmx5IHBsYWNlIEkgdXNlZCB0 aGUgd29yZCDigJxuYW1l4oCdIHdhcyBpbiBteSBzdGF0ZW1lbnQg4oCcRGVmaW5lIHRoYXQgYW4g ZXZlbnQgbmFtZSBjYW4gYmUgdXNlZCBhcyBhIHRvcC1sZXZlbCBjbGFpbeKAnS4mbmJzcDsgV2hh dCBJIHdhcyB0cnlpbmcgdG8gZ2V0IGF0IGlzIHdhcyB0aGF0IGlmIOKAnDxhIGhyZWY9Imh0dHA6 Ly9zcGVjcy5vcGVuaWQubmV0L2xvZ291dCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJj b2xvcjpwdXJwbGUiPmh0dHA6Ly9zcGVjcy5vcGVuaWQubmV0L2xvZ291dDwvc3Bhbj48L2E+4oCd DQogaXMgdXNlZCBhcyBhbiBldmVudCBuYW1lLCB0aGF0IGl0IGNhbiBhbHNvIGJlIHVzZWQgYXMg YSBjbGFpbSBuYW1lIGluIHRoZSBKV1QgY29udGFpbmluZyBpbmZvcm1hdGlvbiBhYm91dCB0aGUg ZXZlbnQuJm5ic3A7IChNYXliZSBJ4oCZbSBub3QgdXNpbmcgdGhlIGNvcnJlY3QgdGVybWlub2xv Z3ksIGhlbmNlIHRoZSB1bmludGVuZGVkIGNvbmZ1c2lvbjxzcGFuIGNsYXNzPSJtLTY1MzQ0MzU1 NzM2Mzk2NzM3ODZhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMw MDIwNjAiPko8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPi4pPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhhbmtz IGFnYWluLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0g TWlrZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Im1fLTY1MzQ0MzU1 NzM2Mzk2NzM3ODZfX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2 MCI+Jm5ic3A7PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOm1fLTY1MzQ0MzU1 NzM2Mzk2NzM3ODZfX01haWxFbmRDb21wb3NlIj48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9Im0tNjUzNDQzNTU3MzYzOTY3Mzc4NmFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+UGhpbA0KIEh1bnQgWzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3Jh Y2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1haWx0 bzpwaGlsLmh1bnRAb3JhY2xlLmNvbTwvc3Bhbj48L2E+XTxzcGFuIGNsYXNzPSJtLTY1MzQ0MzU1 NzM2Mzk2NzM3ODZhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8Yj5T ZW50OjwvYj48c3BhbiBjbGFzcz0ibS02NTM0NDM1NTczNjM5NjczNzg2YXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+VHVlc2RheSwgQXVndXN0IDksIDIwMTYgMTI6MDcgUE08YnI+ DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9Im0tNjUzNDQzNTU3MzYzOTY3Mzc4NmFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPk1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpN aWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0i Y29sb3I6cHVycGxlIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L3NwYW4+PC9hPiZndDs8 YnI+DQo8Yj5DYzo8L2I+PHNwYW4gY2xhc3M9Im0tNjUzNDQzNTU3MzYzOTY3Mzc4NmFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzppZC1ldmVudEBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmlkLWV2ZW50 QGlldGYub3JnPC9zcGFuPjwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz0ibS02 NTM0NDM1NTczNjM5NjczNzg2YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UmU6 IFtJZC1ldmVudF0gU3VtbWFyaXppbmcgcmVjZW50IGRpc2N1c3Npb25zIG9uIElELUV2ZW50IHRv a2VuIGRyYWZ0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRpZG7igJl0 IGNvdmVyIHRoaXMgYXMgSSBkaWRu4oCZdCB3YW50IHRvIGNvbmZ1c2UgcGVvcGxlIHdpdGggdG9v IG1hbnkgdGhpbmdzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QnV0IEkgdGhpbmsgd2UgYWdyZWUg b24gYWxsIG9mIHRoZSBiZWxvdy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SeKAmW0g bm90IHN1cmUgdGhhdCB3ZSBuZWVkIGEg4oCcbmFtZeKAnS4gV2hhdCBpcyB5b3VyIGludGVudGlv biB0aGVyZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QaGlsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkBpbmRlcGVuZGVudGlkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 YSBocmVmPSJodHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tLyIgdGFyZ2V0PSJfYmxhbmsiPjxz cGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnd3dy5pbmRlcGVuZGVudGlkLmNvbTwvc3Bhbj48L2E+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxz cGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9zcGFuPjwvYT48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBBdWcgOSwgMjAxNiwgYXQgMTE6NTQgQU0s IE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5j b20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5NaWNoYWVsLkpv bmVzQG1pY3Jvc29mdC5jb208L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+VGhhbmtzIGZvciB3cml0aW5nIHRo aXMsIFBoaWwuJm5ic3A7IFVuZm9ydHVuYXRlbHksIHRoZSBzdW1tYXJ5IGJlbG93IGRvZXMgbm90 IGluY2x1ZGUgbXkgZmVlZGJhY2ssIHdoaWNoIGF0IHRoZSBlc3NlbmNlLCBpcyB0byBrZWVwIHRo ZSBJRCBFdmVudHMgZGF0YSBzdHJ1Y3R1cmUgYXMNCiBzaW1wbGUgYW5kIGdlbmVyYWwtcHVycG9z ZSBhcyBwb3NzaWJsZS4gJm5ic3A7KEkgc3Ryb25nbHkgYmVsaWV2ZSB0aGF0IEpXVCBpcyB0aGUg c3VjY2VzcyBpdCBpcyBiZWNhdXNlIHdlIG1hZGUgSldUIGFzIHNpbXBsZSBhbmQgZ2VuZXJhbC1w dXJwb3NlIGFzIHBvc3NpYmxlLCBhbmQgd2Ugc2hvdWxkIGZvbGxvdyB0aGlzIHN1Y2Nlc3NmdWwg ZXhhbXBsZSBhbmQgZG8gdGhlIHNhbWUgaGVyZS4pPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMDAyMDYwIj5JIGJlbGlldmUgdGhhdCB0aGUgSUQgRXZlbnRzIHNwZWMg bmVlZHMgdG8gaW5jbHVkZSB0aGVzZSB0aGluZ3MsIGFuZCB0aGVzZSB0aGluZ3Mgb25seTo8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6U3lt Ym9sO2NvbG9yOiMwMDIwNjAiPsK3PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7 Y29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4g Y2xhc3M9Im0tNjUzNDQzNTU3MzYzOTY3Mzc4NmFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+RGVmaW5lDQogb2Yg dGhlIOKAnGV2ZW50c+KAnSBjbGFpbTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6IzAwMjA2MCI+wrc8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0ibS02NTM0NDM1NTczNjM5NjczNzg2YXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMDAyMDYwIj5EZWZpbmUNCiB0aGF0IGFuIGV2ZW50IG5hbWUgY2FuIGJlIHVzZWQgYXMg YSB0b3AtbGV2ZWwgY2xhaW08L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOiMwMDIwNjAiPsK3PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9Im0tNjUzNDQzNTU3MzYzOTY3Mzc4NmFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzAwMjA2MCI+UmVxdWlyZQ0KIHRoYXQg4oCcaXNz4oCdIGJlIGluY2x1ZGVkIGFuZCB0aGF0IHRo ZSBKV1QgYmUgc2lnbmVkIGJ5IHRoZSBpc3N1ZXI8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOiMwMDIwNjAiPsK3PC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9Im0tNjUzNDQzNTU3MzYzOTY3 Mzc4NmFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzAwMjA2MCI+SW5jbHVkZQ0KIGEgc3RhdGVtZW50IGFsb25nIHRoZSBsaW5l cyBvZiDigJxUaGUgY2xhaW1zIHRvIGJlIGluY2x1ZGVkIHdpdGggYW55IHBhcnRpY3VsYXIgZXZl bnQgYXJlIHRvIGJlIGRlZmluZWQgYnkgdGhlIGV2ZW504oCdPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5BbmQgSeKAmWQgc3RvcCB0aGVyZS48L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPkl0IHNob3VsZCBiZSBl bnRpcmVseSB1cCB0byBhcHBsaWNhdGlvbnMgdG8gc2F5IHdoYXQgY2xhaW1zIGFyZSBpbmNsdWRl ZCB3aXRoIGV2ZW50cyB0aGV5IGRlZmluZSBhbmQgd2hhdCB0aGVpciBmb3JtYXQgYW5kIG1lYW5p bmdzIGFyZS4mbmJzcDsgVGhlbiB0aGUgSUQgRXZlbnRzIHNwZWMNCiB3aWxsIGJlIGFzIGdlbmVy YWwtcHVycG9zZSBhcyBwb3NzaWJsZSwgd2l0aCBpdCBiZWluZyBuYXR1cmFsIGZvciBpdCB0byBi ZSB1c2VkIGluIGVzc2VudGlhbGx5IGFsbCBKU09OIEV2ZW50IGNvbnRleHRzLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+QXMgc29vbiBhcyB3ZSBzdGFy dCBwdXR0aW5nIHJlc3RyaWN0aW9ucyBvbiB0aGUgdXNlIG9mIHBhcnRpY3VsYXIgY2xhaW1zIGJ5 IGV2ZW50cywgd2XigJlyZSBtYWtpbmcgdGhlIElEIEV2ZW50cyBzcGVjIGxlc3MgZ2VuZXJhbC1w dXJwb3NlIGFuZCBsZXNzIG5hdHVyYWwgdG8gdXNlLiZuYnNwOw0KIEluIHBhcnRpY3VsYXIsIHRo ZSBvbmx5IHRoaW5nIHRoYXQgdGhlIHNwZWMgc2hvdWxkIHNheSBhYm91dCB0aGUg4oCcc3Vi4oCd IGNsYWltIGlzIHRoYXQg4oCcTGlrZSBhbGwgb3RoZXIgY2xhaW1zIG90aGVyIHRoYW4g4oCYZXZl bnRz4oCZIGFuZCDigJhpc3PigJksIHdoZXRoZXIgdGhlIOKAmHN1YuKAmSBjbGFpbSBpcyB0byBi ZSBpbmNsdWRlZCB3aXRoIGFuIGV2ZW50IGlzIGVudGlyZWx5IGV2ZW50LXNwZWNpZmljLiZuYnNw OyBUaGUgY2xhaW1zIHRvIGJlIGluY2x1ZGVkIHdpdGggYW55DQogcGFydGljdWxhciBldmVudCBh cmUgZXhwbGljaXRseSBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIHNwZWNpZmljYXRpb24u4oCd PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAy MDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9Im0tNjUzNDQzNTU3MzYzOTY3Mzc4NmFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+SWQtZXZlbnQNCiBbPGEgaHJlZj0ibWFpbHRvOmlkLWV2ZW50LWJvdW5jZXNA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5tYWls dG86aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+XTxzcGFuIGNsYXNzPSJtLTY1 MzQ0MzU1NzM2Mzk2NzM3ODZhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48Yj5P biBCZWhhbGYgT2Y8c3BhbiBjbGFzcz0ibS02NTM0NDM1NTczNjM5NjczNzg2YXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPlBoaWwNCiBIdW50PGJyPg0KPGI+U2VudDo8L2I+ PHNwYW4gY2xhc3M9Im0tNjUzNDQzNTU3MzYzOTY3Mzc4NmFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPlR1ZXNkYXksIEF1Z3VzdCA5LCAyMDE2IDEwOjE5IEFNPGJyPg0KPGI+VG86 PC9iPjxzcGFuIGNsYXNzPSJtLTY1MzQ0MzU1NzM2Mzk2NzM3ODZhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86aWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5pZC1ldmVudEBpZXRmLm9yZzwv c3Bhbj48L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9Im0tNjUzNDQzNTU3MzYz OTY3Mzc4NmFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPltJZC1ldmVudF0gU3Vt bWFyaXppbmcgcmVjZW50IGRpc2N1c3Npb25zIG9uIElELUV2ZW50IHRva2VuIGRyYWZ0PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aG91Z2h0 IEkgd291bGQgdXBkYXRlIHRoZSBsaXN0IG9uIHNvbWUgZGlzY3Vzc2lvbnMgdGhhdCBoYXZlIGJl ZW4gaGFwcGVuaW5nIG92ZXIgaW4gdGhlIE9wZW5JRCBDb25uZWN0IGFuZCBSSVNDIHdvcmtpbmcg Z3JvdXBzIGNvbmZlcmVuY2UgY2FsbHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVzZSBkaXNjdXNzaW9ucyBoYXZlIGJlZW4gYWJvdXQgdGhl IGNvcmUgc3BlYyBhbmQgdGhlIHJvbGUgb2Yg4oCcdG9wLWxldmVs4oCdIGF0dHJpYnV0ZXMgdnMu IGV2ZW50IOKAnGV4dGVuc2lvbuKAnSBhdHRyaWJ1dGVzLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2VlOjxzcGFuIGNsYXNzPSJt LTY1MzQ0MzU1NzM2Mzk2NzM3ODZhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaHVudC1pZGV2ZW50LXRv a2VuLTAxIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWh1bnQtaWRldmVudC10b2tlbi0wMTwvc3Bhbj48 L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkluIHBhcnRpY3VsYXIgc2hvdWxkIOKAnHN1YuKAnSBiZSB1c2VkIGluIHRoZSB0b3Ag bGV2ZWwgdG8g4oCccG9pbnTigJ0gdG8gdGhlIHN1YmplY3QgKGluIHRoZSBicm9hZGVyIGVuZ2xp c2ggc2Vuc2UpIG9mIHRoZSBldmVudCwgb3Igc2hvdWxkIGl0IGJlIGNvbnN0cmFpbmVkIHRvIHRo ZSBTQU1ML0lEIFRva2VuIGRlZmluaXRpb24gd2hpY2ggaXMgdGhlIGF1dGhlbnRpY2F0ZWQgdXNl ci4gJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRha2VuIGluIHRoZSBuYXJyb3dlciBkZWZpbml0aW9uLCBpdCBpcyBpbXBv cnRhbnQgdG8gb2JzZXJ2ZSB0aGF0IGluIGFuIElEIFRva2VuLCDigJxzdWLigJ0gYW5kIOKAnGlz c+KAnSBnbyB0b2dldGhlci4mbmJzcDsgVGhlIGlzc3VlciBwcm92aWRlcyB0aGUgY29udGV4dCBm b3IgdGhlIGF1dGhlbnRpY2F0ZWQgc3ViamVjdCBpZGVudGlmaWVyLiBUaGUgcHJvYmxlbSB3aXRo IGV2ZW50cywgaXMgdGhhdCBpdCBtaWdodCBub3QgYmUgdGhlDQogQVMgKG9yIE9QKSB3aGljaCBp cyBpc3N1aW5nIHRoZSBldmVudC4gJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRvIHN1bW1hcml6ZSBhIGZhaXIgYW1vdW50 IG9mIGRpc2N1c3Npb24sIHRoZSBmZWVsaW5nIHNlZW1zIHRvIGJlIHRoZSBmb2xsb3dpbmc6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiogJm5ic3A7VGhlIEV2ZW50IFRva2VuIHRvcCBsZXZlbCBhdHRyaWJ1dGVzIHNob3VsZCBiZSBm YWlybHkgbGltaXRlZCBhbmQgbm90IGluY2x1ZGUgdGhlIHN1YiBhdHRyaWJ1dGUuICZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KiAm bmJzcDtGb3IgZXZlbnRzIHRoYXQgYXJlIGFib3V0IGEgdXNlciwgdGhlIHJlbGV2YW50IGV2ZW50 IHNwZWNpZmljYXRpb24gbWF5IGluY2x1ZGUgYSDigJxzdWLigJ0gYXR0cmlidXRlIHdpdGhpbiB0 aGUgZXZlbnTigJlzIHN1Yi1vYmplY3QgYW5kIG5vdCBpbiB0aGUgdG9wLWxldmVsLiBGdXJ0aGVy IHRoYXQgc3ViLW9iamVjdCBjYW4gYWxzbyBpbmNsdWRlIHRoZSBpc3N1ZXIgb2YgdGhlIHVzZXIu ICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+KiBUaGUgdG9wLWxldmVsIOKAnGlzc+KAnSBzaGFsbCBtZWFuIHRoZSBpc3N1ZXIgb2Yg dGhlIGV2ZW50IHdoZXJlIHRoZSBzdGF0ZSBjaGFuZ2Ugb2NjdXJyZWQuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4qICZuYnNwO+KAnHN1YuKA nSBzaG91bGQgbm90IGJlIHByZXNlbnQgaW4gdGhlIHRvcCBsZXZlbCBzdHJ1Y3R1cmUuJm5ic3A7 IEFsc28sIOKAnGV2ZW50c+KAnSBtdXN0IGFsc28gYmUgcHJlc2VudC48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGVyZSB3b3VsZCBi ZSBhIG5ldyBleGFtcGxlIGxvZ291dDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHByZT57PG86cD48L286cD48L3ByZT4NCjxw cmU+Jm5ic3A7ICZsdDvigJQgdG9wIGxldmVsIGlzIGFib3V0IHRoZSBldmVudCBpdHNlbGYgLSZn dDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsgPHNwYW4gc3R5bGU9ImNvbG9yOiM1RTMw RUIiPiZxdW90O2lzcyZxdW90OzogJnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBs ZS5jb20vIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6 Ly9zZXJ2ZXIuZXhhbXBsZS5jb208L3NwYW4+PC9hPiZxdW90Oyw8L3NwYW4+PG86cD48L286cD48 L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOiM1RTMwRUIiPiZuYnNwOyAmcXVvdDthdWQm cXVvdDs6ICZxdW90O3M2QmhkUmtxdDMmcXVvdDssPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjojNUUzMEVCIj4mbmJzcDsgJnF1b3Q7anRpJnF1b3Q7OiAm cXVvdDszZDBjM2NmNzk3NTg0YmQxOTNiZDBmYjFiZDRlN2QzMCZxdW90Oyw8L3NwYW4+PG86cD48 L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOiM1RTMwRUIiPiZuYnNwOyAmcXVv dDtpYXQmcXVvdDs6IDE0NTg2NjgxODAsPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxz cGFuIHN0eWxlPSJjb2xvcjojNUUzMEVCIj4mbmJzcDsgJnF1b3Q7ZXhwJnF1b3Q7OiAxNDU4NjY4 NTgwLDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6IzVF MzBFQiI+Jm5ic3A7ICZxdW90O2V2ZW50cyZxdW90OzogWzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6IzVFMzBFQiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZx dW90OzxhIGhyZWY9Imh0dHBzOi8vc3BlY3Mub3BlbmlkLm5ldC9sb2dvdXQiIHRhcmdldD0iX2Js YW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3NwZWNzLm9wZW5pZC5uZXQv bG9nb3V0PC9zcGFuPjwvYT4mcXVvdDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNw YW4gc3R5bGU9ImNvbG9yOiM1RTMwRUIiPiZuYnNwOyBdLDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT4gPHNwYW4gc3R5bGU9ImNvbG9yOiNFNjNCN0EiPiZuYnNwOyZxdW90OzxhIGhyZWY9 Imh0dHBzOi8vc3BlY3Mub3BlbmlkLm5ldC9sb2dvdXQiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBz dHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3NwZWNzLm9wZW5pZC5uZXQvbG9nb3V0PC9zcGFu PjwvYT4mcXVvdDs6IHs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9 ImNvbG9yOiNFNjNCN0EiPiZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7LSBUaGlzIGxldmVsIGlzIGRl ZmluZWQgZW50aXJlbHkgYnkgdGhlIGV2ZW50IFVSSS0mZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjojRTYzQjdBIj4mbmJzcDsmbmJzcDsmbmJzcDsg JnF1b3Q7aXNzJnF1b3Q7OiAmcXVvdDs8YSBocmVmPSJodHRwczovL29pZGMuZXhhbXBsZS5jb20v IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly9vaWRj LmV4YW1wbGUuY29tPC9zcGFuPjwvYT4mcXVvdDssPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjojRTYzQjdBIj4mbmJzcDsmbmJzcDsmbmJzcDsg4oCcanRp JnF1b3Q7OiAmcXVvdDswOGE1MDE5Yy0xN2UxLTQ5NzctOGY0Mi02NWExMjg0M2VhMDLigJ0sPC9z cGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2NvbG9yOiNFNjNCN0EiPiZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtzdWImcXVvdDs6ICZxdW90 OzI0ODI4OTc2MTAwMeKAnSw8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6I0U2M0I3QSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IOKA nGV4cOKAnTogJmx0O0lEIHRva2VuIGV4cGlyeSZndDs8L3NwYW4+PG86cD48L286cD48L3ByZT4N CjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6I0U2M0I3QSI+Jm5ic3A7 IH08L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQiPn08L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiB0aGUgYWJvdmUgZXhhbXBs ZSBub3RlIHRoYXQgdGhlIOKAnGV2ZW504oCdIG9iamVjdCBjYW4gaGF2ZSBpdHMgb3duIGlzcyBh bmQgc3ViamVjdCAoc3ViIG9yIGp0aSkgdGhhdCBoYXZlIG1lYW5pbmcgd2l0aGluIHRoZSBjb250 ZXh0IG9mIGFuIE9wZW5JRCBPUCBwcm92aWRlci4mbmJzcDsgVGhlIGlzc3VlciBvZiB0aGUgZXZl bnQgY2FuIGJlIGRpZmZlcmVudCAodGhlIHRvcC1sZXZlbCkgYW5kIHJlcHJlc2VudHMgdGhlDQog ZW50aXR5IHRoYXQgc2lnbnMgdGhlIGV2ZW50IChpZiBpdCBpcyBzaWduZWQpLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgdG9w LWxldmVsIGF0dHJpYnV0ZXMgaWRlbnRpZnkgYW4gaW5kaXZpZHVhbCBldmVudCBhbmQgYXJlIHVz ZWQgdG8gdmFsaWRhdGUgdGhlIGV2ZW50IChzaWduaW5nIGV0YykuJm5ic3A7IFdoZXJlIGFzIHRo ZSBuZXN0ZWQgb2JqZWN0IGNvbnRhaW5zIGFsbCBvZiB0aGUgZGF0YSBhYm91dCB0aGUgZXZlbnQg YW5kIGlzIGRlZmluZWQgYnkgdGhlIHByb2ZpbGluZyBzcGVjaWZpY2F0aW9uIChlLmcuIGEgcG9z c2libGUNCiBPcGVuSUQgTG9nb3V0IEV2ZW50IHNwZWMpLiZuYnNwOyBJbiB0aGlzIGNhc2UsIGlu IE9wZW5JRCwgbG9nZ2luZyBvdXQgdXN1YWxseSB0cmFuc2xhdGVzIGludG8gcmV2b2tpbmcgYW4g SUQgVG9rZW4uIFRodXMgdGhlIOKAnGp0aeKAnSBmb3IgdGhlIElEIHRva2VuICgwOGE1MDE5Yy4u Ljg0M2VhMDIpIGlzIGluY2x1ZGVkIGluIHRoZSBMb2dvdXQgb2JqZWN0LjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TaWRlIG5vdGUu Jm5ic3A7IFJlZ2FyZGluZyDigJxsb2dvdXTigJ0sIGl0IG1pZ2h0IGJlIHVzZWZ1bCB0byBpbmNs dWRlIHRoZSBleHBpcnkgb2YgdGhlIElEIFRva2VuIGluIGNhc2UgdGhlIHN1YnNjcmliZXIgaGFz IG5vdCB5ZXQgcmVjZWl2ZWQgYW4gSUQgVG9rZW4uIFRoaXMgd291bGQgbGV0IHRoZSBzdWJzY3Jp YmVyIGtub3cgaG93IGxvbmcgaXQgbmVlZHMgdG8ga2VlcCB0aGUgcmV2b2NhdGlvbiBpbmZvcm1h dGlvbiBmb3IuJm5ic3A7DQogSU9X4oCmYWZ0ZXIgdGhlIHRoZSBJRCBUb2tlbiBpcyBleHBpcmVk LCB0aGUgc3Vic2NyaWJlciB3b3VsZCBubyBsb25nZXIgbmVlZCB0byB0cmFjayB0aGUgcmV2b2Nh dGlvbiBzdGF0ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SXQgaXMgYWxzbyBnb29kIHRvIG9ic2VydmUgdGhhdCB0aGUg4oCcYXVk 4oCdIGF0IHRoZSB0b3AgbGV2ZWwgZGVzY3JpYmVzIHRoZSBzdWJzY3JpYmVyIG9mIHRoZSBldmVu dC4mbmJzcDsgVGhpcyBtYXkgYWxzbyBiZSBkaWZmZXJlbnQgdGhlbiB0aGUgb3JpZ2luYWwgYXVk aWVuY2Ugb2YgdGhlIElEIFRva2VuLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbyB0byBjb25jbHVkZS4gQnkgbWFraW5nIHRvcC1s ZXZlbCBhdHRyaWJ1dGVzIHN0cmljdGx5IGFib3V0IHRoZSBldmVudHMgb3duIHZhbGlkYXRpb24s IGFuZCBuZXN0ZWQgb2JqZWN0cyBhYm91dCB0aGUgZXZlbnQsIHdlIGF2b2lkIGNvbGxpc2lvbnMg aW4gZGVmaW5pdGlvbnMgc3VjaCBhcyB0aGUgaXNzdWVyIG9mIHRoZSBldmVudCwgdnMuIHRoZSBv cmlnaW5hbCBpc3N1ZXIgb2YgYSBzZWN1cml0eSBhc3NlcnRpb24uPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaG9wZSBJ4oCZdmUg Z290dGVuIGV2ZXJ5b25l4oCZcyBmZWVkYmFjayBjb3JyZWN0IGhlcmUuIExldHMgY29udGludWUg dG8gZGlzY3Vzcy4gSSB3aWxsIHJldmlzZSB0aGUgZHJhZnQgdG8gZm9sbG93IHRoZSBncm91cHMg dGhpbmtpbmcgaGVyZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlBoaWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+QGluZGVwZW5kZW50aWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHA6Ly93d3cuaW5kZXBl bmRlbnRpZC5jb20vIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ d3d3LmluZGVwZW5kZW50aWQuY29tPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0i bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9 ImNvbG9yOnB1cnBsZSI+cGhpbC5odW50QG9yYWNsZS5jb208L3NwYW4+PC9hPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KSWQtZXZl bnQgbWFpbGluZyBsaXN0PGJyPg0KPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6cHVycGxlIj5JZC1l dmVudEBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KPC9zcGFuPjxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQiIHRh cmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOnB1cnBsZSI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudDwvc3Bhbj48L2E+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQpJZC1ldmVudCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVm PSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPklk LWV2ZW50QGlldGYub3JnPC9zcGFuPjwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5 bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9p ZC1ldmVudDwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJZC1ldmVudCBtYWlsaW5nIGxpc3Q8YnI+ DQo8YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpw dXJwbGUiPklkLWV2ZW50QGlldGYub3JnPC9zcGFuPjwvYT48YnI+DQo8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50Ij48c3BhbiBzdHlsZT0iY29s b3I6cHVycGxlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50 PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KSWQtZXZlbnQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFp bHRvOklkLWV2ZW50QGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5JZC1ldmVu dEBpZXRmLm9yZzwvc3Bhbj48L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9pZC1ldmVudCI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudDwvc3Bhbj48L2E+PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KSWQtZXZlbnQg bWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYub3JnIj5JZC1l dmVudEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2lkLWV2ZW50Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2lkLWV2ZW50PC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_SN1PR0301MB164534BDE4F6485B1CAC4FACF51E0SN1PR0301MB1645_-- From nobody Thu Aug 11 11:10:05 2016 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 8345B12D7A5 for ; Thu, 11 Aug 2016 11:10:03 -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=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=engageidentity-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 Kubu4ECVTuPF for ; Thu, 11 Aug 2016 11:09:59 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::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 2CB3912D855 for ; Thu, 11 Aug 2016 11:09:58 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id o80so7390576wme.1 for ; Thu, 11 Aug 2016 11:09:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=engageidentity-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5OWUTFScFJCFO4apqvx+zPKxWgROVVDaOrUHMpkubzU=; b=Ixr9rS4APYv/jZ5hHKYeJGTLjkBLUqFNoTJY+mhsllXwgJaMew+wbki0cyg8pkLdQX KxTls3zROfP2IqivoL8kNDXoQiaFalk7uw/ncMj9jwE09+KH0L0aYZ9B27R3zJK4whzy 3TPX0RHyvBRwYfxX66eOrV33InA50cxZigrjIcrucvbrNxhBIBNag2m7qXkrg4KyE2gT 6pAPH4gXWbJg463SUTq8kkKebWlwFvsq9jztSQF3ghvn4o+vvLk72bjGBCI3SRPbD/f9 vhsUEuKssGH21efyoFeIYNK2lPfPojpkPA/dBaY1AfwHOnsUpYWiitDn1KcRm03wdID5 MyYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5OWUTFScFJCFO4apqvx+zPKxWgROVVDaOrUHMpkubzU=; b=B2BiuJ4vImlOM4itH8bxmqeSYYFL2Faey2crAYGUvxQ6urb5dEoTuatvrQkSh9VAtt ikoNwqkkOO4daVnbJ1mcWO4stkejGC/VyIFkDDEeTW3QiLRqpF/FiHwH+GTfuyz00TyZ K4cQ11ywg/jboR8dAaSsU7M+5qYexyWXPW/2np7SO+b6/jcE3GKVFnWhXqVeOBfTmSad R9rCtRk0jsaJsCuzgFeb8YKgQJU7spFW3nBQJy2aQl+4i2wwcGSwOB9Hg3fH94jSYktx zKUnnMH2deBHJy0EwtIK7oEJcYTxoL7cL3QIk0XNxTwL1h8WJlhi7br/okav8zoyJDVC TUug== X-Gm-Message-State: AEkoouvl4RTxutnUKflQP2qIZclZbcJr8RCqfLgbhqNBKlO63YUHrH9M1R8gtMuCl5xfEB+PpxclzTbTUE7f4CKr X-Received: by 10.25.22.234 with SMTP id 103mr1858114lfw.100.1470938996353; Thu, 11 Aug 2016 11:09:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.3.241 with HTTP; Thu, 11 Aug 2016 11:09:54 -0700 (PDT) Received: by 10.114.3.241 with HTTP; Thu, 11 Aug 2016 11:09:54 -0700 (PDT) In-Reply-To: References: <14E2EF51-7123-4E91-87DD-56AEA08202C1@oracle.com> <3F0DD3E6-46CD-4AA5-8F06-F79140F5D4BE@oracle.com> <56E7DF06-EE77-4FD1-BF44-15A083AC5B5A@ve7jtb.com> <12274564-507F-492B-94E8-C65C6A84FDB7@oracle.com> From: Sarah Squire Date: Thu, 11 Aug 2016 11:09:54 -0700 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=001a114112be5d40150539cfac1d Archived-At: Cc: John Bradley , Phil Hunt , "openid-specs-ab@lists.openid.net Ab" , "id-event@ietf.org" , Marius Scurtescu Subject: Re: [Id-event] Summarizing recent discussions on ID-Event token draft X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 11 Aug 2016 18:10:03 -0000 --001a114112be5d40150539cfac1d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Are we including use cases where the RP is the event issuer? On Aug 11, 2016 11:02 AM, "Mike Jones" wrote: > You=E2=80=99re aware that forcing =E2=80=9Csub=E2=80=9D to be a URI is a = breaking change for most > implementations, right? This is hardly a way to encourage adoption! > > > > The thing you wrote below that makes me think that you=E2=80=99re thinkin= g about > the purpose of the ID Events spec differently than me is this: =E2=80=9Cs= o that > all event specs can use it=E2=80=9D. The purpose of the logout event **i= sn=E2=80=99t** > for all event specs to use it. It=E2=80=99s for the logout use case to u= se it. > There=E2=80=99s no expectation that events intended for one use case will= even be > comprehensible in other use cases because they won=E2=80=99t understand t= he > contents of the event. We shouldn=E2=80=99t drive any of the design by t= rying to > achieve that unachievable goal, since events will **always** contain > information that=E2=80=99s specific to their use case. > > > > You=E2=80=99re making complexity arguments, whereas you=E2=80=99re also p= roposing more > complex rules than I am (at least as I see it). Trying to restrict the u= se > of =E2=80=9Csub=E2=80=9D (or any other claims) is unneeded complexity. > > > > I understand that you see things differently. I hope you=E2=80=99ll none= theless > think about my argument that having fewer rules about claims usage in > events will make them simpler. I passionately care about keeping this > simple, which is why I=E2=80=99m investing my time in this discussion. I= f it=E2=80=99s > simple, it will likely get widely used. > > > > I=E2=80=99m going to sign out of the discussion for now because my wife i= s about > to get out of surgery. I hope you have a good day. > > > > -- Mike > > > > *From:* Phil Hunt [mailto:phil.hunt@oracle.com] > *Sent:* Thursday, August 11, 2016 12:49 PM > *To:* Mike Jones > *Cc:* John Bradley ; openid-specs-ab@lists.openid.net > Ab ; id-event@ietf.org; Marius > Scurtescu > *Subject:* Re: [Id-event] Summarizing recent discussions on ID-Event > token draft > > > > Mike, > > > > Speaking as editor the format you propose ONLY works if =E2=80=9Csub=E2= =80=9D becomes a > URI so that all event specs can use it. Otherwise, OIDC becomes a specia= l > case which really kills the point of this work. It also makes the > specification much much more complex. Maybe it is just me, but a complex > spec generally implies complex implementation too. > > > > If you want sub at the top level, that would mean that the OIDC spec > format would have to look like: > > { > > "iss": "https://event.example.com", > > "aud": "s6BhdRkqt3", > > "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", > > "sub": =E2=80=9Chttps://token.example.com/248289761001", > > "iat": 1458668180, > > "exp": 1458668580, > > "events": [ > > "https://specs.openid.net/logout" > > ], > > "sid": "08a5019c-17e1-4977-8f42-65a12843ea02" > > } > > > > Given that events are signed (or should be), *I will object strongly > within the OIDF that the event issuer and the token issuer MUST be the sa= me > or that OIDF adopt a different format*. Yes having iss be the same is a > nice security convenience, but it imposes the architecture restriction th= at > it be the same server. At scale, delivery of events may become a problem > for large scale providers if they are also delivering tokens to relying > parties. The restriction isn=E2=80=99t really justified given the crypto > alternative =E2=80=94 which was the whole point of using JWT in the first= place. > > > > Per Justin=E2=80=99s comment, it seems elegant/trivial that a logout even= t simply > has logout at the top level and an ID Token attached (though it might > convey a lot of unneeded claims). IMO, the OIDC logout spec should only > convey the ID Token JTI. It is going to be rare that you log out all > devices for a user. To most users, it means clear SSO within this browse= r > only! One can argue that clearing all devices/sessions is a different > event entirely. It is an account reset or lock-out action. > > > > Phil > > > > @independentid > > www.independentid.com > > phil.hunt@oracle.com > > > > > > > > > > On Aug 11, 2016, at 9:32 AM, Mike Jones > wrote: > > > > See my previous message, John, which was a reply to Phil=E2=80=99s messag= e that > you also replied to, that contained a logout claims example. I=E2=80=99m= not > proposing to special-case the Connect Logout message in any way. The =E2= =80=9Ciss=E2=80=9D > is the event issuer. The other claims in the message are those defined b= y > the event to be included, just like those for any other event. Yes, the > logout message doesn=E2=80=99t include a second issuer, a second subject,= an ID > Token as a claim, or anything else complicated like that, because those > things aren=E2=80=99t needed for the logout use case. > > > > As I=E2=80=99d written previously, the ID Events spec should define the = =E2=80=9Cevents=E2=80=9D > claim, how to use an event name as a claim (when needed), and say that th= e > event JWT must be signed by the issuer, and stop there. Trying to > micro-manage claims usage within an event will only result in the ID Even= ts > spec being harder to use. If we=E2=80=99d tried to similarly micro-manag= e JWT > claims usage, JWT would likely not have been the success that it is. > > > > -- Mike > > > > *From:* John Bradley [mailto:ve7jtb@ve7jtb.com] > *Sent:* Thursday, August 11, 2016 12:22 PM > *To:* Phil Hunt (IDM) > *Cc:* Mike Jones ; id-event@ietf.org; Marius > Scurtescu ; openid-specs-ab@lists.openid.net Ab < > openid-specs-ab@lists.openid.net> > *Subject:* Re: [Id-event] Summarizing recent discussions on ID-Event > token draft > > > > Not surprisingly a multipurpose message format will not be as optimized a= s > a single purpose one. > > > > Connect itself doesn=E2=80=99t really have a conflict around issuer the s= ame > entity sending the logout message is always the one that created the > id_token that it refers to. > > > > Using the same format as id_token with the same semantics to identify the > thing to be terminated makes sense from a purely openID Connect point of > view. > > > > Oter messages that have different notions of subject and are issued by > different parties than the one that controls the subject cause issues whe= n > you try and fit them into the same format as an ID_Token, I grant you tha= t. > > > > It was mentioned that we need to differentiate between these events and > id_tokens. Mostly we need to do that in cases where the token might be > presented in the front channel. > > > > To do that se do have mandatory claims for nonce and c_hash or at_hash as > well as the addition of events parameter to reduce confusion. Now I adm= it > that some people may still get that wrong, and the removal of sub from t= he > top level would remove any concern. However Mike has a point that adopti= on > may be hurt if we change the semantics too much. > > > > I don=E2=80=99t see backchannel single logout being used by many social l= ogin RP, > it is a lot of work to maintain server side state. It is mostly an > enterprise and large site sort of feature. > > That may or may not impact on if it is better to be simple and aligned > with connect=E2=80=99s id token or more general purpose to fit with other > enterprise to SaaS features like SCIM events. > > > > I think the two directions lead to different formats. > > > > The compromise of special casing Connect SLO and bodging the formats > together is probably the worst option. > > > > John B. > > > > > > On Aug 11, 2016, at 11:59 AM, Phil Hunt (IDM) > wrote: > > > > How do you resolve conflicts on iss then? The top level has to be the > issuer of the event as the issuer signs. > > > > If one spec can use it all must be able to. I believe you previously > objected to that saying sub must be as how id tokens define them. But tha= t > isnt unique and requires iss. Now we would have sub at the top with an > event issuer at the top and a sub issuer in the extension. That seems > incredibly complex not to mention awkward. > > > > If we make sub a uri for all then it can work ass iss from id token would > not be needed. But i can see many objecting to the change in format. > > > > Why not have a logout be an event with an id token attached for example? > > > Phil > > > On Aug 11, 2016, at 8:03 AM, Mike Jones > wrote: > > The simple rule is that if the particular event calls for the =E2=80=9Csu= b=E2=80=9D claim > to be at the top level, then it is. This is no different from any other > claim that an event might place at the top level. > > > > The complexity arises if =E2=80=9Csub=E2=80=9D is unnecessarily special-c= ased. We > shouldn=E2=80=99t do that, because it limits the applicability of the spe= cification. > > > > -- Mike > > > > *From:* Phil Hunt (IDM) [mailto:phil.hunt@oracle.com] > *Sent:* Thursday, August 11, 2016 9:40 AM > *To:* Mike Jones > *Cc:* Marius Scurtescu ; id-event@ietf.org > *Subject:* Re: [Id-event] Summarizing recent discussions on ID-Event > token draft > > > > I think using sub at the top level leads to complexity. Eg Can you provid= e > a rule for when top level is used or not by an individual spec? IMO. Top > level should always be used the same way by all implementers. > > > > Based on the calls at risc/connect, we discussed that it would be best to > move all event specifics to the event object area. This way different > events can have different event addressing (eg sub/iss, uri, jit/iss). Wh= en > iss is needed to uniquely qualify a sub, it can be provided without > conflicting with the issuer of the event. Similarly jti and iss can be us= ed > for a revoked token without conflicting with the event jti. > > > > I plan to post a new draft shortly that will give some examples based on > feedback from the openid risc/connect discussions. > > > > We can always change again. > > > Phil > > > On Aug 11, 2016, at 4:54 AM, Mike Jones > wrote: > > No, I=E2=80=99m not saying that =E2=80=9Csub=E2=80=9D cannot appear at th= e top level. I=E2=80=99m saying > that =E2=80=9Csub=E2=80=9D will only occur at the top level if the partic= ular event defines > that =E2=80=9Csub=E2=80=9D is used in that way for that event. > > > > There are probably use cases for multiple events per message but I doubt > there are use cases for multiple **unrelated** events per message. By > definition, related events that use top-level claims would need to use th= em > in a compatible way. I don=E2=80=99t see that as being a problem. > > > > That being said, the predominant use case is likely to be a single event > per JWT. > > > > -- > Mike > > > > *From:* Marius Scurtescu [mailto:mscurtescu@google.com] > *Sent:* Tuesday, August 9, 2016 7:15 PM > *To:* Phil Hunt > *Cc:* Mike Jones ; id-event@ietf.org > *Subject:* Re: [Id-event] Summarizing recent discussions on ID-Event > token draft > > > > Mike, are you suggesting that a sub claim can only show up at the event > level and not at the top level: > > > > In particular, the only thing that the spec should say about the =E2=80= =9Csub=E2=80=9D > claim is that =E2=80=9CLike all other claims other than =E2=80=98events= =E2=80=99 and =E2=80=98iss=E2=80=99, whether > the =E2=80=98sub=E2=80=99 claim is to be included with an event is entire= ly event-specific. > > > > A top level sub and multiple events are incompatible IMO. > > > > Do we have a compelling reason to support multiple events per message? > > > > > Marius > > > > On Tue, Aug 9, 2016 at 12:39 PM, Phil Hunt wrote: > > I was referring to this in your email > > "Define that an event name can be used as a top-level claim=E2=80=9D > > > > > > Is this different from the event uri? > > > > Phil > > > > @independentid > > www.independentid.com > > phil.hunt@oracle.com > > > > > > > > > > On Aug 9, 2016, at 12:12 PM, Mike Jones > wrote: > > > > I=E2=80=99m glad to hear that we agree on keeping it as simple and genera= l-purpose > as possible and that you agree with my write-up. I think we then have a > good path forward. > > > > I=E2=80=99m not sure what you mean by =E2=80=9CI=E2=80=99m not sure that = we need a =E2=80=9Cname=E2=80=9D. What > is your intention there.=E2=80=9D The only place I used the word =E2=80= =9Cname=E2=80=9D was in > my statement =E2=80=9CDefine that an event name can be used as a top-leve= l claim=E2=80=9D. > What I was trying to get at is was that if =E2=80=9Chttp://specs.openid.n= et/logout=E2=80=9D > is used as an event name, that it can also be used as a claim name in the > JWT containing information about the event. (Maybe I=E2=80=99m not using= the > correct terminology, hence the unintended confusion J.) > > > > Thanks again, > > -- Mike > > > > *From:* Phil Hunt [mailto:phil.hunt@oracle.com] > *Sent:* Tuesday, August 9, 2016 12:07 PM > *To:* Mike Jones > *Cc:* id-event@ietf.org > *Subject:* Re: [Id-event] Summarizing recent discussions on ID-Event > token draft > > > > I didn=E2=80=99t cover this as I didn=E2=80=99t want to confuse people wi= th too many > things. > > > > But I think we agree on all of the below. > > > > I=E2=80=99m not sure that we need a =E2=80=9Cname=E2=80=9D. What is your = intention there. > > > > Phil > > > > @independentid > > www.independentid.com > > phil.hunt@oracle.com > > > > > > > > > > On Aug 9, 2016, at 11:54 AM, Mike Jones > wrote: > > > > Thanks for writing this, Phil. Unfortunately, the summary below does not > include my feedback, which at the essence, is to keep the ID Events data > structure as simple and general-purpose as possible. (I strongly believe > that JWT is the success it is because we made JWT as simple and > general-purpose as possible, and we should follow this successful example > and do the same here.) > > > > I believe that the ID Events spec needs to include these things, and thes= e > things only: > > =C2=B7 Define of the =E2=80=9Cevents=E2=80=9D claim > > =C2=B7 Define that an event name can be used as a top-level claim > > =C2=B7 Require that =E2=80=9Ciss=E2=80=9D be included and that the = JWT be signed by the > issuer > > =C2=B7 Include a statement along the lines of =E2=80=9CThe claims t= o be included > with any particular event are to be defined by the event=E2=80=9D > > > > And I=E2=80=99d stop there. > > > > It should be entirely up to applications to say what claims are included > with events they define and what their format and meanings are. Then the > ID Events spec will be as general-purpose as possible, with it being > natural for it to be used in essentially all JSON Event contexts. > > > > As soon as we start putting restrictions on the use of particular claims > by events, we=E2=80=99re making the ID Events spec less general-purpose a= nd less > natural to use. In particular, the only thing that the spec should say > about the =E2=80=9Csub=E2=80=9D claim is that =E2=80=9CLike all other cla= ims other than =E2=80=98events=E2=80=99 > and =E2=80=98iss=E2=80=99, whether the =E2=80=98sub=E2=80=99 claim is to = be included with an event is > entirely event-specific. The claims to be included with any particular > event are explicitly outside the scope of this specification.=E2=80=9D > > > > -- Mike > > > > *From:* Id-event [mailto:id-event-bounces@ietf.org] *On Behalf Of *Phil > Hunt > *Sent:* Tuesday, August 9, 2016 10:19 AM > *To:* id-event@ietf.org > *Subject:* [Id-event] Summarizing recent discussions on ID-Event token > draft > > > > I thought I would update the list on some discussions that have been > happening over in the OpenID Connect and RISC working groups conference > calls. > > > > These discussions have been about the core spec and the role of > =E2=80=9Ctop-level=E2=80=9D attributes vs. event =E2=80=9Cextension=E2=80= =9D attributes. > > See: https://tools.ietf.org/html/draft-hunt-idevent-token-01 > > > > In particular should =E2=80=9Csub=E2=80=9D be used in the top level to = =E2=80=9Cpoint=E2=80=9D to the > subject (in the broader english sense) of the event, or should it be > constrained to the SAML/ID Token definition which is the authenticated > user. > > > > Taken in the narrower definition, it is important to observe that in an I= D > Token, =E2=80=9Csub=E2=80=9D and =E2=80=9Ciss=E2=80=9D go together. The = issuer provides the context for > the authenticated subject identifier. The problem with events, is that it > might not be the AS (or OP) which is issuing the event. > > > > To summarize a fair amount of discussion, the feeling seems to be the > following: > > > > * The Event Token top level attributes should be fairly limited and not > include the sub attribute. > > * For events that are about a user, the relevant event specification may > include a =E2=80=9Csub=E2=80=9D attribute within the event=E2=80=99s sub-= object and not in the > top-level. Further that sub-object can also include the issuer of the use= r. > > > * The top-level =E2=80=9Ciss=E2=80=9D shall mean the issuer of the event = where the state > change occurred. > > * =E2=80=9Csub=E2=80=9D should not be present in the top level structure= . Also, =E2=80=9Cevents=E2=80=9D > must also be present. > > > > Here would be a new example logout: > > { > > <=E2=80=94 top level is about the event itself -> > > "iss": "https://server.example.com", > > "aud": "s6BhdRkqt3", > > "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", > > "iat": 1458668180, > > "exp": 1458668580, > > "events": [ > > "https://specs.openid.net/logout" > > ], > > "https://specs.openid.net/logout": { > > <- This level is defined entirely by the event URI-> > > "iss": "https://oidc.example.com", > > =E2=80=9Cjti": "08a5019c-17e1-4977-8f42-65a12843ea02=E2=80=9D, > > "sub": "248289761001=E2=80=9D, > > =E2=80=9Cexp=E2=80=9D: > > } > > } > > > > In the above example note that the =E2=80=9Cevent=E2=80=9D object can hav= e its own iss and > subject (sub or jti) that have meaning within the context of an OpenID OP > provider. The issuer of the event can be different (the top-level) and > represents the entity that signs the event (if it is signed). > > > > The top-level attributes identify an individual event and are used to > validate the event (signing etc). Where as the nested object contains al= l > of the data about the event and is defined by the profiling specification > (e.g. a possible OpenID Logout Event spec). In this case, in OpenID, > logging out usually translates into revoking an ID Token. Thus the =E2=80= =9Cjti=E2=80=9D > for the ID token (08a5019c...843ea02) is included in the Logout object. > > > > Side note. Regarding =E2=80=9Clogout=E2=80=9D, it might be useful to inc= lude the expiry > of the ID Token in case the subscriber has not yet received an ID Token. > This would let the subscriber know how long it needs to keep the revocati= on > information for. IOW=E2=80=A6after the the ID Token is expired, the subs= criber > would no longer need to track the revocation state. > > > > It is also good to observe that the =E2=80=9Caud=E2=80=9D at the top leve= l describes the > subscriber of the event. This may also be different then the original > audience of the ID Token. > > > > So to conclude. By making top-level attributes strictly about the events > own validation, and nested objects about the event, we avoid collisions i= n > definitions such as the issuer of the event, vs. the original issuer of a > security assertion. > > > > I hope I=E2=80=99ve gotten everyone=E2=80=99s feedback correct here. Lets= continue to > discuss. I will revise the draft to follow the groups thinking here. > > > > Phil > > > > @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 > > > > _______________________________________________ > 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 > > --001a114112be5d40150539cfac1d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Are we including use cases where the RP is the event issuer?=


On Aug 11, 2016 1= 1:02 AM, "Mike Jones" <Michael.Jones@microsoft.com> wrote:
=

You=E2=80=99re aware that forcing =E2= =80=9Csub=E2=80=9D to be a URI is a breaking change for most implementation= s, right?=C2=A0 This is hardly a way to encourage adoption!

=C2=A0

The thing you wrote below that makes = me think that you=E2=80=99re thinking about the purpose of the ID Events sp= ec differently than me is this: =E2=80=9Cso that all event specs can use it=E2=80=9D.=C2=A0 The purpose of the logout = event *isn=E2=80=99t* for all event specs to use it.=C2=A0 It=E2=80= =99s for the logout use case to use it.=C2=A0 There=E2=80=99s no expectatio= n that events intended for one use case will even be comprehensible in other use cases because th= ey won=E2=80=99t understand the contents of the event.=C2=A0 We shouldn=E2= =80=99t drive any of the design by trying to achieve that unachievable goal= , since events will *always* contain information that=E2=80=99s specific to their use case.

=C2=A0

You=E2=80=99re making complexity argu= ments, whereas you=E2=80=99re also proposing more complex rules than I am (= at least as I see it).=C2=A0 Trying to restrict the use of =E2=80=9Csub=E2= =80=9D (or any other claims) is unneeded complexity.

=C2=A0

I understand that you see things diff= erently.=C2=A0 I hope you=E2=80=99ll nonetheless think about my argument th= at having fewer rules about claims usage in events will make them simpler.=C2=A0 I passionately care about keeping this simple, which i= s why I=E2=80=99m investing my time in this discussion.=C2=A0 If it=E2=80= =99s simple, it will likely get widely used.

=C2=A0

I=E2=80=99m going to sign out of the = discussion for now because my wife is about to get out of surgery.=C2=A0 I = hope you have a good day.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mi= ke

<= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif;c= olor:#002060">=C2=A0

From: Phil Hunt [mailto:phil.hunt@oracle.com]
Sent: Thursday, August 11, 2016 12:49 PM
To: Mike Jones <Mi= chael.Jones@microsoft.com>
Cc: John Bradley <ve7jtb@ve7= jtb.com>; openid-specs-ab@lists.openid.net Ab <openid-specs-= ab@lists.openid.net>; id-event= @ietf.org; Marius Scurtescu <mscurtescu@google.com>
Subject: Re: [Id-event] Summarizing recent discussions on ID-Event t= oken draft

=C2=A0

Mike,=C2=A0

=C2=A0

Speaking as editor the format you propose ONLY works= if =E2=80=9Csub=E2=80=9D becomes a URI so that all event specs can use it.= =C2=A0 Otherwise, OIDC becomes a special case which really kills the point = of this work. It also makes the specification much much more complex. Maybe it is just me, but a complex spec generally implies co= mplex implementation too.

=C2=A0

If you want sub at the top level, that would mean th= at the OIDC spec format would have to look like:

{

=C2=A0 "iss": "https://event.example.com",

=C2=A0 "aud": "s6BhdRkqt3",

=C2=A0 "jti": "3d0c3cf797584bd19= 3bd0fb1bd4e7d30",

=C2=A0 "sub"= : =E2=80=9Chttps://token.example.com/248289761001",=

=C2=A0 "iat": 1458668180,

=C2=A0 "exp": 1458668580,

=C2=A0 "events": [

=C2=A0 ],

=C2=A0 "sid": "08a5019c-17e1-4977-8f4= 2-65a12843ea02"

}

=C2=A0

Given that events are signed (or should be), I wi= ll object strongly within the OIDF that the event issuer and the token issu= er MUST be the same or that OIDF adopt a different format. Yes having i= ss be the same is a nice security convenience, but it imposes the architecture restriction that it be the sa= me server.=C2=A0 At scale, delivery of events may become a problem for larg= e scale providers if they are also delivering tokens to relying parties. Th= e restriction isn=E2=80=99t really justified given the crypto alternative =E2=80=94 which was the whole point of using = JWT in the first place.

=C2=A0

Per Justin=E2=80=99s comment, it seems elegant/trivi= al that a logout event simply has logout at the top level and an ID Token a= ttached (though it might convey a lot of unneeded claims).=C2=A0 IMO, the O= IDC logout spec should only convey the ID Token JTI.=C2=A0 It is going to be rare that you log out all devices for a user.= =C2=A0 To most users, it means clear SSO within this browser only!=C2=A0 On= e can argue that clearing all devices/sessions is a different event entirel= y. It is an account reset or lock-out action.

=C2=A0

=C2=A0

=C2=A0

See my previous message, John, which = was a reply to Phil=E2=80=99s message that you also replied to, that contai= ned a logout claims example.=C2=A0 I=E2=80=99m not proposing to special-cas= e the Connect Logout message in any way.=C2=A0 The =E2=80=9Ciss=E2=80=9D is = the event issuer.=C2=A0 The other claims in the message are those defined b= y the event to be included, just like those for any other event.=C2=A0 Yes,= the logout message doesn=E2=80=99t include a second issuer, a second subje= ct, an ID Token as a claim, or anything else complicated like that, because th= ose things aren=E2=80=99t needed for the logout use case.<= /u>

=C2=A0

As I=E2=80=99d written previously, th= e ID Events spec should define the =E2=80=9Cevents=E2=80=9D claim, how to u= se an event name as a claim (when needed), and say that the event JWT must be signed by the issuer, and stop there.=C2=A0 Trying to micro-manage= claims usage within an event will only result in the ID Events spec being = harder to use.=C2=A0 If we=E2=80=99d tried to similarly micro-manage JWT cl= aims usage, JWT would likely not have been the success that it is.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mi= ke

=C2=A0

From:=C2=A0John Bradley [mailto:ve7jtb@ve7jtb.com]=C2=A0
Sent:=C2=A0Thursday, August 11, 2016 12:22 PM
To:=C2=A0Phil Hunt (IDM) <phil.hunt@oracle.com>
Cc:=C2=A0Mike Jones <Michael.Jones@microsoft.com<= /a>>; id-event@ietf.org; Marius Scurtescu <mscurtescu@google.com= >; openid-specs-ab@lists.openid.net Ab <openid-specs-ab@list= s.openid.net>
Subject:=C2=A0Re: [Id-event] Summarizing recent discuss= ions on ID-Event token draft

=C2=A0

Not surprisingly a multipurpose message format will = not be as optimized as a single purpose one.

=C2=A0

Connect itself doesn=E2=80=99t really have a conflic= t around issuer the same entity sending the logout message is always the on= e that created the id_token that it refers to.

=C2=A0

Using the same format as id_token with the same sema= ntics to identify the thing to be terminated makes sense from a purely open= ID Connect point of view.

=C2=A0

Oter messages that have different notions of subject= and are issued by different parties than the one that controls the subject= cause issues when you try and fit them into the same format as an ID_Token= , I grant you that.

=C2=A0

It was mentioned that we need to differentiate betwe= en these events and id_tokens.=C2=A0 Mostly we need to do that in cases whe= re the token might be presented in the front channel.

=C2=A0

To do that se do have mandatory claims for nonce and= c_hash or at_hash as well as the addition of events parameter to reduce co= nfusion. =C2=A0 Now I admit that some people may still get that wrong, =C2= =A0and the removal of sub from the top level would remove any concern.=C2=A0 However Mike has a point that adoption may= be hurt if we change the semantics too much.

=C2=A0

I don=E2=80=99t see backchannel single logout being = used by many social login RP, it is a lot of work to maintain server side s= tate. =C2=A0 It is mostly an enterprise and large site sort of feature.<= /u>

That may or may not impact on if it is better to be = simple and aligned with connect=E2=80=99s id token or more general purpose = to fit with other enterprise to SaaS features like SCIM events.

=C2=A0

I think the two directions lead to different formats= . =C2=A0=C2=A0

=C2=A0

The compromise of special casing Connect SLO and bod= ging the formats together is probably the worst option.

=C2=A0

John B.

=C2=A0

=C2=A0

On Aug 11, 2016, at 11:59 AM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:=

=C2=A0

How do you resolve conflicts on iss then?=C2=A0 Th= e top level has to be the issuer of the event as the issuer signs.=C2=A0

=C2=A0

If one spec can use it all must be able to. I beli= eve you previously objected to that saying sub must be as how id tokens def= ine them. But that isnt unique and requires iss. Now we would have sub at the top with an event issuer at the top and a sub= issuer in the extension. That seems incredibly complex not to mention awkw= ard.=C2=A0

=C2=A0

If we make sub a uri for all then it can work ass = iss from id token would not be needed. But i can see many objecting to the = change in format.=C2=A0

=C2=A0

Why not have a logout be an event with an id token= attached for example?


Phil


On Aug 11, 2016, at 8:03 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

The simple rule is that if the partic= ular event calls for the =E2=80=9Csub=E2=80=9D claim to be at the top level= , then it is.=C2=A0 This is no different from any other claim that an event might place at the top level.

=C2=A0

The complexity arises if =E2=80=9Csub= =E2=80=9D is unnecessarily special-cased.=C2=A0 We shouldn=E2=80=99t do tha= t, because it limits the applicability of the specification.<= 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 -- Mi= ke

=C2=A0

From:=C2=A0Phil Hunt (IDM) [mailto:phil.hunt@oracle.com]=C2=A0
Sent:=C2=A0Thursday, August 11, 2016 9:40 AM
To:=C2=A0Mike Jones <Michael.Jones@microsoft.com>
Cc:=C2=A0Marius Scurtescu <mscurtescu@google.com>;=C2=A0id-event@ietf.org
Subject:=C2=A0Re: [Id-event] Summarizing recent discuss= ions on ID-Event token draft

=C2=A0

I think using sub at the top level leads to complexi= ty. Eg Can you provide a rule for when top level is used or not by an indiv= idual spec?=C2=A0 IMO. Top level should always be used the same way by all = implementers.=C2=A0

=C2=A0

Based on the calls at risc/connect, we discussed tha= t it would be best to move all event specifics to the event object area. Th= is way different events can have different event addressing (eg sub/iss, ur= i, jit/iss). When iss is needed to uniquely qualify a sub, it can be provided without conflicting with the is= suer of the event. Similarly jti and iss can be used for a revoked token wi= thout conflicting with the event jti.=C2=A0

=C2=A0

I plan to post a new draft shortly that will give so= me examples based on feedback from the openid risc/connect discussions.<= /u>

=C2=A0

We can always change again.=C2=A0


Phil


On Aug 11, 2016, at 4:54 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

No, I=E2=80=99m not saying that =E2= =80=9Csub=E2=80=9D cannot appear at the top level.=C2=A0 I=E2=80=99m saying= that =E2=80=9Csub=E2=80=9D will only occur at the top level if the particu= lar event defines that =E2=80=9Csub=E2=80=9D is used in that way for that event.

=C2=A0

There are probably use cases for mult= iple events per message but I doubt there are use cases for multiple *un= related* events per message.=C2=A0 By definition, related events that use top-level claims would need to use them in a compa= tible way.=C2=A0 I don=E2=80=99t see that as being a problem.=

=C2=A0

That being said, the predominant use = case is likely to be a single event per JWT.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=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=A0Mari= us Scurtescu [mailto:mscurtescu@google.com]=C2=A0
Sent:=C2=A0Tuesday, August 9, 2016 7:15 PM
To:=C2=A0Phil Hunt <= phil.hunt@oracle.com>
Cc:=C2=A0Mike Jones <Michael.Jones@microsoft.com>;=C2=A0id-event@ietf.org
Subject:=C2=A0Re: [Id-event] Summarizing recent discuss= ions on ID-Event token draft

=C2=A0

Mike, are you suggesting that a sub claim can only s= how up at the event level and not at the top level:

=C2=A0

In particular, the only thing that the spec should s= ay about the =E2=80=9Csub=E2=80=9D claim is that =E2=80=9CLike all other cl= aims other than =E2=80=98events=E2=80=99 and =E2=80=98iss=E2=80=99, whether= the =E2=80=98sub=E2=80=99 claim is to be included with an event is entirel= y event-specific.

=C2=A0

A top level sub and multiple events are incompatible= IMO.

=C2=A0

Do we have a compelling reason to support multiple e= vents per message?

=C2=A0


Marius

=C2=A0

On Tue, Aug 9, 2016 at 12:39 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

I was referring to this in your email<= /p>

"Define that an event name can b= e used as a top-level claim=E2=80=9D

=C2=A0

=C2=A0

Is this different from the event uri?<= /p>

=C2=A0

=C2=A0

=C2=A0

=C2=A0<= /p>

=C2=A0

On Aug 9, 2016, at 12:12 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

=C2=A0

I=E2=80=99m glad to hear that we agre= e on keeping it as simple and general-purpose as possible and that you agre= e with my write-up.=C2=A0 I think we then have a good path forward.

=C2=A0

I=E2=80=99m not sure what you mean by= =E2=80=9CI=E2=80=99m not sure that we need a =E2=80=9Cname=E2=80=9D= . What is your intention there.=E2=80=9D=C2=A0 The only place I used the word =E2=80=9Cname=E2=80=9D was in my statement = =E2=80=9CDefine that an event name can be used as a top-level claim=E2=80= =9D.=C2=A0 What I was trying to get at is was that if =E2=80=9Chttp://specs.openid.net/logout=E2=80=9D is used as an event name, that it can also be used as a claim name in the = JWT containing information about the event.=C2=A0 (Maybe I=E2=80=99m not us= ing the correct terminology, hence the unintended confusion=C2=A0J.)

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Thank= s again,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mi= ke

=C2=A0<= u>

From:=C2=A0Phil Hunt [mailto:phil.hunt@oracle.com]=C2=A0
Sent:=C2=A0Tuesday, August 9, 2016 12:07 PM
To:=C2=A0Mike Jones <Michael.Jones@microsoft.com>
Cc:=C2=A0id-event@ietf.= org
Subject:=C2=A0Re: [Id-event] Summarizing recent discuss= ions on ID-Event token draft

=C2=A0

I didn=E2=80=99t cover this as I didn=E2=80=99t want= to confuse people with too many things.

=C2=A0

But I think we agree on all of the below.<= /u>

=C2=A0

I=E2=80=99m not sure that we need a =E2=80=9Cname=E2= =80=9D. What is your intention there.

=C2=A0

=C2=A0

=C2=A0

=C2=A0<= /p>

=C2=A0

On Aug 9, 2016, at 11:54 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

=C2=A0

Thanks for writing this, Phil.=C2=A0 = Unfortunately, the summary below does not include my feedback, which at the= essence, is to keep the ID Events data structure as simple and general-purpose as possible. =C2=A0(I strongly believe that JWT= is the success it is because we made JWT as simple and general-purpose as = possible, and we should follow this successful example and do the same here= .)

=C2=A0

I believe that the ID Events spec nee= ds to include these things, and these things only:

=C2=B7= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Define of the =E2=80=9Cevents=E2=80=9D claim

=C2=B7= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Define that an event name can be used as a top-level claim

=C2=B7= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Require that =E2=80=9Ciss=E2=80=9D be included and that the JWT be signed by the i= ssuer

=C2=B7= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Include a statement along the lines of =E2=80=9CThe claims to be included with any= particular event are to be defined by the event=E2=80=9D<= /u>

=C2=A0

And I=E2=80=99d stop there.=

=C2=A0

It should be entirely up to applicati= ons to say what claims are included with events they define and what their = format and meanings are.=C2=A0 Then the ID Events spec will be as general-purpose as possible, with it being natural for it to be= used in essentially all JSON Event contexts.

=C2=A0

As soon as we start putting restricti= ons on the use of particular claims by events, we=E2=80=99re making the ID = Events spec less general-purpose and less natural to use.=C2=A0 In particular, the only thing that the spec should say about the =E2=80=9C= sub=E2=80=9D claim is that =E2=80=9CLike all other claims other than =E2=80= =98events=E2=80=99 and =E2=80=98iss=E2=80=99, whether the =E2=80=98sub=E2= =80=99 claim is to be included with an event is entirely event-specific.=C2= =A0 The claims to be included with any particular event are explicitly outside the scope of this specification.= =E2=80=9D

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mi= ke

=C2=A0

From:=C2=A0Id-e= vent [mailto:id-event-bounces@ietf.org]=C2=A0On Behalf Of=C2=A0Phil Hunt
Sent:=C2=A0Tuesday, August 9, 2016 10:19 AM
To:=C2=A0id-event@ietf.= org
Subject:=C2=A0[Id-event] Summarizing recent discussions= on ID-Event token draft

=C2=A0

I thought I would update the list on some discussion= s that have been happening over in the OpenID Connect and RISC working grou= ps conference calls.

=C2=A0

These discussions have been about the core spec and = the role of =E2=80=9Ctop-level=E2=80=9D attributes vs. event =E2=80=9Cexten= sion=E2=80=9D attributes.=C2=A0

=C2=A0

In particular should =E2=80=9Csub=E2=80=9D be used i= n the top level to =E2=80=9Cpoint=E2=80=9D to the subject (in the broader e= nglish sense) of the event, or should it be constrained to the SAML/ID Toke= n definition which is the authenticated user. =C2=A0

=C2=A0

Taken in the narrower definition, it is important to= observe that in an ID Token, =E2=80=9Csub=E2=80=9D and =E2=80=9Ciss=E2=80= =9D go together.=C2=A0 The issuer provides the context for the authenticate= d subject identifier. The problem with events, is that it might not be the AS (or OP) which is issuing the event. =C2=A0

=C2=A0

To summarize a fair amount of discussion, the feelin= g seems to be the following:

=C2=A0

* =C2=A0The Event Token top level attributes should = be fairly limited and not include the sub attribute. =C2=A0

* =C2=A0For events that are about a user, the releva= nt event specification may include a =E2=80=9Csub=E2=80=9D attribute within= the event=E2=80=99s sub-object and not in the top-level. Further that sub-= object can also include the issuer of the user. =C2=A0

* The top-level =E2=80=9Ciss=E2=80=9D shall mean the= issuer of the event where the state change occurred.

* =C2=A0=E2=80=9Csub=E2=80=9D should not be present = in the top level structure.=C2=A0 Also, =E2=80=9Cevents=E2=80=9D must also = be present.

=C2=A0

Here would be a new example logout: 

{
=C2=A0 <=E2=80=94 top level is about the event itself -><=
u>
=C2=A0 "iss": "https://server.example.com",
=C2=A0 "aud": "s6BhdRkqt3=
",
=C2=A0 "jti": "3d0c3=
cf797584bd193bd0fb1bd4e7d30",
=C2=A0 "iat": 1458668180,
=C2=A0 "exp": 1458668580,
=C2=A0 "events": [
=C2=A0=C2=A0=C2=A0 "https://specs.openid.net/logout"
=C2=A0 ],
 =C2=A0"https://specs.openid.net/logout": {=

=C2=A0=C2=A0=C2=A0 <- This level is d=
efined entirely by the event URI->
=C2=A0=C2=A0=C2=A0 "iss": &quo=
t;https://oidc.example.com"=
,
=C2=A0=C2=A0=C2=A0 =E2=80=9Cjti": &=
quot;08a5019c-17e1-4977-8f42-65a12843ea02=E2=80=9D,
=C2=A0=C2=A0=C2=A0 &quo=
t;sub": "248289761001=E2=80=9D,
=C2=A0=C2=A0=C2=A0 =E2=
=80=9Cexp=E2=80=9D: <ID token expiry>
=C2=A0 }<=
u>
}

=C2=A0

In the above example note that the =E2=80=9Cevent=E2= =80=9D object can have its own iss and subject (sub or jti) that have meani= ng within the context of an OpenID OP provider.=C2=A0 The issuer of the eve= nt can be different (the top-level) and represents the entity that signs the event (if it is signed).

=C2=A0

The top-level attributes identify an individual even= t and are used to validate the event (signing etc).=C2=A0 Where as the nest= ed object contains all of the data about the event and is defined by the pr= ofiling specification (e.g. a possible OpenID Logout Event spec).=C2=A0 In this case, in OpenID, logging out usua= lly translates into revoking an ID Token. Thus the =E2=80=9Cjti=E2=80=9D fo= r the ID token (08a5019c...843ea02) is included in the Logout object.

=C2=A0

Side note.=C2=A0 Regarding =E2=80=9Clogout=E2=80=9D,= it might be useful to include the expiry of the ID Token in case the subsc= riber has not yet received an ID Token. This would let the subscriber know = how long it needs to keep the revocation information for.=C2=A0 IOW=E2=80=A6after the the ID Token is expired, the subscriber would no lon= ger need to track the revocation state.

=C2=A0

It is also good to observe that the =E2=80=9Caud=E2= =80=9D at the top level describes the subscriber of the event.=C2=A0 This m= ay also be different then the original audience of the ID Token.<= /u>

=C2=A0

So to conclude. By making top-level attributes stric= tly about the events own validation, and nested objects about the event, we= avoid collisions in definitions such as the issuer of the event, vs. the o= riginal issuer of a security assertion.

=C2=A0

I hope I=E2=80=99ve gotten everyone=E2=80=99s feedba= ck correct here. Lets continue to discuss. I will revise the draft to follo= w the groups thinking here.

=C2=A0

=C2=A0

_____________________________________________= __
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-even= t

=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

_____________________________________________= __
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

--001a114112be5d40150539cfac1d-- From nobody Thu Aug 11 11:27:33 2016 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 550FD12D8FE for ; Thu, 11 Aug 2016 11:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.465 X-Spam-Level: X-Spam-Status: No, score=-5.465 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, 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 4WrVY4ludaea for ; Thu, 11 Aug 2016 11:27:26 -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 68F9012D8F9 for ; Thu, 11 Aug 2016 11:27:26 -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 u7BIRMF5032458 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 11 Aug 2016 18:27:23 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u7BIRLlA014988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 11 Aug 2016 18:27:22 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 u7BIRKkq000669; Thu, 11 Aug 2016 18:27:20 GMT Received: from [192.168.1.6] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 11 Aug 2016 11:27:19 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-C1E1866B-6990-49BE-AC6F-85102EA8975C Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (13G34) In-Reply-To: Date: Thu, 11 Aug 2016 11:27:17 -0700 Content-Transfer-Encoding: 7bit Message-Id: <21751371-BD95-4C15-AE01-D42CF4815233@oracle.com> References: <14E2EF51-7123-4E91-87DD-56AEA08202C1@oracle.com> <3F0DD3E6-46CD-4AA5-8F06-F79140F5D4BE@oracle.com> <56E7DF06-EE77-4FD1-BF44-15A083AC5B5A@ve7jtb.com> <12274564-507F-492B-94E8-C65C6A84FDB7@oracle.com> To: Sarah Squire X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: John Bradley , Mike Jones , "openid-specs-ab@lists.openid.net Ab" , "id-event@ietf.org" , Marius Scurtescu Subject: Re: [Id-event] Summarizing recent discussions on ID-Event token draft X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 11 Aug 2016 18:27:31 -0000 --Apple-Mail-C1E1866B-6990-49BE-AC6F-85102EA8975C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sarah, Good question! Your use case is really the app initiated logout or logout within the contex= t of a single application.=20 If the app initiated front/ backchannel you would be saying log user out of a= ll sso sites for that OP.=20 If instead, the app issued the event to the OP, it would be saying the user w= as logged out of the app. Thus issuer is the app. The OP may or may not take= action depending on its policy.=20 We need to explore the use case.=20 Talking through use cases was part of my reluctance to rushing id token with= out forming a wg.=20 =20 Phil > On Aug 11, 2016, at 11:09 AM, Sarah Squire wrot= e: >=20 > Are we including use cases where the RP is the event issuer? >=20 >=20 >> On Aug 11, 2016 11:02 AM, "Mike Jones" wrot= e: >> You=E2=80=99re aware that forcing =E2=80=9Csub=E2=80=9D to be a URI is a b= reaking change for most implementations, right? This is hardly a way to enc= ourage adoption! >>=20 >> =20 >>=20 >> The thing you wrote below that makes me think that you=E2=80=99re thinkin= g about the purpose of the ID Events spec differently than me is this: =E2=80= =9Cso that all event specs can use it=E2=80=9D. The purpose of the logout e= vent *isn=E2=80=99t* for all event specs to use it. It=E2=80=99s for the lo= gout use case to use it. There=E2=80=99s no expectation that events intende= d for one use case will even be comprehensible in other use cases because th= ey won=E2=80=99t understand the contents of the event. We shouldn=E2=80=99t= drive any of the design by trying to achieve that unachievable goal, since e= vents will *always* contain information that=E2=80=99s specific to their use= case. >>=20 >> =20 >>=20 >> You=E2=80=99re making complexity arguments, whereas you=E2=80=99re also p= roposing more complex rules than I am (at least as I see it). Trying to res= trict the use of =E2=80=9Csub=E2=80=9D (or any other claims) is unneeded com= plexity. >>=20 >> =20 >>=20 >> I understand that you see things differently. I hope you=E2=80=99ll none= theless think about my argument that having fewer rules about claims usage i= n events will make them simpler. I passionately care about keeping this sim= ple, which is why I=E2=80=99m investing my time in this discussion. If it=E2= =80=99s simple, it will likely get widely used. >>=20 >> =20 >>=20 >> I=E2=80=99m going to sign out of the discussion for now because my wife i= s about to get out of surgery. I hope you have a good day. >>=20 >> =20 >>=20 >> -- Mike >>=20 >> =20 >>=20 >> From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 >> Sent: Thursday, August 11, 2016 12:49 PM >> To: Mike Jones >> Cc: John Bradley ; openid-specs-ab@lists.openid.net Ab= ; id-event@ietf.org; Marius Scurtescu >> Subject: Re: [Id-event] Summarizing recent discussions on ID-Event token d= raft >>=20 >> =20 >>=20 >> Mike,=20 >>=20 >> =20 >>=20 >> Speaking as editor the format you propose ONLY works if =E2=80=9Csub=E2=80= =9D becomes a URI so that all event specs can use it. Otherwise, OIDC becom= es a special case which really kills the point of this work. It also makes t= he specification much much more complex. Maybe it is just me, but a complex s= pec generally implies complex implementation too. >>=20 >> =20 >>=20 >> If you want sub at the top level, that would mean that the OIDC spec form= at would have to look like: >>=20 >> { >>=20 >> "iss": "https://event.example.com", >>=20 >> "aud": "s6BhdRkqt3", >>=20 >> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>=20 >> "sub": =E2=80=9Chttps://token.example.com/248289761001", >>=20 >> "iat": 1458668180, >>=20 >> "exp": 1458668580, >>=20 >> "events": [ >>=20 >> "https://specs.openid.net/logout" >>=20 >> ], >>=20 >> "sid": "08a5019c-17e1-4977-8f42-65a12843ea02" >>=20 >> } >>=20 >> =20 >>=20 >> Given that events are signed (or should be), I will object strongly withi= n the OIDF that the event issuer and the token issuer MUST be the same or th= at OIDF adopt a different format. Yes having iss be the same is a nice secur= ity convenience, but it imposes the architecture restriction that it be the s= ame server. At scale, delivery of events may become a problem for large sca= le providers if they are also delivering tokens to relying parties. The rest= riction isn=E2=80=99t really justified given the crypto alternative =E2=80=94= which was the whole point of using JWT in the first place. >>=20 >> =20 >>=20 >> Per Justin=E2=80=99s comment, it seems elegant/trivial that a logout even= t simply has logout at the top level and an ID Token attached (though it mig= ht convey a lot of unneeded claims). IMO, the OIDC logout spec should only c= onvey the ID Token JTI. It is going to be rare that you log out all devices= for a user. To most users, it means clear SSO within this browser only! O= ne can argue that clearing all devices/sessions is a different event entirel= y. It is an account reset or lock-out action. >>=20 >> =20 >>=20 >> Phil >>=20 >> =20 >>=20 >> @independentid >>=20 >> www.independentid.com >>=20 >> phil.hunt@oracle.com >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> On Aug 11, 2016, at 9:32 AM, Mike Jones wro= te: >>=20 >> =20 >>=20 >> See my previous message, John, which was a reply to Phil=E2=80=99s messag= e that you also replied to, that contained a logout claims example. I=E2=80= =99m not proposing to special-case the Connect Logout message in any way. T= he =E2=80=9Ciss=E2=80=9D is the event issuer. The other claims in the messa= ge are those defined by the event to be included, just like those for any ot= her event. Yes, the logout message doesn=E2=80=99t include a second issuer,= a second subject, an ID Token as a claim, or anything else complicated like= that, because those things aren=E2=80=99t needed for the logout use case. >>=20 >> =20 >>=20 >> As I=E2=80=99d written previously, the ID Events spec should define the =E2= =80=9Cevents=E2=80=9D claim, how to use an event name as a claim (when neede= d), and say that the event JWT must be signed by the issuer, and stop there.= Trying to micro-manage claims usage within an event will only result in th= e ID Events spec being harder to use. If we=E2=80=99d tried to similarly mi= cro-manage JWT claims usage, JWT would likely not have been the success that= it is. >>=20 >> =20 >>=20 >> -- Mike >>=20 >> =20 >>=20 >> From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20 >> Sent: Thursday, August 11, 2016 12:22 PM >> To: Phil Hunt (IDM) >> Cc: Mike Jones ; id-event@ietf.org; Marius S= curtescu ; openid-specs-ab@lists.openid.net Ab >> Subject: Re: [Id-event] Summarizing recent discussions on ID-Event token d= raft >>=20 >> =20 >>=20 >> Not surprisingly a multipurpose message format will not be as optimized a= s a single purpose one. >>=20 >> =20 >>=20 >> Connect itself doesn=E2=80=99t really have a conflict around issuer the s= ame entity sending the logout message is always the one that created the id_= token that it refers to. >>=20 >> =20 >>=20 >> Using the same format as id_token with the same semantics to identify the= thing to be terminated makes sense from a purely openID Connect point of vi= ew. >>=20 >> =20 >>=20 >> Oter messages that have different notions of subject and are issued by di= fferent parties than the one that controls the subject cause issues when you= try and fit them into the same format as an ID_Token, I grant you that. >>=20 >> =20 >>=20 >> It was mentioned that we need to differentiate between these events and i= d_tokens. Mostly we need to do that in cases where the token might be prese= nted in the front channel. >>=20 >> =20 >>=20 >> To do that se do have mandatory claims for nonce and c_hash or at_hash as= well as the addition of events parameter to reduce confusion. Now I admit= that some people may still get that wrong, and the removal of sub from the= top level would remove any concern. However Mike has a point that adoption= may be hurt if we change the semantics too much. >>=20 >> =20 >>=20 >> I don=E2=80=99t see backchannel single logout being used by many social l= ogin RP, it is a lot of work to maintain server side state. It is mostly a= n enterprise and large site sort of feature. >>=20 >> That may or may not impact on if it is better to be simple and aligned wi= th connect=E2=80=99s id token or more general purpose to fit with other ente= rprise to SaaS features like SCIM events. >>=20 >> =20 >>=20 >> I think the two directions lead to different formats. =20 >>=20 >> =20 >>=20 >> The compromise of special casing Connect SLO and bodging the formats toge= ther is probably the worst option. >>=20 >> =20 >>=20 >> John B. >>=20 >> =20 >>=20 >> =20 >>=20 >> On Aug 11, 2016, at 11:59 AM, Phil Hunt (IDM) wrot= e: >>=20 >> =20 >>=20 >> How do you resolve conflicts on iss then? The top level has to be the is= suer of the event as the issuer signs.=20 >>=20 >> =20 >>=20 >> If one spec can use it all must be able to. I believe you previously obje= cted to that saying sub must be as how id tokens define them. But that isnt u= nique and requires iss. Now we would have sub at the top with an event issue= r at the top and a sub issuer in the extension. That seems incredibly comple= x not to mention awkward.=20 >>=20 >> =20 >>=20 >> If we make sub a uri for all then it can work ass iss from id token would= not be needed. But i can see many objecting to the change in format.=20 >>=20 >> =20 >>=20 >> Why not have a logout be an event with an id token attached for example? >>=20 >>=20 >> Phil >>=20 >>=20 >> On Aug 11, 2016, at 8:03 AM, Mike Jones wro= te: >>=20 >> The simple rule is that if the particular event calls for the =E2=80=9Csu= b=E2=80=9D claim to be at the top level, then it is. This is no different f= rom any other claim that an event might place at the top level. >>=20 >> =20 >>=20 >> The complexity arises if =E2=80=9Csub=E2=80=9D is unnecessarily special-c= ased. We shouldn=E2=80=99t do that, because it limits the applicability of t= he specification. >>=20 >> =20 >>=20 >> -- Mike >>=20 >> =20 >>=20 >> From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com]=20 >> Sent: Thursday, August 11, 2016 9:40 AM >> To: Mike Jones >> Cc: Marius Scurtescu ; id-event@ietf.org >> Subject: Re: [Id-event] Summarizing recent discussions on ID-Event token d= raft >>=20 >> =20 >>=20 >> I think using sub at the top level leads to complexity. Eg Can you provid= e a rule for when top level is used or not by an individual spec? IMO. Top l= evel should always be used the same way by all implementers.=20 >>=20 >> =20 >>=20 >> Based on the calls at risc/connect, we discussed that it would be best to= move all event specifics to the event object area. This way different event= s can have different event addressing (eg sub/iss, uri, jit/iss). When iss i= s needed to uniquely qualify a sub, it can be provided without conflicting w= ith the issuer of the event. Similarly jti and iss can be used for a revoked= token without conflicting with the event jti.=20 >>=20 >> =20 >>=20 >> I plan to post a new draft shortly that will give some examples based on f= eedback from the openid risc/connect discussions. >>=20 >> =20 >>=20 >> We can always change again.=20 >>=20 >>=20 >> Phil >>=20 >>=20 >> On Aug 11, 2016, at 4:54 AM, Mike Jones wro= te: >>=20 >> No, I=E2=80=99m not saying that =E2=80=9Csub=E2=80=9D cannot appear at th= e top level. I=E2=80=99m saying that =E2=80=9Csub=E2=80=9D will only occur a= t the top level if the particular event defines that =E2=80=9Csub=E2=80=9D i= s used in that way for that event. >>=20 >> =20 >>=20 >> There are probably use cases for multiple events per message but I doubt t= here are use cases for multiple *unrelated* events per message. By definiti= on, related events that use top-level claims would need to use them in a com= patible way. I don=E2=80=99t see that as being a problem. >>=20 >> =20 >>=20 >> That being said, the predominant use case is likely to be a single event p= er JWT. >>=20 >> =20 >>=20 >> -- M= ike >>=20 >> =20 >>=20 >> From: Marius Scurtescu [mailto:mscurtescu@google.com]=20 >> Sent: Tuesday, August 9, 2016 7:15 PM >> To: Phil Hunt >> Cc: Mike Jones ; id-event@ietf.org >> Subject: Re: [Id-event] Summarizing recent discussions on ID-Event token d= raft >>=20 >> =20 >>=20 >> Mike, are you suggesting that a sub claim can only show up at the event l= evel and not at the top level: >>=20 >> =20 >>=20 >> In particular, the only thing that the spec should say about the =E2=80=9C= sub=E2=80=9D claim is that =E2=80=9CLike all other claims other than =E2=80=98= events=E2=80=99 and =E2=80=98iss=E2=80=99, whether the =E2=80=98sub=E2=80=99= claim is to be included with an event is entirely event-specific. >>=20 >> =20 >>=20 >> A top level sub and multiple events are incompatible IMO. >>=20 >> =20 >>=20 >> Do we have a compelling reason to support multiple events per message? >>=20 >> =20 >>=20 >>=20 >>=20 >> Marius >>=20 >> =20 >>=20 >> On Tue, Aug 9, 2016 at 12:39 PM, Phil Hunt wrote: >>=20 >> I was referring to this in your email >>=20 >> "Define that an event name can be used as a top-level claim=E2=80=9D >>=20 >> =20 >>=20 >> =20 >>=20 >> Is this different from the event uri? >>=20 >> =20 >>=20 >> Phil >>=20 >> =20 >>=20 >> @independentid >>=20 >> www.independentid.com >>=20 >> phil.hunt@oracle.com >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> On Aug 9, 2016, at 12:12 PM, Mike Jones wro= te: >>=20 >> =20 >>=20 >> I=E2=80=99m glad to hear that we agree on keeping it as simple and genera= l-purpose as possible and that you agree with my write-up. I think we then h= ave a good path forward. >>=20 >> =20 >>=20 >> I=E2=80=99m not sure what you mean by =E2=80=9CI=E2=80=99m not sure that w= e need a =E2=80=9Cname=E2=80=9D. What is your intention there.=E2=80=9D Th= e only place I used the word =E2=80=9Cname=E2=80=9D was in my statement =E2=80= =9CDefine that an event name can be used as a top-level claim=E2=80=9D. Wha= t I was trying to get at is was that if =E2=80=9Chttp://specs.openid.net/log= out=E2=80=9D is used as an event name, that it can also be used as a claim n= ame in the JWT containing information about the event. (Maybe I=E2=80=99m n= ot using the correct terminology, hence the unintended confusion J.) >>=20 >> =20 >>=20 >> Thanks again, >>=20 >> -- Mike >>=20 >> =20 >>=20 >> From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 >> Sent: Tuesday, August 9, 2016 12:07 PM >> To: Mike Jones >> Cc: id-event@ietf.org >> Subject: Re: [Id-event] Summarizing recent discussions on ID-Event token d= raft >>=20 >> =20 >>=20 >> I didn=E2=80=99t cover this as I didn=E2=80=99t want to confuse people wi= th too many things. >>=20 >> =20 >>=20 >> But I think we agree on all of the below. >>=20 >> =20 >>=20 >> I=E2=80=99m not sure that we need a =E2=80=9Cname=E2=80=9D. What is your i= ntention there. >>=20 >> =20 >>=20 >> Phil >>=20 >> =20 >>=20 >> @independentid >>=20 >> www.independentid.com >>=20 >> phil.hunt@oracle.com >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> On Aug 9, 2016, at 11:54 AM, Mike Jones wro= te: >>=20 >> =20 >>=20 >> Thanks for writing this, Phil. Unfortunately, the summary below does not= include my feedback, which at the essence, is to keep the ID Events data st= ructure as simple and general-purpose as possible. (I strongly believe that= JWT is the success it is because we made JWT as simple and general-purpose a= s possible, and we should follow this successful example and do the same her= e.) >>=20 >> =20 >>=20 >> I believe that the ID Events spec needs to include these things, and thes= e things only: >>=20 >> =C2=B7 Define of the =E2=80=9Cevents=E2=80=9D claim >>=20 >> =C2=B7 Define that an event name can be used as a top-level claim >>=20 >> =C2=B7 Require that =E2=80=9Ciss=E2=80=9D be included and that the J= WT be signed by the issuer >>=20 >> =C2=B7 Include a statement along the lines of =E2=80=9CThe claims t= o be included with any particular event are to be defined by the event=E2=80= =9D >>=20 >> =20 >>=20 >> And I=E2=80=99d stop there. >>=20 >> =20 >>=20 >> It should be entirely up to applications to say what claims are included w= ith events they define and what their format and meanings are. Then the ID E= vents spec will be as general-purpose as possible, with it being natural for= it to be used in essentially all JSON Event contexts. >>=20 >> =20 >>=20 >> As soon as we start putting restrictions on the use of particular claims b= y events, we=E2=80=99re making the ID Events spec less general-purpose and l= ess natural to use. In particular, the only thing that the spec should say a= bout the =E2=80=9Csub=E2=80=9D claim is that =E2=80=9CLike all other claims o= ther than =E2=80=98events=E2=80=99 and =E2=80=98iss=E2=80=99, whether the =E2= =80=98sub=E2=80=99 claim is to be included with an event is entirely event-s= pecific. The claims to be included with any particular event are explicitl= y outside the scope of this specification.=E2=80=9D >>=20 >> =20 >>=20 >> -- Mike >>=20 >> =20 >>=20 >> From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Phil Hunt >> Sent: Tuesday, August 9, 2016 10:19 AM >> To: id-event@ietf.org >> Subject: [Id-event] Summarizing recent discussions on ID-Event token draf= t >>=20 >> =20 >>=20 >> I thought I would update the list on some discussions that have been happ= ening over in the OpenID Connect and RISC working groups conference calls. >>=20 >> =20 >>=20 >> These discussions have been about the core spec and the role of =E2=80=9C= top-level=E2=80=9D attributes vs. event =E2=80=9Cextension=E2=80=9D attribut= es.=20 >>=20 >> See: https://tools.ietf.org/html/draft-hunt-idevent-token-01 >>=20 >> =20 >>=20 >> In particular should =E2=80=9Csub=E2=80=9D be used in the top level to =E2= =80=9Cpoint=E2=80=9D to the subject (in the broader english sense) of the ev= ent, or should it be constrained to the SAML/ID Token definition which is th= e authenticated user. =20 >>=20 >> =20 >>=20 >> Taken in the narrower definition, it is important to observe that in an I= D Token, =E2=80=9Csub=E2=80=9D and =E2=80=9Ciss=E2=80=9D go together. The i= ssuer provides the context for the authenticated subject identifier. The pro= blem with events, is that it might not be the AS (or OP) which is issuing th= e event. =20 >>=20 >> =20 >>=20 >> To summarize a fair amount of discussion, the feeling seems to be the fol= lowing: >>=20 >> =20 >>=20 >> * The Event Token top level attributes should be fairly limited and not i= nclude the sub attribute. =20 >>=20 >> * For events that are about a user, the relevant event specification may= include a =E2=80=9Csub=E2=80=9D attribute within the event=E2=80=99s sub-ob= ject and not in the top-level. Further that sub-object can also include the i= ssuer of the user. =20 >>=20 >> * The top-level =E2=80=9Ciss=E2=80=9D shall mean the issuer of the event w= here the state change occurred. >>=20 >> * =E2=80=9Csub=E2=80=9D should not be present in the top level structure= . Also, =E2=80=9Cevents=E2=80=9D must also be present. >>=20 >> =20 >>=20 >> Here would be a new example logout: >>=20 >> { >> <=E2=80=94 top level is about the event itself -> >> "iss": "https://server.example.com", >> "aud": "s6BhdRkqt3", >> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >> "iat": 1458668180, >> "exp": 1458668580, >> "events": [ >> "https://specs.openid.net/logout" >> ], >> "https://specs.openid.net/logout": { >> <- This level is defined entirely by the event URI-> >> "iss": "https://oidc.example.com", >> =E2=80=9Cjti": "08a5019c-17e1-4977-8f42-65a12843ea02=E2=80=9D, >> "sub": "248289761001=E2=80=9D, >> =E2=80=9Cexp=E2=80=9D: >> } >> } >> =20 >>=20 >> In the above example note that the =E2=80=9Cevent=E2=80=9D object can hav= e its own iss and subject (sub or jti) that have meaning within the context o= f an OpenID OP provider. The issuer of the event can be different (the top-= level) and represents the entity that signs the event (if it is signed). >>=20 >> =20 >>=20 >> The top-level attributes identify an individual event and are used to val= idate the event (signing etc). Where as the nested object contains all of t= he data about the event and is defined by the profiling specification (e.g. a= possible OpenID Logout Event spec). In this case, in OpenID, logging out u= sually translates into revoking an ID Token. Thus the =E2=80=9Cjti=E2=80=9D f= or the ID token (08a5019c...843ea02) is included in the Logout object. >>=20 >> =20 >>=20 >> Side note. Regarding =E2=80=9Clogout=E2=80=9D, it might be useful to inc= lude the expiry of the ID Token in case the subscriber has not yet received a= n ID Token. This would let the subscriber know how long it needs to keep the= revocation information for. IOW=E2=80=A6after the the ID Token is expired,= the subscriber would no longer need to track the revocation state. >>=20 >> =20 >>=20 >> It is also good to observe that the =E2=80=9Caud=E2=80=9D at the top leve= l describes the subscriber of the event. This may also be different then th= e original audience of the ID Token. >>=20 >> =20 >>=20 >> So to conclude. By making top-level attributes strictly about the events o= wn validation, and nested objects about the event, we avoid collisions in de= finitions such as the issuer of the event, vs. the original issuer of a secu= rity assertion. >>=20 >> =20 >>=20 >> I hope I=E2=80=99ve gotten everyone=E2=80=99s feedback correct here. Lets= continue to discuss. I will revise the draft to follow the groups thinking h= ere. >>=20 >> =20 >>=20 >> Phil >>=20 >> =20 >>=20 >> @independentid >>=20 >> www.independentid.com >>=20 >> 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 >>=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 >> =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://www.ietf.org/mailman/listinfo/id-event --Apple-Mail-C1E1866B-6990-49BE-AC6F-85102EA8975C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Sarah,

Good question!

Your use case i= s really the app initiated logout or logout within the context of a single a= pplication. 

If the app initiated front/ backchannel you would be sayi= ng log user out of all sso sites for that OP. 

If instead, the app iss= ued the event to the OP, it would be saying the user was logged out of the a= pp. Thus issuer is the app. The OP may or may not take action depending on i= ts policy. 

We need to explore the use case. 

Talking through us= e cases was part of my reluctance to rushing id token without forming a wg.&= nbsp;
 
Phil

On Aug 11, 2016, at 11:09 AM, Sarah Sq= uire <sarah@engageidentity.co= m> wrote:

= Are we including use cases where the RP is the event issuer?


On Aug 11, 2016 11= :02 AM, "Mike Jones" <Mich= ael.Jones@microsoft.com> wrote:

You=E2=80=99re aware that forcing =E2=80= =9Csub=E2=80=9D to be a URI is a breaking change for most implementations, r= ight?  This is hardly a way to encourage adoption!=

 

The thing you wrote below that makes me= think that you=E2=80=99re thinking about the purpose of the ID Events spec d= ifferently than me is this: =E2=80=9Cso that all event specs can use it=E2=80=9D.  The purpose of the logout ev= ent *isn=E2=80=99t* for all event specs to use it.  It=E2=80=99s= for the logout use case to use it.  There=E2=80=99s no expectation tha= t events intended for one use case will even be comprehensible in other use cases because the= y won=E2=80=99t understand the contents of the event.  We shouldn=E2=80= =99t drive any of the design by trying to achieve that unachievable goal, si= nce events will *always* contain information that=E2=80=99s specific to their use case.

 

You=E2=80=99re making complexity argume= nts, whereas you=E2=80=99re also proposing more complex rules than I am (at l= east as I see it).  Trying to restrict the use of =E2=80=9Csub=E2=80=9D= (or any other claims) is unneeded complexity.

 

I understand that you see things differ= ently.  I hope you=E2=80=99ll nonetheless think about my argument that h= aving fewer rules about claims usage in events will make them simpler.  I passionately care about keeping this simple, which is= why I=E2=80=99m investing my time in this discussion.  If it=E2=80=99s= simple, it will likely get widely used.

 

I=E2=80=99m going to sign out of the di= scussion for now because my wife is about to get out of surgery.  I hop= e you have a good day.

 

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

 

From: Phil Hunt [mailto:phil.hunt@oracle.com]
Sent: Thursday, August 11, 2016 12:49 PM
To: Mike Jones <Mic= hael.Jones@microsoft.com>
Cc: John Bradley <ve7jtb@ve7j= tb.com>; openid-specs= -ab@lists.openid.net Ab <openid-specs-ab@lists.openid.net>; id-event@ietf.org; Marius Scurtescu <mscurtescu@google.com>
Subject: Re: [Id-event] Summarizing recent discussions on ID-Event to= ken draft

 

Mike, 

 

Speaking as editor the format you propose ONLY works i= f =E2=80=9Csub=E2=80=9D becomes a URI so that all event specs can use it.&nb= sp; Otherwise, OIDC becomes a special case which really kills the point of t= his work. It also makes the specification much much more complex. Maybe it is just me, but a complex spec generally implies com= plex implementation too.

 

If you want sub at the top level, that would mean tha= t the OIDC spec format would have to look like:

{

  "aud": "s6BhdRkqt3",

  "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",

  "iat": 1458668180,

  "exp": 1458668580,

  "events": [

  ],

  "sid": "08a5019c-17e1-4977-8f42-65a12843e= a02"

}

 

Given that events are signed (or should be), I wil= l object strongly within the OIDF that the event issuer and the token issuer= MUST be the same or that OIDF adopt a different format. Yes having iss b= e the same is a nice security convenience, but it imposes the architecture restriction that it be the sam= e server.  At scale, delivery of events may become a problem for large s= cale providers if they are also delivering tokens to relying parties. The re= striction isn=E2=80=99t really justified given the crypto alternative =E2=80=94 which was the whole point of using J= WT in the first place.

 

Per Justin=E2=80=99s comment, it seems elegant/trivia= l that a logout event simply has logout at the top level and an ID Token att= ached (though it might convey a lot of unneeded claims).  IMO, the OIDC= logout spec should only convey the ID Token JTI.  It is going to be rare that you log out all devices for a user.&= nbsp; To most users, it means clear SSO within this browser only!  One c= an argue that clearing all devices/sessions is a different event entirely. I= t is an account reset or lock-out action.

 

 

 

See my previous message, John, which wa= s a reply to Phil=E2=80=99s message that you also replied to, that contained= a logout claims example.  I=E2=80=99m not proposing to special-case the Connect Logout message in any way.  The =E2=80=9Ciss=E2=80=9D is t= he event issuer.  The other claims in the message are those defined by t= he event to be included, just like those for any other event.  Yes, the= logout message doesn=E2=80=99t include a second issuer, a second subject, an ID Token as a claim, or anything else complicated like that, because tho= se things aren=E2=80=99t needed for the logout use case.

 

As I=E2=80=99d written previously, the I= D Events spec should define the =E2=80=9Cevents=E2=80=9D claim, how to use a= n event name as a claim (when needed), and say that the event JWT must be signed by the issuer, and stop there.  Trying to micro-manage c= laims usage within an event will only result in the ID Events spec being har= der to use.  If we=E2=80=99d tried to similarly micro-manage JWT claims= usage, JWT would likely not have been the success that it is.

 

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

 

From: John Bradley [mailto:ve7jtb@ve7jtb.com] 
Sent: Thursday, August 11, 2016 12:22 PM
To: Phil Hunt (IDM) <phil.hunt@oracle.com= >
Cc: Mike Jones <Michael.Jones@microsoft.com>; id-event@ietf.org; Marius Scurtescu <mscurtescu@google.com&= gt;; openid-specs-ab@lists.openid.net Ab <openid-specs-ab@lists= .openid.net>
Subject: Re: [Id-event] Summarizing recent discussi= ons on ID-Event token draft

 

Not surprisingly a multipurpose message format will n= ot be as optimized as a single purpose one.

 

Connect itself doesn=E2=80=99t really have a conflict= around issuer the same entity sending the logout message is always the one t= hat created the id_token that it refers to.

 

Using the same format as id_token with the same seman= tics to identify the thing to be terminated makes sense from a purely openID= Connect point of view.

 

Oter messages that have different notions of subject a= nd are issued by different parties than the one that controls the subject ca= use issues when you try and fit them into the same format as an ID_Token, I g= rant you that.

 

It was mentioned that we need to differentiate betwee= n these events and id_tokens.  Mostly we need to do that in cases where= the token might be presented in the front channel.

 

To do that se do have mandatory claims for nonce and c= _hash or at_hash as well as the addition of events parameter to reduce confu= sion.   Now I admit that some people may still get that wrong,  an= d the removal of sub from the top level would remove any concern.  However Mike has a point that adoption may b= e hurt if we change the semantics too much.

 

I don=E2=80=99t see backchannel single logout being u= sed by many social login RP, it is a lot of work to maintain server side sta= te.   It is mostly an enterprise and large site sort of feature.=

That may or may not impact on if it is better to be s= imple and aligned with connect=E2=80=99s id token or more general purpose to= fit with other enterprise to SaaS features like SCIM events.<= /p>

 

I think the two directions lead to different formats.=   

 

The compromise of special casing Connect SLO and bodg= ing the formats together is probably the worst option.

 

John B.

 

 

On Aug 11, 2016, at 11:59 AM, Phil Hunt (IDM) <= phil.hunt@oracle.com> wrote:

 

How do you resolve conflicts on iss then?  The t= op level has to be the issuer of the event as the issuer signs. =

 

If one spec can use it all must be able to. I believ= e you previously objected to that saying sub must be as how id tokens define= them. But that isnt unique and requires iss. Now we would have sub at the top with an event issuer at the top and a sub i= ssuer in the extension. That seems incredibly complex not to mention awkward= . 

 

If we make sub a uri for all then it can work ass is= s from id token would not be needed. But i can see many objecting to the cha= nge in format. 

 

Why not have a logout be an event with an id token a= ttached for example?


Phil


On Aug 11, 2016, at 8:03 AM, Mike Jones <= Michael.Jones@microsoft.com> wrote:

The simple rule is that if the particul= ar event calls for the =E2=80=9Csub=E2=80=9D claim to be at the top level, t= hen it is.  This is no different from any other claim that an event might place at the top level.

 

The complexity arises if =E2=80=9Csub=E2= =80=9D is unnecessarily special-cased.  We shouldn=E2=80=99t do that, b= ecause it limits the applicability of the specification.

 

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

 

From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com] 
Sent: Thursday, August 11, 2016 9:40 AM
To: Mike Jones <= Michael.Jones@microsoft.com>
Cc: Marius Scurtescu <mscurtescu@google.com>; id-event@ietf.org
Subject: Re: [Id-event] Summarizing recent discussi= ons on ID-Event token draft

 

I think using sub at the top level leads to complexit= y. Eg Can you provide a rule for when top level is used or not by an individ= ual spec?  IMO. Top level should always be used the same way by all imp= lementers. 

 

Based on the calls at risc/connect, we discussed that= it would be best to move all event specifics to the event object area. This= way different events can have different event addressing (eg sub/iss, uri, j= it/iss). When iss is needed to uniquely qualify a sub, it can be provided without conflicting with the iss= uer of the event. Similarly jti and iss can be used for a revoked token with= out conflicting with the event jti. 

 

I plan to post a new draft shortly that will give som= e examples based on feedback from the openid risc/connect discussions.

 

We can always change again. 


Phil


On Aug 11, 2016, at 4:54 AM, Mike Jones <= Michael.Jones@microsoft.com> wrote:

No, I=E2=80=99m not saying that =E2=80=9C= sub=E2=80=9D cannot appear at the top level.  I=E2=80=99m saying that =E2= =80=9Csub=E2=80=9D will only occur at the top level if the particular event d= efines that =E2=80=9Csub=E2=80=9D is used in that way for that event.

 

There are probably use cases for multip= le events per message but I doubt there are use cases for multiple *unrel= ated* events per message.  By definition, related events that use top-level claims would need to use them in a compat= ible way.  I don=E2=80=99t see that as being a problem.

 

That being said, the predominant use ca= se is likely to be a single event per JWT.

 

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

 

From: Marius Scurtescu [mailto:mscurtescu@google.com] 
Sent: Tuesday, August 9, 2016 7:15 PM
To: Phil Hunt <p= hil.hunt@oracle.com>
Cc: Mike Jones <= Michael.Jones@microsoft.com>; id-event@ietf.org
Subject: Re: [Id-event] Summarizing recent discussi= ons on ID-Event token draft

 

Mike, are you suggesting that a sub claim can only sh= ow up at the event level and not at the top level:

 

In particular, the only thing that the spec should sa= y about the =E2=80=9Csub=E2=80=9D claim is that =E2=80=9CLike all other clai= ms other than =E2=80=98events=E2=80=99 and =E2=80=98iss=E2=80=99, whether th= e =E2=80=98sub=E2=80=99 claim is to be included with an event is entirely ev= ent-specific.

 

A top level sub and multiple events are incompatible I= MO.

 

Do we have a compelling reason to support multiple ev= ents per message?

 


Marius

 

On Tue, Aug 9, 2016 at 12:39 PM, Phil Hunt <phil.hunt@oracle.com> wrote:<= u>

I was referring to this in your email

"Define that an event name can be used a= s a top-level claim=E2=80=9D

 

 

Is this different from the event uri?

 

 

On Aug 9, 2016, at 12:12 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

 

I=E2=80=99m glad to hear that we agree o= n keeping it as simple and general-purpose as possible and that you agree wi= th my write-up.  I think we then have a good path forward.

 

I=E2=80=99m not sure what you mean by =E2= =80=9CI=E2=80=99m not sure that we need a =E2=80=9Cname=E2=80=9D. Wha= t is your intention there.=E2=80=9D  The only place I used the word =E2=80=9Cname=E2=80=9D was in my statement =E2= =80=9CDefine that an event name can be used as a top-level claim=E2=80=9D.&n= bsp; What I was trying to get at is was that if =E2=80=9Chttp://specs.openid.net/logout=E2=80=9D is used as an event name, that it can also be used as a claim name in the J= WT containing information about the event.  (Maybe I=E2=80=99m not usin= g the correct terminology, hence the unintended confusion = = J.)

 

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

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

 <= /u>

From: Phil Hunt [mailto:phil.hunt@oracle.com] 
Sent: Tuesday, August 9, 2016 12:07 PM
To: Mike Jones <= Michael.Jones@microsoft.com>
Cc: id-event@ietf.o= rg
Subject: Re: [Id-event] Summarizing recent discussi= ons on ID-Event token draft

 

I didn=E2=80=99t cover this as I didn=E2=80=99t want t= o confuse people with too many things.

 

But I think we agree on all of the below.

 

I=E2=80=99m not sure that we need a =E2=80=9Cname=E2=80= =9D. What is your intention there.

 

 

On Aug 9, 2016, at 11:54 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

 

Thanks for writing this, Phil.  Un= fortunately, the summary below does not include my feedback, which at the es= sence, is to keep the ID Events data structure as simple and general-purpose as possible.  (I strongly believe that JWT i= s the success it is because we made JWT as simple and general-purpose as pos= sible, and we should follow this successful example and do the same here.)

 

I believe that the ID Events spec needs= to include these things, and these things only:

=C2=B7&nbs= p;      Defi= ne of the =E2=80=9Cevents=E2=80=9D claim

=C2=B7&nbs= p;      Defi= ne that an event name can be used as a top-level claim

=C2=B7&nbs= p;      Requ= ire that =E2=80=9Ciss=E2=80=9D be included and that the JWT be signed by the is= suer

=C2=B7&nbs= p;      Incl= ude a statement along the lines of =E2=80=9CThe claims to be included with any p= articular event are to be defined by the event=E2=80=9D=

 

And I=E2=80=99d stop there.

 

It should be entirely up to application= s to say what claims are included with events they define and what their for= mat and meanings are.  Then the ID Events spec will be as general-purpose as possible, with it being natural for it to be u= sed in essentially all JSON Event contexts.

 

As soon as we start putting restriction= s on the use of particular claims by events, we=E2=80=99re making the ID Eve= nts spec less general-purpose and less natural to use.  In particular, the only thing that the spec should say about the =E2=80=9Cs= ub=E2=80=9D claim is that =E2=80=9CLike all other claims other than =E2=80=98= events=E2=80=99 and =E2=80=98iss=E2=80=99, whether the =E2=80=98sub=E2=80=99= claim is to be included with an event is entirely event-specific.  The= claims to be included with any particular event are explicitly outside the scope of this specification.=E2= =80=9D

 

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

 

From: Id-event= [mailto:id-event-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Tuesday, August 9, 2016 10:19 AM
To: id-event@ietf.o= rg
Subject: [Id-event] Summarizing recent discussions o= n ID-Event token draft

 

I thought I would update the list on some discussions= that have been happening over in the OpenID Connect and RISC working groups= conference calls.

 

These discussions have been about the core spec and t= he role of =E2=80=9Ctop-level=E2=80=9D attributes vs. event =E2=80=9Cextensi= on=E2=80=9D attributes. 

 

In particular should =E2=80=9Csub=E2=80=9D be used in= the top level to =E2=80=9Cpoint=E2=80=9D to the subject (in the broader eng= lish sense) of the event, or should it be constrained to the SAML/ID Token d= efinition which is the authenticated user.  

 

Taken in the narrower definition, it is important to o= bserve that in an ID Token, =E2=80=9Csub=E2=80=9D and =E2=80=9Ciss=E2=80=9D g= o together.  The issuer provides the context for the authenticated subj= ect identifier. The problem with events, is that it might not be the AS (or OP) which is issuing the event.  

 

To summarize a fair amount of discussion, the feeling= seems to be the following:

 

*  The Event Token top level attributes should b= e fairly limited and not include the sub attribute.  

=

*  For events that are about a user, the relevan= t event specification may include a =E2=80=9Csub=E2=80=9D attribute within t= he event=E2=80=99s sub-object and not in the top-level. Further that sub-obj= ect can also include the issuer of the user.  

* The top-level =E2=80=9Ciss=E2=80=9D shall mean the i= ssuer of the event where the state change occurred.

*  =E2=80=9Csub=E2=80=9D should not be present i= n the top level structure.  Also, =E2=80=9Cevents=E2=80=9D must also be= present.

 

Here would be a new example logout:

= 
{
  <=E2=80=94 top level is about the event itself ->
  "iss": "https://server.example.com",
  "aud": "s6BhdRkqt3",=

  "jti": "3d0c3cf797584bd193bd0=
fb1bd4e7d30",
  "iat": 1458668180,
  "exp": 1458668580,
  "events": [

    "https://specs.openid.net/logout"=



  ],


  "h=
ttps://specs.openid.net/logout": {

    <- This level is de=
fined entirely by the event URI->


    "iss": "https://oidc.example.com",=



    =E2=80=9Cjti": "08a501=
9c-17e1-4977-8f42-65a12843ea02=E2=80=9D,


    "sub"=
: "248289761001=E2=80=9D,


    =E2=80=
=9Cexp=E2=80=9D: <ID token expiry>


  }


}












 






















In the above example note that the =E2=80=9Cevent=E2=80=
=9D object can have its own iss and subject (sub or jti) that have meaning w=
ithin the context of an OpenID OP provider.  The issuer of the event ca=
n be different (the top-level) and represents the
 entity that signs the event (if it is signed).






















 






















The top-level attributes identify an individual event=
 and are used to validate the event (signing etc).  Where as the nested=
 object contains all of the data about the event and is defined by the profi=
ling specification (e.g. a possible
 OpenID Logout Event spec).  In this case, in OpenID, logging out usual=
ly translates into revoking an ID Token. Thus the =E2=80=9Cjti=E2=80=9D for t=
he ID token (08a5019c...843ea02) is included in the Logout object.=























 






















Side note.  Regarding =E2=80=9Clogout=E2=80=9D, i=
t might be useful to include the expiry of the ID Token in case the subscrib=
er has not yet received an ID Token. This would let the subscriber know how l=
ong it needs to keep the revocation information for. 
 IOW=E2=80=A6after the the ID Token is expired, the subscriber would no long=
er need to track the revocation state.






















 






















It is also good to observe that the =E2=80=9Caud=E2=80=
=9D at the top level describes the subscriber of the event.  This may a=
lso be different then the original audience of the ID Token.





















 






















So to conclude. By making top-level attributes strict=
ly about the events own validation, and nested objects about the event, we a=
void collisions in definitions such as the issuer of the event, vs. the orig=
inal issuer of a security assertion.






















 






















I hope I=E2=80=99ve gotten everyone=E2=80=99s feedbac=
k correct here. Lets continue to discuss. I will revise the draft to follow t=
he groups thinking here.






















 

 

_______________________________________________=
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/i= d-event

 

_______________________________________________<= br> Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/i= d-event

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

 

_______________________________________________=
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/<= wbr>listinfo/id-event

= --Apple-Mail-C1E1866B-6990-49BE-AC6F-85102EA8975C-- From nobody Thu Aug 11 11:30:57 2016 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 DB26A127077 for ; Thu, 11 Aug 2016 11:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=engageidentity-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 nqphwglFhFyt for ; Thu, 11 Aug 2016 11:30:52 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::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 CF93F12D1B2 for ; Thu, 11 Aug 2016 11:30:51 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id i5so8636336wmg.0 for ; Thu, 11 Aug 2016 11:30:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=engageidentity-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4oPsYN2Np49iNFnJ2zrCqJQQ07aPPizNpcWD6UPUoSA=; b=aNyfx6myIAMefhRu+nge6Uddcsj5PVzhr3HBUQJ10uLqwMswupRs2PaDOLt+r+X+zR JDR9aXGDH4z0yO8XW7qMTnrzGGWs5fc8SO0aPzvlwF33vbn5dA2asz8zGiENxj0DdGcG yXphUkR5+gP8qCJ7k9ENeWF2AuRqlNY5zCurATwL9koHePGjAqWbmkbZmFvqJFz15yCv DfALg3V3+TlrNKDZ6ineJIwm8yvc7mj9iLk7EHGnMIrOoN3LRhUtQy95t9AB1tEZqL6V I9SuhKxAoYaEswDQ9u7kjcTl2eiOmcKXLe+f6Xx4X0iPy+VKsiCQwY8Npha/DxyACKSz jfWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4oPsYN2Np49iNFnJ2zrCqJQQ07aPPizNpcWD6UPUoSA=; b=HtWm2XJcvIu5fBYcL2VcApF4Ez5npbHXf1+DchNwTlJfpsy/jkMAWvGq2UAXwh8oWV fEYAIf/4LeYQy/ndkmUMQocAIhmhRFqbEIfA/giC6aJiNRnBh4xQw3sjDz4ZygkYZNCM rAbJukL7vKxQDIT2QizolcLI9Rq5lWmgtfGF6DJIpKRr0XEP93qyOHB4dcxdREujbF0X RyKmOZ9kKJERBQK6NFZ7FXxEEpsItmXM506jvCsEDfcnJXOtMeNLXz6+15NqJHOq50O7 TaQ6Y3Db+mKpYH7+l0eD4QMWdvS9hvR6paVT9IdzINnUS7UfotRS3qH3pKx2dZEjEY/m oZFw== X-Gm-Message-State: AEkooutUUJyU+f3CQbJNpdONVRinRrqYUtoHfA4lH9jRvkUmqWnRYYZxqxjih4Pa16GVEZyp4vmMGbBTg7OxPppK X-Received: by 10.25.27.139 with SMTP id b133mr1991990lfb.157.1470940250068; Thu, 11 Aug 2016 11:30:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.3.241 with HTTP; Thu, 11 Aug 2016 11:30:48 -0700 (PDT) Received: by 10.114.3.241 with HTTP; Thu, 11 Aug 2016 11:30:48 -0700 (PDT) In-Reply-To: <21751371-BD95-4C15-AE01-D42CF4815233@oracle.com> References: <14E2EF51-7123-4E91-87DD-56AEA08202C1@oracle.com> <3F0DD3E6-46CD-4AA5-8F06-F79140F5D4BE@oracle.com> <56E7DF06-EE77-4FD1-BF44-15A083AC5B5A@ve7jtb.com> <12274564-507F-492B-94E8-C65C6A84FDB7@oracle.com> <21751371-BD95-4C15-AE01-D42CF4815233@oracle.com> From: Sarah Squire Date: Thu, 11 Aug 2016 11:30:48 -0700 Message-ID: To: "Phil Hunt (IDM)" Content-Type: multipart/alternative; boundary=001a1140211e177a9d0539cff700 Archived-At: Cc: John Bradley , Mike Jones , "openid-specs-ab@lists.openid.net Ab" , "id-event@ietf.org" , Marius Scurtescu Subject: Re: [Id-event] Summarizing recent discussions on ID-Event token draft X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 11 Aug 2016 18:30:56 -0000 --001a1140211e177a9d0539cff700 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable There are also rp-initiated use cases around suspected fraud, parallel authentication of a second factor, and issuance of a consent receipt. On Aug 11, 2016 12:27 PM, "Phil Hunt (IDM)" wrote: > Sarah, > > Good question! > > Your use case is really the app initiated logout or logout within the > context of a single application. > > If the app initiated front/ backchannel you would be saying log user out > of all sso sites for that OP. > > If instead, the app issued the event to the OP, it would be saying the > user was logged out of the app. Thus issuer is the app. The OP may or may > not take action depending on its policy. > > We need to explore the use case. > > Talking through use cases was part of my reluctance to rushing id token > without forming a wg. > > Phil > > On Aug 11, 2016, at 11:09 AM, Sarah Squire > wrote: > > Are we including use cases where the RP is the event issuer? > > On Aug 11, 2016 11:02 AM, "Mike Jones" > wrote: > >> You=E2=80=99re aware that forcing =E2=80=9Csub=E2=80=9D to be a URI is a= breaking change for most >> implementations, right? This is hardly a way to encourage adoption! >> >> >> >> The thing you wrote below that makes me think that you=E2=80=99re thinki= ng about >> the purpose of the ID Events spec differently than me is this: =E2=80=9C= so that >> all event specs can use it=E2=80=9D. The purpose of the logout event **= isn=E2=80=99t** >> for all event specs to use it. It=E2=80=99s for the logout use case to = use it. >> There=E2=80=99s no expectation that events intended for one use case wil= l even be >> comprehensible in other use cases because they won=E2=80=99t understand = the >> contents of the event. We shouldn=E2=80=99t drive any of the design by = trying to >> achieve that unachievable goal, since events will **always** contain >> information that=E2=80=99s specific to their use case. >> >> >> >> You=E2=80=99re making complexity arguments, whereas you=E2=80=99re also = proposing more >> complex rules than I am (at least as I see it). Trying to restrict the = use >> of =E2=80=9Csub=E2=80=9D (or any other claims) is unneeded complexity. >> >> >> >> I understand that you see things differently. I hope you=E2=80=99ll non= etheless >> think about my argument that having fewer rules about claims usage in >> events will make them simpler. I passionately care about keeping this >> simple, which is why I=E2=80=99m investing my time in this discussion. = If it=E2=80=99s >> simple, it will likely get widely used. >> >> >> >> I=E2=80=99m going to sign out of the discussion for now because my wife = is about >> to get out of surgery. I hope you have a good day. >> >> >> >> -- Mike >> >> >> >> *From:* Phil Hunt [mailto:phil.hunt@oracle.com] >> *Sent:* Thursday, August 11, 2016 12:49 PM >> *To:* Mike Jones >> *Cc:* John Bradley ; openid-specs-ab@lists.openid.net >> Ab ; id-event@ietf.org; Marius >> Scurtescu >> *Subject:* Re: [Id-event] Summarizing recent discussions on ID-Event >> token draft >> >> >> >> Mike, >> >> >> >> Speaking as editor the format you propose ONLY works if =E2=80=9Csub=E2= =80=9D becomes a >> URI so that all event specs can use it. Otherwise, OIDC becomes a speci= al >> case which really kills the point of this work. It also makes the >> specification much much more complex. Maybe it is just me, but a complex >> spec generally implies complex implementation too. >> >> >> >> If you want sub at the top level, that would mean that the OIDC spec >> format would have to look like: >> >> { >> >> "iss": "https://event.example.com", >> >> "aud": "s6BhdRkqt3", >> >> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >> >> "sub": =E2=80=9Chttps://token.example.com/248289761001", >> >> "iat": 1458668180, >> >> "exp": 1458668580, >> >> "events": [ >> >> "https://specs.openid.net/logout" >> >> ], >> >> "sid": "08a5019c-17e1-4977-8f42-65a12843ea02" >> >> } >> >> >> >> Given that events are signed (or should be), *I will object strongly >> within the OIDF that the event issuer and the token issuer MUST be the s= ame >> or that OIDF adopt a different format*. Yes having iss be the same is a >> nice security convenience, but it imposes the architecture restriction t= hat >> it be the same server. At scale, delivery of events may become a proble= m >> for large scale providers if they are also delivering tokens to relying >> parties. The restriction isn=E2=80=99t really justified given the crypto >> alternative =E2=80=94 which was the whole point of using JWT in the firs= t place. >> >> >> >> Per Justin=E2=80=99s comment, it seems elegant/trivial that a logout eve= nt simply >> has logout at the top level and an ID Token attached (though it might >> convey a lot of unneeded claims). IMO, the OIDC logout spec should only >> convey the ID Token JTI. It is going to be rare that you log out all >> devices for a user. To most users, it means clear SSO within this brows= er >> only! One can argue that clearing all devices/sessions is a different >> event entirely. It is an account reset or lock-out action. >> >> >> >> Phil >> >> >> >> @independentid >> >> www.independentid.com >> >> phil.hunt@oracle.com >> >> >> >> >> >> >> >> >> >> On Aug 11, 2016, at 9:32 AM, Mike Jones >> wrote: >> >> >> >> See my previous message, John, which was a reply to Phil=E2=80=99s messa= ge that >> you also replied to, that contained a logout claims example. I=E2=80=99= m not >> proposing to special-case the Connect Logout message in any way. The = =E2=80=9Ciss=E2=80=9D >> is the event issuer. The other claims in the message are those defined = by >> the event to be included, just like those for any other event. Yes, the >> logout message doesn=E2=80=99t include a second issuer, a second subject= , an ID >> Token as a claim, or anything else complicated like that, because those >> things aren=E2=80=99t needed for the logout use case. >> >> >> >> As I=E2=80=99d written previously, the ID Events spec should define the = =E2=80=9Cevents=E2=80=9D >> claim, how to use an event name as a claim (when needed), and say that t= he >> event JWT must be signed by the issuer, and stop there. Trying to >> micro-manage claims usage within an event will only result in the ID Eve= nts >> spec being harder to use. If we=E2=80=99d tried to similarly micro-mana= ge JWT >> claims usage, JWT would likely not have been the success that it is. >> >> >> >> -- Mike >> >> >> >> *From:* John Bradley [mailto:ve7jtb@ve7jtb.com] >> *Sent:* Thursday, August 11, 2016 12:22 PM >> *To:* Phil Hunt (IDM) >> *Cc:* Mike Jones ; id-event@ietf.org; >> Marius Scurtescu ; openid-specs-ab@lists.openid.n >> et Ab >> *Subject:* Re: [Id-event] Summarizing recent discussions on ID-Event >> token draft >> >> >> >> Not surprisingly a multipurpose message format will not be as optimized >> as a single purpose one. >> >> >> >> Connect itself doesn=E2=80=99t really have a conflict around issuer the = same >> entity sending the logout message is always the one that created the >> id_token that it refers to. >> >> >> >> Using the same format as id_token with the same semantics to identify th= e >> thing to be terminated makes sense from a purely openID Connect point of >> view. >> >> >> >> Oter messages that have different notions of subject and are issued by >> different parties than the one that controls the subject cause issues wh= en >> you try and fit them into the same format as an ID_Token, I grant you th= at. >> >> >> >> It was mentioned that we need to differentiate between these events and >> id_tokens. Mostly we need to do that in cases where the token might be >> presented in the front channel. >> >> >> >> To do that se do have mandatory claims for nonce and c_hash or at_hash a= s >> well as the addition of events parameter to reduce confusion. Now I ad= mit >> that some people may still get that wrong, and the removal of sub from = the >> top level would remove any concern. However Mike has a point that adopt= ion >> may be hurt if we change the semantics too much. >> >> >> >> I don=E2=80=99t see backchannel single logout being used by many social = login RP, >> it is a lot of work to maintain server side state. It is mostly an >> enterprise and large site sort of feature. >> >> That may or may not impact on if it is better to be simple and aligned >> with connect=E2=80=99s id token or more general purpose to fit with othe= r >> enterprise to SaaS features like SCIM events. >> >> >> >> I think the two directions lead to different formats. >> >> >> >> The compromise of special casing Connect SLO and bodging the formats >> together is probably the worst option. >> >> >> >> John B. >> >> >> >> >> >> On Aug 11, 2016, at 11:59 AM, Phil Hunt (IDM) >> wrote: >> >> >> >> How do you resolve conflicts on iss then? The top level has to be the >> issuer of the event as the issuer signs. >> >> >> >> If one spec can use it all must be able to. I believe you previously >> objected to that saying sub must be as how id tokens define them. But th= at >> isnt unique and requires iss. Now we would have sub at the top with an >> event issuer at the top and a sub issuer in the extension. That seems >> incredibly complex not to mention awkward. >> >> >> >> If we make sub a uri for all then it can work ass iss from id token woul= d >> not be needed. But i can see many objecting to the change in format. >> >> >> >> Why not have a logout be an event with an id token attached for example? >> >> >> Phil >> >> >> On Aug 11, 2016, at 8:03 AM, Mike Jones >> wrote: >> >> The simple rule is that if the particular event calls for the =E2=80=9Cs= ub=E2=80=9D claim >> to be at the top level, then it is. This is no different from any other >> claim that an event might place at the top level. >> >> >> >> The complexity arises if =E2=80=9Csub=E2=80=9D is unnecessarily special-= cased. We >> shouldn=E2=80=99t do that, because it limits the applicability of the sp= ecification. >> >> >> >> -- Mike >> >> >> >> *From:* Phil Hunt (IDM) [mailto:phil.hunt@oracle.com] >> *Sent:* Thursday, August 11, 2016 9:40 AM >> *To:* Mike Jones >> *Cc:* Marius Scurtescu ; id-event@ietf.org >> *Subject:* Re: [Id-event] Summarizing recent discussions on ID-Event >> token draft >> >> >> >> I think using sub at the top level leads to complexity. Eg Can you >> provide a rule for when top level is used or not by an individual spec? >> IMO. Top level should always be used the same way by all implementers. >> >> >> >> Based on the calls at risc/connect, we discussed that it would be best t= o >> move all event specifics to the event object area. This way different >> events can have different event addressing (eg sub/iss, uri, jit/iss). W= hen >> iss is needed to uniquely qualify a sub, it can be provided without >> conflicting with the issuer of the event. Similarly jti and iss can be u= sed >> for a revoked token without conflicting with the event jti. >> >> >> >> I plan to post a new draft shortly that will give some examples based on >> feedback from the openid risc/connect discussions. >> >> >> >> We can always change again. >> >> >> Phil >> >> >> On Aug 11, 2016, at 4:54 AM, Mike Jones >> wrote: >> >> No, I=E2=80=99m not saying that =E2=80=9Csub=E2=80=9D cannot appear at t= he top level. I=E2=80=99m saying >> that =E2=80=9Csub=E2=80=9D will only occur at the top level if the parti= cular event defines >> that =E2=80=9Csub=E2=80=9D is used in that way for that event. >> >> >> >> There are probably use cases for multiple events per message but I doubt >> there are use cases for multiple **unrelated** events per message. By >> definition, related events that use top-level claims would need to use t= hem >> in a compatible way. I don=E2=80=99t see that as being a problem. >> >> >> >> That being said, the predominant use case is likely to be a single event >> per JWT. >> >> >> >> -- >> Mike >> >> >> >> *From:* Marius Scurtescu [mailto:mscurtescu@google.com] >> *Sent:* Tuesday, August 9, 2016 7:15 PM >> *To:* Phil Hunt >> *Cc:* Mike Jones ; id-event@ietf.org >> *Subject:* Re: [Id-event] Summarizing recent discussions on ID-Event >> token draft >> >> >> >> Mike, are you suggesting that a sub claim can only show up at the event >> level and not at the top level: >> >> >> >> In particular, the only thing that the spec should say about the =E2=80= =9Csub=E2=80=9D >> claim is that =E2=80=9CLike all other claims other than =E2=80=98events= =E2=80=99 and =E2=80=98iss=E2=80=99, whether >> the =E2=80=98sub=E2=80=99 claim is to be included with an event is entir= ely event-specific. >> >> >> >> A top level sub and multiple events are incompatible IMO. >> >> >> >> Do we have a compelling reason to support multiple events per message? >> >> >> >> >> Marius >> >> >> >> On Tue, Aug 9, 2016 at 12:39 PM, Phil Hunt wrote: >> >> I was referring to this in your email >> >> "Define that an event name can be used as a top-level claim=E2=80=9D >> >> >> >> >> >> Is this different from the event uri? >> >> >> >> Phil >> >> >> >> @independentid >> >> www.independentid.com >> >> phil.hunt@oracle.com >> >> >> >> >> >> >> >> >> >> On Aug 9, 2016, at 12:12 PM, Mike Jones >> wrote: >> >> >> >> I=E2=80=99m glad to hear that we agree on keeping it as simple and >> general-purpose as possible and that you agree with my write-up. I thin= k >> we then have a good path forward. >> >> >> >> I=E2=80=99m not sure what you mean by =E2=80=9CI=E2=80=99m not sure that= we need a =E2=80=9Cname=E2=80=9D. What >> is your intention there.=E2=80=9D The only place I used the word =E2=80= =9Cname=E2=80=9D was in >> my statement =E2=80=9CDefine that an event name can be used as a top-lev= el claim=E2=80=9D. >> What I was trying to get at is was that if =E2=80=9Chttp://specs.openid.= net/logou >> t=E2=80=9D is used as an event name, that it can also be used as a claim= name in >> the JWT containing information about the event. (Maybe I=E2=80=99m not = using the >> correct terminology, hence the unintended confusion J.) >> >> >> >> Thanks again, >> >> -- Mike >> >> >> >> *From:* Phil Hunt [mailto:phil.hunt@oracle.com] >> *Sent:* Tuesday, August 9, 2016 12:07 PM >> *To:* Mike Jones >> *Cc:* id-event@ietf.org >> *Subject:* Re: [Id-event] Summarizing recent discussions on ID-Event >> token draft >> >> >> >> I didn=E2=80=99t cover this as I didn=E2=80=99t want to confuse people w= ith too many >> things. >> >> >> >> But I think we agree on all of the below. >> >> >> >> I=E2=80=99m not sure that we need a =E2=80=9Cname=E2=80=9D. What is your= intention there. >> >> >> >> Phil >> >> >> >> @independentid >> >> www.independentid.com >> >> phil.hunt@oracle.com >> >> >> >> >> >> >> >> >> >> On Aug 9, 2016, at 11:54 AM, Mike Jones >> wrote: >> >> >> >> Thanks for writing this, Phil. Unfortunately, the summary below does no= t >> include my feedback, which at the essence, is to keep the ID Events data >> structure as simple and general-purpose as possible. (I strongly believ= e >> that JWT is the success it is because we made JWT as simple and >> general-purpose as possible, and we should follow this successful exampl= e >> and do the same here.) >> >> >> >> I believe that the ID Events spec needs to include these things, and >> these things only: >> >> =C2=B7 Define of the =E2=80=9Cevents=E2=80=9D claim >> >> =C2=B7 Define that an event name can be used as a top-level claim >> >> =C2=B7 Require that =E2=80=9Ciss=E2=80=9D be included and that the= JWT be signed by the >> issuer >> >> =C2=B7 Include a statement along the lines of =E2=80=9CThe claims = to be >> included with any particular event are to be defined by the event=E2=80= =9D >> >> >> >> And I=E2=80=99d stop there. >> >> >> >> It should be entirely up to applications to say what claims are included >> with events they define and what their format and meanings are. Then th= e >> ID Events spec will be as general-purpose as possible, with it being >> natural for it to be used in essentially all JSON Event contexts. >> >> >> >> As soon as we start putting restrictions on the use of particular claims >> by events, we=E2=80=99re making the ID Events spec less general-purpose = and less >> natural to use. In particular, the only thing that the spec should say >> about the =E2=80=9Csub=E2=80=9D claim is that =E2=80=9CLike all other cl= aims other than =E2=80=98events=E2=80=99 >> and =E2=80=98iss=E2=80=99, whether the =E2=80=98sub=E2=80=99 claim is to= be included with an event is >> entirely event-specific. The claims to be included with any particular >> event are explicitly outside the scope of this specification.=E2=80=9D >> >> >> >> -- Mike >> >> >> >> *From:* Id-event [mailto:id-event-bounces@ietf.org] *On Behalf Of *Phil >> Hunt >> *Sent:* Tuesday, August 9, 2016 10:19 AM >> *To:* id-event@ietf.org >> *Subject:* [Id-event] Summarizing recent discussions on ID-Event token >> draft >> >> >> >> I thought I would update the list on some discussions that have been >> happening over in the OpenID Connect and RISC working groups conference >> calls. >> >> >> >> These discussions have been about the core spec and the role of >> =E2=80=9Ctop-level=E2=80=9D attributes vs. event =E2=80=9Cextension=E2= =80=9D attributes. >> >> See: https://tools.ietf.org/html/draft-hunt-idevent-token-01 >> >> >> >> In particular should =E2=80=9Csub=E2=80=9D be used in the top level to = =E2=80=9Cpoint=E2=80=9D to the >> subject (in the broader english sense) of the event, or should it be >> constrained to the SAML/ID Token definition which is the authenticated >> user. >> >> >> >> Taken in the narrower definition, it is important to observe that in an >> ID Token, =E2=80=9Csub=E2=80=9D and =E2=80=9Ciss=E2=80=9D go together. = The issuer provides the context for >> the authenticated subject identifier. The problem with events, is that i= t >> might not be the AS (or OP) which is issuing the event. >> >> >> >> To summarize a fair amount of discussion, the feeling seems to be the >> following: >> >> >> >> * The Event Token top level attributes should be fairly limited and not >> include the sub attribute. >> >> * For events that are about a user, the relevant event specification ma= y >> include a =E2=80=9Csub=E2=80=9D attribute within the event=E2=80=99s sub= -object and not in the >> top-level. Further that sub-object can also include the issuer of the us= er. >> >> >> * The top-level =E2=80=9Ciss=E2=80=9D shall mean the issuer of the event= where the state >> change occurred. >> >> * =E2=80=9Csub=E2=80=9D should not be present in the top level structur= e. Also, >> =E2=80=9Cevents=E2=80=9D must also be present. >> >> >> >> Here would be a new example logout: >> >> { >> >> <=E2=80=94 top level is about the event itself -> >> >> "iss": "https://server.example.com", >> >> "aud": "s6BhdRkqt3", >> >> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >> >> "iat": 1458668180, >> >> "exp": 1458668580, >> >> "events": [ >> >> "https://specs.openid.net/logout" >> >> ], >> >> "https://specs.openid.net/logout": { >> >> <- This level is defined entirely by the event URI-> >> >> "iss": "https://oidc.example.com", >> >> =E2=80=9Cjti": "08a5019c-17e1-4977-8f42-65a12843ea02=E2=80=9D, >> >> "sub": "248289761001=E2=80=9D, >> >> =E2=80=9Cexp=E2=80=9D: >> >> } >> >> } >> >> >> >> In the above example note that the =E2=80=9Cevent=E2=80=9D object can ha= ve its own iss >> and subject (sub or jti) that have meaning within the context of an Open= ID >> OP provider. The issuer of the event can be different (the top-level) a= nd >> represents the entity that signs the event (if it is signed). >> >> >> >> The top-level attributes identify an individual event and are used to >> validate the event (signing etc). Where as the nested object contains a= ll >> of the data about the event and is defined by the profiling specificatio= n >> (e.g. a possible OpenID Logout Event spec). In this case, in OpenID, >> logging out usually translates into revoking an ID Token. Thus the =E2= =80=9Cjti=E2=80=9D >> for the ID token (08a5019c...843ea02) is included in the Logout object. >> >> >> >> Side note. Regarding =E2=80=9Clogout=E2=80=9D, it might be useful to in= clude the expiry >> of the ID Token in case the subscriber has not yet received an ID Token. >> This would let the subscriber know how long it needs to keep the revocat= ion >> information for. IOW=E2=80=A6after the the ID Token is expired, the sub= scriber >> would no longer need to track the revocation state. >> >> >> >> It is also good to observe that the =E2=80=9Caud=E2=80=9D at the top lev= el describes the >> subscriber of the event. This may also be different then the original >> audience of the ID Token. >> >> >> >> So to conclude. By making top-level attributes strictly about the events >> own validation, and nested objects about the event, we avoid collisions = in >> definitions such as the issuer of the event, vs. the original issuer of = a >> security assertion. >> >> >> >> I hope I=E2=80=99ve gotten everyone=E2=80=99s feedback correct here. Let= s continue to >> discuss. I will revise the draft to follow the groups thinking here. >> >> >> >> Phil >> >> >> >> @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 >> >> >> >> _______________________________________________ >> 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 >> >> --001a1140211e177a9d0539cff700 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

There are also rp-initiated use cases around suspected fraud= , parallel authentication of a second factor, and issuance of a consent rec= eipt.


On Aug 11, 2016 1= 2:27 PM, "Phil Hunt (IDM)" <phil.hunt@oracle.com> wrote:
Sarah,

Good question!

Your use case is really the app i= nitiated logout or logout within the context of a single application.=C2=A0=

If the app initiated front/ backchannel you would= be saying log user out of all sso sites for that OP.=C2=A0

<= /div>
If instead, the app issued the event to the OP, it would be sayin= g the user was logged out of the app. Thus issuer is the app. The OP may or= may not take action depending on its policy.=C2=A0

We need to explore the use case.=C2=A0

Talking t= hrough use cases was part of my reluctance to rushing id token without form= ing a wg.=C2=A0
=C2=A0
Phil

On Aug 11, 2016, at 11:09 A= M, Sarah Squire <sarah@engageidentity.com> wrote:

Are we including use cases where the RP is t= he event issuer?


On Aug 11, 2016 1= 1:02 AM, "Mike Jones" <Michael.Jones@microsoft.com> wrote:

You=E2=80=99re aware that forcing =E2= =80=9Csub=E2=80=9D to be a URI is a breaking change for most implementation= s, right?=C2=A0 This is hardly a way to encourage adoption!

=C2=A0

The thing you wrote below that makes = me think that you=E2=80=99re thinking about the purpose of the ID Events sp= ec differently than me is this: =E2=80=9Cso that all event specs can use it=E2=80=9D.=C2=A0 The purpose of the logout = event *isn=E2=80=99t* for all event specs to use it.=C2=A0 It=E2=80= =99s for the logout use case to use it.=C2=A0 There=E2=80=99s no expectatio= n that events intended for one use case will even be comprehensible in other use cases because th= ey won=E2=80=99t understand the contents of the event.=C2=A0 We shouldn=E2= =80=99t drive any of the design by trying to achieve that unachievable goal= , since events will *always* contain information that=E2=80=99s specific to their use case.

=C2=A0

You=E2=80=99re making complexity argu= ments, whereas you=E2=80=99re also proposing more complex rules than I am (= at least as I see it).=C2=A0 Trying to restrict the use of =E2=80=9Csub=E2= =80=9D (or any other claims) is unneeded complexity.

=C2=A0

I understand that you see things diff= erently.=C2=A0 I hope you=E2=80=99ll nonetheless think about my argument th= at having fewer rules about claims usage in events will make them simpler.=C2=A0 I passionately care about keeping this simple, which i= s why I=E2=80=99m investing my time in this discussion.=C2=A0 If it=E2=80= =99s simple, it will likely get widely used.

=C2=A0

I=E2=80=99m going to sign out of the = discussion for now because my wife is about to get out of surgery.=C2=A0 I = hope you have a good day.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mi= ke

=C2=A0

From: Phil Hunt [mailto:phil.hunt@oracle.com]
Sent: Thursday, August 11, 2016 12:49 PM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: John Bradley <ve7jtb@ve7jtb.com>; openid-specs-ab@lists.openid.net Ab <= openid-sp= ecs-ab@lists.openid.net>; id-event@ietf.org; Marius Scurtescu <mscurtescu@google.com>=
Subject: Re: [Id-event] Summarizing recent discussions on ID-Event t= oken draft

=C2=A0

Mike,=C2=A0

=C2=A0

Speaking as editor the format you propose ONLY works= if =E2=80=9Csub=E2=80=9D becomes a URI so that all event specs can use it.= =C2=A0 Otherwise, OIDC becomes a special case which really kills the point = of this work. It also makes the specification much much more complex. Maybe it is just me, but a complex spec generally implies co= mplex implementation too.

=C2=A0

If you want sub at the top level, that would mean th= at the OIDC spec format would have to look like:

{

=C2=A0 "iss": "https://event.example.com",

=C2=A0 "aud": "s6BhdRkqt3",

=C2=A0 "jti": "3d0c3cf797584bd193bd0f= b1bd4e7d30",

=C2=A0 "sub"= : =E2=80=9Chttps://token.example.com/248289761001",=

=C2=A0 "iat": 1458668180,

=C2=A0 "exp": 1458668580,

=C2=A0 "events": [

=C2=A0 ],

=C2=A0 "sid": "08a5019c-17e1-4977-8f4= 2-65a12843ea02"

}

=C2=A0

Given that events are signed (or should be), I wi= ll object strongly within the OIDF that the event issuer and the token issu= er MUST be the same or that OIDF adopt a different format. Yes having i= ss be the same is a nice security convenience, but it imposes the architecture restriction that it be the sa= me server.=C2=A0 At scale, delivery of events may become a problem for larg= e scale providers if they are also delivering tokens to relying parties. Th= e restriction isn=E2=80=99t really justified given the crypto alternative =E2=80=94 which was the whole point of using = JWT in the first place.

=C2=A0

Per Justin=E2=80=99s comment, it seems elegant/trivi= al that a logout event simply has logout at the top level and an ID Token a= ttached (though it might convey a lot of unneeded claims).=C2=A0 IMO, the O= IDC logout spec should only convey the ID Token JTI.=C2=A0 It is going to be rare that you log out all devices for a user.= =C2=A0 To most users, it means clear SSO within this browser only!=C2=A0 On= e can argue that clearing all devices/sessions is a different event entirel= y. It is an account reset or lock-out action.

=C2=A0

=C2=A0

=C2=A0

See my previous message, John, which = was a reply to Phil=E2=80=99s message that you also replied to, that contai= ned a logout claims example.=C2=A0 I=E2=80=99m not proposing to special-cas= e the Connect Logout message in any way.=C2=A0 The =E2=80=9Ciss=E2=80=9D is = the event issuer.=C2=A0 The other claims in the message are those defined b= y the event to be included, just like those for any other event.=C2=A0 Yes,= the logout message doesn=E2=80=99t include a second issuer, a second subje= ct, an ID Token as a claim, or anything else complicated like that, because th= ose things aren=E2=80=99t needed for the logout use case.<= /u>

=C2=A0

As I=E2=80=99d written previously, th= e ID Events spec should define the =E2=80=9Cevents=E2=80=9D claim, how to u= se an event name as a claim (when needed), and say that the event JWT must be signed by the issuer, and stop there.=C2=A0 Trying to micro-manage= claims usage within an event will only result in the ID Events spec being = harder to use.=C2=A0 If we=E2=80=99d tried to similarly micro-manage JWT cl= aims usage, JWT would likely not have been the success that it is.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mi= ke

=C2=A0

From:=C2=A0John Bradley [mailto:ve7jtb@ve7jtb.com]=C2=A0
Sent:=C2=A0Thursday, August 11, 2016 12:22 PM
To:=C2=A0Phil Hunt (IDM) <phil.hunt@oracle.com>
Cc:=C2=A0Mike Jones <Michael.Jones@microsoft.com<= /a>>; id-event@ietf.org; Marius Scurtescu <mscurtescu@google.com= >; openid-specs-ab@lists.openid.net Ab <openid-specs-ab@list= s.openid.net>
Subject:=C2=A0Re: [Id-event] Summarizing recent discuss= ions on ID-Event token draft

=C2=A0

Not surprisingly a multipurpose message format will = not be as optimized as a single purpose one.

=C2=A0

Connect itself doesn=E2=80=99t really have a conflic= t around issuer the same entity sending the logout message is always the on= e that created the id_token that it refers to.

=C2=A0

Using the same format as id_token with the same sema= ntics to identify the thing to be terminated makes sense from a purely open= ID Connect point of view.

=C2=A0

Oter messages that have different notions of subject= and are issued by different parties than the one that controls the subject= cause issues when you try and fit them into the same format as an ID_Token= , I grant you that.

=C2=A0

It was mentioned that we need to differentiate betwe= en these events and id_tokens.=C2=A0 Mostly we need to do that in cases whe= re the token might be presented in the front channel.

=C2=A0

To do that se do have mandatory claims for nonce and= c_hash or at_hash as well as the addition of events parameter to reduce co= nfusion. =C2=A0 Now I admit that some people may still get that wrong, =C2= =A0and the removal of sub from the top level would remove any concern.=C2=A0 However Mike has a point that adoption may= be hurt if we change the semantics too much.

=C2=A0

I don=E2=80=99t see backchannel single logout being = used by many social login RP, it is a lot of work to maintain server side s= tate. =C2=A0 It is mostly an enterprise and large site sort of feature.<= /u>

That may or may not impact on if it is better to be = simple and aligned with connect=E2=80=99s id token or more general purpose = to fit with other enterprise to SaaS features like SCIM events.

=C2=A0

I think the two directions lead to different formats= . =C2=A0=C2=A0

=C2=A0

The compromise of special casing Connect SLO and bod= ging the formats together is probably the worst option.

=C2=A0

John B.

=C2=A0

=C2=A0

On Aug 11, 2016, at 11:59 AM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:=

=C2=A0

How do you resolve conflicts on iss then?=C2=A0 Th= e top level has to be the issuer of the event as the issuer signs.=C2=A0

=C2=A0

If one spec can use it all must be able to. I beli= eve you previously objected to that saying sub must be as how id tokens def= ine them. But that isnt unique and requires iss. Now we would have sub at the top with an event issuer at the top and a sub= issuer in the extension. That seems incredibly complex not to mention awkw= ard.=C2=A0

=C2=A0

If we make sub a uri for all then it can work ass = iss from id token would not be needed. But i can see many objecting to the = change in format.=C2=A0

=C2=A0

Why not have a logout be an event with an id token= attached for example?


Phil


On Aug 11, 2016, at 8:03 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

The simple rule is that if the partic= ular event calls for the =E2=80=9Csub=E2=80=9D claim to be at the top level= , then it is.=C2=A0 This is no different from any other claim that an event might place at the top level.

=C2=A0

The complexity arises if =E2=80=9Csub= =E2=80=9D is unnecessarily special-cased.=C2=A0 We shouldn=E2=80=99t do tha= t, because it limits the applicability of the specification.<= 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 -- Mi= ke

=C2=A0

From:=C2=A0Phil Hunt (IDM) [mailto:phil.hunt@oracle.com]=C2=A0
Sent:=C2=A0Thursday, August 11, 2016 9:40 AM
To:=C2=A0Mike Jones <Michael.Jones@microsoft.com>
Cc:=C2=A0Marius Scurtescu <mscurtescu@google.com>;=C2=A0id-event@ietf.org
Subject:=C2=A0Re: [Id-event] Summarizing recent discuss= ions on ID-Event token draft

=C2=A0

I think using sub at the top level leads to complexi= ty. Eg Can you provide a rule for when top level is used or not by an indiv= idual spec?=C2=A0 IMO. Top level should always be used the same way by all = implementers.=C2=A0

=C2=A0

Based on the calls at risc/connect, we discussed tha= t it would be best to move all event specifics to the event object area. Th= is way different events can have different event addressing (eg sub/iss, ur= i, jit/iss). When iss is needed to uniquely qualify a sub, it can be provided without conflicting with the is= suer of the event. Similarly jti and iss can be used for a revoked token wi= thout conflicting with the event jti.=C2=A0

=C2=A0

I plan to post a new draft shortly that will give so= me examples based on feedback from the openid risc/connect discussions.<= /u>

=C2=A0

We can always change again.=C2=A0


Phil


On Aug 11, 2016, at 4:54 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

No, I=E2=80=99m not saying that =E2= =80=9Csub=E2=80=9D cannot appear at the top level.=C2=A0 I=E2=80=99m saying= that =E2=80=9Csub=E2=80=9D will only occur at the top level if the particu= lar event defines that =E2=80=9Csub=E2=80=9D is used in that way for that event.

=C2=A0

There are probably use cases for mult= iple events per message but I doubt there are use cases for multiple *un= related* events per message.=C2=A0 By definition, related events that use top-level claims would need to use them in a compa= tible way.=C2=A0 I don=E2=80=99t see that as being a problem.=

=C2=A0

That being said, the predominant use = case is likely to be a single event per JWT.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=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=A0Mari= us Scurtescu [mailto:mscurtescu@google.com]=C2=A0
Sent:=C2=A0Tuesday, August 9, 2016 7:15 PM
To:=C2=A0Phil Hunt <= phil.hunt@oracle.com>
Cc:=C2=A0Mike Jones <Michael.Jones@microsoft.com>;=C2=A0id-event@ietf.org
Subject:=C2=A0Re: [Id-event] Summarizing recent discuss= ions on ID-Event token draft

=C2=A0

Mike, are you suggesting that a sub claim can only s= how up at the event level and not at the top level:

=C2=A0

In particular, the only thing that the spec should s= ay about the =E2=80=9Csub=E2=80=9D claim is that =E2=80=9CLike all other cl= aims other than =E2=80=98events=E2=80=99 and =E2=80=98iss=E2=80=99, whether= the =E2=80=98sub=E2=80=99 claim is to be included with an event is entirel= y event-specific.

=C2=A0

A top level sub and multiple events are incompatible= IMO.

=C2=A0

Do we have a compelling reason to support multiple e= vents per message?

=C2=A0


Marius

=C2=A0

On Tue, Aug 9, 2016 at 12:39 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

I was referring to this in your email<= /p>

"Define that an event name can b= e used as a top-level claim=E2=80=9D

=C2=A0

=C2=A0

Is this different from the event uri?<= /p>

=C2=A0

=C2=A0

=C2=A0

=C2=A0<= /p>

=C2=A0

On Aug 9, 2016, at 12:12 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

=C2=A0

I=E2=80=99m glad to hear that we agre= e on keeping it as simple and general-purpose as possible and that you agre= e with my write-up.=C2=A0 I think we then have a good path forward.

=C2=A0

I=E2=80=99m not sure what you mean by= =E2=80=9CI=E2=80=99m not sure that we need a =E2=80=9Cname=E2=80=9D= . What is your intention there.=E2=80=9D=C2=A0 The only place I used the word =E2=80=9Cname=E2=80=9D was in my statement = =E2=80=9CDefine that an event name can be used as a top-level claim=E2=80= =9D.=C2=A0 What I was trying to get at is was that if =E2=80=9Chttp://specs.openid.net/logout=E2=80=9D is used as an event name, that it can also be used as a claim name in the = JWT containing information about the event.=C2=A0 (Maybe I=E2=80=99m not us= ing the correct terminology, hence the unintended confusion=C2=A0J.)

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Thank= s again,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mi= ke

=C2=A0

I didn=E2=80=99t cover this as I didn=E2=80=99t want= to confuse people with too many things.

=C2=A0

But I think we agree on all of the below.<= /u>

=C2=A0

I=E2=80=99m not sure that we need a =E2=80=9Cname=E2= =80=9D. What is your intention there.

=C2=A0

=C2=A0

=C2=A0

=C2=A0<= /p>

=C2=A0

On Aug 9, 2016, at 11:54 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

=C2=A0

Thanks for writing this, Phil.=C2=A0 = Unfortunately, the summary below does not include my feedback, which at the= essence, is to keep the ID Events data structure as simple and general-purpose as possible. =C2=A0(I strongly believe that JWT= is the success it is because we made JWT as simple and general-purpose as = possible, and we should follow this successful example and do the same here= .)

=C2=A0

I believe that the ID Events spec nee= ds to include these things, and these things only:

=C2=B7= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Define of the =E2=80=9Cevents=E2=80=9D claim

=C2=B7= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Define that an event name can be used as a top-level claim

=C2=B7= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Require that =E2=80=9Ciss=E2=80=9D be included and that the JWT be signed by the i= ssuer

=C2=B7= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Include a statement along the lines of =E2=80=9CThe claims to be included with any= particular event are to be defined by the event=E2=80=9D<= /u>

=C2=A0

And I=E2=80=99d stop there.=

=C2=A0

It should be entirely up to applicati= ons to say what claims are included with events they define and what their = format and meanings are.=C2=A0 Then the ID Events spec will be as general-purpose as possible, with it being natural for it to be= used in essentially all JSON Event contexts.

=C2=A0

As soon as we start putting restricti= ons on the use of particular claims by events, we=E2=80=99re making the ID = Events spec less general-purpose and less natural to use.=C2=A0 In particular, the only thing that the spec should say about the =E2=80=9C= sub=E2=80=9D claim is that =E2=80=9CLike all other claims other than =E2=80= =98events=E2=80=99 and =E2=80=98iss=E2=80=99, whether the =E2=80=98sub=E2= =80=99 claim is to be included with an event is entirely event-specific.=C2= =A0 The claims to be included with any particular event are explicitly outside the scope of this specification.= =E2=80=9D

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mi= ke

=C2=A0

From:=C2=A0Id-e= vent [mailto:id-event-bounces@ietf.org]=C2=A0On Behalf Of=C2=A0Phil Hunt
Sent:=C2=A0Tuesday, August 9, 2016 10:19 AM
To:=C2=A0id-event@ietf.= org
Subject:=C2=A0[Id-event] Summarizing recent discussions= on ID-Event token draft

=C2=A0

I thought I would update the list on some discussion= s that have been happening over in the OpenID Connect and RISC working grou= ps conference calls.

=C2=A0

These discussions have been about the core spec and = the role of =E2=80=9Ctop-level=E2=80=9D attributes vs. event =E2=80=9Cexten= sion=E2=80=9D attributes.=C2=A0

=C2=A0

In particular should =E2=80=9Csub=E2=80=9D be used i= n the top level to =E2=80=9Cpoint=E2=80=9D to the subject (in the broader e= nglish sense) of the event, or should it be constrained to the SAML/ID Toke= n definition which is the authenticated user. =C2=A0

=C2=A0

Taken in the narrower definition, it is important to= observe that in an ID Token, =E2=80=9Csub=E2=80=9D and =E2=80=9Ciss=E2=80= =9D go together.=C2=A0 The issuer provides the context for the authenticate= d subject identifier. The problem with events, is that it might not be the AS (or OP) which is issuing the event. =C2=A0

=C2=A0

To summarize a fair amount of discussion, the feelin= g seems to be the following:

=C2=A0

* =C2=A0The Event Token top level attributes should = be fairly limited and not include the sub attribute. =C2=A0

* =C2=A0For events that are about a user, the releva= nt event specification may include a =E2=80=9Csub=E2=80=9D attribute within= the event=E2=80=99s sub-object and not in the top-level. Further that sub-= object can also include the issuer of the user. =C2=A0

* The top-level =E2=80=9Ciss=E2=80=9D shall mean the= issuer of the event where the state change occurred.

* =C2=A0=E2=80=9Csub=E2=80=9D should not be present = in the top level structure.=C2=A0 Also, =E2=80=9Cevents=E2=80=9D must also = be present.

=C2=A0

Here would be a new example logout: 

{
=C2=A0 <=E2=80=94 top level is about the event itself -><=
u>
=C2=A0 "iss": "https://server.example.com",
=C2=A0 "aud": "s6BhdRkqt3=
",
=C2=A0 "jti": "3d0c3cf797=
584bd193bd0fb1bd4e7d30",
=C2=A0 "iat": 1458668180,
=C2=A0 "exp": 1458668580,
=C2=A0 "events": [
=C2=A0=C2=A0=C2=A0 "https://specs.openid.net/logout"
=C2=A0 ],
 =C2=A0"https://specs.openid.net/logout": {=

=C2=A0=C2=A0=C2=A0 <- This level is d=
efined entirely by the event URI->
=C2=A0=C2=A0=C2=A0 "iss": &quo=
t;https://oidc.example.com"=
,
=C2=A0=C2=A0=C2=A0 =E2=80=9Cjti": &=
quot;08a5019c-17e1-4977-8f42-65a12843ea02=E2=80=9D,
=C2=A0=C2=A0=C2=A0 &quo=
t;sub": "248289761001=E2=80=9D,
=C2=A0=C2=A0=C2=A0 =E2=
=80=9Cexp=E2=80=9D: <ID token expiry>
=C2=A0 }<=
u>
}

=C2=A0

In the above example note that the =E2=80=9Cevent=E2= =80=9D object can have its own iss and subject (sub or jti) that have meani= ng within the context of an OpenID OP provider.=C2=A0 The issuer of the eve= nt can be different (the top-level) and represents the entity that signs the event (if it is signed).

=C2=A0

The top-level attributes identify an individual even= t and are used to validate the event (signing etc).=C2=A0 Where as the nest= ed object contains all of the data about the event and is defined by the pr= ofiling specification (e.g. a possible OpenID Logout Event spec).=C2=A0 In this case, in OpenID, logging out usua= lly translates into revoking an ID Token. Thus the =E2=80=9Cjti=E2=80=9D fo= r the ID token (08a5019c...843ea02) is included in the Logout object.

=C2=A0

Side note.=C2=A0 Regarding =E2=80=9Clogout=E2=80=9D,= it might be useful to include the expiry of the ID Token in case the subsc= riber has not yet received an ID Token. This would let the subscriber know = how long it needs to keep the revocation information for.=C2=A0 IOW=E2=80=A6after the the ID Token is expired, the subscriber would no lon= ger need to track the revocation state.

=C2=A0

It is also good to observe that the =E2=80=9Caud=E2= =80=9D at the top level describes the subscriber of the event.=C2=A0 This m= ay also be different then the original audience of the ID Token.<= /u>

=C2=A0

So to conclude. By making top-level attributes stric= tly about the events own validation, and nested objects about the event, we= avoid collisions in definitions such as the issuer of the event, vs. the o= riginal issuer of a security assertion.

=C2=A0

I hope I=E2=80=99ve gotten everyone=E2=80=99s feedba= ck correct here. Lets continue to discuss. I will revise the draft to follo= w the groups thinking here.

=C2=A0

=C2=A0

_____________________________________________= __
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-even= t

=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

_____________________________________________= __
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.iet= f.org/mailman/listinfo/id-event

--001a1140211e177a9d0539cff700-- From nobody Thu Aug 11 11:55:05 2016 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 F21A412D853 for ; Thu, 11 Aug 2016 11:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.946 X-Spam-Level: X-Spam-Status: No, score=-3.946 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=-1.247, 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 HdIy-Bt8ANtU for ; Thu, 11 Aug 2016 11:54:59 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::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 143BB12D84A for ; Thu, 11 Aug 2016 11:54:56 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id o80so9760945wme.1 for ; Thu, 11 Aug 2016 11:54:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=R9Q4jmFDXgBR+40jg719aHH2bIj3mG8+QshaWP6D2tM=; b=gpDdPEGKYO4xTyygl1Q2SWVDZtu2E1CZOVUmqJK9R4Lq4OOB/O0gNF5FiINXDK7PuS vM7i1doZdiZ2OWB2T4ga+ii42EWKTu3geH21MMokJ2DStE4ObEjTp82V4b7p/CLoDOcu xyxC502EbHohs4wtNhB/2cGo0M/WuVWayGwwVV+zDrVdqmOoUrr6tnWTdUMtKozfPfwi HZE6AWJMPf8kf6+8KuoRb2FFq2/cAgby9AOpXuAIMZcflful/AE44pirmwUByox9jAI2 PX4IBwX9M4vBm2sRQmDaF689z0VdZlp2SvcBTyqt4v1a6Jr6AHklH0QUeuVbEqMTXz+j 1P+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=R9Q4jmFDXgBR+40jg719aHH2bIj3mG8+QshaWP6D2tM=; b=G0W0s580gGoUm3fKVSUKPFuxzKQBuc8K8XrikHpYliay3XPd3aBjH46Xm0uRgfHUqU mWFzFcMp5xNF7c2mr3Iim6o0wLTOdHhk89G2aBt4HaRhzMHNtMTeooo4FuHJ4NpKks1g Tm8AeD7lWNg6hqxsobrqZcRMfZeJ8qkDCtST2NaZIqc4orizp+J5G6hrQ8N09KTDO8Wq 4L4U6h24rWw5m27HJht4kkT+LE+pdpf8YtoB3kYp0YQtRt9p3Ro5GRsRaZoMRxZ+8n5q PtxzBzWBjPQBrHo3pmvd//bndgYUqiPS2Sam3nIpQOJFdKTu2MLRVTK1iDCVq3WyiqPK rDIg== X-Gm-Message-State: AEkoouskON31MQm6eXcunjgEpkPeuHPd+6XYeCDiYQkh/HFNm+yfUVfoF+yL+hi/EcM6lnsQEOYijgz1UX6ybr8p X-Received: by 10.28.196.136 with SMTP id u130mr10448241wmf.83.1470941694042; Thu, 11 Aug 2016 11:54:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.167.78 with HTTP; Thu, 11 Aug 2016 11:54:33 -0700 (PDT) In-Reply-To: References: <14E2EF51-7123-4E91-87DD-56AEA08202C1@oracle.com> <3F0DD3E6-46CD-4AA5-8F06-F79140F5D4BE@oracle.com> <56E7DF06-EE77-4FD1-BF44-15A083AC5B5A@ve7jtb.com> <12274564-507F-492B-94E8-C65C6A84FDB7@oracle.com> <21751371-BD95-4C15-AE01-D42CF4815233@oracle.com> From: Marius Scurtescu Date: Thu, 11 Aug 2016 11:54:33 -0700 Message-ID: To: Sarah Squire Content-Type: multipart/alternative; boundary=94eb2c192e74298e6e0539d04d8f Archived-At: Cc: John Bradley , Mike Jones , "openid-specs-ab@lists.openid.net Ab" , "id-event@ietf.org" , "Phil Hunt \(IDM\)" Subject: Re: [Id-event] Summarizing recent discussions on ID-Event token draft X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 11 Aug 2016 18:55:04 -0000 --94eb2c192e74298e6e0539d04d8f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Can we step back and look at all the requirements mentioned in this thread and see if we can simplify them: 1. Multiple events per SET (Security Event Token). 2. SET issuer different from event issuer. 3. Existing Id Token parsers must not confuse a SET for an Id Token. 4. Nested token format. 4 is needed by 1. 4 can fulfill 3, if sub can be present only in nested events. I don't think 1 is really needed, but with 4 it comes really easy. A nested format with sub only at event level seems to meet all the requirements. Allowing different event specs to define top level claims, like sub, is very problematic IMO because you can run into incompatible events. Same with requiring that all events in a single token must refer to the same sub. This can lead to very complex and buggy publisher implementations. Marius On Thu, Aug 11, 2016 at 11:30 AM, Sarah Squire wrote: > There are also rp-initiated use cases around suspected fraud, parallel > authentication of a second factor, and issuance of a consent receipt. > > On Aug 11, 2016 12:27 PM, "Phil Hunt (IDM)" wrote: > >> Sarah, >> >> Good question! >> >> Your use case is really the app initiated logout or logout within the >> context of a single application. >> >> If the app initiated front/ backchannel you would be saying log user out >> of all sso sites for that OP. >> >> If instead, the app issued the event to the OP, it would be saying the >> user was logged out of the app. Thus issuer is the app. The OP may or ma= y >> not take action depending on its policy. >> >> We need to explore the use case. >> >> Talking through use cases was part of my reluctance to rushing id token >> without forming a wg. >> >> Phil >> >> On Aug 11, 2016, at 11:09 AM, Sarah Squire >> wrote: >> >> Are we including use cases where the RP is the event issuer? >> >> On Aug 11, 2016 11:02 AM, "Mike Jones" >> wrote: >> >>> You=E2=80=99re aware that forcing =E2=80=9Csub=E2=80=9D to be a URI is = a breaking change for >>> most implementations, right? This is hardly a way to encourage adoptio= n! >>> >>> >>> >>> The thing you wrote below that makes me think that you=E2=80=99re think= ing about >>> the purpose of the ID Events spec differently than me is this: =E2=80= =9Cso that >>> all event specs can use it=E2=80=9D. The purpose of the logout event *= *isn=E2=80=99t** >>> for all event specs to use it. It=E2=80=99s for the logout use case to= use it. >>> There=E2=80=99s no expectation that events intended for one use case wi= ll even be >>> comprehensible in other use cases because they won=E2=80=99t understand= the >>> contents of the event. We shouldn=E2=80=99t drive any of the design by= trying to >>> achieve that unachievable goal, since events will **always** contain >>> information that=E2=80=99s specific to their use case. >>> >>> >>> >>> You=E2=80=99re making complexity arguments, whereas you=E2=80=99re also= proposing more >>> complex rules than I am (at least as I see it). Trying to restrict the= use >>> of =E2=80=9Csub=E2=80=9D (or any other claims) is unneeded complexity. >>> >>> >>> >>> I understand that you see things differently. I hope you=E2=80=99ll no= netheless >>> think about my argument that having fewer rules about claims usage in >>> events will make them simpler. I passionately care about keeping this >>> simple, which is why I=E2=80=99m investing my time in this discussion. = If it=E2=80=99s >>> simple, it will likely get widely used. >>> >>> >>> >>> I=E2=80=99m going to sign out of the discussion for now because my wife= is about >>> to get out of surgery. I hope you have a good day. >>> >>> >>> >>> -- Mike >>> >>> >>> >>> *From:* Phil Hunt [mailto:phil.hunt@oracle.com] >>> *Sent:* Thursday, August 11, 2016 12:49 PM >>> *To:* Mike Jones >>> *Cc:* John Bradley ; openid-specs-ab@lists.openid.ne= t >>> Ab ; id-event@ietf.org; Marius >>> Scurtescu >>> *Subject:* Re: [Id-event] Summarizing recent discussions on ID-Event >>> token draft >>> >>> >>> >>> Mike, >>> >>> >>> >>> Speaking as editor the format you propose ONLY works if =E2=80=9Csub=E2= =80=9D becomes a >>> URI so that all event specs can use it. Otherwise, OIDC becomes a spec= ial >>> case which really kills the point of this work. It also makes the >>> specification much much more complex. Maybe it is just me, but a comple= x >>> spec generally implies complex implementation too. >>> >>> >>> >>> If you want sub at the top level, that would mean that the OIDC spec >>> format would have to look like: >>> >>> { >>> >>> "iss": "https://event.example.com", >>> >>> "aud": "s6BhdRkqt3", >>> >>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>> >>> "sub": =E2=80=9Chttps://token.example.com/248289761001", >>> >>> "iat": 1458668180, >>> >>> "exp": 1458668580, >>> >>> "events": [ >>> >>> "https://specs.openid.net/logout" >>> >>> ], >>> >>> "sid": "08a5019c-17e1-4977-8f42-65a12843ea02" >>> >>> } >>> >>> >>> >>> Given that events are signed (or should be), *I will object strongly >>> within the OIDF that the event issuer and the token issuer MUST be the = same >>> or that OIDF adopt a different format*. Yes having iss be the same is a >>> nice security convenience, but it imposes the architecture restriction = that >>> it be the same server. At scale, delivery of events may become a probl= em >>> for large scale providers if they are also delivering tokens to relying >>> parties. The restriction isn=E2=80=99t really justified given the crypt= o >>> alternative =E2=80=94 which was the whole point of using JWT in the fir= st place. >>> >>> >>> >>> Per Justin=E2=80=99s comment, it seems elegant/trivial that a logout ev= ent >>> simply has logout at the top level and an ID Token attached (though it >>> might convey a lot of unneeded claims). IMO, the OIDC logout spec shou= ld >>> only convey the ID Token JTI. It is going to be rare that you log out = all >>> devices for a user. To most users, it means clear SSO within this brow= ser >>> only! One can argue that clearing all devices/sessions is a different >>> event entirely. It is an account reset or lock-out action. >>> >>> >>> >>> Phil >>> >>> >>> >>> @independentid >>> >>> www.independentid.com >>> >>> phil.hunt@oracle.com >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Aug 11, 2016, at 9:32 AM, Mike Jones >>> wrote: >>> >>> >>> >>> See my previous message, John, which was a reply to Phil=E2=80=99s mess= age that >>> you also replied to, that contained a logout claims example. I=E2=80= =99m not >>> proposing to special-case the Connect Logout message in any way. The = =E2=80=9Ciss=E2=80=9D >>> is the event issuer. The other claims in the message are those defined= by >>> the event to be included, just like those for any other event. Yes, th= e >>> logout message doesn=E2=80=99t include a second issuer, a second subjec= t, an ID >>> Token as a claim, or anything else complicated like that, because those >>> things aren=E2=80=99t needed for the logout use case. >>> >>> >>> >>> As I=E2=80=99d written previously, the ID Events spec should define the= =E2=80=9Cevents=E2=80=9D >>> claim, how to use an event name as a claim (when needed), and say that = the >>> event JWT must be signed by the issuer, and stop there. Trying to >>> micro-manage claims usage within an event will only result in the ID Ev= ents >>> spec being harder to use. If we=E2=80=99d tried to similarly micro-man= age JWT >>> claims usage, JWT would likely not have been the success that it is. >>> >>> >>> >>> -- Mike >>> >>> >>> >>> *From:* John Bradley [mailto:ve7jtb@ve7jtb.com] >>> *Sent:* Thursday, August 11, 2016 12:22 PM >>> *To:* Phil Hunt (IDM) >>> *Cc:* Mike Jones ; id-event@ietf.org; >>> Marius Scurtescu ; openid-specs-ab@lists.openid.= n >>> et Ab >>> *Subject:* Re: [Id-event] Summarizing recent discussions on ID-Event >>> token draft >>> >>> >>> >>> Not surprisingly a multipurpose message format will not be as optimized >>> as a single purpose one. >>> >>> >>> >>> Connect itself doesn=E2=80=99t really have a conflict around issuer the= same >>> entity sending the logout message is always the one that created the >>> id_token that it refers to. >>> >>> >>> >>> Using the same format as id_token with the same semantics to identify >>> the thing to be terminated makes sense from a purely openID Connect poi= nt >>> of view. >>> >>> >>> >>> Oter messages that have different notions of subject and are issued by >>> different parties than the one that controls the subject cause issues w= hen >>> you try and fit them into the same format as an ID_Token, I grant you t= hat. >>> >>> >>> >>> It was mentioned that we need to differentiate between these events and >>> id_tokens. Mostly we need to do that in cases where the token might be >>> presented in the front channel. >>> >>> >>> >>> To do that se do have mandatory claims for nonce and c_hash or at_hash >>> as well as the addition of events parameter to reduce confusion. Now = I >>> admit that some people may still get that wrong, and the removal of su= b >>> from the top level would remove any concern. However Mike has a point = that >>> adoption may be hurt if we change the semantics too much. >>> >>> >>> >>> I don=E2=80=99t see backchannel single logout being used by many social= login >>> RP, it is a lot of work to maintain server side state. It is mostly a= n >>> enterprise and large site sort of feature. >>> >>> That may or may not impact on if it is better to be simple and aligned >>> with connect=E2=80=99s id token or more general purpose to fit with oth= er >>> enterprise to SaaS features like SCIM events. >>> >>> >>> >>> I think the two directions lead to different formats. >>> >>> >>> >>> The compromise of special casing Connect SLO and bodging the formats >>> together is probably the worst option. >>> >>> >>> >>> John B. >>> >>> >>> >>> >>> >>> On Aug 11, 2016, at 11:59 AM, Phil Hunt (IDM) >>> wrote: >>> >>> >>> >>> How do you resolve conflicts on iss then? The top level has to be the >>> issuer of the event as the issuer signs. >>> >>> >>> >>> If one spec can use it all must be able to. I believe you previously >>> objected to that saying sub must be as how id tokens define them. But t= hat >>> isnt unique and requires iss. Now we would have sub at the top with an >>> event issuer at the top and a sub issuer in the extension. That seems >>> incredibly complex not to mention awkward. >>> >>> >>> >>> If we make sub a uri for all then it can work ass iss from id token >>> would not be needed. But i can see many objecting to the change in form= at. >>> >>> >>> >>> Why not have a logout be an event with an id token attached for example= ? >>> >>> >>> Phil >>> >>> >>> On Aug 11, 2016, at 8:03 AM, Mike Jones >>> wrote: >>> >>> The simple rule is that if the particular event calls for the =E2=80=9C= sub=E2=80=9D >>> claim to be at the top level, then it is. This is no different from an= y >>> other claim that an event might place at the top level. >>> >>> >>> >>> The complexity arises if =E2=80=9Csub=E2=80=9D is unnecessarily special= -cased. We >>> shouldn=E2=80=99t do that, because it limits the applicability of the s= pecification. >>> >>> >>> >>> -- Mike >>> >>> >>> >>> *From:* Phil Hunt (IDM) [mailto:phil.hunt@oracle.com] >>> *Sent:* Thursday, August 11, 2016 9:40 AM >>> *To:* Mike Jones >>> *Cc:* Marius Scurtescu ; id-event@ietf.org >>> *Subject:* Re: [Id-event] Summarizing recent discussions on ID-Event >>> token draft >>> >>> >>> >>> I think using sub at the top level leads to complexity. Eg Can you >>> provide a rule for when top level is used or not by an individual spec? >>> IMO. Top level should always be used the same way by all implementers. >>> >>> >>> >>> Based on the calls at risc/connect, we discussed that it would be best >>> to move all event specifics to the event object area. This way differen= t >>> events can have different event addressing (eg sub/iss, uri, jit/iss). = When >>> iss is needed to uniquely qualify a sub, it can be provided without >>> conflicting with the issuer of the event. Similarly jti and iss can be = used >>> for a revoked token without conflicting with the event jti. >>> >>> >>> >>> I plan to post a new draft shortly that will give some examples based o= n >>> feedback from the openid risc/connect discussions. >>> >>> >>> >>> We can always change again. >>> >>> >>> Phil >>> >>> >>> On Aug 11, 2016, at 4:54 AM, Mike Jones >>> wrote: >>> >>> No, I=E2=80=99m not saying that =E2=80=9Csub=E2=80=9D cannot appear at = the top level. I=E2=80=99m >>> saying that =E2=80=9Csub=E2=80=9D will only occur at the top level if t= he particular event >>> defines that =E2=80=9Csub=E2=80=9D is used in that way for that event. >>> >>> >>> >>> There are probably use cases for multiple events per message but I doub= t >>> there are use cases for multiple **unrelated** events per message. By >>> definition, related events that use top-level claims would need to use = them >>> in a compatible way. I don=E2=80=99t see that as being a problem. >>> >>> >>> >>> That being said, the predominant use case is likely to be a single even= t >>> per JWT. >>> >>> >>> >>> -- >>> Mike >>> >>> >>> >>> *From:* Marius Scurtescu [mailto:mscurtescu@google.com] >>> *Sent:* Tuesday, August 9, 2016 7:15 PM >>> *To:* Phil Hunt >>> *Cc:* Mike Jones ; id-event@ietf.org >>> *Subject:* Re: [Id-event] Summarizing recent discussions on ID-Event >>> token draft >>> >>> >>> >>> Mike, are you suggesting that a sub claim can only show up at the event >>> level and not at the top level: >>> >>> >>> >>> In particular, the only thing that the spec should say about the =E2=80= =9Csub=E2=80=9D >>> claim is that =E2=80=9CLike all other claims other than =E2=80=98events= =E2=80=99 and =E2=80=98iss=E2=80=99, whether >>> the =E2=80=98sub=E2=80=99 claim is to be included with an event is enti= rely event-specific. >>> >>> >>> >>> A top level sub and multiple events are incompatible IMO. >>> >>> >>> >>> Do we have a compelling reason to support multiple events per message? >>> >>> >>> >>> >>> Marius >>> >>> >>> >>> On Tue, Aug 9, 2016 at 12:39 PM, Phil Hunt wrote= : >>> >>> I was referring to this in your email >>> >>> "Define that an event name can be used as a top-level claim=E2=80=9D >>> >>> >>> >>> >>> >>> Is this different from the event uri? >>> >>> >>> >>> Phil >>> >>> >>> >>> @independentid >>> >>> www.independentid.com >>> >>> phil.hunt@oracle.com >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Aug 9, 2016, at 12:12 PM, Mike Jones >>> wrote: >>> >>> >>> >>> I=E2=80=99m glad to hear that we agree on keeping it as simple and >>> general-purpose as possible and that you agree with my write-up. I thi= nk >>> we then have a good path forward. >>> >>> >>> >>> I=E2=80=99m not sure what you mean by =E2=80=9CI=E2=80=99m not sure tha= t we need a =E2=80=9Cname=E2=80=9D. What >>> is your intention there.=E2=80=9D The only place I used the word =E2= =80=9Cname=E2=80=9D was in >>> my statement =E2=80=9CDefine that an event name can be used as a top-le= vel claim=E2=80=9D. >>> What I was trying to get at is was that if =E2=80=9C >>> http://specs.openid.net/logout=E2=80=9D is used as an event name, that = it can >>> also be used as a claim name in the JWT containing information about th= e >>> event. (Maybe I=E2=80=99m not using the correct terminology, hence the= unintended >>> confusion J.) >>> >>> >>> >>> Thanks again, >>> >>> -- Mike >>> >>> >>> >>> *From:* Phil Hunt [mailto:phil.hunt@oracle.com] >>> *Sent:* Tuesday, August 9, 2016 12:07 PM >>> *To:* Mike Jones >>> *Cc:* id-event@ietf.org >>> *Subject:* Re: [Id-event] Summarizing recent discussions on ID-Event >>> token draft >>> >>> >>> >>> I didn=E2=80=99t cover this as I didn=E2=80=99t want to confuse people = with too many >>> things. >>> >>> >>> >>> But I think we agree on all of the below. >>> >>> >>> >>> I=E2=80=99m not sure that we need a =E2=80=9Cname=E2=80=9D. What is you= r intention there. >>> >>> >>> >>> Phil >>> >>> >>> >>> @independentid >>> >>> www.independentid.com >>> >>> phil.hunt@oracle.com >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Aug 9, 2016, at 11:54 AM, Mike Jones >>> wrote: >>> >>> >>> >>> Thanks for writing this, Phil. Unfortunately, the summary below does >>> not include my feedback, which at the essence, is to keep the ID Events >>> data structure as simple and general-purpose as possible. (I strongly >>> believe that JWT is the success it is because we made JWT as simple and >>> general-purpose as possible, and we should follow this successful examp= le >>> and do the same here.) >>> >>> >>> >>> I believe that the ID Events spec needs to include these things, and >>> these things only: >>> >>> =C2=B7 Define of the =E2=80=9Cevents=E2=80=9D claim >>> >>> =C2=B7 Define that an event name can be used as a top-level claim >>> >>> =C2=B7 Require that =E2=80=9Ciss=E2=80=9D be included and that th= e JWT be signed by >>> the issuer >>> >>> =C2=B7 Include a statement along the lines of =E2=80=9CThe claims= to be >>> included with any particular event are to be defined by the event=E2=80= =9D >>> >>> >>> >>> And I=E2=80=99d stop there. >>> >>> >>> >>> It should be entirely up to applications to say what claims are include= d >>> with events they define and what their format and meanings are. Then t= he >>> ID Events spec will be as general-purpose as possible, with it being >>> natural for it to be used in essentially all JSON Event contexts. >>> >>> >>> >>> As soon as we start putting restrictions on the use of particular claim= s >>> by events, we=E2=80=99re making the ID Events spec less general-purpose= and less >>> natural to use. In particular, the only thing that the spec should say >>> about the =E2=80=9Csub=E2=80=9D claim is that =E2=80=9CLike all other c= laims other than =E2=80=98events=E2=80=99 >>> and =E2=80=98iss=E2=80=99, whether the =E2=80=98sub=E2=80=99 claim is t= o be included with an event is >>> entirely event-specific. The claims to be included with any particular >>> event are explicitly outside the scope of this specification.=E2=80=9D >>> >>> >>> >>> -- Mike >>> >>> >>> >>> *From:* Id-event [mailto:id-event-bounces@ietf.org] *On Behalf Of *Phil >>> Hunt >>> *Sent:* Tuesday, August 9, 2016 10:19 AM >>> *To:* id-event@ietf.org >>> *Subject:* [Id-event] Summarizing recent discussions on ID-Event token >>> draft >>> >>> >>> >>> I thought I would update the list on some discussions that have been >>> happening over in the OpenID Connect and RISC working groups conference >>> calls. >>> >>> >>> >>> These discussions have been about the core spec and the role of >>> =E2=80=9Ctop-level=E2=80=9D attributes vs. event =E2=80=9Cextension=E2= =80=9D attributes. >>> >>> See: https://tools.ietf.org/html/draft-hunt-idevent-token-01 >>> >>> >>> >>> In particular should =E2=80=9Csub=E2=80=9D be used in the top level to = =E2=80=9Cpoint=E2=80=9D to the >>> subject (in the broader english sense) of the event, or should it be >>> constrained to the SAML/ID Token definition which is the authenticated >>> user. >>> >>> >>> >>> Taken in the narrower definition, it is important to observe that in an >>> ID Token, =E2=80=9Csub=E2=80=9D and =E2=80=9Ciss=E2=80=9D go together. = The issuer provides the context for >>> the authenticated subject identifier. The problem with events, is that = it >>> might not be the AS (or OP) which is issuing the event. >>> >>> >>> >>> To summarize a fair amount of discussion, the feeling seems to be the >>> following: >>> >>> >>> >>> * The Event Token top level attributes should be fairly limited and no= t >>> include the sub attribute. >>> >>> * For events that are about a user, the relevant event specification >>> may include a =E2=80=9Csub=E2=80=9D attribute within the event=E2=80=99= s sub-object and not in the >>> top-level. Further that sub-object can also include the issuer of the u= ser. >>> >>> >>> * The top-level =E2=80=9Ciss=E2=80=9D shall mean the issuer of the even= t where the state >>> change occurred. >>> >>> * =E2=80=9Csub=E2=80=9D should not be present in the top level structu= re. Also, >>> =E2=80=9Cevents=E2=80=9D must also be present. >>> >>> >>> >>> Here would be a new example logout: >>> >>> { >>> >>> <=E2=80=94 top level is about the event itself -> >>> >>> "iss": "https://server.example.com", >>> >>> "aud": "s6BhdRkqt3", >>> >>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>> >>> "iat": 1458668180, >>> >>> "exp": 1458668580, >>> >>> "events": [ >>> >>> "https://specs.openid.net/logout" >>> >>> ], >>> >>> "https://specs.openid.net/logout": { >>> >>> <- This level is defined entirely by the event URI-> >>> >>> "iss": "https://oidc.example.com", >>> >>> =E2=80=9Cjti": "08a5019c-17e1-4977-8f42-65a12843ea02=E2=80=9D, >>> >>> "sub": "248289761001=E2=80=9D, >>> >>> =E2=80=9Cexp=E2=80=9D: >>> >>> } >>> >>> } >>> >>> >>> >>> In the above example note that the =E2=80=9Cevent=E2=80=9D object can h= ave its own iss >>> and subject (sub or jti) that have meaning within the context of an Ope= nID >>> OP provider. The issuer of the event can be different (the top-level) = and >>> represents the entity that signs the event (if it is signed). >>> >>> >>> >>> The top-level attributes identify an individual event and are used to >>> validate the event (signing etc). Where as the nested object contains = all >>> of the data about the event and is defined by the profiling specificati= on >>> (e.g. a possible OpenID Logout Event spec). In this case, in OpenID, >>> logging out usually translates into revoking an ID Token. Thus the =E2= =80=9Cjti=E2=80=9D >>> for the ID token (08a5019c...843ea02) is included in the Logout object. >>> >>> >>> >>> Side note. Regarding =E2=80=9Clogout=E2=80=9D, it might be useful to i= nclude the expiry >>> of the ID Token in case the subscriber has not yet received an ID Token= . >>> This would let the subscriber know how long it needs to keep the revoca= tion >>> information for. IOW=E2=80=A6after the the ID Token is expired, the su= bscriber >>> would no longer need to track the revocation state. >>> >>> >>> >>> It is also good to observe that the =E2=80=9Caud=E2=80=9D at the top le= vel describes the >>> subscriber of the event. This may also be different then the original >>> audience of the ID Token. >>> >>> >>> >>> So to conclude. By making top-level attributes strictly about the event= s >>> own validation, and nested objects about the event, we avoid collisions= in >>> definitions such as the issuer of the event, vs. the original issuer of= a >>> security assertion. >>> >>> >>> >>> I hope I=E2=80=99ve gotten everyone=E2=80=99s feedback correct here. Le= ts continue to >>> discuss. I will revise the draft to follow the groups thinking here. >>> >>> >>> >>> Phil >>> >>> >>> >>> @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 >>> >>> >>> >>> _______________________________________________ >>> 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 >>> >>> --94eb2c192e74298e6e0539d04d8f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Can we step back and look at all the requirements mentione= d in this thread and see if we can simplify them:
1. Multiple events pe= r SET=C2=A0(Security Event Token).
2. SET issuer different from e= vent issuer.
3. Existing Id Token parsers must not confuse a SET = for an Id Token.
4. Nested token format.

4 is needed by 1.
4 can fulfill 3, if sub can be present only in= nested events.

I don't think 1 is really = needed, but with 4 it comes really easy.

A nested = format with sub only at event level seems to meet all the requirements.

Allowing different event specs to define top level cl= aims, like sub, is very problematic IMO because you can run into incompatib= le events. Same with requiring that all events in a single token must refer= to the same sub. This can lead to very complex and buggy publisher impleme= ntations.



Marius

On Thu, Aug 11, 2016 at 11:30 AM, Sarah Squi= re <sarah@engageidentity.com> wrote:

There are also rp-initiated use cases arou= nd suspected fraud, parallel authentication of a second factor, and issuanc= e of a consent receipt.


On Aug 11, 2016 1= 2:27 PM, "Phil Hunt (IDM)" <phil.hunt@oracle.com> wrote:
Sarah,
=

Good question!

Your use case i= s really the app initiated logout or logout within the context of a single = application.=C2=A0

If the app initiated front/ bac= kchannel you would be saying log user out of all sso sites for that OP.=C2= =A0

If instead, the app issued the event to the OP= , it would be saying the user was logged out of the app. Thus issuer is the= app. The OP may or may not take action depending on its policy.=C2=A0

We need to explore the use case.=C2=A0

<= /div>
Talking through use cases was part of my reluctance to rushing id= token without forming a wg.=C2=A0
=C2=A0
Phil

On Aug 1= 1, 2016, at 11:09 AM, Sarah Squire <sarah@engageidentity.com> wrote:

Are we including use case= s where the RP is the event issuer?


On Aug 11, 2016 1= 1:02 AM, "Mike Jones" <Michael.Jones@microsoft.com> wrote:

You=E2=80=99re aware that forcing =E2= =80=9Csub=E2=80=9D to be a URI is a breaking change for most implementation= s, right?=C2=A0 This is hardly a way to encourage adoption!

=C2=A0

The thing you wrote below that makes = me think that you=E2=80=99re thinking about the purpose of the ID Events sp= ec differently than me is this: =E2=80=9Cso that all event specs can use it=E2=80=9D.=C2=A0 The purpose of the logout = event *isn=E2=80=99t* for all event specs to use it.=C2=A0 It=E2=80= =99s for the logout use case to use it.=C2=A0 There=E2=80=99s no expectatio= n that events intended for one use case will even be comprehensible in other use cases because th= ey won=E2=80=99t understand the contents of the event.=C2=A0 We shouldn=E2= =80=99t drive any of the design by trying to achieve that unachievable goal= , since events will *always* contain information that=E2=80=99s specific to their use case.

=C2=A0

You=E2=80=99re making complexity argu= ments, whereas you=E2=80=99re also proposing more complex rules than I am (= at least as I see it).=C2=A0 Trying to restrict the use of =E2=80=9Csub=E2= =80=9D (or any other claims) is unneeded complexity.

=C2=A0

I understand that you see things diff= erently.=C2=A0 I hope you=E2=80=99ll nonetheless think about my argument th= at having fewer rules about claims usage in events will make them simpler.=C2=A0 I passionately care about keeping this simple, which i= s why I=E2=80=99m investing my time in this discussion.=C2=A0 If it=E2=80= =99s simple, it will likely get widely used.

=C2=A0

I=E2=80=99m going to sign out of the = discussion for now because my wife is about to get out of surgery.=C2=A0 I = hope you have a good day.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mi= ke

=C2=A0=

From: Phil Hunt [mailto:phil.hunt@oracle.com]
Sent: Thursday, August 11, 2016 12:49 PM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: John Bradley <ve7jtb@ve7jtb.com>; openid-specs-ab@lists.openid.net Ab <= openid-sp= ecs-ab@lists.openid.net>; id-event@ietf.org; Marius Scurtescu <mscurtescu@google.com>=
Subject: Re: [Id-event] Summarizing recent discussions on ID-Event t= oken draft

=C2=A0

Mike,=C2=A0

=C2=A0

Speaking as editor the format you propose ONLY works= if =E2=80=9Csub=E2=80=9D becomes a URI so that all event specs can use it.= =C2=A0 Otherwise, OIDC becomes a special case which really kills the point = of this work. It also makes the specification much much more complex. Maybe it is just me, but a complex spec generally implies co= mplex implementation too.

=C2=A0

If you want sub at the top level, that would mean th= at the OIDC spec format would have to look like:

{

=C2=A0 "iss": "https://event.example.com",

=C2=A0 "aud": "s6BhdRkqt3",

=C2=A0 "jti": "3d0c3cf797584bd193bd0f= b1bd4e7d30",

=C2=A0 "sub"= : =E2=80=9Chttps://token.example.com/248289761001",=

=C2=A0 "iat": 1458668180,

=C2=A0 "exp": 1458668580,

=C2=A0 "events": [

=C2=A0 ],

=C2=A0 "sid": "08a5019c-17e1-4977-8f4= 2-65a12843ea02"

}

=C2=A0

Given that events are signed (or should be), I wi= ll object strongly within the OIDF that the event issuer and the token issu= er MUST be the same or that OIDF adopt a different format. Yes having i= ss be the same is a nice security convenience, but it imposes the architecture restriction that it be the sa= me server.=C2=A0 At scale, delivery of events may become a problem for larg= e scale providers if they are also delivering tokens to relying parties. Th= e restriction isn=E2=80=99t really justified given the crypto alternative =E2=80=94 which was the whole point of using = JWT in the first place.

=C2=A0

Per Justin=E2=80=99s comment, it seems elegant/trivi= al that a logout event simply has logout at the top level and an ID Token a= ttached (though it might convey a lot of unneeded claims).=C2=A0 IMO, the O= IDC logout spec should only convey the ID Token JTI.=C2=A0 It is going to be rare that you log out all devices for a user.= =C2=A0 To most users, it means clear SSO within this browser only!=C2=A0 On= e can argue that clearing all devices/sessions is a different event entirel= y. It is an account reset or lock-out action.

=C2=A0

=C2=A0

=C2=A0

See my previous message, John, which = was a reply to Phil=E2=80=99s message that you also replied to, that contai= ned a logout claims example.=C2=A0 I=E2=80=99m not proposing to special-cas= e the Connect Logout message in any way.=C2=A0 The =E2=80=9Ciss=E2=80=9D is = the event issuer.=C2=A0 The other claims in the message are those defined b= y the event to be included, just like those for any other event.=C2=A0 Yes,= the logout message doesn=E2=80=99t include a second issuer, a second subje= ct, an ID Token as a claim, or anything else complicated like that, because th= ose things aren=E2=80=99t needed for the logout use case.<= /u>

=C2=A0

As I=E2=80=99d written previously, th= e ID Events spec should define the =E2=80=9Cevents=E2=80=9D claim, how to u= se an event name as a claim (when needed), and say that the event JWT must be signed by the issuer, and stop there.=C2=A0 Trying to micro-manage= claims usage within an event will only result in the ID Events spec being = harder to use.=C2=A0 If we=E2=80=99d tried to similarly micro-manage JWT cl= aims usage, JWT would likely not have been the success that it is.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mi= ke

=C2=A0

From:=C2=A0John Bradley [mailto:ve7jtb@ve7jtb.com]=C2=A0
Sent:=C2=A0Thursday, August 11, 2016 12:22 PM
To:=C2=A0Phil Hunt (IDM) <phil.hunt@oracle.com>
Cc:=C2=A0Mike Jones <Michael.Jones@microsoft.com<= /a>>; id-event@ietf.org; Marius Scurtescu <mscurtescu@google.com= >; openid-specs-ab@lists.openid.net Ab <openid-specs-ab@list= s.openid.net>
Subject:=C2=A0Re: [Id-event] Summarizing recent discuss= ions on ID-Event token draft

=C2=A0

Not surprisingly a multipurpose message format will = not be as optimized as a single purpose one.

=C2=A0

Connect itself doesn=E2=80=99t really have a conflic= t around issuer the same entity sending the logout message is always the on= e that created the id_token that it refers to.

=C2=A0

Using the same format as id_token with the same sema= ntics to identify the thing to be terminated makes sense from a purely open= ID Connect point of view.

=C2=A0

Oter messages that have different notions of subject= and are issued by different parties than the one that controls the subject= cause issues when you try and fit them into the same format as an ID_Token= , I grant you that.

=C2=A0

It was mentioned that we need to differentiate betwe= en these events and id_tokens.=C2=A0 Mostly we need to do that in cases whe= re the token might be presented in the front channel.

=C2=A0

To do that se do have mandatory claims for nonce and= c_hash or at_hash as well as the addition of events parameter to reduce co= nfusion. =C2=A0 Now I admit that some people may still get that wrong, =C2= =A0and the removal of sub from the top level would remove any concern.=C2=A0 However Mike has a point that adoption may= be hurt if we change the semantics too much.

=C2=A0

I don=E2=80=99t see backchannel single logout being = used by many social login RP, it is a lot of work to maintain server side s= tate. =C2=A0 It is mostly an enterprise and large site sort of feature.<= /u>

That may or may not impact on if it is better to be = simple and aligned with connect=E2=80=99s id token or more general purpose = to fit with other enterprise to SaaS features like SCIM events.

=C2=A0

I think the two directions lead to different formats= . =C2=A0=C2=A0

=C2=A0

The compromise of special casing Connect SLO and bod= ging the formats together is probably the worst option.

=C2=A0

John B.

=C2=A0

=C2=A0

On Aug 11, 2016, at 11:59 AM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:=

=C2=A0

How do you resolve conflicts on iss then?=C2=A0 Th= e top level has to be the issuer of the event as the issuer signs.=C2=A0

=C2=A0

If one spec can use it all must be able to. I beli= eve you previously objected to that saying sub must be as how id tokens def= ine them. But that isnt unique and requires iss. Now we would have sub at the top with an event issuer at the top and a sub= issuer in the extension. That seems incredibly complex not to mention awkw= ard.=C2=A0

=C2=A0

If we make sub a uri for all then it can work ass = iss from id token would not be needed. But i can see many objecting to the = change in format.=C2=A0

=C2=A0

Why not have a logout be an event with an id token= attached for example?


Phil


On Aug 11, 2016, at 8:03 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

The simple rule is that if the partic= ular event calls for the =E2=80=9Csub=E2=80=9D claim to be at the top level= , then it is.=C2=A0 This is no different from any other claim that an event might place at the top level.

=C2=A0

The complexity arises if =E2=80=9Csub= =E2=80=9D is unnecessarily special-cased.=C2=A0 We shouldn=E2=80=99t do tha= t, because it limits the applicability of the specification.<= 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 -- Mi= ke

=C2=A0

From:=C2=A0Phil Hunt (IDM) [mailto:phil.hunt@oracle.com]=C2=A0
Sent:=C2=A0Thursday, August 11, 2016 9:40 AM
To:=C2=A0Mike Jones <Michael.Jones@microsoft.com>
Cc:=C2=A0Marius Scurtescu <mscurtescu@google.com>;=C2=A0id-event@ietf.org
Subject:=C2=A0Re: [Id-event] Summarizing recent discuss= ions on ID-Event token draft

=C2=A0

I think using sub at the top level leads to complexi= ty. Eg Can you provide a rule for when top level is used or not by an indiv= idual spec?=C2=A0 IMO. Top level should always be used the same way by all = implementers.=C2=A0

=C2=A0

Based on the calls at risc/connect, we discussed tha= t it would be best to move all event specifics to the event object area. Th= is way different events can have different event addressing (eg sub/iss, ur= i, jit/iss). When iss is needed to uniquely qualify a sub, it can be provided without conflicting with the is= suer of the event. Similarly jti and iss can be used for a revoked token wi= thout conflicting with the event jti.=C2=A0

=C2=A0

I plan to post a new draft shortly that will give so= me examples based on feedback from the openid risc/connect discussions.<= /u>

=C2=A0

We can always change again.=C2=A0


Phil


On Aug 11, 2016, at 4:54 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

No, I=E2=80=99m not saying that =E2= =80=9Csub=E2=80=9D cannot appear at the top level.=C2=A0 I=E2=80=99m saying= that =E2=80=9Csub=E2=80=9D will only occur at the top level if the particu= lar event defines that =E2=80=9Csub=E2=80=9D is used in that way for that event.

=C2=A0

There are probably use cases for mult= iple events per message but I doubt there are use cases for multiple *un= related* events per message.=C2=A0 By definition, related events that use top-level claims would need to use them in a compa= tible way.=C2=A0 I don=E2=80=99t see that as being a problem.=

=C2=A0

That being said, the predominant use = case is likely to be a single event per JWT.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=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=A0Mari= us Scurtescu [mailto:mscurtescu@google.com]=C2=A0
Sent:=C2=A0Tuesday, August 9, 2016 7:15 PM
To:=C2=A0Phil Hunt <= phil.hunt@oracle.com>
Cc:=C2=A0Mike Jones <Michael.Jones@microsoft.com>;=C2=A0id-event@ietf.org
Subject:=C2=A0Re: [Id-event] Summarizing recent discuss= ions on ID-Event token draft

=C2=A0

Mike, are you suggesting that a sub claim can only s= how up at the event level and not at the top level:

=C2=A0

In particular, the only thing that the spec should s= ay about the =E2=80=9Csub=E2=80=9D claim is that =E2=80=9CLike all other cl= aims other than =E2=80=98events=E2=80=99 and =E2=80=98iss=E2=80=99, whether= the =E2=80=98sub=E2=80=99 claim is to be included with an event is entirel= y event-specific.

=C2=A0

A top level sub and multiple events are incompatible= IMO.

=C2=A0

Do we have a compelling reason to support multiple e= vents per message?

=C2=A0


Marius

=C2=A0

On Tue, Aug 9, 2016 at 12:39 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

I was referring to this in your email<= /p>

"Define that an event name can b= e used as a top-level claim=E2=80=9D

=C2=A0

=C2=A0

Is this different from the event uri?<= /p>

=C2=A0

=C2=A0

=C2=A0

=C2=A0<= /p>

=C2=A0

On Aug 9, 2016, at 12:12 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

=C2=A0

I=E2=80=99m glad to hear that we agre= e on keeping it as simple and general-purpose as possible and that you agre= e with my write-up.=C2=A0 I think we then have a good path forward.

=C2=A0

I=E2=80=99m not sure what you mean by= =E2=80=9CI=E2=80=99m not sure that we need a =E2=80=9Cname=E2=80=9D= . What is your intention there.=E2=80=9D=C2=A0 The only place I used the word =E2=80=9Cname=E2=80=9D was in my statement = =E2=80=9CDefine that an event name can be used as a top-level claim=E2=80= =9D.=C2=A0 What I was trying to get at is was that if =E2=80=9Chttp://specs.openid.net/logout=E2=80=9D is used as an event name, that it can also be used as a claim name in the = JWT containing information about the event.=C2=A0 (Maybe I=E2=80=99m not us= ing the correct terminology, hence the unintended confusion=C2=A0J.)

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Thank= s again,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mi= ke

From:=C2=A0Phil Hunt [mailto:phil.hunt@oracle.com]=C2=A0
Sent:=C2=A0Tuesday, August 9, 2016 12:07 PM
To:=C2=A0Mike Jones <Michael.Jones@microsoft.com>
Cc:=C2=A0id-event@ietf.= org
Subject:=C2=A0Re: [Id-event] Summarizing recent discuss= ions on ID-Event token draft

=C2=A0

I didn=E2=80=99t cover this as I didn=E2=80=99t want= to confuse people with too many things.

=C2=A0

But I think we agree on all of the below.<= /u>

=C2=A0

I=E2=80=99m not sure that we need a =E2=80=9Cname=E2= =80=9D. What is your intention there.

=C2=A0

=C2=A0

=C2=A0

=C2=A0<= /p>

=C2=A0

On Aug 9, 2016, at 11:54 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

=C2=A0

Thanks for writing this, Phil.=C2=A0 = Unfortunately, the summary below does not include my feedback, which at the= essence, is to keep the ID Events data structure as simple and general-purpose as possible. =C2=A0(I strongly believe that JWT= is the success it is because we made JWT as simple and general-purpose as = possible, and we should follow this successful example and do the same here= .)

=C2=A0

I believe that the ID Events spec nee= ds to include these things, and these things only:

=C2=B7= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Define of the =E2=80=9Cevents=E2=80=9D claim

=C2=B7= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Define that an event name can be used as a top-level claim

=C2=B7= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Require that =E2=80=9Ciss=E2=80=9D be included and that the JWT be signed by the i= ssuer

=C2=B7= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Include a statement along the lines of =E2=80=9CThe claims to be included with any= particular event are to be defined by the event=E2=80=9D<= /u>

=C2=A0

And I=E2=80=99d stop there.=

=C2=A0

It should be entirely up to applicati= ons to say what claims are included with events they define and what their = format and meanings are.=C2=A0 Then the ID Events spec will be as general-purpose as possible, with it being natural for it to be= used in essentially all JSON Event contexts.

=C2=A0

As soon as we start putting restricti= ons on the use of particular claims by events, we=E2=80=99re making the ID = Events spec less general-purpose and less natural to use.=C2=A0 In particular, the only thing that the spec should say about the =E2=80=9C= sub=E2=80=9D claim is that =E2=80=9CLike all other claims other than =E2=80= =98events=E2=80=99 and =E2=80=98iss=E2=80=99, whether the =E2=80=98sub=E2= =80=99 claim is to be included with an event is entirely event-specific.=C2= =A0 The claims to be included with any particular event are explicitly outside the scope of this specification.= =E2=80=9D

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mi= ke

=C2=A0

From:=C2=A0Id-e= vent [mailto:id-event-bounces@ietf.org]=C2=A0On Behalf Of=C2=A0Phil Hunt
Sent:=C2=A0Tuesday, August 9, 2016 10:19 AM
To:=C2=A0id-event@ietf.= org
Subject:=C2=A0[Id-event] Summarizing recent discussions= on ID-Event token draft

=C2=A0

I thought I would update the list on some discussion= s that have been happening over in the OpenID Connect and RISC working grou= ps conference calls.

=C2=A0

These discussions have been about the core spec and = the role of =E2=80=9Ctop-level=E2=80=9D attributes vs. event =E2=80=9Cexten= sion=E2=80=9D attributes.=C2=A0

=C2=A0

In particular should =E2=80=9Csub=E2=80=9D be used i= n the top level to =E2=80=9Cpoint=E2=80=9D to the subject (in the broader e= nglish sense) of the event, or should it be constrained to the SAML/ID Toke= n definition which is the authenticated user. =C2=A0

=C2=A0

Taken in the narrower definition, it is important to= observe that in an ID Token, =E2=80=9Csub=E2=80=9D and =E2=80=9Ciss=E2=80= =9D go together.=C2=A0 The issuer provides the context for the authenticate= d subject identifier. The problem with events, is that it might not be the AS (or OP) which is issuing the event. =C2=A0

=C2=A0

To summarize a fair amount of discussion, the feelin= g seems to be the following:

=C2=A0

* =C2=A0The Event Token top level attributes should = be fairly limited and not include the sub attribute. =C2=A0

* =C2=A0For events that are about a user, the releva= nt event specification may include a =E2=80=9Csub=E2=80=9D attribute within= the event=E2=80=99s sub-object and not in the top-level. Further that sub-= object can also include the issuer of the user. =C2=A0

* The top-level =E2=80=9Ciss=E2=80=9D shall mean the= issuer of the event where the state change occurred.

* =C2=A0=E2=80=9Csub=E2=80=9D should not be present = in the top level structure.=C2=A0 Also, =E2=80=9Cevents=E2=80=9D must also = be present.

=C2=A0

Here would be a new example logout: 

{
=C2=A0 <=E2=80=94 top level is about the event itself -><=
u>
=C2=A0 "iss": "https://server.example.com",
=C2=A0 "aud": "s6BhdRkqt3=
",
=C2=A0 "jti": "3d0c3cf797=
584bd193bd0fb1bd4e7d30",
=C2=A0 "iat": 1458668180,
=C2=A0 "exp": 1458668580,
=C2=A0 "events": [
=C2=A0=C2=A0=C2=A0 "https://specs.openid.net/logout"
=C2=A0 ],
 =C2=A0"https://specs.openid.net/logout": {=

=C2=A0=C2=A0=C2=A0 <- This level is d=
efined entirely by the event URI->
=C2=A0=C2=A0=C2=A0 "iss": &quo=
t;https://oidc.example.com"=
,
=C2=A0=C2=A0=C2=A0 =E2=80=9Cjti": &=
quot;08a5019c-17e1-4977-8f42-65a12843ea02=E2=80=9D,
=C2=A0=C2=A0=C2=A0 &quo=
t;sub": "248289761001=E2=80=9D,
=C2=A0=C2=A0=C2=A0 =E2=
=80=9Cexp=E2=80=9D: <ID token expiry>
=C2=A0 }<=
u>
}

=C2=A0

In the above example note that the =E2=80=9Cevent=E2= =80=9D object can have its own iss and subject (sub or jti) that have meani= ng within the context of an OpenID OP provider.=C2=A0 The issuer of the eve= nt can be different (the top-level) and represents the entity that signs the event (if it is signed).

=C2=A0

The top-level attributes identify an individual even= t and are used to validate the event (signing etc).=C2=A0 Where as the nest= ed object contains all of the data about the event and is defined by the pr= ofiling specification (e.g. a possible OpenID Logout Event spec).=C2=A0 In this case, in OpenID, logging out usua= lly translates into revoking an ID Token. Thus the =E2=80=9Cjti=E2=80=9D fo= r the ID token (08a5019c...843ea02) is included in the Logout object.

=C2=A0

Side note.=C2=A0 Regarding =E2=80=9Clogout=E2=80=9D,= it might be useful to include the expiry of the ID Token in case the subsc= riber has not yet received an ID Token. This would let the subscriber know = how long it needs to keep the revocation information for.=C2=A0 IOW=E2=80=A6after the the ID Token is expired, the subscriber would no lon= ger need to track the revocation state.

=C2=A0

It is also good to observe that the =E2=80=9Caud=E2= =80=9D at the top level describes the subscriber of the event.=C2=A0 This m= ay also be different then the original audience of the ID Token.<= /u>

=C2=A0

So to conclude. By making top-level attributes stric= tly about the events own validation, and nested objects about the event, we= avoid collisions in definitions such as the issuer of the event, vs. the o= riginal issuer of a security assertion.

=C2=A0

I hope I=E2=80=99ve gotten everyone=E2=80=99s feedba= ck correct here. Lets continue to discuss. I will revise the draft to follo= w the groups thinking here.

=C2=A0

=C2=A0

_____________________________________________= __
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-even= t

=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

_____________________________________________= __
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.iet= f.org/mailman/listinfo/id-event


--94eb2c192e74298e6e0539d04d8f-- From nobody Thu Aug 11 12:03:46 2016 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 2BBB912D8D1 for ; Thu, 11 Aug 2016 12:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.446 X-Spam-Level: X-Spam-Status: No, score=-5.446 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247, 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 K8PZNezrd0aN for ; Thu, 11 Aug 2016 12:03:40 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (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 1C59B12D8FE for ; Thu, 11 Aug 2016 12:03:39 -0700 (PDT) X-AuditID: 12074423-21fff70000007eab-69-57accc09dd39 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 (Symantec Messaging Gateway) with SMTP id E6.A1.32427.90CCCA75; Thu, 11 Aug 2016 15:03:38 -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 u7BJ3aOH025859; Thu, 11 Aug 2016 15:03:36 -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 u7BJ3Yg4031936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 11 Aug 2016 15:03:35 -0400 To: Marius Scurtescu , Sarah Squire References: <14E2EF51-7123-4E91-87DD-56AEA08202C1@oracle.com> <3F0DD3E6-46CD-4AA5-8F06-F79140F5D4BE@oracle.com> <56E7DF06-EE77-4FD1-BF44-15A083AC5B5A@ve7jtb.com> <12274564-507F-492B-94E8-C65C6A84FDB7@oracle.com> <21751371-BD95-4C15-AE01-D42CF4815233@oracle.com> From: Justin Richer Message-ID: Date: Thu, 11 Aug 2016 15:03:31 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------465B8D1DD205662481BB16FD" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJKsWRmVeSWpSXmKPExsUixG6nost1Zk24wY2jTBYdC7qZLG6dXcNk ceXhD3aL3dsOsDuweMzYMYnFY8GmUo8lS34yeTzf2c8UwBLFZZOSmpNZllqkb5fAlXFxyTvm gjMz+Cq6ml8zNjA+m8nSxcjJISFgItF2+xxTFyMXh5BAG5PEimN3GCGcjYwSc9dcYYZwbjNJ bOq6yAjSIiyQJLHr/iZmEFtEIE5i5sUnrBBFb9klfuyazQaSYBaok3g/oQ/MZhNQlZi+pgVo BwcHr4CVxJJj5iBhFqDw75mHGUHCogIxEuv7EkDCvAKCEidnPgG7jlMgUKLr8hsWiIlhEq+X dTBOYOSfhaRsFpIUhG0rcWfubmYIW16ieetsKFtXYtG2FezI4gsY2VYxyqbkVunmJmbmFKcm 6xYnJ+blpRbpmunlZpbopaaUbmIEx4CL8g7Gl33ehxgFOBiVeHg3LF0TLsSaWFZcmXuIUZKD SUmUd9sBoBBfUn5KZUZicUZ8UWlOavEhRgkOZiUR3vmHgHK8KYmVValF+TApaQ4WJXHe7d/a w4UE0hNLUrNTUwtSi2CyMhwcShK8n04BNQoWpaanVqRl5pQgpJk4OEGG8wANlzoNMry4IDG3 ODMdIn+KUVFKnPcOSLMASCKjNA+uF5SiEt4eNn3FKA70ijDva5AqHmB6g+t+BTSYCWjwCTOw wSWJCCmpBkaREyeM1u1Qyjl884nGme+/WmR1rB+YrFnW+9CnuSE2zZzDQGPm+o8Zha0tn/MO dC3UzAtoNQ8VCVb6wHX7jtuZXwsFKvNKDh05pvb1knjw32WSirukO6fvlns4rSl36S57t4bP dlzOC+9v6ZQQKD+q97gs5i+L/6bfx3uNtnY4/Bd/8uTRmXtKLMUZiYZazEXFiQATsHsfLAMA AA== Archived-At: Cc: "openid-specs-ab@lists.openid.net Ab" , "id-event@ietf.org" Subject: Re: [Id-event] [Openid-specs-ab] Summarizing recent discussions on ID-Event token draft X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 11 Aug 2016 19:03:45 -0000 This is a multi-part message in MIME format. --------------465B8D1DD205662481BB16FD Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit +1 to this. I'd also add that the "pass through" logic I mentioned in the other email fits this as well. Basically, if my event *doesn't* have a "sub", then I assume it's the same "sub" as the root object. But the lower level would always shadow the upper one, in the context of the event itself. This is of course an optimization, but it allows for the kind of structures like Mike is talking about without things getting overly weird for the general case. -- Justin On 8/11/2016 2:54 PM, Marius Scurtescu via Openid-specs-ab wrote: > Can we step back and look at all the requirements mentioned in this > thread and see if we can simplify them: > 1. Multiple events per SET (Security Event Token). > 2. SET issuer different from event issuer. > 3. Existing Id Token parsers must not confuse a SET for an Id Token. > 4. Nested token format. > > 4 is needed by 1. > 4 can fulfill 3, if sub can be present only in nested events. > > I don't think 1 is really needed, but with 4 it comes really easy. > > A nested format with sub only at event level seems to meet all the > requirements. > > Allowing different event specs to define top level claims, like sub, > is very problematic IMO because you can run into incompatible events. > Same with requiring that all events in a single token must refer to > the same sub. This can lead to very complex and buggy publisher > implementations. > > > > Marius > > On Thu, Aug 11, 2016 at 11:30 AM, Sarah Squire > > wrote: > > There are also rp-initiated use cases around suspected fraud, > parallel authentication of a second factor, and issuance of a > consent receipt. > > > On Aug 11, 2016 12:27 PM, "Phil Hunt (IDM)" > wrote: > > Sarah, > > Good question! > > Your use case is really the app initiated logout or logout > within the context of a single application. > > If the app initiated front/ backchannel you would be saying > log user out of all sso sites for that OP. > > If instead, the app issued the event to the OP, it would be > saying the user was logged out of the app. Thus issuer is the > app. The OP may or may not take action depending on its policy. > > We need to explore the use case. > > Talking through use cases was part of my reluctance to rushing > id token without forming a wg. > > Phil > > On Aug 11, 2016, at 11:09 AM, Sarah Squire > > > wrote: > >> Are we including use cases where the RP is the event issuer? >> >> >> On Aug 11, 2016 11:02 AM, "Mike Jones" >> > > wrote: >> >> You’re aware that forcing “sub” to be a URI is a breaking >> change for most implementations, right? This is hardly a >> way to encourage adoption! >> >> The thing you wrote below that makes me think that you’re >> thinking about the purpose of the ID Events spec >> differently than me is this: “so that all event specs can >> use it”. The purpose of the logout event **isn’t** for >> all event specs to use it. It’s for the logout use case >> to use it. There’s no expectation that events intended >> for one use case will even be comprehensible in other use >> cases because they won’t understand the contents of the >> event. We shouldn’t drive any of the design by trying to >> achieve that unachievable goal, since events will >> **always** contain information that’s specific to their >> use case. >> >> You’re making complexity arguments, whereas you’re also >> proposing more complex rules than I am (at least as I see >> it). Trying to restrict the use of “sub” (or any other >> claims) is unneeded complexity. >> >> I understand that you see things differently. I hope >> you’ll nonetheless think about my argument that having >> fewer rules about claims usage in events will make them >> simpler. I passionately care about keeping this simple, >> which is why I’m investing my time in this discussion. >> If it’s simple, it will likely get widely used. >> >> I’m going to sign out of the discussion for now because >> my wife is about to get out of surgery. I hope you have >> a good day. >> >> -- Mike >> >> *From:*Phil Hunt [mailto:phil.hunt@oracle.com >> ] >> *Sent:* Thursday, August 11, 2016 12:49 PM >> *To:* Mike Jones > > >> *Cc:* John Bradley > >; openid-specs-ab@lists.openid >> .net Ab >> > .net>; >> id-event@ietf.org ; Marius >> Scurtescu > > >> *Subject:* Re: [Id-event] Summarizing recent discussions >> on ID-Event token draft >> >> Mike, >> >> Speaking as editor the format you propose ONLY works if >> “sub” becomes a URI so that all event specs can use it. >> Otherwise, OIDC becomes a special case which really kills >> the point of this work. It also makes the specification >> much much more complex. Maybe it is just me, but a >> complex spec generally implies complex implementation too. >> >> If you want sub at the top level, that would mean that >> the OIDC spec format would have to look like: >> >> { >> >> "iss": "https://event.example.com", >> >> "aud": "s6BhdRkqt3", >> >> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >> >> "sub": “https://token.example.com/248289761001", >> >> "iat": 1458668180, >> >> "exp": 1458668580, >> >> "events": [ >> >> "https://specs.openid.net/logout" >> >> ], >> >> "sid": "08a5019c-17e1-4977-8f42-65a12843ea02" >> >> } >> >> Given that events are signed (or should be), _I will >> object strongly within the OIDF that the event issuer and >> the token issuer MUST be the same or that OIDF adopt a >> different format_. Yes having iss be the same is a nice >> security convenience, but it imposes the architecture >> restriction that it be the same server. At scale, >> delivery of events may become a problem for large scale >> providers if they are also delivering tokens to relying >> parties. The restriction isn’t really justified given the >> crypto alternative — which was the whole point of using >> JWT in the first place. >> >> Per Justin’s comment, it seems elegant/trivial that a >> logout event simply has logout at the top level and an ID >> Token attached (though it might convey a lot of unneeded >> claims). IMO, the OIDC logout spec should only convey >> the ID Token JTI. It is going to be rare that you log >> out all devices for a user. To most users, it means >> clear SSO within this browser only! One can argue that >> clearing all devices/sessions is a different event >> entirely. It is an account reset or lock-out action. >> >> Phil >> >> @independentid >> >> www.independentid.com >> >> phil.hunt@oracle.com >> >> On Aug 11, 2016, at 9:32 AM, Mike Jones >> wrote: >> >> See my previous message, John, which was a reply to >> Phil’s message that you also replied to, that >> contained a logout claims example. I’m not proposing >> to special-case the Connect Logout message in any >> way. The “iss” is the event issuer. The other claims >> in the message are those defined by the event to be >> included, just like those for any other event. Yes, >> the logout message doesn’t include a second issuer, a >> second subject, an ID Token as a claim, or anything >> else complicated like that, because those things >> aren’t needed for the logout use case. >> >> As I’d written previously, the ID Events spec should >> define the “events” claim, how to use an event name >> as a claim (when needed), and say that the event JWT >> must be signed by the issuer, and stop there. Trying >> to micro-manage claims usage within an event will >> only result in the ID Events spec being harder to >> use. If we’d tried to similarly micro-manage JWT >> claims usage, JWT would likely not have been the >> success that it is. >> >> -- Mike >> >> *From:*John Bradley [mailto:ve7jtb@ve7jtb.com] >> *Sent:*Thursday, August 11, 2016 12:22 PM >> *To:*Phil Hunt (IDM) >> *Cc:*Mike Jones ; >> id-event@ietf.org; Marius Scurtescu >> ; >> openid-specs-ab@lists.openid.net Ab >> >> *Subject:*Re: [Id-event] Summarizing recent >> discussions on ID-Event token draft >> >> Not surprisingly a multipurpose message format will >> not be as optimized as a single purpose one. >> >> Connect itself doesn’t really have a conflict around >> issuer the same entity sending the logout message is >> always the one that created the id_token that it >> refers to. >> >> Using the same format as id_token with the same >> semantics to identify the thing to be terminated >> makes sense from a purely openID Connect point of view. >> >> Oter messages that have different notions of subject >> and are issued by different parties than the one that >> controls the subject cause issues when you try and >> fit them into the same format as an ID_Token, I grant >> you that. >> >> It was mentioned that we need to differentiate >> between these events and id_tokens. Mostly we need to >> do that in cases where the token might be presented >> in the front channel. >> >> To do that se do have mandatory claims for nonce and >> c_hash or at_hash as well as the addition of events >> parameter to reduce confusion. Now I admit that some >> people may still get that wrong, and the removal of >> sub from the top level would remove any concern. >> However Mike has a point that adoption may be hurt if >> we change the semantics too much. >> >> I don’t see backchannel single logout being used by >> many social login RP, it is a lot of work to maintain >> server side state. It is mostly an enterprise and >> large site sort of feature. >> >> That may or may not impact on if it is better to be >> simple and aligned with connect’s id token or more >> general purpose to fit with other enterprise to SaaS >> features like SCIM events. >> >> I think the two directions lead to different formats. >> >> The compromise of special casing Connect SLO and >> bodging the formats together is probably the worst >> option. >> >> John B. >> >> On Aug 11, 2016, at 11:59 AM, Phil Hunt (IDM) >> wrote: >> >> How do you resolve conflicts on iss then? The >> top level has to be the issuer of the event as >> the issuer signs. >> >> If one spec can use it all must be able to. I >> believe you previously objected to that saying >> sub must be as how id tokens define them. But >> that isnt unique and requires iss. Now we would >> have sub at the top with an event issuer at the >> top and a sub issuer in the extension. That seems >> incredibly complex not to mention awkward. >> >> If we make sub a uri for all then it can work ass >> iss from id token would not be needed. But i can >> see many objecting to the change in format. >> >> Why not have a logout be an event with an id >> token attached for example? >> >> >> Phil >> >> >> On Aug 11, 2016, at 8:03 AM, Mike Jones >> wrote: >> >> The simple rule is that if the particular >> event calls for the “sub” claim to be at the >> top level, then it is. This is no different >> from any other claim that an event might >> place at the top level. >> >> The complexity arises if “sub” is >> unnecessarily special-cased. We shouldn’t do >> that, because it limits the applicability of >> the specification. >> >> -- Mike >> >> *From:*Phil Hunt (IDM) >> [mailto:phil.hunt@oracle.com] >> *Sent:*Thursday, August 11, 2016 9:40 AM >> *To:*Mike Jones >> *Cc:*Marius Scurtescu >> ;id-event@ietf.org >> *Subject:*Re: [Id-event] Summarizing recent >> discussions on ID-Event token draft >> >> I think using sub at the top level leads to >> complexity. Eg Can you provide a rule for >> when top level is used or not by an >> individual spec? IMO. Top level should >> always be used the same way by all implementers. >> >> Based on the calls at risc/connect, we >> discussed that it would be best to move all >> event specifics to the event object area. >> This way different events can have different >> event addressing (eg sub/iss, uri, jit/iss). >> When iss is needed to uniquely qualify a sub, >> it can be provided without conflicting with >> the issuer of the event. Similarly jti and >> iss can be used for a revoked token without >> conflicting with the event jti. >> >> I plan to post a new draft shortly that will >> give some examples based on feedback from the >> openid risc/connect discussions. >> >> We can always change again. >> >> >> Phil >> >> >> On Aug 11, 2016, at 4:54 AM, Mike Jones >> wrote: >> >> No, I’m not saying that “sub” cannot >> appear at the top level. I’m saying that >> “sub” will only occur at the top level if >> the particular event defines that “sub” >> is used in that way for that event. >> >> There are probably use cases for multiple >> events per message but I doubt there are >> use cases for multiple **unrelated** >> events per message. By definition, >> related events that use top-level claims >> would need to use them in a compatible >> way. I don’t see that as being a problem. >> >> That being said, the predominant use case >> is likely to be a single event per JWT. >> >> -- Mike >> >> *From:*Marius Scurtescu >> [mailto:mscurtescu@google.com] >> *Sent:*Tuesday, August 9, 2016 7:15 PM >> *To:*Phil Hunt >> *Cc:*Mike Jones >> ;id-event@ietf.org >> *Subject:*Re: [Id-event] Summarizing >> recent discussions on ID-Event token draft >> >> Mike, are you suggesting that a sub claim >> can only show up at the event level and >> not at the top level: >> >> In particular, the only thing that >> the spec should say about the “sub” >> claim is that “Like all other claims >> other than ‘events’ and ‘iss’, >> whether the ‘sub’ claim is to be >> included with an event is entirely >> event-specific. >> >> A top level sub and multiple events are >> incompatible IMO. >> >> Do we have a compelling reason to support >> multiple events per message? >> >> >> Marius >> >> On Tue, Aug 9, 2016 at 12:39 PM, Phil >> Hunt wrote: >> >> I was referring to this in your email >> >> "Define that an event name can be >> used as a top-level claim” >> >> Is this different from the event uri? >> >> Phil >> >> @independentid >> >> www.independentid.com >> >> phil.hunt@oracle.com >> >> On Aug 9, 2016, at 12:12 PM, Mike >> Jones >> wrote: >> >> I’m glad to hear that we agree on >> keeping it as simple and >> general-purpose as possible and >> that you agree with my write-up. >> I think we then have a good path >> forward. >> >> I’m not sure what you mean by >> “I’m not sure that we need a >> “name”. What is your intention >> there.” The only place I used the >> word “name” was in my statement >> “Define that an event name can be >> used as a top-level claim”. What >> I was trying to get at is was >> that if >> “http://specs.openid.net/logout” >> is used as an event name, that it >> can also be used as a claim name >> in the JWT containing information >> about the event. (Maybe I’m not >> using the correct terminology, >> hence the unintended confusionJ.) >> >> Thanks again, >> >> -- Mike >> >> *From:*Phil Hunt >> [mailto:phil.hunt@oracle.com] >> *Sent:*Tuesday, August 9, 2016 >> 12:07 PM >> *To:*Mike Jones >> >> *Cc:*id-event@ietf.org >> *Subject:*Re: [Id-event] >> Summarizing recent discussions on >> ID-Event token draft >> >> I didn’t cover this as I didn’t >> want to confuse people with too >> many things. >> >> But I think we agree on all of >> the below. >> >> I’m not sure that we need a >> “name”. What is your intention there. >> >> Phil >> >> @independentid >> >> www.independentid.com >> >> phil.hunt@oracle.com >> >> On Aug 9, 2016, at 11:54 AM, >> Mike Jones >> >> wrote: >> >> Thanks for writing this, >> Phil. Unfortunately, the >> summary below does not >> include my feedback, which at >> the essence, is to keep the >> ID Events data structure as >> simple and general-purpose as >> possible. (I strongly >> believe that JWT is the >> success it is because we made >> JWT as simple and >> general-purpose as possible, >> and we should follow this >> successful example and do the >> same here.) >> >> I believe that the ID Events >> spec needs to include these >> things, and these things only: >> >> ·Define of the “events” claim >> >> ·Define that an event name >> can be used as a top-level claim >> >> ·Require that “iss” be >> included and that the JWT be >> signed by the issuer >> >> ·Include a statement along >> the lines of “The claims to >> be included with any >> particular event are to be >> defined by the event” >> >> And I’d stop there. >> >> It should be entirely up to >> applications to say what >> claims are included with >> events they define and what >> their format and meanings >> are. Then the ID Events spec >> will be as general-purpose as >> possible, with it being >> natural for it to be used in >> essentially all JSON Event >> contexts. >> >> As soon as we start putting >> restrictions on the use of >> particular claims by events, >> we’re making the ID Events >> spec less general-purpose and >> less natural to use. In >> particular, the only thing >> that the spec should say >> about the “sub” claim is that >> “Like all other claims other >> than ‘events’ and ‘iss’, >> whether the ‘sub’ claim is to >> be included with an event is >> entirely event-specific. The >> claims to be included with >> any particular event are >> explicitly outside the scope >> of this specification.” >> >> -- Mike >> >> *From:*Id-event >> [mailto:id-event-bounces@ietf.org]*On >> Behalf Of*Phil Hunt >> *Sent:*Tuesday, August 9, >> 2016 10:19 AM >> *To:*id-event@ietf.org >> *Subject:*[Id-event] >> Summarizing recent >> discussions on ID-Event token >> draft >> >> I thought I would update the >> list on some discussions that >> have been happening over in >> the OpenID Connect and RISC >> working groups conference calls. >> >> These discussions have been >> about the core spec and the >> role of “top-level” >> attributes vs. event >> “extension” attributes. >> >> See:https://tools.ietf.org/html/draft-hunt-idevent-token-01 >> >> In particular should “sub” be >> used in the top level to >> “point” to the subject (in >> the broader english sense) of >> the event, or should it be >> constrained to the SAML/ID >> Token definition which is the >> authenticated user. >> >> Taken in the narrower >> definition, it is important >> to observe that in an ID >> Token, “sub” and “iss” go >> together. The issuer >> provides the context for the >> authenticated subject >> identifier. The problem with >> events, is that it might not >> be the AS (or OP) which is >> issuing the event. >> >> To summarize a fair amount of >> discussion, the feeling seems >> to be the following: >> >> * The Event Token top level >> attributes should be fairly >> limited and not include the >> sub attribute. >> >> * For events that are about >> a user, the relevant event >> specification may include a >> “sub” attribute within the >> event’s sub-object and not in >> the top-level. Further that >> sub-object can also include >> the issuer of the user. >> >> * The top-level “iss” shall >> mean the issuer of the event >> where the state change occurred. >> >> * “sub” should not be >> present in the top level >> structure. Also, “events” >> must also be present. >> >> Here would be a new example >> logout: >> >> { >> >> <— top level is about the event itself -> >> >> "iss": >> "https://server.example.com", >> >> "aud": "s6BhdRkqt3", >> >> "jti": >> "3d0c3cf797584bd193bd0fb1bd4e7d30", >> >> "iat": 1458668180, >> >> "exp": 1458668580, >> >> "events": [ >> >> >> "https://specs.openid.net/logout" >> >> ], >> >> "https://specs.openid.net/logout": >> { >> >> <- This level is defined >> entirely by the event URI-> >> >> "iss": >> "https://oidc.example.com", >> >> “jti": >> "08a5019c-17e1-4977-8f42-65a12843ea02”, >> >> "sub": "248289761001”, >> >> “exp”: >> >> } >> >> } >> >> In the above example note >> that the “event” object can >> have its own iss and subject >> (sub or jti) that have >> meaning within the context of >> an OpenID OP provider. The >> issuer of the event can be >> different (the top-level) and >> represents the entity that >> signs the event (if it is >> signed). >> >> The top-level attributes >> identify an individual event >> and are used to validate the >> event (signing etc). Where >> as the nested object contains >> all of the data about the >> event and is defined by the >> profiling specification (e.g. >> a possible OpenID Logout >> Event spec). In this case, >> in OpenID, logging out >> usually translates into >> revoking an ID Token. Thus >> the “jti” for the ID token >> (08a5019c...843ea02) is >> included in the Logout object. >> >> Side note. Regarding >> “logout”, it might be useful >> to include the expiry of the >> ID Token in case the >> subscriber has not yet >> received an ID Token. This >> would let the subscriber know >> how long it needs to keep the >> revocation information for. >> IOW…after the the ID Token is >> expired, the subscriber would >> no longer need to track the >> revocation state. >> >> It is also good to observe >> that the “aud” at the top >> level describes the >> subscriber of the event. >> This may also be different >> then the original audience of >> the ID Token. >> >> So to conclude. By making >> top-level attributes strictly >> about the events own >> validation, and nested >> objects about the event, we >> avoid collisions in >> definitions such as the >> issuer of the event, vs. the >> original issuer of a security >> assertion. >> >> I hope I’ve gotten everyone’s >> feedback correct here. Lets >> continue to discuss. I will >> revise the draft to follow >> the groups thinking here. >> >> Phil >> >> @independentid >> >> www.independentid.com >> >> phil.hunt@oracle.com >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.orghttps://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 >> > _______________________________________________ > Openid-specs-ab mailing list > Openid-specs-ab@lists.openid.net > http://lists.openid.net/mailman/listinfo/openid-specs-ab --------------465B8D1DD205662481BB16FD Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

+1 to this.

I'd also add that the "pass through" logic I mentioned in the other email fits this as well. Basically, if my event *doesn't* have a "sub", then I assume it's the same "sub" as the root object. But the lower level would always shadow the upper one, in the context of the event itself.

This is of course an optimization, but it allows for the kind of structures like Mike is talking about without things getting overly weird for the general case.

 -- Justin


On 8/11/2016 2:54 PM, Marius Scurtescu via Openid-specs-ab wrote:
Can we step back and look at all the requirements mentioned in this thread and see if we can simplify them:
1. Multiple events per SET (Security Event Token).
2. SET issuer different from event issuer.
3. Existing Id Token parsers must not confuse a SET for an Id Token.
4. Nested token format.

4 is needed by 1.
4 can fulfill 3, if sub can be present only in nested events.

I don't think 1 is really needed, but with 4 it comes really easy.

A nested format with sub only at event level seems to meet all the requirements.

Allowing different event specs to define top level claims, like sub, is very problematic IMO because you can run into incompatible events. Same with requiring that all events in a single token must refer to the same sub. This can lead to very complex and buggy publisher implementations.



Marius

On Thu, Aug 11, 2016 at 11:30 AM, Sarah Squire <sarah@engageidentity.com> wrote:

There are also rp-initiated use cases around suspected fraud, parallel authentication of a second factor, and issuance of a consent receipt.


On Aug 11, 2016 12:27 PM, "Phil Hunt (IDM)" <phil.hunt@oracle.com> wrote:
Sarah,

Good question!

Your use case is really the app initiated logout or logout within the context of a single application. 

If the app initiated front/ backchannel you would be saying log user out of all sso sites for that OP. 

If instead, the app issued the event to the OP, it would be saying the user was logged out of the app. Thus issuer is the app. The OP may or may not take action depending on its policy. 

We need to explore the use case. 

Talking through use cases was part of my reluctance to rushing id token without forming a wg. 
 
Phil

On Aug 11, 2016, at 11:09 AM, Sarah Squire <sarah@engageidentity.com> wrote:

Are we including use cases where the RP is the event issuer?


On Aug 11, 2016 11:02 AM, "Mike Jones" <Michael.Jones@microsoft.com> wrote:

You’re aware that forcing “sub” to be a URI is a breaking change for most implementations, right?  This is hardly a way to encourage adoption!

 

The thing you wrote below that makes me think that you’re thinking about the purpose of the ID Events spec differently than me is this: “so that all event specs can use it”.  The purpose of the logout event *isn’t* for all event specs to use it.  It’s for the logout use case to use it.  There’s no expectation that events intended for one use case will even be comprehensible in other use cases because they won’t understand the contents of the event.  We shouldn’t drive any of the design by trying to achieve that unachievable goal, since events will *always* contain information that’s specific to their use case.

 

You’re making complexity arguments, whereas you’re also proposing more complex rules than I am (at least as I see it).  Trying to restrict the use of “sub” (or any other claims) is unneeded complexity.

 

I understand that you see things differently.  I hope you’ll nonetheless think about my argument that having fewer rules about claims usage in events will make them simpler.  I passionately care about keeping this simple, which is why I’m investing my time in this discussion.  If it’s simple, it will likely get widely used.

 

I’m going to sign out of the discussion for now because my wife is about to get out of surgery.  I hope you have a good day.

 

                                                       -- Mike

 

From: Phil Hunt [mailto:phil.hunt@oracle.com]
Sent: Thursday, August 11, 2016 12:49 PM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: John Bradley <ve7jtb@ve7jtb.com>; openid-specs-ab@lists.openid.net Ab <openid-specs-ab@lists.openid.net>; id-event@ietf.org; Marius Scurtescu <mscurtescu@google.com>
Subject: Re: [Id-event] Summarizing recent discussions on ID-Event token draft

 

Mike, 

 

Speaking as editor the format you propose ONLY works if “sub” becomes a URI so that all event specs can use it.  Otherwise, OIDC becomes a special case which really kills the point of this work. It also makes the specification much much more complex. Maybe it is just me, but a complex spec generally implies complex implementation too.

 

If you want sub at the top level, that would mean that the OIDC spec format would have to look like:

{

  "aud": "s6BhdRkqt3",

  "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",

  "iat": 1458668180,

  "exp": 1458668580,

  "events": [

  ],

  "sid": "08a5019c-17e1-4977-8f42-65a12843ea02"

}

 

Given that events are signed (or should be), I will object strongly within the OIDF that the event issuer and the token issuer MUST be the same or that OIDF adopt a different format. Yes having iss be the same is a nice security convenience, but it imposes the architecture restriction that it be the same server.  At scale, delivery of events may become a problem for large scale providers if they are also delivering tokens to relying parties. The restriction isn’t really justified given the crypto alternative — which was the whole point of using JWT in the first place.

 

Per Justin’s comment, it seems elegant/trivial that a logout event simply has logout at the top level and an ID Token attached (though it might convey a lot of unneeded claims).  IMO, the OIDC logout spec should only convey the ID Token JTI.  It is going to be rare that you log out all devices for a user.  To most users, it means clear SSO within this browser only!  One can argue that clearing all devices/sessions is a different event entirely. It is an account reset or lock-out action.

 

 

 

 

 

On Aug 11, 2016, at 9:32 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

 

See my previous message, John, which was a reply to Phil’s message that you also replied to, that contained a logout claims example.  I’m not proposing to special-case the Connect Logout message in any way.  The “iss” is the event issuer.  The other claims in the message are those defined by the event to be included, just like those for any other event.  Yes, the logout message doesn’t include a second issuer, a second subject, an ID Token as a claim, or anything else complicated like that, because those things aren’t needed for the logout use case.

 

As I’d written previously, the ID Events spec should define the “events” claim, how to use an event name as a claim (when needed), and say that the event JWT must be signed by the issuer, and stop there.  Trying to micro-manage claims usage within an event will only result in the ID Events spec being harder to use.  If we’d tried to similarly micro-manage JWT claims usage, JWT would likely not have been the success that it is.

 

                                                       -- Mike

 

From: John Bradley [mailto:ve7jtb@ve7jtb.com] 
Sent: Thursday, August 11, 2016 12:22 PM
To: Phil Hunt (IDM) <phil.hunt@oracle.com>
Cc: Mike Jones <Michael.Jones@microsoft.com>; id-event@ietf.org; Marius Scurtescu <mscurtescu@google.com>; openid-specs-ab@lists.openid.net Ab <openid-specs-ab@lists.openid.net>
Subject: Re: [Id-event] Summarizing recent discussions on ID-Event token draft

 

Not surprisingly a multipurpose message format will not be as optimized as a single purpose one.

 

Connect itself doesn’t really have a conflict around issuer the same entity sending the logout message is always the one that created the id_token that it refers to.

 

Using the same format as id_token with the same semantics to identify the thing to be terminated makes sense from a purely openID Connect point of view.

 

Oter messages that have different notions of subject and are issued by different parties than the one that controls the subject cause issues when you try and fit them into the same format as an ID_Token, I grant you that.

 

It was mentioned that we need to differentiate between these events and id_tokens.  Mostly we need to do that in cases where the token might be presented in the front channel.

 

To do that se do have mandatory claims for nonce and c_hash or at_hash as well as the addition of events parameter to reduce confusion.   Now I admit that some people may still get that wrong,  and the removal of sub from the top level would remove any concern.  However Mike has a point that adoption may be hurt if we change the semantics too much.

 

I don’t see backchannel single logout being used by many social login RP, it is a lot of work to maintain server side state.   It is mostly an enterprise and large site sort of feature.

That may or may not impact on if it is better to be simple and aligned with connect’s id token or more general purpose to fit with other enterprise to SaaS features like SCIM events.

 

I think the two directions lead to different formats.   

 

The compromise of special casing Connect SLO and bodging the formats together is probably the worst option.

 

John B.

 

 

On Aug 11, 2016, at 11:59 AM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:

 

How do you resolve conflicts on iss then?  The top level has to be the issuer of the event as the issuer signs. 

 

If one spec can use it all must be able to. I believe you previously objected to that saying sub must be as how id tokens define them. But that isnt unique and requires iss. Now we would have sub at the top with an event issuer at the top and a sub issuer in the extension. That seems incredibly complex not to mention awkward. 

 

If we make sub a uri for all then it can work ass iss from id token would not be needed. But i can see many objecting to the change in format. 

 

Why not have a logout be an event with an id token attached for example?


Phil


On Aug 11, 2016, at 8:03 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

The simple rule is that if the particular event calls for the “sub” claim to be at the top level, then it is.  This is no different from any other claim that an event might place at the top level.

 

The complexity arises if “sub” is unnecessarily special-cased.  We shouldn’t do that, because it limits the applicability of the specification.

 

                                                       -- Mike

 

From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com] 
Sent: Thursday, August 11, 2016 9:40 AM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: Marius Scurtescu <mscurtescu@google.com>; id-event@ietf.org
Subject: Re: [Id-event] Summarizing recent discussions on ID-Event token draft

 

I think using sub at the top level leads to complexity. Eg Can you provide a rule for when top level is used or not by an individual spec?  IMO. Top level should always be used the same way by all implementers. 

 

Based on the calls at risc/connect, we discussed that it would be best to move all event specifics to the event object area. This way different events can have different event addressing (eg sub/iss, uri, jit/iss). When iss is needed to uniquely qualify a sub, it can be provided without conflicting with the issuer of the event. Similarly jti and iss can be used for a revoked token without conflicting with the event jti. 

 

I plan to post a new draft shortly that will give some examples based on feedback from the openid risc/connect discussions.

 

We can always change again. 


Phil


On Aug 11, 2016, at 4:54 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

No, I’m not saying that “sub” cannot appear at the top level.  I’m saying that “sub” will only occur at the top level if the particular event defines that “sub” is used in that way for that event.

 

There are probably use cases for multiple events per message but I doubt there are use cases for multiple *unrelated* events per message.  By definition, related events that use top-level claims would need to use them in a compatible way.  I don’t see that as being a problem.

 

That being said, the predominant use case is likely to be a single event per JWT.

 

                                                                     -- Mike

 

From: Marius Scurtescu [mailto:mscurtescu@google.com] 
Sent: Tuesday, August 9, 2016 7:15 PM
To: Phil Hunt <phil.hunt@oracle.com>
Cc: Mike Jones <Michael.Jones@microsoft.com>; id-event@ietf.org
Subject: Re: [Id-event] Summarizing recent discussions on ID-Event token draft

 

Mike, are you suggesting that a sub claim can only show up at the event level and not at the top level:

 

In particular, the only thing that the spec should say about the “sub” claim is that “Like all other claims other than ‘events’ and ‘iss’, whether the ‘sub’ claim is to be included with an event is entirely event-specific.

 

A top level sub and multiple events are incompatible IMO.

 

Do we have a compelling reason to support multiple events per message?

 


Marius

 

On Tue, Aug 9, 2016 at 12:39 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

I was referring to this in your email

"Define that an event name can be used as a top-level claim”

 

 

Is this different from the event uri?

 

 

 

 

 

On Aug 9, 2016, at 12:12 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

 

I’m glad to hear that we agree on keeping it as simple and general-purpose as possible and that you agree with my write-up.  I think we then have a good path forward.

 

I’m not sure what you mean by “I’m not sure that we need a “name”. What is your intention there.”  The only place I used the word “name” was in my statement “Define that an event name can be used as a top-level claim”.  What I was trying to get at is was that if “http://specs.openid.net/logout” is used as an event name, that it can also be used as a claim name in the JWT containing information about the event.  (Maybe I’m not using the correct terminology, hence the unintended confusion J.)

 

                                                       Thanks again,

                                                       -- Mike

 

From: Phil Hunt [mailto:phil.hunt@oracle.com] 
Sent: Tuesday, August 9, 2016 12:07 PM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: id-event@ietf.org
Subject: Re: [Id-event] Summarizing recent discussions on ID-Event token draft

 

I didn’t cover this as I didn’t want to confuse people with too many things.

 

But I think we agree on all of the below.

 

I’m not sure that we need a “name”. What is your intention there.

 

 

 

 

 

On Aug 9, 2016, at 11:54 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

 

Thanks for writing this, Phil.  Unfortunately, the summary below does not include my feedback, which at the essence, is to keep the ID Events data structure as simple and general-purpose as possible.  (I strongly believe that JWT is the success it is because we made JWT as simple and general-purpose as possible, and we should follow this successful example and do the same here.)

 

I believe that the ID Events spec needs to include these things, and these things only:

·       Define of the “events” claim

·       Define that an event name can be used as a top-level claim

·       Require that “iss” be included and that the JWT be signed by the issuer

·       Include a statement along the lines of “The claims to be included with any particular event are to be defined by the event”

 

And I’d stop there.

 

It should be entirely up to applications to say what claims are included with events they define and what their format and meanings are.  Then the ID Events spec will be as general-purpose as possible, with it being natural for it to be used in essentially all JSON Event contexts.

 

As soon as we start putting restrictions on the use of particular claims by events, we’re making the ID Events spec less general-purpose and less natural to use.  In particular, the only thing that the spec should say about the “sub” claim is that “Like all other claims other than ‘events’ and ‘iss’, whether the ‘sub’ claim is to be included with an event is entirely event-specific.  The claims to be included with any particular event are explicitly outside the scope of this specification.”

 

                                                       -- Mike

 

From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Tuesday, August 9, 2016 10:19 AM
To: id-event@ietf.org
Subject: [Id-event] Summarizing recent discussions on ID-Event token draft

 

I thought I would update the list on some discussions that have been happening over in the OpenID Connect and RISC working groups conference calls.

 

These discussions have been about the core spec and the role of “top-level” attributes vs. event “extension” attributes. 

 

In particular should “sub” be used in the top level to “point” to the subject (in the broader english sense) of the event, or should it be constrained to the SAML/ID Token definition which is the authenticated user.  

 

Taken in the narrower definition, it is important to observe that in an ID Token, “sub” and “iss” go together.  The issuer provides the context for the authenticated subject identifier. The problem with events, is that it might not be the AS (or OP) which is issuing the event.  

 

To summarize a fair amount of discussion, the feeling seems to be the following:

 

*  The Event Token top level attributes should be fairly limited and not include the sub attribute.  

*  For events that are about a user, the relevant event specification may include a “sub” attribute within the event’s sub-object and not in the top-level. Further that sub-object can also include the issuer of the user.  

* The top-level “iss” shall mean the issuer of the event where the state change occurred.

*  “sub” should not be present in the top level structure.  Also, “events” must also be present.

 

Here would be a new example logout:

{
  <— top level is about the event itself ->
  "iss": "https://server.example.com",
  "aud": "s6BhdRkqt3",
  "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
  "iat": 1458668180,
  "exp": 1458668580,
  "events": [
    "https://specs.openid.net/logout"
  ],
  "https://specs.openid.net/logout": {
    <- This level is defined entirely by the event URI->
    "iss": "https://oidc.example.com",
    “jti": "08a5019c-17e1-4977-8f42-65a12843ea02”,
    "sub": "248289761001”,
    “exp”: <ID token expiry>
  }
}

 

In the above example note that the “event” object can have its own iss and subject (sub or jti) that have meaning within the context of an OpenID OP provider.  The issuer of the event can be different (the top-level) and represents the entity that signs the event (if it is signed).

 

The top-level attributes identify an individual event and are used to validate the event (signing etc).  Where as the nested object contains all of the data about the event and is defined by the profiling specification (e.g. a possible OpenID Logout Event spec).  In this case, in OpenID, logging out usually translates into revoking an ID Token. Thus the “jti” for the ID token (08a5019c...843ea02) is included in the Logout object.

 

Side note.  Regarding “logout”, it might be useful to include the expiry of the ID Token in case the subscriber has not yet received an ID Token. This would let the subscriber know how long it needs to keep the revocation information for.  IOW…after the the ID Token is expired, the subscriber would no longer need to track the revocation state.

 

It is also good to observe that the “aud” at the top level describes the subscriber of the event.  This may also be different then the original audience of the ID Token.

 

So to conclude. By making top-level attributes strictly about the events own validation, and nested objects about the event, we avoid collisions in definitions such as the issuer of the event, vs. the original issuer of a security assertion.

 

I hope I’ve gotten everyone’s feedback correct here. Lets continue to discuss. I will revise the draft to follow the groups thinking here.

 

 

_______________________________________________ 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 
_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs-ab
--------------465B8D1DD205662481BB16FD-- From nobody Thu Aug 11 12:19:38 2016 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 8561D12D780 for ; Thu, 11 Aug 2016 12:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.465 X-Spam-Level: X-Spam-Status: No, score=-5.465 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, 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 KdxqVYKGGsUe for ; Thu, 11 Aug 2016 12:19:33 -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 1F70D12D842 for ; Thu, 11 Aug 2016 12:19:33 -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 u7BJJSZ2010920 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 11 Aug 2016 19:19:28 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 u7BJJR3O016825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 11 Aug 2016 19:19:27 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u7BJJGeI009469; Thu, 11 Aug 2016 19:19:21 GMT Received: from [192.168.1.6] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 11 Aug 2016 12:19:15 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-8539D404-24A6-4E4D-8860-349A51A33717 Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (13G34) In-Reply-To: Date: Thu, 11 Aug 2016 12:19:13 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <14E2EF51-7123-4E91-87DD-56AEA08202C1@oracle.com> <3F0DD3E6-46CD-4AA5-8F06-F79140F5D4BE@oracle.com> <56E7DF06-EE77-4FD1-BF44-15A083AC5B5A@ve7jtb.com> <12274564-507F-492B-94E8-C65C6A84FDB7@oracle.com> <21751371-BD95-4C15-AE01-D42CF4815233@oracle.com> To: Marius Scurtescu X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: John Bradley , Mike Jones , "openid-specs-ab@lists.openid.net Ab" , Sarah Squire , "id-event@ietf.org" Subject: Re: [Id-event] Summarizing recent discussions on ID-Event token draft X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 11 Aug 2016 19:19:37 -0000 --Apple-Mail-8539D404-24A6-4E4D-8860-349A51A33717 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1 Great discussion folks.=20 I hope to put in an example of consent that Sarah mentioned too. I think it r= eally adds to the discussions.=20 I will publish the next draft knowing that we are not there yet.=20 But as long as we keep discussing that is a good thing! Phil > On Aug 11, 2016, at 11:54 AM, Marius Scurtescu wro= te: >=20 > Can we step back and look at all the requirements mentioned in this thread= and see if we can simplify them: > 1. Multiple events per SET (Security Event Token). > 2. SET issuer different from event issuer. > 3. Existing Id Token parsers must not confuse a SET for an Id Token. > 4. Nested token format. >=20 > 4 is needed by 1. > 4 can fulfill 3, if sub can be present only in nested events. >=20 > I don't think 1 is really needed, but with 4 it comes really easy. >=20 > A nested format with sub only at event level seems to meet all the require= ments. >=20 > Allowing different event specs to define top level claims, like sub, is ve= ry problematic IMO because you can run into incompatible events. Same with r= equiring that all events in a single token must refer to the same sub. This c= an lead to very complex and buggy publisher implementations. >=20 >=20 >=20 > Marius >=20 >> On Thu, Aug 11, 2016 at 11:30 AM, Sarah Squire = wrote: >> There are also rp-initiated use cases around suspected fraud, parallel au= thentication of a second factor, and issuance of a consent receipt. >>=20 >>=20 >>> On Aug 11, 2016 12:27 PM, "Phil Hunt (IDM)" wrote= : >>> Sarah, >>>=20 >>> Good question! >>>=20 >>> Your use case is really the app initiated logout or logout within the co= ntext of a single application.=20 >>>=20 >>> If the app initiated front/ backchannel you would be saying log user out= of all sso sites for that OP.=20 >>>=20 >>> If instead, the app issued the event to the OP, it would be saying the u= ser was logged out of the app. Thus issuer is the app. The OP may or may not= take action depending on its policy.=20 >>>=20 >>> We need to explore the use case.=20 >>>=20 >>> Talking through use cases was part of my reluctance to rushing id token w= ithout forming a wg.=20 >>> =20 >>> Phil >>>=20 >>>> On Aug 11, 2016, at 11:09 AM, Sarah Squire w= rote: >>>>=20 >>>> Are we including use cases where the RP is the event issuer? >>>>=20 >>>>=20 >>>>> On Aug 11, 2016 11:02 AM, "Mike Jones" w= rote: >>>>> You=E2=80=99re aware that forcing =E2=80=9Csub=E2=80=9D to be a URI is= a breaking change for most implementations, right? This is hardly a way to= encourage adoption! >>>>>=20 >>>>> =20 >>>>>=20 >>>>> The thing you wrote below that makes me think that you=E2=80=99re thin= king about the purpose of the ID Events spec differently than me is this: =E2= =80=9Cso that all event specs can use it=E2=80=9D. The purpose of the logou= t event *isn=E2=80=99t* for all event specs to use it. It=E2=80=99s for the= logout use case to use it. There=E2=80=99s no expectation that events inte= nded for one use case will even be comprehensible in other use cases because= they won=E2=80=99t understand the contents of the event. We shouldn=E2=80=99= t drive any of the design by trying to achieve that unachievable goal, since= events will *always* contain information that=E2=80=99s specific to their u= se case. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> You=E2=80=99re making complexity arguments, whereas you=E2=80=99re als= o proposing more complex rules than I am (at least as I see it). Trying to r= estrict the use of =E2=80=9Csub=E2=80=9D (or any other claims) is unneeded c= omplexity. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> I understand that you see things differently. I hope you=E2=80=99ll n= onetheless think about my argument that having fewer rules about claims usag= e in events will make them simpler. I passionately care about keeping this s= imple, which is why I=E2=80=99m investing my time in this discussion. If it= =E2=80=99s simple, it will likely get widely used. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> I=E2=80=99m going to sign out of the discussion for now because my wif= e is about to get out of surgery. I hope you have a good day. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> -- Mike >>>>>=20 >>>>> =20 >>>>>=20 >>>>> From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 >>>>> Sent: Thursday, August 11, 2016 12:49 PM >>>>> To: Mike Jones >>>>> Cc: John Bradley ; openid-specs-ab@lists.openid.net= Ab ; id-event@ietf.org; Marius Scurtescu <= mscurtescu@google.com> >>>>> Subject: Re: [Id-event] Summarizing recent discussions on ID-Event tok= en draft >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Mike,=20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Speaking as editor the format you propose ONLY works if =E2=80=9Csub=E2= =80=9D becomes a URI so that all event specs can use it. Otherwise, OIDC be= comes a special case which really kills the point of this work. It also make= s the specification much much more complex. Maybe it is just me, but a compl= ex spec generally implies complex implementation too. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> If you want sub at the top level, that would mean that the OIDC spec f= ormat would have to look like: >>>>>=20 >>>>> { >>>>>=20 >>>>> "iss": "https://event.example.com", >>>>>=20 >>>>> "aud": "s6BhdRkqt3", >>>>>=20 >>>>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>>>>=20 >>>>> "sub": =E2=80=9Chttps://token.example.com/248289761001", >>>>>=20 >>>>> "iat": 1458668180, >>>>>=20 >>>>> "exp": 1458668580, >>>>>=20 >>>>> "events": [ >>>>>=20 >>>>> "https://specs.openid.net/logout" >>>>>=20 >>>>> ], >>>>>=20 >>>>> "sid": "08a5019c-17e1-4977-8f42-65a12843ea02" >>>>>=20 >>>>> } >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Given that events are signed (or should be), I will object strongly wi= thin the OIDF that the event issuer and the token issuer MUST be the same or= that OIDF adopt a different format. Yes having iss be the same is a nice se= curity convenience, but it imposes the architecture restriction that it be t= he same server. At scale, delivery of events may become a problem for large= scale providers if they are also delivering tokens to relying parties. The r= estriction isn=E2=80=99t really justified given the crypto alternative =E2=80= =94 which was the whole point of using JWT in the first place. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Per Justin=E2=80=99s comment, it seems elegant/trivial that a logout e= vent simply has logout at the top level and an ID Token attached (though it m= ight convey a lot of unneeded claims). IMO, the OIDC logout spec should onl= y convey the ID Token JTI. It is going to be rare that you log out all devi= ces for a user. To most users, it means clear SSO within this browser only!= One can argue that clearing all devices/sessions is a different event enti= rely. It is an account reset or lock-out action. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Phil >>>>>=20 >>>>> =20 >>>>>=20 >>>>> @independentid >>>>>=20 >>>>> www.independentid.com >>>>>=20 >>>>> phil.hunt@oracle.com >>>>>=20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> On Aug 11, 2016, at 9:32 AM, Mike Jones w= rote: >>>>>=20 >>>>> =20 >>>>>=20 >>>>> See my previous message, John, which was a reply to Phil=E2=80=99s mes= sage that you also replied to, that contained a logout claims example. I=E2= =80=99m not proposing to special-case the Connect Logout message in any way.= The =E2=80=9Ciss=E2=80=9D is the event issuer. The other claims in the me= ssage are those defined by the event to be included, just like those for any= other event. Yes, the logout message doesn=E2=80=99t include a second issu= er, a second subject, an ID Token as a claim, or anything else complicated l= ike that, because those things aren=E2=80=99t needed for the logout use case= . >>>>>=20 >>>>> =20 >>>>>=20 >>>>> As I=E2=80=99d written previously, the ID Events spec should define th= e =E2=80=9Cevents=E2=80=9D claim, how to use an event name as a claim (when n= eeded), and say that the event JWT must be signed by the issuer, and stop th= ere. Trying to micro-manage claims usage within an event will only result i= n the ID Events spec being harder to use. If we=E2=80=99d tried to similarl= y micro-manage JWT claims usage, JWT would likely not have been the success t= hat it is. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> -- Mike >>>>>=20 >>>>> =20 >>>>>=20 >>>>> From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20 >>>>> Sent: Thursday, August 11, 2016 12:22 PM >>>>> To: Phil Hunt (IDM) >>>>> Cc: Mike Jones ; id-event@ietf.org; Mariu= s Scurtescu ; openid-specs-ab@lists.openid.net Ab >>>>> Subject: Re: [Id-event] Summarizing recent discussions on ID-Event tok= en draft >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Not surprisingly a multipurpose message format will not be as optimize= d as a single purpose one. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Connect itself doesn=E2=80=99t really have a conflict around issuer th= e same entity sending the logout message is always the one that created the i= d_token that it refers to. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Using the same format as id_token with the same semantics to identify t= he thing to be terminated makes sense from a purely openID Connect point of v= iew. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Oter messages that have different notions of subject and are issued by= different parties than the one that controls the subject cause issues when y= ou try and fit them into the same format as an ID_Token, I grant you that. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> It was mentioned that we need to differentiate between these events an= d id_tokens. Mostly we need to do that in cases where the token might be pr= esented in the front channel. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> To do that se do have mandatory claims for nonce and c_hash or at_hash= as well as the addition of events parameter to reduce confusion. Now I ad= mit that some people may still get that wrong, and the removal of sub from t= he top level would remove any concern. However Mike has a point that adopti= on may be hurt if we change the semantics too much. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> I don=E2=80=99t see backchannel single logout being used by many socia= l login RP, it is a lot of work to maintain server side state. It is mostl= y an enterprise and large site sort of feature. >>>>>=20 >>>>> That may or may not impact on if it is better to be simple and aligned= with connect=E2=80=99s id token or more general purpose to fit with other e= nterprise to SaaS features like SCIM events. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> I think the two directions lead to different formats. =20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> The compromise of special casing Connect SLO and bodging the formats t= ogether is probably the worst option. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> John B. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> On Aug 11, 2016, at 11:59 AM, Phil Hunt (IDM) w= rote: >>>>>=20 >>>>> =20 >>>>>=20 >>>>> How do you resolve conflicts on iss then? The top level has to be the= issuer of the event as the issuer signs.=20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> If one spec can use it all must be able to. I believe you previously o= bjected to that saying sub must be as how id tokens define them. But that is= nt unique and requires iss. Now we would have sub at the top with an event i= ssuer at the top and a sub issuer in the extension. That seems incredibly co= mplex not to mention awkward.=20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> If we make sub a uri for all then it can work ass iss from id token wo= uld not be needed. But i can see many objecting to the change in format.=20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Why not have a logout be an event with an id token attached for exampl= e? >>>>>=20 >>>>>=20 >>>>> Phil >>>>>=20 >>>>>=20 >>>>> On Aug 11, 2016, at 8:03 AM, Mike Jones w= rote: >>>>>=20 >>>>> The simple rule is that if the particular event calls for the =E2=80=9C= sub=E2=80=9D claim to be at the top level, then it is. This is no different= from any other claim that an event might place at the top level. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> The complexity arises if =E2=80=9Csub=E2=80=9D is unnecessarily specia= l-cased. We shouldn=E2=80=99t do that, because it limits the applicability o= f the specification. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> -- Mike >>>>>=20 >>>>> =20 >>>>>=20 >>>>> From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com]=20 >>>>> Sent: Thursday, August 11, 2016 9:40 AM >>>>> To: Mike Jones >>>>> Cc: Marius Scurtescu ; id-event@ietf.org >>>>> Subject: Re: [Id-event] Summarizing recent discussions on ID-Event tok= en draft >>>>>=20 >>>>> =20 >>>>>=20 >>>>> I think using sub at the top level leads to complexity. Eg Can you pro= vide a rule for when top level is used or not by an individual spec? IMO. T= op level should always be used the same way by all implementers.=20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Based on the calls at risc/connect, we discussed that it would be best= to move all event specifics to the event object area. This way different ev= ents can have different event addressing (eg sub/iss, uri, jit/iss). When is= s is needed to uniquely qualify a sub, it can be provided without conflictin= g with the issuer of the event. Similarly jti and iss can be used for a revo= ked token without conflicting with the event jti.=20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> I plan to post a new draft shortly that will give some examples based o= n feedback from the openid risc/connect discussions. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> We can always change again.=20 >>>>>=20 >>>>>=20 >>>>> Phil >>>>>=20 >>>>>=20 >>>>> On Aug 11, 2016, at 4:54 AM, Mike Jones w= rote: >>>>>=20 >>>>> No, I=E2=80=99m not saying that =E2=80=9Csub=E2=80=9D cannot appear at= the top level. I=E2=80=99m saying that =E2=80=9Csub=E2=80=9D will only occ= ur at the top level if the particular event defines that =E2=80=9Csub=E2=80=9D= is used in that way for that event. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> There are probably use cases for multiple events per message but I dou= bt there are use cases for multiple *unrelated* events per message. By defi= nition, related events that use top-level claims would need to use them in a= compatible way. I don=E2=80=99t see that as being a problem. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> That being said, the predominant use case is likely to be a single eve= nt per JWT. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> -= - Mike >>>>>=20 >>>>> =20 >>>>>=20 >>>>> From: Marius Scurtescu [mailto:mscurtescu@google.com]=20 >>>>> Sent: Tuesday, August 9, 2016 7:15 PM >>>>> To: Phil Hunt >>>>> Cc: Mike Jones ; id-event@ietf.org >>>>> Subject: Re: [Id-event] Summarizing recent discussions on ID-Event tok= en draft >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Mike, are you suggesting that a sub claim can only show up at the even= t level and not at the top level: >>>>>=20 >>>>> =20 >>>>>=20 >>>>> In particular, the only thing that the spec should say about the =E2=80= =9Csub=E2=80=9D claim is that =E2=80=9CLike all other claims other than =E2=80= =98events=E2=80=99 and =E2=80=98iss=E2=80=99, whether the =E2=80=98sub=E2=80= =99 claim is to be included with an event is entirely event-specific. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> A top level sub and multiple events are incompatible IMO. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Do we have a compelling reason to support multiple events per message?= >>>>>=20 >>>>> =20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Marius >>>>>=20 >>>>> =20 >>>>>=20 >>>>> On Tue, Aug 9, 2016 at 12:39 PM, Phil Hunt wrot= e: >>>>>=20 >>>>> I was referring to this in your email >>>>>=20 >>>>> "Define that an event name can be used as a top-level claim=E2=80=9D >>>>>=20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Is this different from the event uri? >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Phil >>>>>=20 >>>>> =20 >>>>>=20 >>>>> @independentid >>>>>=20 >>>>> www.independentid.com >>>>>=20 >>>>> phil.hunt@oracle.com >>>>>=20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> On Aug 9, 2016, at 12:12 PM, Mike Jones w= rote: >>>>>=20 >>>>> =20 >>>>>=20 >>>>> I=E2=80=99m glad to hear that we agree on keeping it as simple and gen= eral-purpose as possible and that you agree with my write-up. I think we th= en have a good path forward. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> I=E2=80=99m not sure what you mean by =E2=80=9CI=E2=80=99m not sure th= at we need a =E2=80=9Cname=E2=80=9D. What is your intention there.=E2=80=9D = The only place I used the word =E2=80=9Cname=E2=80=9D was in my statement =E2= =80=9CDefine that an event name can be used as a top-level claim=E2=80=9D. W= hat I was trying to get at is was that if =E2=80=9Chttp://specs.openid.net/l= ogout=E2=80=9D is used as an event name, that it can also be used as a claim= name in the JWT containing information about the event. (Maybe I=E2=80=99m= not using the correct terminology, hence the unintended confusion J.) >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Thanks again, >>>>>=20 >>>>> -- Mike >>>>>=20 >>>>> =20 >>>>>=20 >>>>> From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 >>>>> Sent: Tuesday, August 9, 2016 12:07 PM >>>>> To: Mike Jones >>>>> Cc: id-event@ietf.org >>>>> Subject: Re: [Id-event] Summarizing recent discussions on ID-Event tok= en draft >>>>>=20 >>>>> =20 >>>>>=20 >>>>> I didn=E2=80=99t cover this as I didn=E2=80=99t want to confuse people= with too many things. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> But I think we agree on all of the below. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> I=E2=80=99m not sure that we need a =E2=80=9Cname=E2=80=9D. What is yo= ur intention there. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Phil >>>>>=20 >>>>> =20 >>>>>=20 >>>>> @independentid >>>>>=20 >>>>> www.independentid.com >>>>>=20 >>>>> phil.hunt@oracle.com >>>>>=20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> On Aug 9, 2016, at 11:54 AM, Mike Jones w= rote: >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Thanks for writing this, Phil. Unfortunately, the summary below does n= ot include my feedback, which at the essence, is to keep the ID Events data s= tructure as simple and general-purpose as possible. (I strongly believe tha= t JWT is the success it is because we made JWT as simple and general-purpose= as possible, and we should follow this successful example and do the same h= ere.) >>>>>=20 >>>>> =20 >>>>>=20 >>>>> I believe that the ID Events spec needs to include these things, and t= hese things only: >>>>>=20 >>>>> =C2=B7 Define of the =E2=80=9Cevents=E2=80=9D claim >>>>>=20 >>>>> =C2=B7 Define that an event name can be used as a top-level clai= m >>>>>=20 >>>>> =C2=B7 Require that =E2=80=9Ciss=E2=80=9D be included and that t= he JWT be signed by the issuer >>>>>=20 >>>>> =C2=B7 Include a statement along the lines of =E2=80=9CThe claim= s to be included with any particular event are to be defined by the event=E2= =80=9D >>>>>=20 >>>>> =20 >>>>>=20 >>>>> And I=E2=80=99d stop there. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> It should be entirely up to applications to say what claims are includ= ed with events they define and what their format and meanings are. Then the= ID Events spec will be as general-purpose as possible, with it being natura= l for it to be used in essentially all JSON Event contexts. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> As soon as we start putting restrictions on the use of particular clai= ms by events, we=E2=80=99re making the ID Events spec less general-purpose a= nd less natural to use. In particular, the only thing that the spec should= say about the =E2=80=9Csub=E2=80=9D claim is that =E2=80=9CLike all other c= laims other than =E2=80=98events=E2=80=99 and =E2=80=98iss=E2=80=99, whether= the =E2=80=98sub=E2=80=99 claim is to be included with an event is entirely= event-specific. The claims to be included with any particular event are ex= plicitly outside the scope of this specification.=E2=80=9D >>>>>=20 >>>>> =20 >>>>>=20 >>>>> -- Mike >>>>>=20 >>>>> =20 >>>>>=20 >>>>> From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Phil Hu= nt >>>>> Sent: Tuesday, August 9, 2016 10:19 AM >>>>> To: id-event@ietf.org >>>>> Subject: [Id-event] Summarizing recent discussions on ID-Event token d= raft >>>>>=20 >>>>> =20 >>>>>=20 >>>>> I thought I would update the list on some discussions that have been h= appening over in the OpenID Connect and RISC working groups conference calls= . >>>>>=20 >>>>> =20 >>>>>=20 >>>>> These discussions have been about the core spec and the role of =E2=80= =9Ctop-level=E2=80=9D attributes vs. event =E2=80=9Cextension=E2=80=9D attri= butes.=20 >>>>>=20 >>>>> See: https://tools.ietf.org/html/draft-hunt-idevent-token-01 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> In particular should =E2=80=9Csub=E2=80=9D be used in the top level to= =E2=80=9Cpoint=E2=80=9D to the subject (in the broader english sense) of th= e event, or should it be constrained to the SAML/ID Token definition which i= s the authenticated user. =20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Taken in the narrower definition, it is important to observe that in a= n ID Token, =E2=80=9Csub=E2=80=9D and =E2=80=9Ciss=E2=80=9D go together. Th= e issuer provides the context for the authenticated subject identifier. The p= roblem with events, is that it might not be the AS (or OP) which is issuing t= he event.=20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> To summarize a fair amount of discussion, the feeling seems to be the f= ollowing: >>>>>=20 >>>>> =20 >>>>>=20 >>>>> * The Event Token top level attributes should be fairly limited and n= ot include the sub attribute. =20 >>>>>=20 >>>>> * For events that are about a user, the relevant event specification m= ay include a =E2=80=9Csub=E2=80=9D attribute within the event=E2=80=99s sub-= object and not in the top-level. Further that sub-object can also include th= e issuer of the user. =20 >>>>>=20 >>>>> * The top-level =E2=80=9Ciss=E2=80=9D shall mean the issuer of the eve= nt where the state change occurred. >>>>>=20 >>>>> * =E2=80=9Csub=E2=80=9D should not be present in the top level struct= ure. Also, =E2=80=9Cevents=E2=80=9D must also be present. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Here would be a new example logout: >>>>>=20 >>>>> { >>>>> <=E2=80=94 top level is about the event itself -> >>>>> "iss": "https://server.example.com", >>>>> "aud": "s6BhdRkqt3", >>>>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>>>> "iat": 1458668180, >>>>> "exp": 1458668580, >>>>> "events": [ >>>>> "https://specs.openid.net/logout" >>>>> ], >>>>> "https://specs.openid.net/logout": { >>>>> <- This level is defined entirely by the event URI-> >>>>> "iss": "https://oidc.example.com", >>>>> =E2=80=9Cjti": "08a5019c-17e1-4977-8f42-65a12843ea02=E2=80=9D, >>>>> "sub": "248289761001=E2=80=9D, >>>>> =E2=80=9Cexp=E2=80=9D: >>>>> } >>>>> } >>>>> =20 >>>>>=20 >>>>> In the above example note that the =E2=80=9Cevent=E2=80=9D object can h= ave its own iss and subject (sub or jti) that have meaning within the contex= t of an OpenID OP provider. The issuer of the event can be different (the t= op-level) and represents the entity that signs the event (if it is signed). >>>>>=20 >>>>> =20 >>>>>=20 >>>>> The top-level attributes identify an individual event and are used to v= alidate the event (signing etc). Where as the nested object contains all of= the data about the event and is defined by the profiling specification (e.g= . a possible OpenID Logout Event spec). In this case, in OpenID, logging ou= t usually translates into revoking an ID Token. Thus the =E2=80=9Cjti=E2=80=9D= for the ID token (08a5019c...843ea02) is included in the Logout object. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Side note. Regarding =E2=80=9Clogout=E2=80=9D, it might be useful to i= nclude the expiry of the ID Token in case the subscriber has not yet receive= d an ID Token. This would let the subscriber know how long it needs to keep t= he revocation information for. IOW=E2=80=A6after the the ID Token is expire= d, the subscriber would no longer need to track the revocation state. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> It is also good to observe that the =E2=80=9Caud=E2=80=9D at the top l= evel describes the subscriber of the event. This may also be different then= the original audience of the ID Token. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> So to conclude. By making top-level attributes strictly about the even= ts own validation, and nested objects about the event, we avoid collisions i= n definitions such as the issuer of the event, vs. the original issuer of a s= ecurity assertion. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> I hope I=E2=80=99ve gotten everyone=E2=80=99s feedback correct here. L= ets continue to discuss. I will revise the draft to follow the groups thinki= ng here. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Phil >>>>>=20 >>>>> =20 >>>>>=20 >>>>> @independentid >>>>>=20 >>>>> www.independentid.com >>>>>=20 >>>>> 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 >>>>>=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 >>>>> =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://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-8539D404-24A6-4E4D-8860-349A51A33717 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
+1

Great discussion folks. 

I hope to put in an e= xample of consent that Sarah mentioned too. I think it really adds to the di= scussions. 

I will publish the next draft knowing that we are not there ye= t. 

But as long as we keep discussing that is a good thing!

Phi= l

On Aug 11, 2016, at 11:54 AM, Marius Scurtescu <mscurtescu@google.com> wrote:

<= /div>
Can we step back and lo= ok at all the requirements mentioned in this thread and see if we can simpli= fy them:
1. Multiple events per SET (Security Event Token).
2. SET issuer different from event issuer.
3. Existing Id Token= parsers must not confuse a SET for an Id Token.
4. Nested token f= ormat.

4 is needed by 1.
4 can fulfill 3,= if sub can be present only in nested events.

I= don't think 1 is really needed, but with 4 it comes really easy.
=
A nested format with sub only at event level seems to meet al= l the requirements.

Allowing different event specs t= o define top level claims, like sub, is very problematic IMO because you can= run into incompatible events. Same with requiring that all events in a sing= le token must refer to the same sub. This can lead to very complex and buggy= publisher implementations.



Marius

On Thu, Aug 11, 2016 at 11:30 AM, Sarah Squir= e <sarah@engageidentity.com> wrote:

There are also rp-initiated use cases around sus= pected fraud, parallel authentication of a second factor, and issuance of a c= onsent receipt.


On Aug 11, 2016 12= :27 PM, "Phil Hunt (IDM)" <phil.hunt@oracle.com> wrote:
Sarah,

=
Good question!

Your use case is really the app= initiated logout or logout within the context of a single application. = ;

If the app initiated front/ backchannel you would= be saying log user out of all sso sites for that OP. 

If instead, the app issued the event to the OP, it would be saying t= he user was logged out of the app. Thus issuer is the app. The OP may or may= not take action depending on its policy. 

We n= eed to explore the use case. 

Talking through u= se cases was part of my reluctance to rushing id token without forming a wg.=  
 
Phil

On Aug 11, 2016, at 11:09 AM, Sarah S= quire <sara= h@engageidentity.com> wrote:

<= div>

Are we including use cases where the RP is the event issu= er?


On Aug 11, 2016 11= :02 AM, "Mike Jones" <Michael.Jones@microsoft.com> wrote:

You=E2=80=99re aware that forcing =E2=80= =9Csub=E2=80=9D to be a URI is a breaking change for most implementations, r= ight?  This is hardly a way to encourage adoption!=

 

The thing you wrote below that makes me= think that you=E2=80=99re thinking about the purpose of the ID Events spec d= ifferently than me is this: =E2=80=9Cso that all event specs can use it=E2=80=9D.  The purpose of the logout ev= ent *isn=E2=80=99t* for all event specs to use it.  It=E2=80=99s= for the logout use case to use it.  There=E2=80=99s no expectation tha= t events intended for one use case will even be comprehensible in other use cases because the= y won=E2=80=99t understand the contents of the event.  We shouldn=E2=80= =99t drive any of the design by trying to achieve that unachievable goal, si= nce events will *always* contain information that=E2=80=99s specific to their use case.

 

You=E2=80=99re making complexity argume= nts, whereas you=E2=80=99re also proposing more complex rules than I am (at l= east as I see it).  Trying to restrict the use of =E2=80=9Csub=E2=80=9D= (or any other claims) is unneeded complexity.

 

I understand that you see things differ= ently.  I hope you=E2=80=99ll nonetheless think about my argument that h= aving fewer rules about claims usage in events will make them simpler.  I passionately care about keeping this simple, which is= why I=E2=80=99m investing my time in this discussion.  If it=E2=80=99s= simple, it will likely get widely used.

 

I=E2=80=99m going to sign out of the di= scussion for now because my wife is about to get out of surgery.  I hop= e you have a good day.

 

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

 

From: Phil Hunt [mailto:phil.hunt@oracle.com]
Sent: Thursday, August 11, 2016 12:49 PM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: John Bradley <ve7jtb@ve7jtb.com>; openid-specs-ab@lists.openid.net Ab <openid-specs-a= b@lists.openid.net>; id-event@ietf.org; Marius Scurtescu <mscurtescu@google.com>
Subject: Re: [Id-event] Summarizing recent discussions on ID-Event to= ken draft

 

Mike, 

 

Speaking as editor the format you propose ONLY works i= f =E2=80=9Csub=E2=80=9D becomes a URI so that all event specs can use it.&nb= sp; Otherwise, OIDC becomes a special case which really kills the point of t= his work. It also makes the specification much much more complex. Maybe it is just me, but a complex spec generally implies com= plex implementation too.

 

If you want sub at the top level, that would mean tha= t the OIDC spec format would have to look like:

{

  "aud": "s6BhdRkqt3",

  "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30"= ,

  "iat": 1458668180,

  "exp": 1458668580,

  "events": [

  ],

  "sid": "08a5019c-17e1-4977-8f42-65a12843e= a02"

}

 

Given that events are signed (or should be), I wil= l object strongly within the OIDF that the event issuer and the token issuer= MUST be the same or that OIDF adopt a different format. Yes having iss b= e the same is a nice security convenience, but it imposes the architecture restriction that it be the sam= e server.  At scale, delivery of events may become a problem for large s= cale providers if they are also delivering tokens to relying parties. The re= striction isn=E2=80=99t really justified given the crypto alternative =E2=80=94 which was the whole point of using J= WT in the first place.

 

Per Justin=E2=80=99s comment, it seems elegant/trivia= l that a logout event simply has logout at the top level and an ID Token att= ached (though it might convey a lot of unneeded claims).  IMO, the OIDC= logout spec should only convey the ID Token JTI.  It is going to be rare that you log out all devices for a user.&= nbsp; To most users, it means clear SSO within this browser only!  One c= an argue that clearing all devices/sessions is a different event entirely. I= t is an account reset or lock-out action.

 

 

 

See my previous message, John, which wa= s a reply to Phil=E2=80=99s message that you also replied to, that contained= a logout claims example.  I=E2=80=99m not proposing to special-case the Connect Logout message in any way.  The =E2=80=9Ciss=E2=80=9D is t= he event issuer.  The other claims in the message are those defined by t= he event to be included, just like those for any other event.  Yes, the= logout message doesn=E2=80=99t include a second issuer, a second subject, an ID Token as a claim, or anything else complicated like that, because tho= se things aren=E2=80=99t needed for the logout use case.

 

As I=E2=80=99d written previously, the I= D Events spec should define the =E2=80=9Cevents=E2=80=9D claim, how to use a= n event name as a claim (when needed), and say that the event JWT must be signed by the issuer, and stop there.  Trying to micro-manage c= laims usage within an event will only result in the ID Events spec being har= der to use.  If we=E2=80=99d tried to similarly micro-manage JWT claims= usage, JWT would likely not have been the success that it is.

 

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

 

From: John Bradley [mailto:ve7jtb@ve7jtb.com] 
Sent: Thursday, August 11, 2016 12:22 PM
To: Phil Hunt (IDM) <phil.hunt@oracle.com= >
Cc: Mike Jones <Michael.Jones@microsoft.com>; id-event@ietf.org; Marius Scurtescu <mscurtescu@google.com&= gt;; openid-specs-ab@lists.openid.net Ab <openid-specs-ab@lists= .openid.net>
Subject: Re: [Id-event] Summarizing recent discussi= ons on ID-Event token draft

 

Not surprisingly a multipurpose message format will n= ot be as optimized as a single purpose one.

 

Connect itself doesn=E2=80=99t really have a conflict= around issuer the same entity sending the logout message is always the one t= hat created the id_token that it refers to.

 

Using the same format as id_token with the same seman= tics to identify the thing to be terminated makes sense from a purely openID= Connect point of view.

 

Oter messages that have different notions of subject a= nd are issued by different parties than the one that controls the subject ca= use issues when you try and fit them into the same format as an ID_Token, I g= rant you that.

 

It was mentioned that we need to differentiate betwee= n these events and id_tokens.  Mostly we need to do that in cases where= the token might be presented in the front channel.

 

To do that se do have mandatory claims for nonce and c= _hash or at_hash as well as the addition of events parameter to reduce confu= sion.   Now I admit that some people may still get that wrong,  an= d the removal of sub from the top level would remove any concern.  However Mike has a point that adoption may b= e hurt if we change the semantics too much.

 

I don=E2=80=99t see backchannel single logout being u= sed by many social login RP, it is a lot of work to maintain server side sta= te.   It is mostly an enterprise and large site sort of feature.=

That may or may not impact on if it is better to be s= imple and aligned with connect=E2=80=99s id token or more general purpose to= fit with other enterprise to SaaS features like SCIM events.<= /p>

 

I think the two directions lead to different formats.=   

 

The compromise of special casing Connect SLO and bodg= ing the formats together is probably the worst option.

 

John B.

 

 

On Aug 11, 2016, at 11:59 AM, Phil Hunt (IDM) <= phil.hunt@oracle.com> wrote:

 

How do you resolve conflicts on iss then?  The t= op level has to be the issuer of the event as the issuer signs. =

 

If one spec can use it all must be able to. I believ= e you previously objected to that saying sub must be as how id tokens define= them. But that isnt unique and requires iss. Now we would have sub at the top with an event issuer at the top and a sub i= ssuer in the extension. That seems incredibly complex not to mention awkward= . 

 

If we make sub a uri for all then it can work ass is= s from id token would not be needed. But i can see many objecting to the cha= nge in format. 

 

Why not have a logout be an event with an id token a= ttached for example?


Phil


On Aug 11, 2016, at 8:03 AM, Mike Jones <= Michael.Jones@microsoft.com> wrote:

The simple rule is that if the particul= ar event calls for the =E2=80=9Csub=E2=80=9D claim to be at the top level, t= hen it is.  This is no different from any other claim that an event might place at the top level.

 

The complexity arises if =E2=80=9Csub=E2= =80=9D is unnecessarily special-cased.  We shouldn=E2=80=99t do that, b= ecause it limits the applicability of the specification.

 

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

 

From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com] 
Sent: Thursday, August 11, 2016 9:40 AM
To: Mike Jones <= Michael.Jones@microsoft.com>
Cc: Marius Scurtescu <mscurtescu@google.com>; id-event@ietf.org
Subject: Re: [Id-event] Summarizing recent discussi= ons on ID-Event token draft

 

I think using sub at the top level leads to complexit= y. Eg Can you provide a rule for when top level is used or not by an individ= ual spec?  IMO. Top level should always be used the same way by all imp= lementers. 

 

Based on the calls at risc/connect, we discussed that= it would be best to move all event specifics to the event object area. This= way different events can have different event addressing (eg sub/iss, uri, j= it/iss). When iss is needed to uniquely qualify a sub, it can be provided without conflicting with the iss= uer of the event. Similarly jti and iss can be used for a revoked token with= out conflicting with the event jti. 

 

I plan to post a new draft shortly that will give som= e examples based on feedback from the openid risc/connect discussions.

 

We can always change again. 


Phil


On Aug 11, 2016, at 4:54 AM, Mike Jones <= Michael.Jones@microsoft.com> wrote:

No, I=E2=80=99m not saying that =E2=80=9C= sub=E2=80=9D cannot appear at the top level.  I=E2=80=99m saying that =E2= =80=9Csub=E2=80=9D will only occur at the top level if the particular event d= efines that =E2=80=9Csub=E2=80=9D is used in that way for that event.

 

There are probably use cases for multip= le events per message but I doubt there are use cases for multiple *unrel= ated* events per message.  By definition, related events that use top-level claims would need to use them in a compat= ible way.  I don=E2=80=99t see that as being a problem.

 

That being said, the predominant use ca= se is likely to be a single event per JWT.

 

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

 

From: Marius Scurtescu [mailto:mscurtescu@google.com] 
Sent: Tuesday, August 9, 2016 7:15 PM
To: Phil Hunt <p= hil.hunt@oracle.com>
Cc: Mike Jones <= Michael.Jones@microsoft.com>; id-event@ietf.org
Subject: Re: [Id-event] Summarizing recent discussi= ons on ID-Event token draft

 

Mike, are you suggesting that a sub claim can only sh= ow up at the event level and not at the top level:

 

In particular, the only thing that the spec should sa= y about the =E2=80=9Csub=E2=80=9D claim is that =E2=80=9CLike all other clai= ms other than =E2=80=98events=E2=80=99 and =E2=80=98iss=E2=80=99, whether th= e =E2=80=98sub=E2=80=99 claim is to be included with an event is entirely ev= ent-specific.

 

A top level sub and multiple events are incompatible I= MO.

 

Do we have a compelling reason to support multiple ev= ents per message?

 


Marius

 

On Tue, Aug 9, 2016 at 12:39 PM, Phil Hunt <phil.hunt@oracle.com> wrote:<= u>

I was referring to this in your email

"Define that an event name can be used a= s a top-level claim=E2=80=9D

 

 

Is this different from the event uri?

 

 

On Aug 9, 2016, at 12:12 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

 

I=E2=80=99m glad to hear that we agree o= n keeping it as simple and general-purpose as possible and that you agree wi= th my write-up.  I think we then have a good path forward.

 

I=E2=80=99m not sure what you mean by =E2= =80=9CI=E2=80=99m not sure that we need a =E2=80=9Cname=E2=80=9D. Wha= t is your intention there.=E2=80=9D  The only place I used the word =E2=80=9Cname=E2=80=9D was in my statement =E2= =80=9CDefine that an event name can be used as a top-level claim=E2=80=9D.&n= bsp; What I was trying to get at is was that if =E2=80=9Chttp://specs.openid.net/logout=E2=80=9D is used as an event name, that it can also be used as a claim name in the J= WT containing information about the event.  (Maybe I=E2=80=99m not usin= g the correct terminology, hence the unintended confusion = = J.)

 

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

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

 

From: Phil Hunt [mailto:phil.hunt@oracle.com] 
Sent: Tuesday, August 9, 2016 12:07 PM
To: Mike Jones <= Michael.Jones@microsoft.com>
Cc: id-event@ietf.o= rg
Subject: Re: [Id-event] Summarizing recent discussi= ons on ID-Event token draft

 

I didn=E2=80=99t cover this as I didn=E2=80=99t want t= o confuse people with too many things.

 

But I think we agree on all of the below.

 

I=E2=80=99m not sure that we need a =E2=80=9Cname=E2=80= =9D. What is your intention there.

 

 

On Aug 9, 2016, at 11:54 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

 

Thanks for writing this, Phil.  Un= fortunately, the summary below does not include my feedback, which at the es= sence, is to keep the ID Events data structure as simple and general-purpose as possible.  (I strongly believe that JWT i= s the success it is because we made JWT as simple and general-purpose as pos= sible, and we should follow this successful example and do the same here.)

 

I believe that the ID Events spec needs= to include these things, and these things only:

=C2=B7&nbs= p;      Defi= ne of the =E2=80=9Cevents=E2=80=9D claim

=C2=B7&nbs= p;      Defi= ne that an event name can be used as a top-level claim

=C2=B7&nbs= p;      Requ= ire that =E2=80=9Ciss=E2=80=9D be included and that the JWT be signed by the is= suer

=C2=B7&nbs= p;      Incl= ude a statement along the lines of =E2=80=9CThe claims to be included with any p= articular event are to be defined by the event=E2=80=9D=

 

And I=E2=80=99d stop there.

 

It should be entirely up to application= s to say what claims are included with events they define and what their for= mat and meanings are.  Then the ID Events spec will be as general-purpose as possible, with it being natural for it to be u= sed in essentially all JSON Event contexts.

 

As soon as we start putting restriction= s on the use of particular claims by events, we=E2=80=99re making the ID Eve= nts spec less general-purpose and less natural to use.  In particular, the only thing that the spec should say about the =E2=80=9Cs= ub=E2=80=9D claim is that =E2=80=9CLike all other claims other than =E2=80=98= events=E2=80=99 and =E2=80=98iss=E2=80=99, whether the =E2=80=98sub=E2=80=99= claim is to be included with an event is entirely event-specific.  The= claims to be included with any particular event are explicitly outside the scope of this specification.=E2= =80=9D

 

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

 

From: Id-event= [mailto:id-event-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Tuesday, August 9, 2016 10:19 AM
To: id-event@ietf.o= rg
Subject: [Id-event] Summarizing recent discussions o= n ID-Event token draft

 

I thought I would update the list on some discussions= that have been happening over in the OpenID Connect and RISC working groups= conference calls.

 

These discussions have been about the core spec and t= he role of =E2=80=9Ctop-level=E2=80=9D attributes vs. event =E2=80=9Cextensi= on=E2=80=9D attributes. 

 

In particular should =E2=80=9Csub=E2=80=9D be used in= the top level to =E2=80=9Cpoint=E2=80=9D to the subject (in the broader eng= lish sense) of the event, or should it be constrained to the SAML/ID Token d= efinition which is the authenticated user.  

 

Taken in the narrower definition, it is important to o= bserve that in an ID Token, =E2=80=9Csub=E2=80=9D and =E2=80=9Ciss=E2=80=9D g= o together.  The issuer provides the context for the authenticated subj= ect identifier. The problem with events, is that it might not be the AS (or OP) which is issuing the event.  

 

To summarize a fair amount of discussion, the feeling= seems to be the following:

 

*  The Event Token top level attributes should b= e fairly limited and not include the sub attribute.  

=

*  For events that are about a user, the relevan= t event specification may include a =E2=80=9Csub=E2=80=9D attribute within t= he event=E2=80=99s sub-object and not in the top-level. Further that sub-obj= ect can also include the issuer of the user.  

* The top-level =E2=80=9Ciss=E2=80=9D shall mean the i= ssuer of the event where the state change occurred.

*  =E2=80=9Csub=E2=80=9D should not be present i= n the top level structure.  Also, =E2=80=9Cevents=E2=80=9D must also be= present.

 

Here would be a new example logout:

= 
{
  <=E2=80=94 top level is about the event itself ->
  "iss": "https://server.example.com",
  "aud": "s6BhdRkqt3",=

  "jti": "3d0c3cf797584bd193bd0fb1bd=
4e7d30",
  "iat": 1458668180,
  "exp": 1458668580,
  "events": [

    "https://specs.openid.net/logout"=



  ],


  "h=
ttps://specs.openid.net/logout": {

    <- This level is de=
fined entirely by the event URI->


    "iss": "https://oidc.example.com",=



    =E2=80=9Cjti": "08a501=
9c-17e1-4977-8f42-65a12843ea02=E2=80=9D,


    "sub"=
: "248289761001=E2=80=9D,


    =E2=80=
=9Cexp=E2=80=9D: <ID token expiry>


  }


}












 






















In the above example note that the =E2=80=9Cevent=E2=80=
=9D object can have its own iss and subject (sub or jti) that have meaning w=
ithin the context of an OpenID OP provider.  The issuer of the event ca=
n be different (the top-level) and represents the
 entity that signs the event (if it is signed).






















 






















The top-level attributes identify an individual event=
 and are used to validate the event (signing etc).  Where as the nested=
 object contains all of the data about the event and is defined by the profi=
ling specification (e.g. a possible
 OpenID Logout Event spec).  In this case, in OpenID, logging out usual=
ly translates into revoking an ID Token. Thus the =E2=80=9Cjti=E2=80=9D for t=
he ID token (08a5019c...843ea02) is included in the Logout object.=























 






















Side note.  Regarding =E2=80=9Clogout=E2=80=9D, i=
t might be useful to include the expiry of the ID Token in case the subscrib=
er has not yet received an ID Token. This would let the subscriber know how l=
ong it needs to keep the revocation information for. 
 IOW=E2=80=A6after the the ID Token is expired, the subscriber would no long=
er need to track the revocation state.






















 






















It is also good to observe that the =E2=80=9Caud=E2=80=
=9D at the top level describes the subscriber of the event.  This may a=
lso be different then the original audience of the ID Token.





















 






















So to conclude. By making top-level attributes strict=
ly about the events own validation, and nested objects about the event, we a=
void collisions in definitions such as the issuer of the event, vs. the orig=
inal issuer of a security assertion.






















 






















I hope I=E2=80=99ve gotten everyone=E2=80=99s feedbac=
k correct here. Lets continue to discuss. I will revise the draft to follow t=
he groups thinking here.






















 

 

_______________________________________________=
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/i= d-event

 

_______________________________________________<= br> Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/i= d-event

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

 

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


____________________= ___________________________
Id-event mailing list
= Id-event@ietf.org
<= span>https://www.= ietf.org/mailman/listinfo/id-event
<= /html>= --Apple-Mail-8539D404-24A6-4E4D-8860-349A51A33717-- From nobody Thu Aug 11 14:52:29 2016 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 B4D2212D813 for ; Thu, 11 Aug 2016 14:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.467 X-Spam-Level: X-Spam-Status: No, score=-5.467 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=-1.247, 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 jhhBAL6RsQyB for ; Thu, 11 Aug 2016 14:52: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 4F8D112D7C6 for ; Thu, 11 Aug 2016 14:52:27 -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 u7BLqQ6m024014 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 11 Aug 2016 21:52:26 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u7BLqPCs000872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 11 Aug 2016 21:52:25 GMT Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u7BLqOTb019775; Thu, 11 Aug 2016 21:52:25 GMT Received: from [192.168.1.15] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 11 Aug 2016 14:52:24 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_C47E33E0-782E-40FF-B07E-6DA04DDEC170" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Phil Hunt Date: Thu, 11 Aug 2016 14:52:22 -0700 Message-Id: <806310CE-D8EE-4C8F-A266-1A2C9FB757ED@oracle.com> References: <147094715054.21314.10243750537820543398.idtracker@ietfa.amsl.com> To: id-event@ietf.org X-Mailer: Apple Mail (2.3124) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: openid-specs-risc@lists.openid.net, "openid-specs-ab@lists.openid.net Ab" Subject: [Id-event] Fwd: New Version Notification for draft-hunt-idevent-token-02.txt X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 11 Aug 2016 21:52:29 -0000 --Apple-Mail=_C47E33E0-782E-40FF-B07E-6DA04DDEC170 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This is an updated draft and contains a lot of the items from the = discussion today. Based on feedback from OpenID RISC and Connect WG calls, I have moved = the =E2=80=9Csub=E2=80=9D in the examples to the event extension area. = This allows each event spec to decide how they define or address a = subject. It also avoids conflicts around =E2=80=9Ciss=E2=80=9D when the = event issuer is not the namespace of the =E2=80=9Csub=E2=80=9D claim. The examples now show a consistent parsing pattern where the top level = of the JSON structure is essentially an =E2=80=9Cenvelope=E2=80=9D that = describes and validates the event from a publisher to a subscriber, and = the nested JSON objects are the =E2=80=9Cpayload=E2=80=9D for the event. The spec has been renamed to Security Event Token as part of making the = terminology more consistent and to reflect that some events are not = specifically about identity but are about other related things like IP = addresses, sessions, tokens, web resources etc. I recognize we don=E2=80=99t yet have consensus on this draft, but = I=E2=80=99ve gone ahead and published draft 02 so the broader community = can compare draft 02 with draft 01 to see the differences in event = formats. I expect to see more changes as the discussion continues. Phil @independentid www.independentid.com = phil.hunt@oracle.com = > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-hunt-idevent-token-02.txt > Date: August 11, 2016 at 1:25:50 PM PDT > To: "William Denniss" , "Phil Hunt" = , "Morteza Ansari" >=20 >=20 > A new version of I-D, draft-hunt-idevent-token-02.txt > has been successfully submitted by Phil Hunt and posted to the > IETF repository. >=20 > Name: draft-hunt-idevent-token > Revision: 02 > Title: Security Event Token (SET) > Document date: 2016-08-11 > Group: Individual Submission > Pages: 15 > URL: = https://www.ietf.org/internet-drafts/draft-hunt-idevent-token-02.txt > Status: = https://datatracker.ietf.org/doc/draft-hunt-idevent-token/ > Htmlized: = https://tools.ietf.org/html/draft-hunt-idevent-token-02 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-hunt-idevent-token-02 >=20 > Abstract: > This specification defines the Security Event token which may be > distributed via a protocol such as HTTP. A Security Event Token > (SET) is based on the JSON Web Token and may be optionally signed > and/or encrypted. A SET describes a statement of fact that may be > shared by an event publisher with registered subscribers. >=20 >=20 >=20 >=20 > 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. >=20 > The IETF Secretariat >=20 --Apple-Mail=_C47E33E0-782E-40FF-B07E-6DA04DDEC170 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 This is an updated draft and contains a lot of the items from = the discussion today.

Based on feedback from OpenID RISC and Connect WG calls, I = have moved the =E2=80=9Csub=E2=80=9D in the examples to the event = extension area. This allows each event spec to decide how they define or = address a subject. It also avoids conflicts around =E2=80=9Ciss=E2=80=9D = when the event issuer is not the namespace of the =E2=80=9Csub=E2=80=9D = claim.

The examples now show a consistent parsing pattern where the = top level of the JSON structure is essentially an =E2=80=9Cenvelope=E2=80=9D= that describes and validates the event from a publisher to a = subscriber, and the nested JSON objects are the =E2=80=9Cpayload=E2=80=9D = for the event.

The spec has been renamed to Security Event Token as part of = making the terminology more consistent and to reflect that some events = are not specifically about identity but are about other related things = like IP addresses, sessions, tokens, web resources etc.

I recognize we don=E2=80=99= t yet have consensus on this draft, but I=E2=80=99ve gone ahead and = published draft 02 so the broader community can compare draft 02 with = draft 01 to see the differences in event formats.  I expect to see = more changes as the discussion continues.




Begin forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-hunt-idevent-token-02.txt
Date: = August 11, 2016 at 1:25:50 PM = PDT
To: = "William Denniss" <wdenniss@google.com>, "Phil Hunt" <phil.hunt@yahoo.com>, "Morteza Ansari" <morteza.ansari@cisco.com>

A new version = of I-D, draft-hunt-idevent-token-02.txt
has been = successfully submitted by Phil Hunt and posted to the
IETF = repository.

Name: = draft-hunt-idevent-token
Revision: 02
Title:= = Security Event Token (SET)
Document date: = 2016-08-11
Group: Individual Submission
Pages:= = 15
URL: =            https://www.ietf.org/internet-drafts/draft-hunt-idevent-token-0= 2.txt
Status: =         https://datatracker.ietf.org/doc/draft-hunt-idevent-token/<= br class=3D"">Htmlized:       https://tools.ietf.org/html/draft-hunt-idevent-token-02
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-hunt-idevent-token-02=

Abstract:
=   This specification defines the Security Event token which = may be
  distributed via a protocol such as = HTTP.  A Security Event Token
  (SET) is = based on the JSON Web Token and may be optionally signed
=   and/or encrypted.  A SET describes a statement of fact = that may be
  shared by an event publisher with = registered subscribers.




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.

The IETF = Secretariat


= --Apple-Mail=_C47E33E0-782E-40FF-B07E-6DA04DDEC170-- From nobody Wed Aug 17 07:21:38 2016 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 38DCF12DCF2 for ; Wed, 17 Aug 2016 07:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.468 X-Spam-Level: X-Spam-Status: No, score=-5.468 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=-1.247, 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 hdRtCfMMHLBU for ; Wed, 17 Aug 2016 07:21: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 3B8A712DCC6 for ; Wed, 17 Aug 2016 07:21:19 -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 u7HELFqQ023060 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 17 Aug 2016 14:21:15 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u7HELEV6026762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 17 Aug 2016 14:21:15 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 u7HELE76008393; Wed, 17 Aug 2016 14:21:14 GMT Received: from [10.0.1.4] (/24.86.208.48) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 17 Aug 2016 07:21:13 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (13G35) In-Reply-To: Date: Wed, 17 Aug 2016 07:21:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <20BC519D-B4FC-47A3-825D-AC5D4BA4F097@oracle.com> References: <147094715054.21314.10243750537820543398.idtracker@ietfa.amsl.com> <806310CE-D8EE-4C8F-A266-1A2C9FB757ED@oracle.com> <74cab6ab-7a5a-8be1-255e-ca97821d040e@connect2id.com> <257686BD-0526-4233-86C3-4F6F12692BFF@oracle.com> To: Vladimir Dzhuvinov X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: openid-specs-ab@lists.openid.net, id-event@ietf.org Subject: Re: [Id-event] [Openid-specs-ab] New Version Notification for draft-hunt-idevent-token-02.txt X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 17 Aug 2016 14:21:37 -0000 Vladimir, Cc'ing back to the id-event list.=20 I will put these in for consideration for the next draft. I have already re-= worked some of the text based on feedback from Sarah as well. Hope to check i= nto github later today.=20 One thing for the group to discuss:=20 Do we want?: Option A: a single value event type attribute with an optional extensions at= tribute to force only a single main event type per SET? Option B: Or, stay with current approach and clarify draft text that the int= ent is a single event with extensions (but a combo event would still be poss= ible)? Please respond on the id-event list.=20 Phil > On Aug 16, 2016, at 10:30 PM, Vladimir Dzhuvinov = wrote: >=20 >=20 >> On 16/08/16 19:39, Phil Hunt wrote: >> Vladimir, >>=20 >> The discussion on the id-event list has been that only a single event sho= uld be expressed at a time. > Thanks Phil for clarifying that a SET describes a single event. Could > that be stated explicitly in the spec? >=20 >=20 >> The reason for multi-event uris is to allow for extensions. For example,= you could have an OIDC logout event, but you might also have an extension t= o categorize the security event as a threat/observation/indicator (CTI Cybox= terms) etc. In figure 1 there is an example of an account reset having an e= xtension showing the number of resets. > I see now. I think I got confused by the name of the "events" attribute. > What if it's named "event" instead? >=20 >> The other use case is that the same state change might infer two events f= rom overlapping profiles. For example an account reset in SCIM could be exp= ressed as both a SCIM Account reset and a RISC account reset =E2=80=94 since= different specs may have overlapping definitions that are not quite the sam= e. Should a publisher publish one combined event to reflect that an event c= an be interpreted in two ways, or should two separate events be published fo= r the same state change? The discussion so far has been it should be two se= parate events because the =E2=80=9Caud=E2=80=9D is likely different. >>=20 >> So to sum up, I think the current thought is that an event should be one m= ain event type plus any additional extensions for a single event. >=20 > I would like to propose the following wording in section 2.1: >=20 > event: A multi-valued String that contains one or more URIs representing > the types of the event. [...] >=20 >=20 >=20 > Vladimir >=20 > PS: The second last paragraph on p. 4 has some bits of text left over > from a previous edit. >=20 >> Phil >>=20 >> @independentid >> www.independentid.com phil.hunt@oracle.com= >>=20 >>=20 >>=20 >>=20 >>=20 >>> On Aug 16, 2016, at 8:55 AM, Vladimir Dzhuvinov via Openid-specs-ab wrote: >>>=20 >>> Hi Phil, >>>=20 >>> The spec appears well structured. Putting "sub" into an unambiguous cont= ext was a great idea!=20 >>>=20 >>> I have a question about the proposed format: >>>=20 >>> Each event in the "events" array is an URI, and may be enriched with ext= ra info / context represented as a top-level JSON object that has the event U= RI as key. What if the issuer needs to emit multiple events with identical U= RIs in the "events" array, and they all require an additional context? >>>=20 >>>=20 >>>=20 >>> { >>> "events":[ >>> "https://example.com/event-abc" , >>> "https://example.com/event-abc" >>> ], >>> "https://example.com/event-abc" :{ >>> "xyz":5 >>> }, >>> "https://example.com/event-abc" :{ >>> "xyz":10 >>> } >>> } >>>=20 >>>=20 >>> Vladimir >>>=20 >>>=20 >>>=20 >>>> On 12/08/16 00:52, Phil Hunt via Openid-specs-ab wrote: >>>> This is an updated draft and contains a lot of the items from the discu= ssion today. >>>>=20 >>>> Based on feedback from OpenID RISC and Connect WG calls, I have moved t= he =E2=80=9Csub=E2=80=9D in the examples to the event extension area. This a= llows each event spec to decide how they define or address a subject. It als= o avoids conflicts around =E2=80=9Ciss=E2=80=9D when the event issuer is not= the namespace of the =E2=80=9Csub=E2=80=9D claim. >>>>=20 >>>> The examples now show a consistent parsing pattern where the top level o= f the JSON structure is essentially an =E2=80=9Cenvelope=E2=80=9D that descr= ibes and validates the event from a publisher to a subscriber, and the neste= d JSON objects are the =E2=80=9Cpayload=E2=80=9D for the event. >>>>=20 >>>> The spec has been renamed to Security Event Token as part of making the= terminology more consistent and to reflect that some events are not specifi= cally about identity but are about other related things like IP addresses, s= essions, tokens, web resources etc. >>>>=20 >>>> I recognize we don=E2=80=99t yet have consensus on this draft, but I=E2= =80=99ve gone ahead and published draft 02 so the broader community can comp= are draft 02 with draft 01 to see the differences in event formats. I expec= t to see more changes as the discussion continues. >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com phil.hunt@oracle.com >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>> Begin forwarded message: >>>>>=20 >>>>> From: internet-drafts@ietf.org >>>>> Subject: New Version Notification for draft-hunt-idevent-token-02.txt >>>>> Date: August 11, 2016 at 1:25:50 PM PDT >>>>> To: "William Denniss" , "Phil Hunt" , "Morteza= Ansari" >>>>>=20 >>>>>=20 >>>>> A new version of I-D, draft-hunt-idevent-token-02.txt >>>>> has been successfully submitted by Phil Hunt and posted to the >>>>> IETF repository. >>>>>=20 >>>>> Name: draft-hunt-idevent-token >>>>> Revision: 02 >>>>> Title: Security Event Token (SET) >>>>> Document date: 2016-08-11 >>>>> Group: Individual Submission >>>>> Pages: 15 >>>>> URL: https://www.ietf.org/internet-drafts/draft-hunt-ideven= t-token-02.txt >>>>> Status: https://datatracker.ietf.org/doc/draft-hunt-idevent-to= ken/ >>>>> Htmlized: https://tools.ietf.org/html/draft-hunt-idevent-token-0= 2 >>>>> Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-hunt-idevent= -token-02 >>>>>=20 >>>>> Abstract: >>>>> This specification defines the Security Event token which may be >>>>> distributed via a protocol such as HTTP. A Security Event Token >>>>> (SET) is based on the JSON Web Token and may be optionally signed >>>>> and/or encrypted. A SET describes a statement of fact that may be >>>>> shared by an event publisher with registered subscribers. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Please note that it may take a couple of minutes from the time of subm= ission >>>>> until the htmlized version and diff are available at tools.ietf.org. >>>>>=20 >>>>> The IETF Secretariat >>>>=20 >>>> _______________________________________________ >>>> Openid-specs-ab mailing list >>>> Openid-specs-ab@lists.openid.net >>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab >>> --=20 >>> Vladimir Dzhuvinov >>> _______________________________________________ >>> Openid-specs-ab mailing list >>> Openid-specs-ab@lists.openid.net >>> http://lists.openid.net/mailman/listinfo/openid-specs-ab >=20 > --=20 > Vladimir Dzhuvinov :: vladimir@connect2id.com >=20 >=20 From nobody Thu Aug 18 09:10:39 2016 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 39E1E12DC83; Thu, 18 Aug 2016 09:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.448 X-Spam-Level: X-Spam-Status: No, score=-5.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.247, 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 yJ7GsrTn3YFy; Thu, 18 Aug 2016 09:10:25 -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 DAC1E12DC58; Thu, 18 Aug 2016 09:10:24 -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 u7IGANHg003306 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 18 Aug 2016 16:10:23 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u7IGANpe003390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 18 Aug 2016 16:10:23 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 u7IGAM4R024231; Thu, 18 Aug 2016 16:10:22 GMT Received: from [10.0.1.5] (/24.86.208.48) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 18 Aug 2016 09:10:22 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_8464F83E-BCE7-4B74-A205-EEDDCDEC0735" Message-Id: <55C42D22-868C-4B6D-B027-0A9404636075@oracle.com> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Date: Thu, 18 Aug 2016 09:10:20 -0700 References: <147153621561.27779.14649810501472804929.idtracker@ietfa.amsl.com> To: id-event@ietf.org X-Mailer: Apple Mail (2.3124) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: openid-specs-risc@lists.openid.net, "openid-specs-ab@lists.openid.net Ab" , "scim@ietf.org WG" Subject: [Id-event] Fwd: New Version Notification for draft-hunt-idevent-token-03.txt X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 18 Aug 2016 16:10:29 -0000 --Apple-Mail=_8464F83E-BCE7-4B74-A205-EEDDCDEC0735 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Draft 03 has been published. This includes editorial clarifications to: * Define the outer layer as a SET =E2=80=9Cenvelope=E2=80=9D, vs = embedded JSON as =E2=80=9Cpayload=E2=80=9D * Clarify that only a single event should be conveyed plus optional = extensions. * General edits to improve readability * Register the =E2=80=9Cevents=E2=80=9D claim as a JWT attribute (see = IANA considerations) Many thanks to Mike and Sarah and who contributed significant editorial = feedback. Phil @independentid www.independentid.com = phil.hunt@oracle.com = > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-hunt-idevent-token-03.txt > Date: August 18, 2016 at 9:03:35 AM PDT > To: "Michael B. Jones" , "William Denniss" = , "Phil Hunt" , "Morteza = Ansari" , "Michael Jones" >=20 >=20 > A new version of I-D, draft-hunt-idevent-token-03.txt > has been successfully submitted by Phil Hunt and posted to the > IETF repository. >=20 > Name: draft-hunt-idevent-token > Revision: 03 > Title: Security Event Token (SET) > Document date: 2016-08-18 > Group: Individual Submission > Pages: 16 > URL: = https://www.ietf.org/internet-drafts/draft-hunt-idevent-token-03.txt > Status: = https://datatracker.ietf.org/doc/draft-hunt-idevent-token/ > Htmlized: = https://tools.ietf.org/html/draft-hunt-idevent-token-03 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-hunt-idevent-token-03 >=20 > 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) and may be > optionally signed and/or encrypted. A SET describes a statement of > fact that may be shared by an event publisher with event = subscribers. >=20 >=20 >=20 >=20 > 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. >=20 > The IETF Secretariat >=20 --Apple-Mail=_8464F83E-BCE7-4B74-A205-EEDDCDEC0735 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Draft 03 has been published.

This includes editorial clarifications = to:
* Define the outer layer as a SET = =E2=80=9Cenvelope=E2=80=9D, vs embedded JSON as =E2=80=9Cpayload=E2=80=9D<= /div>
* Clarify that only a single event should be = conveyed plus optional extensions.
* General edits = to improve readability
* Register the =E2=80=9Cevents= =E2=80=9D claim as a  JWT attribute (see IANA = considerations)

Many thanks to Mike and Sarah and who contributed significant = editorial feedback.




Begin forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-hunt-idevent-token-03.txt
Date: = August 18, 2016 at 9:03:35 AM = PDT
To: = "Michael B. Jones" <mbj@microsoft.com>, = "William Denniss" <wdenniss@google.com>, "Phil Hunt" <phil.hunt@yahoo.com>, "Morteza Ansari" <morteza.ansari@cisco.com>, "Michael Jones" <mbj@microsoft.com>

A new version of I-D, draft-hunt-idevent-token-03.txt
has been successfully submitted by Phil Hunt and posted to = the
IETF repository.

Name: = draft-hunt-idevent-token
Revision: 03
Title:= = Security Event Token (SET)
Document date: = 2016-08-18
Group: Individual Submission
Pages:= = 16
URL: =            https://www.ietf.org/internet-drafts/draft-hunt-idevent-token-0= 3.txt
Status: =         https://datatracker.ietf.org/doc/draft-hunt-idevent-token/<= br class=3D"">Htmlized:       https://tools.ietf.org/html/draft-hunt-idevent-token-03
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-hunt-idevent-token-03=

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) and may be
=   optionally signed and/or encrypted.  A SET describes a = statement of
  fact that may be shared by an = event publisher with event subscribers.




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.

The IETF Secretariat


= --Apple-Mail=_8464F83E-BCE7-4B74-A205-EEDDCDEC0735-- From nobody Fri Aug 19 07:42:08 2016 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 90F1F12DB1F; Fri, 19 Aug 2016 07:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 Xdzv636ueztv; Fri, 19 Aug 2016 07:42:01 -0700 (PDT) Received: from p3plsmtpa06-07.prod.phx3.secureserver.net (p3plsmtpa06-07.prod.phx3.secureserver.net [173.201.192.108]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EADC812DB12; Fri, 19 Aug 2016 07:42:00 -0700 (PDT) Received: from [192.168.1.3] ([79.100.92.246]) by p3plsmtpa06-07.prod.phx3.secureserver.net with id Z2hx1t0015JvR27012hyRt; Fri, 19 Aug 2016 07:42:00 -0700 To: Phil Hunt , id-event@ietf.org References: <147153621561.27779.14649810501472804929.idtracker@ietfa.amsl.com> <55C42D22-868C-4B6D-B027-0A9404636075@oracle.com> From: Vladimir Dzhuvinov Organization: Connect2id Ltd. Message-ID: <1aa732d5-4f97-2c58-f4ee-37947761fc95@connect2id.com> Date: Fri, 19 Aug 2016 17:41:56 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <55C42D22-868C-4B6D-B027-0A9404636075@oracle.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070008030103030807080802" Archived-At: Cc: openid-specs-risc@lists.openid.net, "openid-specs-ab@lists.openid.net Ab" , "scim@ietf.org WG" Subject: Re: [Id-event] [Openid-specs-ab] Fwd: New Version Notification for draft-hunt-idevent-token-03.txt X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 19 Aug 2016 14:42:04 -0000 This is a cryptographically signed message in MIME format. --------------ms070008030103030807080802 Content-Type: multipart/alternative; boundary="------------E4C99828B441BB83D126E6F5" This is a multi-part message in MIME format. --------------E4C99828B441BB83D126E6F5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I just went through the new version, the text has a much better structure and clarity now. Thanks everyone! On 18/08/16 19:10, Phil Hunt via Openid-specs-ab wrote: > Draft 03 has been published. > > This includes editorial clarifications to: > * Define the outer layer as a SET =93envelope=94, vs embedded JSON as =93= payload=94 > * Clarify that only a single event should be conveyed plus optional ext= ensions. > * General edits to improve readability > * Register the =93events=94 claim as a JWT attribute (see IANA conside= rations) > > Many thanks to Mike and Sarah and who contributed significant editorial= feedback. > > Phil > > @independentid > www.independentid.com phil.hunt@oracle.c= om > > > > > >> Begin forwarded message: >> >> From: internet-drafts@ietf.org >> Subject: New Version Notification for draft-hunt-idevent-token-03.txt >> Date: August 18, 2016 at 9:03:35 AM PDT >> To: "Michael B. Jones" , "William Denniss" , "Phil Hunt" , "Morteza Ansari" , "Michael Jones" >> >> >> A new version of I-D, draft-hunt-idevent-token-03.txt >> has been successfully submitted by Phil Hunt and posted to the >> IETF repository. >> >> Name: draft-hunt-idevent-token >> Revision: 03 >> Title: Security Event Token (SET) >> Document date: 2016-08-18 >> Group: Individual Submission >> Pages: 16 >> URL: https://www.ietf.org/internet-drafts/draft-hunt-ideven= t-token-03.txt >> Status: https://datatracker.ietf.org/doc/draft-hunt-idevent-to= ken/ >> Htmlized: https://tools.ietf.org/html/draft-hunt-idevent-token-0= 3 >> Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-hunt-idevent= -token-03 >> >> 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) and may be >> optionally signed and/or encrypted. A SET describes a statement of >> fact that may be shared by an event publisher with event subscribers= =2E >> >> >> >> >> Please note that it may take a couple of minutes from the time of subm= ission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> > > > > _______________________________________________ > Openid-specs-ab mailing list > Openid-specs-ab@lists.openid.net > http://lists.openid.net/mailman/listinfo/openid-specs-ab --=20 Vladimir Dzhuvinov :: vladimir@connect2id.com --------------E4C99828B441BB83D126E6F5 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

I just went through the new version, the text has a much better structure and clarity now.

Thanks everyone!


On 18/08/16 19:10, Phil Hunt via Openid-specs-ab wrote:
Draft 03 has been published.

This includes editorial clarifications to:
* Define the outer layer as a SET =93envelope=94, vs embedded JSON as =93=
payload=94
* Clarify that only a single event should be conveyed plus optional exten=
sions.
* General edits to improve readability
* Register the =93events=94 claim as a  JWT attribute (see IANA considera=
tions)

Many thanks to Mike and Sarah and who contributed significant editorial f=
eedback.

Phil

@independentid
www.independentid.com <http://www.independentid.com/>=
phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>






Begin forwarded message:

From: internet-drafts@ietf.org
Subject: New Version Notification for draft-hunt-idevent-token-03.txt
Date: August 18, 2016 at 9:03:35 AM PDT
To: "Michael B. Jones" <mbj@microsoft.com>, "William Denniss" <wde=
nniss@google.com>, "Phil Hunt" <phil.hunt@yahoo.com>, "Mor=
teza Ansari" <morteza.ansari@cisco.com>, "Michael Jones" <mbj=
@microsoft.com>


A new version of I-D, draft-hunt-idevent-token-03.txt
has been successfully submitted by Phil Hunt and posted to the
IETF repository.

Name:		draft-hunt-idevent-token
Revision:	03
Title:		Security Event Token (SET)
Document date:	2016-08-18
Group:		Individual Submission
Pages:		16
URL:            https://www.ietf.=
org/internet-drafts/draft-hunt-idevent-token-03.txt
Status:         https://datatracker.ietf.or=
g/doc/draft-hunt-idevent-token/
Htmlized:       https://tools.ietf.org/html/dr=
aft-hunt-idevent-token-03
Diff:           https://www.ietf.org/r=
fcdiff?url2=3Ddraft-hunt-idevent-token-03

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) and may be
  optionally signed and/or encrypted.  A SET describes a statement of
  fact that may be shared by an event publisher with event subscribers.




Please note that it may take a couple of minutes from the time of submiss=
ion
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat






_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab@lists.openid.net
http://lists.openid.net/mailman/listinfo/open=
id-specs-ab


--=20
Vladimir Dzhuvinov :: vladimir@connect2id.com
--------------E4C99828B441BB83D126E6F5-- --------------ms070008030103030807080802 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfwwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggVFMIIELaADAgECAhBvIAvByRn0gXptBJbNZg3jMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTYwNDA1MDAwMDAwWhcNMTcwNDA1MjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkB Fhd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAL/GlaryvhrL+eLYe+8Pv6D/sITLb5c2D5oaq6drPbcqP06xnyLgeFlIwzshIHi5+/Ib fwSSXRzCDihXBfPlbv2Yf7C0F7QwUYNnqvxfnIZvu/6YFXkWt6Z5h5wvnbFmHWZBiBM8cEMP qdT7myXDKuHSYvpiCFnIAHJOeoyBRV1I8kyupPe9aBkcYmwAyMjMRgeR92iV4TfTSx4CMRax OHwa+WUAc2mjWiZOxyxTByORzm2wB2izX/DoeSwcN9mliRAZQ3eBXQD/HoO0LBIX3MXCp9Ry wHIhz+Qy3mR0VgUu2gGu1r0lLIGwxKE4kEO1I7aBf5hQK/wVKcMyMMpNnU0CAwEAAaOCAfUw ggHxMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBSCdqr1QGt7 r/f9VkCCmYSI3t5aDjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0w OwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u ZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsG AQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P RE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJA Y29ubmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAFClbz5g+/TKUP9zpmoRdZymgYrU fgq1UlnzLcgI3IH46LaMMMzUCRn7tz8OM2igQEqpSW9u80W3jaYsRLUdySvE6Jxr9xVPVDGu JMAenNDS3sgNsKvUcCIeQYYTG4/oYTcuV6jtXTSDK0Y8NQ0pNEg8BnQz3V+nPXYC3/CWoFQ+ 4InVPLGTZedK+yev6ee6wWWL3neskkSsYpwW1qTWtjHQcNw2eBphxRq5aNM9F3wKGdkUHKUJ 4mof2ckALH5SO/n0GGR58cgrtfuD/fcqvfsTtiMCHk6oW2ZE5Ty93aDvEhYo5RrA0TpFGoOA m33FY3lP8EGzGel61qKU5nDH1hUxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZ BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBvIAvByRn0gXptBJbNZg3jMA0GCWCG SAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNjA4MTkxNDQxNTZaMC8GCSqGSIb3DQEJBDEiBCA8tzZw3Jmu7Wd6FtTcBuOLVqand33G Zt836F0G8/tCtzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQbyALwckZ9IF6bQSWzWYN4zCBwwYLKoZI hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQbyALwckZ9IF6bQSWzWYN4zANBgkqhkiG9w0BAQEFAASCAQAyrsq+6ME5 Zm+6gcHUwjY7mwwduJSmPmngH0af9E8pAFTNT2HB83AVcj2HU8ONLO3++QkMC8U942qg8+/J yBoJ+w35WRqPpM8Rd1eaBmBw6YFJAcr5tSUIbjEU/JEo7NSFR+lNkhqBdBY4lv1GLfP/44wc IFdaGPXQlWIVy3ZGuBVJlFGgTvJB3lCclz31n1XZvxVDHDZ86L6rPaBmLTTUPD7eivyRdQtm cYyXSfWKBEqImHZBAuTIwI8gBjnezmlgD1n7wlpnarG8dXKJv3aHz9XnwAKobIEzUIluVCug zpcGO6Uoi/n+O8doB1y5flt6Kv4FF+IaVkfk/BgCgZ4cAAAAAAAA --------------ms070008030103030807080802-- From nobody Sat Aug 20 16:14:14 2016 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 84D2912D731 for ; Sat, 20 Aug 2016 16:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.75 X-Spam-Level: X-Spam-Status: No, score=-4.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.548, 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 bDawJNCi56K4 for ; Sat, 20 Aug 2016 16:14:11 -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 73BD312D661 for ; Sat, 20 Aug 2016 16:14:11 -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 u7KNE8wq002558 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 20 Aug 2016 23:14:09 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u7KNE78v011306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 20 Aug 2016 23:14:07 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u7KNE5SC009114; Sat, 20 Aug 2016 23:14:06 GMT Received: from [192.168.1.6] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 20 Aug 2016 16:14:05 -0700 From: "Phil Hunt (IDM)" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Message-Id: <3957B53A-D016-4C9C-A164-F90C7FB983C8@oracle.com> Date: Sat, 20 Aug 2016 16:14:03 -0700 To: id-event@ietf.org X-Mailer: iPhone Mail (13G35) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: William Denniss , Mike Jones , Leif Johansson , Morteza Ansari , Marius Scurtescu Subject: [Id-event] Ietf97 idevent meeting? X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 20 Aug 2016 23:14:12 -0000 We have been making a lot of progress on the core id event draft. It would b= e good to have an official meeting.=20 Maybe the best thing would be to adopt the charter and get it going? There are a few items more to talk through like timing issues in the draft t= o avoid unanticipated feedback concerns (discussed in issue 1000 on openid c= onnect).=20 Thanks Phil= From nobody Sat Aug 20 19:11:34 2016 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 882CB12D0F6 for ; Sat, 20 Aug 2016 19:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.467 X-Spam-Level: X-Spam-Status: No, score=-7.467 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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.548] 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 bGHhFtzmx15o for ; Sat, 20 Aug 2016 19:11:32 -0700 (PDT) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by ietfa.amsl.com (Postfix) with SMTP id EB27B12D0A9 for ; Sat, 20 Aug 2016 19:11:31 -0700 (PDT) Received: (qmail 40028 invoked by uid 99); 21 Aug 2016 02:11:30 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 21 Aug 2016 02:11:30 +0000 Received: from mail-oi0-f53.google.com (mail-oi0-f53.google.com [209.85.218.53]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id 515751A0118; Sun, 21 Aug 2016 02:11:30 +0000 (UTC) Received: by mail-oi0-f53.google.com with SMTP id l203so110773251oib.1; Sat, 20 Aug 2016 19:11:30 -0700 (PDT) X-Gm-Message-State: AEkoousHHO0Leu7U/xx8w6G0kPGqFfyxnR8LC7VP/Sc0kswXQhpdboA0GTJpZzQ9sBO6nUaZs5fuS/T74VaRjw== X-Received: by 10.202.107.213 with SMTP id g204mr8200014oic.64.1471745489678; Sat, 20 Aug 2016 19:11:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.111.165 with HTTP; Sat, 20 Aug 2016 19:11:28 -0700 (PDT) In-Reply-To: <55C42D22-868C-4B6D-B027-0A9404636075@oracle.com> References: <147153621561.27779.14649810501472804929.idtracker@ietfa.amsl.com> <55C42D22-868C-4B6D-B027-0A9404636075@oracle.com> From: Kiran Ayyagari Date: Sun, 21 Aug 2016 07:41:28 +0530 X-Gmail-Original-Message-ID: Message-ID: To: id-event@ietf.org, openid-specs-risc@lists.openid.net Content-Type: multipart/alternative; boundary=001a11408c8e1cbb96053a8b7318 Archived-At: Cc: "scim@ietf.org WG" Subject: Re: [Id-event] Fwd: New Version Notification for draft-hunt-idevent-token-03.txt X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 21 Aug 2016 02:11:33 -0000 --001a11408c8e1cbb96053a8b7318 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Is there any specific reason for making "events" attribute an array of event URIs? If not, can this be turned into an object containing pairs? Thank you. On Thu, Aug 18, 2016 at 9:40 PM, Phil Hunt wrote: > Draft 03 has been published. > > This includes editorial clarifications to: > * Define the outer layer as a SET =E2=80=9Cenvelope=E2=80=9D, vs embedded= JSON as =E2=80=9Cpayload=E2=80=9D > * Clarify that only a single event should be conveyed plus optional > extensions. > * General edits to improve readability > * Register the =E2=80=9Cevents=E2=80=9D claim as a JWT attribute (see IA= NA considerations) > > Many thanks to Mike and Sarah and who contributed significant editorial > feedback. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > Begin forwarded message: > > *From: *internet-drafts@ietf.org > *Subject: **New Version Notification for draft-hunt-idevent-token-03.txt* > *Date: *August 18, 2016 at 9:03:35 AM PDT > *To: *"Michael B. Jones" , "William Denniss" < > wdenniss@google.com>, "Phil Hunt" , "Morteza Ansari" > , "Michael Jones" > > > A new version of I-D, draft-hunt-idevent-token-03.txt > has been successfully submitted by Phil Hunt and posted to the > IETF repository. > > Name: draft-hunt-idevent-token > Revision: 03 > Title: Security Event Token (SET) > Document date: 2016-08-18 > Group: Individual Submission > Pages: 16 > URL: https://www.ietf.org/internet-drafts/draft- > hunt-idevent-token-03.txt > Status: https://datatracker.ietf.org/doc/draft-hunt-idevent-token= / > Htmlized: https://tools.ietf.org/html/draft-hunt-idevent-token-03 > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-hunt- > idevent-token-03 > > 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) and may be > optionally signed and/or encrypted. A SET describes a statement of > fact that may be shared by an event publisher with event subscribers. > > > > > 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. > > The IETF Secretariat > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > Kiran Ayyagari --001a11408c8e1cbb96053a8b7318 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Is there any specific reason for making "ev= ents" attribute an array of event URIs?

If not, can this = be turned into an object containing <event-uri, event-data> pairs?
Thank you.

On Thu, Aug 18, 2016 at 9:40 PM, Phil Hunt <phil= .hunt@oracle.com> wrote:
Draft 03 has been published.

This includes editorial clarifications to:
* Define the ou= ter layer as a SET =E2=80=9Cenvelope=E2=80=9D, vs embedded JSON as =E2=80= =9Cpayload=E2=80=9D
* Clarify that only a single event should be = conveyed plus optional extensions.
* General edits to improve rea= dability
* Register the =E2=80=9Cevents=E2=80=9D claim as a =C2= =A0JWT attribute (see IANA considerations)

Many th= anks to Mike and Sarah and who contributed significant editorial feedback.<= /div>


Begin forwarded message:

<= div style=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:= 0px">From: internet-drafts@ietf.or= g
Subject: = New Version Notification for draft-hunt-idevent-token-03= .txt
Date:= August 18, 2016 at 9:03:35 AM PDT
To: "Michael B= . Jones" <mb= j@microsoft.com>, "William Denniss" <wdenniss@google.com>, "P= hil Hunt" <phil.hunt@yahoo.com>, "Morteza Ansari" <morteza.ansari@cisco.com>, "Michael Jones" <mbj@microsoft.com>

A new version of I-D, draft-hunt-idevent-token-03.txt
has been su= ccessfully submitted by Phil Hunt and posted to the
IETF repository.
=
Name: draft-hunt-idevent-token
Revision: 03
Title: Security Event To= ken (SET)
Document date: 201= 6-08-18
Group: Individual Submission
Pages: 16
URL: =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/internet-drafts/= draft-hunt-idevent-token-03.txt
Status: =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0https://datatracker.ietf.org/= doc/draft-hunt-idevent-token/
Htmlized: =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0https://tools.ietf.org/html/draft-hunt-ideve= nt-token-03
Diff: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0https://www.ietf.org/rfcdiff?url2=3D= draft-hunt-idevent-token-03

Abstract:
=C2=A0=C2=A0This = specification defines the Security Event token, which may be
=C2=A0=C2= =A0distributed via a protocol such as HTTP.=C2=A0 The Security Event Token<= br> =C2=A0=C2=A0(SET) specification profiles the JSON Web Token (JWT) and m= ay be
=C2=A0=C2=A0optionally signed and/or encrypted.=C2=A0 A SET descr= ibes a statement of
=C2=A0=C2=A0fact that may be shared by an event pub= lisher with event subscribers.




Please note that it may t= ake a couple of minutes from the time of submission
until the htmlized v= ersion and diff are available at tools.ietf.org.

The IETF Secretariat



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

Kiran Ayyagari
--001a11408c8e1cbb96053a8b7318-- From nobody Mon Aug 22 09:28:16 2016 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 25D5F12D74E for ; Mon, 22 Aug 2016 09:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 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.548, 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 XtIMf5Y2X4ex for ; Mon, 22 Aug 2016 09:28:12 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::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 B5BDA12D74C for ; Mon, 22 Aug 2016 09:28:12 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id r9so55787232ywg.0 for ; Mon, 22 Aug 2016 09:28:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dd23/yMDH0TZnGYnkIjCjuXdNSBCJl6N7hhdHcwSZiw=; b=kGPKXBZQIPJbfrXbHQwlPtRVt1cDW3PyR6/30CVkCe+J7Uk+fLRri8FBQ0kM7uyI95 1h1oc/UanEbXANXtXpj9jR88yEhbQk9geXXmJsnFdGSV+9p5ROYatpG4HEcsY8xRrjEc 8P90JgPMvha5PiN92aBjwkQbyujRA9HAu7a+ApYoypOgkZJVhYwW+2H597Bbq9BIAqDp um5/aw1aoAoPc160RYCY7e/LFC3eb0jmN2t0hjj5syTE9q+AUQtJP/ITkIMX6WcC06de tg/s4PIntVM22V1IEkoZFBiW88tv/eItEMQhE1Zef88HHGnj3Jqt4ehQV+GpY+x1uNfE rybg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dd23/yMDH0TZnGYnkIjCjuXdNSBCJl6N7hhdHcwSZiw=; b=I6XZkus8kyXdvelVESf8C6qAUmHCxaE5BPmIDy3r+K0P3Ss0dpKFA1G8xAmRCo6uLM 7DvGcpguBozeWqfLvJS1qwv5zpAmeUoYVzadbxL6ejAtV6552PG1U0bW9+xc4TxsfC/6 d+JhbJqy9nxAu1AAgMUsbeu2vZA3EECk1NQrYFPwlQqKo8czQzyvPuhS+a4svoXbDJDA O/aAeptriN8PWYnDq0tdhvJDRYyH/HLiio5P5bCj/O5jrtHDANIkdkMqVjNcB/Wcbicz FzcwNao0IUnKk+qXzn8/E59KfKDBuwEr8zrdwtjsbsd/Idqs1iftjoNWbimlwUO+FI2p 3O4A== X-Gm-Message-State: AEkoouuX85PYj9D2Oc0IkKGwEnPL4TQLNCl1r9fQ00acjhgfZ7IXnQz9Q2G24y/D0XWkPaNlsOlLa7fdhevd/tY9 X-Received: by 10.129.94.130 with SMTP id s124mr17195150ywb.172.1471883291684; Mon, 22 Aug 2016 09:28:11 -0700 (PDT) MIME-Version: 1.0 References: <3957B53A-D016-4C9C-A164-F90C7FB983C8@oracle.com> In-Reply-To: <3957B53A-D016-4C9C-A164-F90C7FB983C8@oracle.com> From: William Denniss Date: Mon, 22 Aug 2016 16:28:01 +0000 Message-ID: To: "Phil Hunt (IDM)" , id-event@ietf.org Content-Type: multipart/alternative; boundary=001a11491b54c0cb62053aab88da Archived-At: Cc: Mike Jones , Leif Johansson , Morteza Ansari , Marius Scurtescu Subject: Re: [Id-event] Ietf97 idevent meeting? X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 22 Aug 2016 16:28:14 -0000 --001a11491b54c0cb62053aab88da Content-Type: text/plain; charset=UTF-8 Sounds like a good idea to me. I can't attend in person this time, but would definitely remote in. On Sat, Aug 20, 2016 at 4:14 PM Phil Hunt (IDM) wrote: > > We have been making a lot of progress on the core id event draft. It would > be good to have an official meeting. > > Maybe the best thing would be to adopt the charter and get it going? > > There are a few items more to talk through like timing issues in the draft > to avoid unanticipated feedback concerns (discussed in issue 1000 on openid > connect). > > Thanks > > Phil > --001a11491b54c0cb62053aab88da Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sounds like a good idea to me. I can't attend in person this time, but = would definitely remote in.

We have been making a lot of progress on the core id event draft. It would = be good to have an official meeting.

Maybe the best thing would be to adopt the charter and get it going?

There are a few items more to talk through like timing issues in the draft = to avoid unanticipated feedback concerns (discussed in issue 1000 on openid= connect).

Thanks

Phil
--001a11491b54c0cb62053aab88da-- From nobody Mon Aug 22 11:43:44 2016 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 7D61812D097 for ; Mon, 22 Aug 2016 11:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.068 X-Spam-Level: X-Spam-Status: No, score=-15.068 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.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 nU2pwwdBm-Nc for ; Mon, 22 Aug 2016 11:43:41 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2248012B02F for ; Mon, 22 Aug 2016 11:43:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4330; q=dns/txt; s=iport; t=1471891420; x=1473101020; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=t9nzYEYhIMB3v/kxnQhOfMJZED0BooWTVTc2NeyuacM=; b=GwaDIcXF/1WsafQCmchnWszD7PkVOta796xx5X16yxFSLwwH473PjiH1 7UytdLUUNSqG8pGB3mi+oMZPEFLdS+HaJ0UVcfnUx0rudwj1jYTYaERBz 5HNrvBCm4sT8jHgbpnl+mm8iNl3Gx8xV8JD5rzApfvGyy2WG+DMxUynnd 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A9AwAgR7tX/4ENJK1dgnZOgVIHsnSFC?= =?us-ascii?q?IF9hh0CgWQ4FAIBAQEBAQEBXieEXgEBBXkQAgEIBAoDAwECKAcyFAkIAgQBDQW?= =?us-ascii?q?IMb1OAQEBAQEBAQECAQEBAQEBAQEBHoYrhE2EYIU7BZlIAY8ej1CMP4N3AR42g?= =?us-ascii?q?3pwhXx/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,561,1464652800"; d="scan'208,217";a="138330085" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Aug 2016 18:43:40 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u7MIhe3c018031 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 22 Aug 2016 18:43:40 GMT Received: from xch-rcd-004.cisco.com (173.37.102.14) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 22 Aug 2016 13:43:39 -0500 Received: from xch-rcd-004.cisco.com ([173.37.102.14]) by XCH-RCD-004.cisco.com ([173.37.102.14]) with mapi id 15.00.1210.000; Mon, 22 Aug 2016 13:43:39 -0500 From: "Morteza Ansari (moransar)" To: William Denniss , "Phil Hunt (IDM)" , "id-event@ietf.org" Thread-Topic: Ietf97 idevent meeting? Thread-Index: AQHR+ziPq6EeQbyiLUuKoQzXITgt0qBVga2A//+wioA= Date: Mon, 22 Aug 2016 18:43:39 +0000 Message-ID: References: <3957B53A-D016-4C9C-A164-F90C7FB983C8@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/14.6.6.160626 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.31.127] Content-Type: multipart/alternative; boundary="_000_D3E095D4444CDmoransarciscocom_" MIME-Version: 1.0 Archived-At: Cc: Mike Jones , Leif Johansson , Marius Scurtescu Subject: Re: [Id-event] Ietf97 idevent meeting? X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 22 Aug 2016 18:43:42 -0000 --_000_D3E095D4444CDmoransarciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Very unlikely I will be able to make it either, but will gladly join the me= eting remotely. From: William Denniss > Date: Monday, August 22, 2016 at 9:28 AM To: Phil Hunt >, "id-even= t@ietf.org" > Cc: Morteza >, Mike Jones >, Marius Scur= tescu >, Leif Johansson= > Subject: Re: Ietf97 idevent meeting? Sounds like a good idea to me. I can't attend in person this time, but woul= d definitely remote in. On Sat, Aug 20, 2016 at 4:14 PM Phil Hunt (IDM) > wrote: We have been making a lot of progress on the core id event draft. It would = be good to have an official meeting. Maybe the best thing would be to adopt the charter and get it going? There are a few items more to talk through like timing issues in the draft = to avoid unanticipated feedback concerns (discussed in issue 1000 on openid= connect). Thanks Phil --_000_D3E095D4444CDmoransarciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Very unlikely I will be able to make it either, but will gladly join t= he meeting remotely.

From: William Denniss <wdenniss@google.com>
Date: Monday, August 22, 2016 at 9:= 28 AM
To: Phil Hunt <phil.hunt@oracle.com>, "id-event@ietf.org" <id-event@ietf.org>
Cc: Morteza <moransar@cisco.com>, Mike Jones <michael.jones@microsoft.com>, Mari= us Scurtescu <mscurtescu@google= .com>, Leif Johansson <leifj@sunet.se>= ;
Subject: Re: Ietf97 idevent meeting= ?

Sounds like a good idea to me. I can't attend in person this time, but= would definitely remote in.
On Sat, Aug 20, 2016 at 4:14 PM Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:

We have been making a lot of progress on the core id event draft. It would = be good to have an official meeting.

Maybe the best thing would be to adopt the charter and get it going?

There are a few items more to talk through like timing issues in the draft = to avoid unanticipated feedback concerns (discussed in issue 1000 on openid= connect).

Thanks

Phil
 --_000_D3E095D4444CDmoransarciscocom_-- From nobody Wed Aug 24 11:08:08 2016 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 E3B7112D9D2 for ; Wed, 24 Aug 2016 11:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.548, 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 2mertY7AqQx3 for ; Wed, 24 Aug 2016 11:08:03 -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 9F53D12DA2F for ; Wed, 24 Aug 2016 11:07:57 -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 u7OI7ukH015712 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 24 Aug 2016 18:07:56 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u7OI7usW029529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 24 Aug 2016 18:07:56 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 u7OI7t1g028993 for ; Wed, 24 Aug 2016 18:07:56 GMT Received: from [10.0.1.5] (/24.86.208.48) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 24 Aug 2016 11:07:55 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_66338BCE-F110-4502-9D04-FC9817D3175A" Message-Id: Date: Wed, 24 Aug 2016 11:07:50 -0700 To: id-event@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Subject: [Id-event] Discussion on use of "sub" and confusion as ID Token X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 24 Aug 2016 18:08:07 -0000 --Apple-Mail=_66338BCE-F110-4502-9D04-FC9817D3175A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The authors have been having a discussion with regards to using the = =E2=80=9Csub=E2=80=9D claim in the top level. I think it is important to = try and get this discussion back to the main group. My apologies for the = long note. I wanted to get all the pros and cons on the table (hint: = please add if I missed any)... A question remains should =E2=80=9Csub=E2=80=9D be usable at the top = level. The downside of this approach is that a SET could potentially be = presented as an access or iD token and might initially be confused = because existing code does not know it needs to look for an =E2=80=9Cevent= s=E2=80=9D attribute. The SET and ID Token for all intensive purposes = are the same since a SET just has something extra (the events claim). There is also the question that if OIDC Logout uses it in the top level, = may other events use it? RFC7519 defines =E2=80=9Csub=E2=80=9D as a = String or URI value. For example, in SCIM events, the =E2=80=9Csub=E2=80=9D= value could be a SCIM Resource URI that indicates the resource whose = state has changed. In OAuth it could be defined as the token identifier = of the token that has been revoked. A SET about blacklisting an IP = address might put the IP address in sub. So there are three options (Option A seems to be favoured so far): =20 A. Sub at Top Level: =E2=80=9Csub=E2=80=9D generally used to reference = the Security Subject the SET is talking about. It uses a more general = english language intent of subject rather than the traditional use as = seen in SAML or OpenID Connect. Regardless it is still compliant with = RFC7519 (a String or URI). This would tend to lead to a style of SETs where the envelope carries = the validation information, the type of event, and the subject of the = event. Additional data goes in the payload. An advantage of this style, = is that for many events, the only thing needed is the event type and the = subject. No payloads would be needed. For events that don=E2=80=99t want payload, it is probably ok for = profiling event standards to define more claims at the top level. They = MUST be registered in the JWT registry. Profiling events can avoid = registration by just putting their attributes/claims in the payload area = as described in the spec. However, this would be inconsistent with = those that use payloads with unregistered claims. I point out that we = switched from registered event URNs to URIs to avoid registration. = Hence the move to payload objects to eliminate registration for = attributes/claims. =20 This still has the negatives of being confusable as an ID Token by = existing code. There has been a discussion that =E2=80=9Ciss=E2=80=9D = and/or =E2=80=9Caud=E2=80=9D should actually be different and the = receiver should detect that. However in the OIDC Logout case, by = design, the =E2=80=9Ciss=E2=80=9D value would be the same. The = =E2=80=9Caud=E2=80=9D would also likely be the same unless the spec = indicates that an alias =E2=80=9Caud=E2=80=9D be used even though the = audience may be the same entity in both cases. B. Exclusive-Use of Sub: =E2=80=9Csub=E2=80=9D is interpreted to by = traditional definition and is reserved for OAuth tokens and OIDC Connect = usage only. In order to avoid confusing, all profiling event specs = should NOT use =E2=80=9Csub=E2=80=9D in the top level except for OIDC. This has the disadvantage that OIDC requires special handling in terms = of a general use event library, but on the other hand a Logout Event = might be handled directly by existing ID Token code. This still has the disadvantage that an SET could be confused for an ID = Token. C. No-Top-Level Data: In order to more aggressively avoid confusion of = SETs as ID Tokens, make it mandatory that SETs may not contain a = =E2=80=9Csub=E2=80=9D value at the top level. The OIDC Logout Event, = for example, would then include a =E2=80=9Csub=E2=80=9D value in the = payload area. This should cause existing relying parties to fail = correctly. =20 This would provide a maximal difference form a IDToken or access token. This would have the advantage that envelopes contain no data, and that = every SET has a payload where the data is found. It requires more = parsing in some cases, but it is at least consistent. While we don=E2=80=99= t expect general processors like in SOAP for distribution (much of it is = point to point and very contextually driven), I personally expect to = see: * Development of general purpose libraries and tools that are used = enhance protocols and systems=20 * Audit and threat analysis systems will be looking at some events = historically. These will tend to merge multiple event feeds. Mike Jones also suggested using the =E2=80=9Ccty=E2=80=9D (content type) = header attribute from JWT. I think most code today has this set to = ignore or fixed as =E2=80=9CJWT=E2=80=9D. I wonder what current = implements would feel if we introduced a =E2=80=9Ccty=E2=80=9D value of = =E2=80=9CSET=E2=80=9D? Would that help? Thanks for your comments. Phil @independentid www.independentid.com = phil.hunt@oracle.com = --Apple-Mail=_66338BCE-F110-4502-9D04-FC9817D3175A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

The = authors have been having a discussion with regards to using the = =E2=80=9Csub=E2=80=9D claim in the top level. I think it is important to = try and get this discussion back to the main group. My apologies for the = long note. I wanted to get all the pros and cons on the table (hint: =  please add if I missed any)...

A question remains should =E2=80=9Csub=E2= =80=9D be usable at the top level.  The downside of this approach = is that a SET could potentially be presented as an access or iD token = and might initially be confused because existing code does not know it = needs to look for an =E2=80=9Cevents=E2=80=9D attribute.  The SET = and ID Token for all intensive purposes are the same since a SET just = has something extra (the events claim).

There is also the question that if OIDC = Logout uses it in the top level, may other events use it? RFC7519 = defines =E2=80=9Csub=E2=80=9D as a String or URI value. For example, in = SCIM events, the =E2=80=9Csub=E2=80=9D value could be a SCIM Resource = URI that indicates the resource whose state has changed.  In OAuth = it could be defined as the token identifier of the token that has been = revoked.  A SET about blacklisting an IP address might put the IP = address in sub.

So there are three options (Option A seems to be favoured so = far):  

A.  Sub at Top Level:  =E2=80=9Csub=E2=80=9D = generally used to reference the Security Subject the SET is talking = about.  It uses a more general english language intent of subject = rather than the traditional use as seen in SAML or OpenID Connect. =  Regardless it is still compliant with RFC7519 (a String or = URI).

This = would tend to lead to a style of SETs where the envelope carries the = validation information, the type of event, and the subject of the event. = Additional data goes in the payload. An advantage of this style, is that = for many events, the only thing needed is the event type and the = subject.  No payloads would be needed.

For events that don=E2=80= =99t want payload, it is probably ok for profiling event standards to = define more claims at the top level. They MUST be registered in the JWT = registry. Profiling events can avoid registration by just putting their = attributes/claims in the payload area as described in the spec. =  However, this would be inconsistent with those that use payloads = with unregistered claims.  I point out that we switched from = registered event URNs to URIs to avoid registration.  Hence the = move to payload objects to eliminate registration for attributes/claims. =  

This still has the negatives of being confusable as an ID = Token by existing code. There has been a discussion that =E2=80=9Ciss=E2=80= =9D and/or =E2=80=9Caud=E2=80=9D should actually be different and the = receiver should detect that.  However in the OIDC Logout case, by = design, the =E2=80=9Ciss=E2=80=9D value would be the same.  The = =E2=80=9Caud=E2=80=9D would also likely be the same unless the spec = indicates that an alias =E2=80=9Caud=E2=80=9D be used even though the = audience may be the same entity in both cases.

B. Exclusive-Use of = Sub: =E2=80=9Csub=E2=80=9D is interpreted to by traditional = definition and is reserved for OAuth tokens and OIDC Connect usage only. =  In order to  avoid confusing, all profiling event specs = should NOT use =E2=80=9Csub=E2=80=9D in the top level except for = OIDC.

This has = the disadvantage that OIDC requires special handling in terms of a = general use event library, but on the other hand a Logout Event might be = handled directly by existing ID Token code.

This still has the disadvantage that an = SET could be confused for an ID Token.

C. No-Top-Level Data: = In order to more aggressively avoid confusion of SETs as ID Tokens, make = it mandatory that SETs may not contain a =E2=80=9Csub=E2=80=9D value at = the top level.  The OIDC Logout Event, for example, would then = include a =E2=80=9Csub=E2=80=9D value in the payload area. This should = cause existing relying parties to fail correctly.  

This would provide a = maximal difference form a IDToken or access token.

This would have the = advantage that envelopes contain no data, and that every SET has a = payload where the data is found. It requires more parsing in some cases, = but it is at least consistent. While we don=E2=80=99t expect general = processors like in SOAP for distribution (much of it is point to point = and very contextually driven), I personally expect to see:
  *  Development of general purpose libraries and = tools that are used enhance protocols and systems 
  *  Audit and threat analysis systems will be = looking at some events historically. These will tend to merge multiple = event feeds.

Mike Jones also suggested using the =E2=80=9Ccty=E2= =80=9D (content type) header attribute from JWT.  I think most = code today has this set to ignore or fixed as =E2=80=9CJWT=E2=80=9D. =  I wonder what current implements would feel if we introduced a = =E2=80=9Ccty=E2=80=9D value of =E2=80=9CSET=E2=80=9D?  Would that = help?

Thanks for your = comments.





= --Apple-Mail=_66338BCE-F110-4502-9D04-FC9817D3175A-- From nobody Wed Aug 24 12:51:36 2016 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 BDFD312B02F for ; Wed, 24 Aug 2016 12:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 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.548, 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 NPGBqAx20h7k for ; Wed, 24 Aug 2016 12:51:32 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::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 C658812D765 for ; Wed, 24 Aug 2016 12:51:31 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id i5so41510109wmg.0 for ; Wed, 24 Aug 2016 12:51:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EJTtvh05nsIYpELo1mdRKubr9FsH+aQmLv8SwesVXOk=; b=E5X00Iwf3ET8Ztd0Tm5SqEgrvS/T2MGQbrg+U/oAHIZ8n/41j3YS6DM1M6ncXrc6AA Skqa+fVpvtHPGkTXWyv8fJrI6WdsO4XkkeGXM+aa8OT2Umwf3KHRAA3/Se+LDoh53Jx6 AUOoNK7QzRJc1y2CNjvpcy3Il8jZItyi/G15KZGrsdUhaHOqI7py+eeZA0/w1h+DT2za m6WfnWLel++ZheN/txSMLEfP89e3rsjE98g5exzufDnBvnTojm/UMZp7VPOSdIIVzDjI LkzkbzJ+xkmcjkKT8Apk6TjEa5IEitlOLKbDEcRvrhTB1YD8IhaKbh9BUj/XlbHVA9mE b2oA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EJTtvh05nsIYpELo1mdRKubr9FsH+aQmLv8SwesVXOk=; b=QtVb/bI+LNr2sMw2YQHJx65aK4X9NXtqZK1Nv7WtATlh30g+I80sbPfJcEn32mSamM W5m9pWGx9lnD9pjAu+zzwwKYpPxIkJuNeFppTe2wrawqyCqNMBv8+u0mxwUfcuiPmAWt fABmUu1MmhH8+NggZSEZA6uPFNQSeDSmd6kQMWZ3qDHfP6Wp24VYlxR8MiEq2k/fcT8V vWpBLQDveZ50+Kw25f3hvMUhtf733GxrHr5NX5cUze4ZWIq67a+My3Dd8Za0DdYsyqO4 TLCUosdp549JZQyBGZv9bx3YWcZiCJBZF14fCPNWxnZjdxDEkCAFYYnQI5JkQW8nnP/0 6vVg== X-Gm-Message-State: AE9vXwN484NR5hcHybsvyXEAFG4SJ/WkXPmv81XkahlBQ0QC4vp4n7xH4YzpJZ9cbfvAFwwIukOfMhNwIVhUq25G X-Received: by 10.28.107.144 with SMTP id a16mr4428798wmi.75.1472068290012; Wed, 24 Aug 2016 12:51:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.167.78 with HTTP; Wed, 24 Aug 2016 12:51:09 -0700 (PDT) In-Reply-To: References: From: Marius Scurtescu Date: Wed, 24 Aug 2016 12:51:09 -0700 Message-ID: To: Phil Hunt Content-Type: multipart/alternative; boundary=001a1147bd7e8366c2053ad69b8d Archived-At: Cc: id-event@ietf.org Subject: Re: [Id-event] Discussion on use of "sub" and confusion as ID Token X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 24 Aug 2016 19:51:35 -0000 --001a1147bd7e8366c2053ad69b8d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Aug 24, 2016 at 11:07 AM, Phil Hunt wrote: > > The authors have been having a discussion with regards to using the =E2= =80=9Csub=E2=80=9D > claim in the top level. I think it is important to try and get this > discussion back to the main group. My apologies for the long note. I want= ed > to get all the pros and cons on the table (hint: please add if I missed > any)... > > A question remains should =E2=80=9Csub=E2=80=9D be usable at the top leve= l. The downside > of this approach is that a SET could potentially be presented as an acces= s > or iD token and might initially be confused because existing code does no= t > know it needs to look for an =E2=80=9Cevents=E2=80=9D attribute. The SET= and ID Token for > all intensive purposes are the same since a SET just has something extra > (the events claim). > > There is also the question that if OIDC Logout uses it in the top level, > may other events use it? RFC7519 defines =E2=80=9Csub=E2=80=9D as a Strin= g or URI value. > For example, in SCIM events, the =E2=80=9Csub=E2=80=9D value could be a S= CIM Resource URI > that indicates the resource whose state has changed. In OAuth it could b= e > defined as the token identifier of the token that has been revoked. A SE= T > about blacklisting an IP address might put the IP address in sub. > > So there are three options (Option A seems to be favoured so far): > > *A. Sub at Top Level:* =E2=80=9Csub=E2=80=9D generally used to referenc= e the Security > Subject the SET is talking about. It uses a more general english languag= e > intent of subject rather than the traditional use as seen in SAML or Open= ID > Connect. Regardless it is still compliant with RFC7519 (a String or URI)= . > > This would tend to lead to a style of SETs where the envelope carries the > validation information, the type of event, and the subject of the event. > Additional data goes in the payload. An advantage of this style, is that > for many events, the only thing needed is the event type and the subject. > No payloads would be needed. > > For events that don=E2=80=99t want payload, it is probably ok for profili= ng event > standards to define more claims at the top level. They MUST be registered > in the JWT registry. Profiling events can avoid registration by just > putting their attributes/claims in the payload area as described in the > spec. However, this would be inconsistent with those that use payloads > with unregistered claims. I point out that we switched from registered > event URNs to URIs to avoid registration. Hence the move to payload > objects to eliminate registration for attributes/claims. > > This still has the negatives of being confusable as an ID Token by > existing code. There has been a discussion that =E2=80=9Ciss=E2=80=9D and= /or =E2=80=9Caud=E2=80=9D should > actually be different and the receiver should detect that. However in th= e > OIDC Logout case, by design, the =E2=80=9Ciss=E2=80=9D value would be the= same. The =E2=80=9Caud=E2=80=9D > would also likely be the same unless the spec indicates that an alias =E2= =80=9Caud=E2=80=9D > be used even though the audience may be the same entity in both cases. > > *B. Exclusive-Use of Sub:* =E2=80=9Csub=E2=80=9D is interpreted to by tra= ditional > definition and is reserved for OAuth tokens and OIDC Connect usage only. > In order to avoid confusing, all profiling event specs should NOT use > =E2=80=9Csub=E2=80=9D in the top level except for OIDC. > > This has the disadvantage that OIDC requires special handling in terms of > a general use event library, but on the other hand a Logout Event might b= e > handled directly by existing ID Token code. > > This still has the disadvantage that an SET could be confused for an ID > Token. > > *C. No-Top-Level Data:* In order to more aggressively avoid confusion of > SETs as ID Tokens, make it mandatory that SETs may not contain a =E2=80= =9Csub=E2=80=9D > value at the top level. The OIDC Logout Event, for example, would then > include a =E2=80=9Csub=E2=80=9D value in the payload area. This should ca= use existing > relying parties to fail correctly. > > This would provide a maximal difference form a IDToken or access token. > > This would have the advantage that envelopes contain no data, and that > every SET has a payload where the data is found. It requires more parsing > in some cases, but it is at least consistent. While we don=E2=80=99t expe= ct general > processors like in SOAP for distribution (much of it is point to point an= d > very contextually driven), I personally expect to see: > * Development of general purpose libraries and tools that are used > enhance protocols and systems > * Audit and threat analysis systems will be looking at some events > historically. These will tend to merge multiple event feeds. > > Mike Jones also suggested using the *=E2=80=9Ccty=E2=80=9D* (content type= ) header > attribute from JWT. I think most code today has this set to ignore or > fixed as =E2=80=9CJWT=E2=80=9D. I wonder what current implements would f= eel if we > introduced a =E2=80=9Ccty=E2=80=9D value of =E2=80=9CSET=E2=80=9D? Would= that help? > I think it is very important to be able to clearly distinguish different types of JWT tokens. For example, not being able to cross post a Security Event Token as an Id Token. Reading RFC 7519 I don't think cty fits the bill, but I could be wrong. cty is a header parameter used by the crypto algorithm and the default value is JWT. We need to distinguish sub-types of JWT, and it should be a claim inside the JWT. With the above issue in mind, I think option A is the cleanest solution. > Thanks for your comments. > > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > --001a1147bd7e8366c2053ad69b8d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Aug 24, 2016 at 11:07 AM, Phil Hunt <phil.hunt@oracle.com> wrote:
=
The authors have been having a discussion with regards to us= ing the =E2=80=9Csub=E2=80=9D claim in the top level. I think it is importa= nt to try and get this discussion back to the main group. My apologies for = the long note. I wanted to get all the pros and cons on the table (hint: = =C2=A0please add if I missed any)...

A question re= mains should =E2=80=9Csub=E2=80=9D be usable at the top level.=C2=A0 The do= wnside of this approach is that a SET could potentially be presented as an = access or iD token and might initially be confused because existing code do= es not know it needs to look for an =E2=80=9Cevents=E2=80=9D attribute.=C2= =A0 The SET and ID Token for all intensive purposes are the same since a SE= T just has something extra (the events claim).

The= re is also the question that if OIDC Logout uses it in the top level, may o= ther events use it? RFC7519 defines =E2=80=9Csub=E2=80=9D as a String or UR= I value. For example, in SCIM events, the =E2=80=9Csub=E2=80=9D value could= be a SCIM Resource URI that indicates the resource whose state has changed= .=C2=A0 In OAuth it could be defined as the token identifier of the token t= hat has been revoked.=C2=A0 A SET about blacklisting an IP address might pu= t the IP address in sub.

So there are three option= s (Option A seems to be favoured so far): =C2=A0

<= b>A.=C2=A0 Sub at Top Level: =C2=A0=E2=80=9Csub=E2=80=9D generally used= to reference the Security Subject the SET is talking about.=C2=A0 It uses = a more general english language intent of subject rather than the tradition= al use as seen in SAML or OpenID Connect.=C2=A0 Regardless it is still comp= liant with RFC7519 (a String or URI).

This would t= end to lead to a style of SETs where the envelope carries the validation in= formation, the type of event, and the subject of the event. Additional data= goes in the payload. An advantage of this style, is that for many events, = the only thing needed is the event type and the subject.=C2=A0 No payloads = would be needed.

For events that don=E2=80=99= t want payload, it is probably ok for profiling event standards to define m= ore claims at the top level. They MUST be registered in the JWT registry. P= rofiling events can avoid registration by just putting their attributes/cla= ims in the payload area as described in the spec.=C2=A0 However, this would= be inconsistent with those that use payloads with unregistered claims.=C2= =A0 I point out that we switched from registered event URNs to URIs to avoi= d registration.=C2=A0 Hence the move to payload objects to eliminate regist= ration for attributes/claims. =C2=A0

This st= ill has the negatives of being confusable as an ID Token by existing code. = There has been a discussion that =E2=80=9Ciss=E2=80=9D and/or =E2=80=9Caud= =E2=80=9D should actually be different and the receiver should detect that.= =C2=A0 However in the OIDC Logout case, by design, the =E2=80=9Ciss=E2=80= =9D value would be the same.=C2=A0 The =E2=80=9Caud=E2=80=9D would also lik= ely be the same unless the spec indicates that an alias =E2=80=9Caud=E2=80= =9D be used even though the audience may be the same entity in both cases.<= /div>

B. Exclusive-Use of Sub: =E2=80=9Csub=E2=80= =9D is interpreted to by traditional definition and is reserved for OAuth t= okens and OIDC Connect usage only.=C2=A0 In order to =C2=A0avoid confusing,= all profiling event specs should NOT use =E2=80=9Csub=E2=80=9D in the top = level except for OIDC.

This has the disadvantage t= hat OIDC requires special handling in terms of a general use event library,= but on the other hand a Logout Event might be handled directly by existing= ID Token code.

This still has the disadvantage th= at an SET could be confused for an ID Token.

C.= No-Top-Level Data: In order to more aggressively avoid confusion of SE= Ts as ID Tokens, make it mandatory that SETs may not contain a =E2=80=9Csub= =E2=80=9D value at the top level.=C2=A0 The OIDC Logout Event, for example,= would then include a =E2=80=9Csub=E2=80=9D value in the payload area. This= should cause existing relying parties to fail correctly. =C2=A0
=
This would provide a maximal difference form a IDToken or ac= cess token.

This would have the advantage that env= elopes contain no data, and that every SET has a payload where the data is = found. It requires more parsing in some cases, but it is at least consisten= t. While we don=E2=80=99t expect general processors like in SOAP for distri= bution (much of it is point to point and very contextually driven), I perso= nally expect to see:
=C2=A0 * =C2=A0Development of general purpos= e libraries and tools that are used enhance protocols and systems=C2=A0
=C2=A0 * =C2=A0Audit and threat analysis systems will be looking at = some events historically. These will tend to merge multiple event feeds.

Mike Jones also suggested using the =E2=80=9Ccty= =E2=80=9D (content type) header attribute from JWT.=C2=A0 I think most = code today has this set to ignore or fixed as =E2=80=9CJWT=E2=80=9D.=C2=A0 = I wonder what current implements would feel if we introduced a =E2=80=9Ccty= =E2=80=9D value of =E2=80=9CSET=E2=80=9D?=C2=A0 Would that help?

I think it is very important to be able t= o clearly distinguish different types of JWT tokens. For example, not being= able to cross post a Security Event Token as an Id Token.=C2=A0
=
Reading=C2=A0RFC 7519 I don't think cty fits the bill, b= ut I could be wrong. cty is a header parameter used by the crypto algorithm= and the default value is JWT. We need to distinguish sub-types of JWT, and= it should be a claim inside the JWT.

With the abo= ve issue in mind, I think option A is the cleanest solution.

=


Thanks for your comments.





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


--001a1147bd7e8366c2053ad69b8d-- From nobody Wed Aug 24 13:13:20 2016 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 EF58B12D133 for ; Wed, 24 Aug 2016 13:13:18 -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 XSWJfnyx0bNH for ; Wed, 24 Aug 2016 13:13:16 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0109.outbound.protection.outlook.com [104.47.36.109]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2243212D097 for ; Wed, 24 Aug 2016 13:13:15 -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=Ja4KWu7YYWnxECnpKpAhGorB4o3oAG1HjGBTpz0dUdk=; b=h4a34oQRnEd4J7L3y5q53td1I6JnOFh//UtrQApCzXPFy93Okq32QOjIlc/towYQ+smx8HMMJfYUNyQzH2WvzFbDR8HrUp1GR2Ffkgv6ql/gRGexKTEvJ33C3CLy4ATp7u2I4hOFNsrGIS97s4ULthJ56V3Jnb1vR+vmLpBb90A= Received: from SN1PR0301MB1645.namprd03.prod.outlook.com (10.162.130.139) by SN1PR0301MB1647.namprd03.prod.outlook.com (10.162.130.141) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.13; Wed, 24 Aug 2016 20:13:01 +0000 Received: from SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) by SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) with mapi id 15.01.0587.013; Wed, 24 Aug 2016 20:13:02 +0000 From: Mike Jones To: Marius Scurtescu , Phil Hunt Thread-Topic: [Id-event] Discussion on use of "sub" and confusion as ID Token Thread-Index: AQHR/jJ6Kzu5WyrJDU6lijc1KOHPZaBYhVKAgAAEQkA= Date: Wed, 24 Aug 2016 20:13:02 +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: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [64.134.242.226] x-ms-office365-filtering-correlation-id: 667cb442-d64f-4075-a7ab-08d3cc5b0d79 x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1647; 6:8PWckItWzemB0TbjY/mYFT0Lq2CmoAmPaGeYz6PZU3LmZwHq0lWYdGnSZ9LyzP4g9gmwjH5DJAwtq+lER0e7MAOFLc8dcPfbeBE4lOCMj2LyJKpWwBxvnoBSIdhL5aClC4fMRYabBMHLur24kKD2Rm454o7z5BywBge8gs+vPVLSwsMT0KFi3q8dVeNXkcFCoVuoa2JtpmJVe+sWOCHS+lfxDw45+Q5x647Kv0l2BZrHC2MkwxUKUx/z6PKVZcPWXpLxR+7Rwm5jbiNMz6ZDuBJYRk6zIbQBjrr2SIQct2pbgqM3j2lIcPWEH/+DUHzdnNE1kFTCg7JDMoYtOu+C5Q==; 5:kHHUjI8mnXVqjVdDnZ+/vw5RerLpvJInKzd/M0OaS4xg9Q+dvG9SwGT5WMYNV0OSrjesvV3ahgP518b0a/bvBiGVcs5U7P93hiGSmi/df1CqHw0CJst6SeVF+8X1qzH4BWMTxam17FW7VSz9v8uSqg==; 24:4eH3+UI3dGgY10Qj4v2y3tJLy+CMluCN1smkUm5LOSBtsyiPSqZMum8ms80eRkaiE924GZL2mIpv7B4YuRSHzTLjFrj9YpVPKnleADG5aIw=; 7:zA55dcja5yIFl8tMW31Od2UnWWUzh5ZnV3/uCxx7JbEuThyybkaEd17W4xDrnD80Cm/IPUJLA2x2fdij7olnGTzRBf8bpv7e0oJb1z4wNmb24+mioJa6Jjxia6L3bZjP6YDuKL+VpvzgxWPuMxWjE0hzv0ICyrJLmvi7zuswpimAIR8KzFS3Uq9fUNXWM0/iF0pVuGyN6m7cUtfn3ma9EwNBVJkcPHCA1k+aKD713MrwEDbHmF0ZQVOrhLoxawTE x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1647; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(21748063052155)(21532816269658)(146099531331640)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:SN1PR0301MB1647; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1647; x-forefront-prvs: 0044C17179 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(24454002)(199003)(377454003)(3660700001)(3280700002)(66066001)(5005710100001)(97736004)(19300405004)(92566002)(7846002)(7736002)(81166006)(16601075003)(8936002)(81156014)(106356001)(99286002)(16236675004)(8676002)(68736007)(19609705001)(106116001)(105586002)(76576001)(122556002)(15975445007)(5660300001)(76176999)(54356999)(19617315012)(33656002)(101416001)(10090500001)(50986999)(5002640100001)(87936001)(9686002)(19625215002)(3846002)(586003)(86362001)(86612001)(6116002)(790700001)(4326007)(8990500004)(102836003)(2906002)(19580405001)(189998001)(77096005)(5001770100001)(10290500002)(19580395003)(2900100001)(7906003)(10400500002)(7696003)(74316002)(2950100001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0301MB1647; H:SN1PR0301MB1645.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB16450C7C64DACA2254C9C36CF5EA0SN1PR0301MB1645_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Aug 2016 20:13:02.5034 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1647 Archived-At: Cc: "id-event@ietf.org" Subject: Re: [Id-event] Discussion on use of "sub" and confusion as ID Token X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 24 Aug 2016 20:13:19 -0000 --_000_SN1PR0301MB16450C7C64DACA2254C9C36CF5EA0SN1PR0301MB1645_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SnVzdCBmb3IgY29tcGxldGVuZXNzLCB0aGUgb3RoZXIgd2F5IG9mIGRpc3Rpbmd1aXNoaW5nIGJl dHdlZW4gSldUcyBpcyB0aGUg4oCcdHlw4oCdIHZhbHVlLiAgKFRoZSBkaWZmZXJlbmNlIGJldHdl ZW4g4oCcY3R54oCdIGFuZCDigJx0eXDigJ0gaXMgdGhhdCDigJxjdHnigJ0gaXMgdGhlIHR5cGUg b2YgdGhlIGNvbnRlbnQgb2YgdGhlIEpXUy9KV0UgcGF5bG9hZCB3aGVyZWFzIOKAnHR5cOKAnSBp cyB0aGUgdHlwZSBvZiB0aGUgZW50aXJlIG9iamVjdC4pICBZb3XigJlsbCBzZWUgdGhhdCDigJx0 eXDigJ0gaXMgZXZlbiB1c2VkIGluIHRoZSBKV1MgZXhhbXBsZXMuICDigJx0eXDigJ0gaXMgZGVz Y3JpYmVkIGF0IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NTE1I3NlY3Rpb24tNC4x LjkgYW5kIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NTE5I3NlY3Rpb24tNS4xLiAg 4oCcY3R54oCdIGlzIGRlc2NyaWJlZCBhdCBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj NzUxNSNzZWN0aW9uLTQuMS4xMCBhbmQgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc1 MTkjc2VjdGlvbi01LjIuDQoNClBsYWNpbmcgcmVzdHJpY3Rpb25zIG9uIOKAnHN1YuKAnSB3b3Vs ZCB1bm5lY2Vzc2FyeSBhbmQgY291bnRlci1wcm9kdWN0aXZlLiAgSXTigJlzIHRoZSBraW5kIG9m IGNvbXBsZXhpdHkgdGhhdCBjb3VsZCByZXN1bHQgaW4gdGhlIEFEcyBhbmQgSUVTRyByYWlzaW5n IHF1ZXN0aW9ucyB0aGF0IHdvdWxkIHN0YW5kIGluIHRoZSB3YXkgb2YgYWNjZXB0YW5jZSBvZiB0 aGUgaW5kaXZpZHVhbCBzdWJtaXNzaW9uLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBJZC1ldmVudCBbbWFp bHRvOmlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNYXJpdXMgU2N1cnRl c2N1DQpTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAyNCwgMjAxNiAxMjo1MSBQTQ0KVG86IFBoaWwg SHVudCA8cGhpbC5odW50QG9yYWNsZS5jb20+DQpDYzogaWQtZXZlbnRAaWV0Zi5vcmcNClN1Ympl Y3Q6IFJlOiBbSWQtZXZlbnRdIERpc2N1c3Npb24gb24gdXNlIG9mICJzdWIiIGFuZCBjb25mdXNp b24gYXMgSUQgVG9rZW4NCg0KT24gV2VkLCBBdWcgMjQsIDIwMTYgYXQgMTE6MDcgQU0sIFBoaWwg SHVudCA8cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj4g d3JvdGU6DQoNClRoZSBhdXRob3JzIGhhdmUgYmVlbiBoYXZpbmcgYSBkaXNjdXNzaW9uIHdpdGgg cmVnYXJkcyB0byB1c2luZyB0aGUg4oCcc3Vi4oCdIGNsYWltIGluIHRoZSB0b3AgbGV2ZWwuIEkg dGhpbmsgaXQgaXMgaW1wb3J0YW50IHRvIHRyeSBhbmQgZ2V0IHRoaXMgZGlzY3Vzc2lvbiBiYWNr IHRvIHRoZSBtYWluIGdyb3VwLiBNeSBhcG9sb2dpZXMgZm9yIHRoZSBsb25nIG5vdGUuIEkgd2Fu dGVkIHRvIGdldCBhbGwgdGhlIHByb3MgYW5kIGNvbnMgb24gdGhlIHRhYmxlIChoaW50OiAgcGxl YXNlIGFkZCBpZiBJIG1pc3NlZCBhbnkpLi4uDQoNCkEgcXVlc3Rpb24gcmVtYWlucyBzaG91bGQg 4oCcc3Vi4oCdIGJlIHVzYWJsZSBhdCB0aGUgdG9wIGxldmVsLiAgVGhlIGRvd25zaWRlIG9mIHRo aXMgYXBwcm9hY2ggaXMgdGhhdCBhIFNFVCBjb3VsZCBwb3RlbnRpYWxseSBiZSBwcmVzZW50ZWQg YXMgYW4gYWNjZXNzIG9yIGlEIHRva2VuIGFuZCBtaWdodCBpbml0aWFsbHkgYmUgY29uZnVzZWQg YmVjYXVzZSBleGlzdGluZyBjb2RlIGRvZXMgbm90IGtub3cgaXQgbmVlZHMgdG8gbG9vayBmb3Ig YW4g4oCcZXZlbnRz4oCdIGF0dHJpYnV0ZS4gIFRoZSBTRVQgYW5kIElEIFRva2VuIGZvciBhbGwg aW50ZW5zaXZlIHB1cnBvc2VzIGFyZSB0aGUgc2FtZSBzaW5jZSBhIFNFVCBqdXN0IGhhcyBzb21l dGhpbmcgZXh0cmEgKHRoZSBldmVudHMgY2xhaW0pLg0KDQpUaGVyZSBpcyBhbHNvIHRoZSBxdWVz dGlvbiB0aGF0IGlmIE9JREMgTG9nb3V0IHVzZXMgaXQgaW4gdGhlIHRvcCBsZXZlbCwgbWF5IG90 aGVyIGV2ZW50cyB1c2UgaXQ/IFJGQzc1MTkgZGVmaW5lcyDigJxzdWLigJ0gYXMgYSBTdHJpbmcg b3IgVVJJIHZhbHVlLiBGb3IgZXhhbXBsZSwgaW4gU0NJTSBldmVudHMsIHRoZSDigJxzdWLigJ0g dmFsdWUgY291bGQgYmUgYSBTQ0lNIFJlc291cmNlIFVSSSB0aGF0IGluZGljYXRlcyB0aGUgcmVz b3VyY2Ugd2hvc2Ugc3RhdGUgaGFzIGNoYW5nZWQuICBJbiBPQXV0aCBpdCBjb3VsZCBiZSBkZWZp bmVkIGFzIHRoZSB0b2tlbiBpZGVudGlmaWVyIG9mIHRoZSB0b2tlbiB0aGF0IGhhcyBiZWVuIHJl dm9rZWQuICBBIFNFVCBhYm91dCBibGFja2xpc3RpbmcgYW4gSVAgYWRkcmVzcyBtaWdodCBwdXQg dGhlIElQIGFkZHJlc3MgaW4gc3ViLg0KDQpTbyB0aGVyZSBhcmUgdGhyZWUgb3B0aW9ucyAoT3B0 aW9uIEEgc2VlbXMgdG8gYmUgZmF2b3VyZWQgc28gZmFyKToNCg0KQS4gIFN1YiBhdCBUb3AgTGV2 ZWw6ICDigJxzdWLigJ0gZ2VuZXJhbGx5IHVzZWQgdG8gcmVmZXJlbmNlIHRoZSBTZWN1cml0eSBT dWJqZWN0IHRoZSBTRVQgaXMgdGFsa2luZyBhYm91dC4gIEl0IHVzZXMgYSBtb3JlIGdlbmVyYWwg ZW5nbGlzaCBsYW5ndWFnZSBpbnRlbnQgb2Ygc3ViamVjdCByYXRoZXIgdGhhbiB0aGUgdHJhZGl0 aW9uYWwgdXNlIGFzIHNlZW4gaW4gU0FNTCBvciBPcGVuSUQgQ29ubmVjdC4gIFJlZ2FyZGxlc3Mg aXQgaXMgc3RpbGwgY29tcGxpYW50IHdpdGggUkZDNzUxOSAoYSBTdHJpbmcgb3IgVVJJKS4NCg0K VGhpcyB3b3VsZCB0ZW5kIHRvIGxlYWQgdG8gYSBzdHlsZSBvZiBTRVRzIHdoZXJlIHRoZSBlbnZl bG9wZSBjYXJyaWVzIHRoZSB2YWxpZGF0aW9uIGluZm9ybWF0aW9uLCB0aGUgdHlwZSBvZiBldmVu dCwgYW5kIHRoZSBzdWJqZWN0IG9mIHRoZSBldmVudC4gQWRkaXRpb25hbCBkYXRhIGdvZXMgaW4g dGhlIHBheWxvYWQuIEFuIGFkdmFudGFnZSBvZiB0aGlzIHN0eWxlLCBpcyB0aGF0IGZvciBtYW55 IGV2ZW50cywgdGhlIG9ubHkgdGhpbmcgbmVlZGVkIGlzIHRoZSBldmVudCB0eXBlIGFuZCB0aGUg c3ViamVjdC4gIE5vIHBheWxvYWRzIHdvdWxkIGJlIG5lZWRlZC4NCg0KRm9yIGV2ZW50cyB0aGF0 IGRvbuKAmXQgd2FudCBwYXlsb2FkLCBpdCBpcyBwcm9iYWJseSBvayBmb3IgcHJvZmlsaW5nIGV2 ZW50IHN0YW5kYXJkcyB0byBkZWZpbmUgbW9yZSBjbGFpbXMgYXQgdGhlIHRvcCBsZXZlbC4gVGhl eSBNVVNUIGJlIHJlZ2lzdGVyZWQgaW4gdGhlIEpXVCByZWdpc3RyeS4gUHJvZmlsaW5nIGV2ZW50 cyBjYW4gYXZvaWQgcmVnaXN0cmF0aW9uIGJ5IGp1c3QgcHV0dGluZyB0aGVpciBhdHRyaWJ1dGVz L2NsYWltcyBpbiB0aGUgcGF5bG9hZCBhcmVhIGFzIGRlc2NyaWJlZCBpbiB0aGUgc3BlYy4gIEhv d2V2ZXIsIHRoaXMgd291bGQgYmUgaW5jb25zaXN0ZW50IHdpdGggdGhvc2UgdGhhdCB1c2UgcGF5 bG9hZHMgd2l0aCB1bnJlZ2lzdGVyZWQgY2xhaW1zLiAgSSBwb2ludCBvdXQgdGhhdCB3ZSBzd2l0 Y2hlZCBmcm9tIHJlZ2lzdGVyZWQgZXZlbnQgVVJOcyB0byBVUklzIHRvIGF2b2lkIHJlZ2lzdHJh dGlvbi4gIEhlbmNlIHRoZSBtb3ZlIHRvIHBheWxvYWQgb2JqZWN0cyB0byBlbGltaW5hdGUgcmVn aXN0cmF0aW9uIGZvciBhdHRyaWJ1dGVzL2NsYWltcy4NCg0KVGhpcyBzdGlsbCBoYXMgdGhlIG5l Z2F0aXZlcyBvZiBiZWluZyBjb25mdXNhYmxlIGFzIGFuIElEIFRva2VuIGJ5IGV4aXN0aW5nIGNv ZGUuIFRoZXJlIGhhcyBiZWVuIGEgZGlzY3Vzc2lvbiB0aGF0IOKAnGlzc+KAnSBhbmQvb3Ig4oCc YXVk4oCdIHNob3VsZCBhY3R1YWxseSBiZSBkaWZmZXJlbnQgYW5kIHRoZSByZWNlaXZlciBzaG91 bGQgZGV0ZWN0IHRoYXQuICBIb3dldmVyIGluIHRoZSBPSURDIExvZ291dCBjYXNlLCBieSBkZXNp Z24sIHRoZSDigJxpc3PigJ0gdmFsdWUgd291bGQgYmUgdGhlIHNhbWUuICBUaGUg4oCcYXVk4oCd IHdvdWxkIGFsc28gbGlrZWx5IGJlIHRoZSBzYW1lIHVubGVzcyB0aGUgc3BlYyBpbmRpY2F0ZXMg dGhhdCBhbiBhbGlhcyDigJxhdWTigJ0gYmUgdXNlZCBldmVuIHRob3VnaCB0aGUgYXVkaWVuY2Ug bWF5IGJlIHRoZSBzYW1lIGVudGl0eSBpbiBib3RoIGNhc2VzLg0KDQpCLiBFeGNsdXNpdmUtVXNl IG9mIFN1Yjog4oCcc3Vi4oCdIGlzIGludGVycHJldGVkIHRvIGJ5IHRyYWRpdGlvbmFsIGRlZmlu aXRpb24gYW5kIGlzIHJlc2VydmVkIGZvciBPQXV0aCB0b2tlbnMgYW5kIE9JREMgQ29ubmVjdCB1 c2FnZSBvbmx5LiAgSW4gb3JkZXIgdG8gIGF2b2lkIGNvbmZ1c2luZywgYWxsIHByb2ZpbGluZyBl dmVudCBzcGVjcyBzaG91bGQgTk9UIHVzZSDigJxzdWLigJ0gaW4gdGhlIHRvcCBsZXZlbCBleGNl cHQgZm9yIE9JREMuDQoNClRoaXMgaGFzIHRoZSBkaXNhZHZhbnRhZ2UgdGhhdCBPSURDIHJlcXVp cmVzIHNwZWNpYWwgaGFuZGxpbmcgaW4gdGVybXMgb2YgYSBnZW5lcmFsIHVzZSBldmVudCBsaWJy YXJ5LCBidXQgb24gdGhlIG90aGVyIGhhbmQgYSBMb2dvdXQgRXZlbnQgbWlnaHQgYmUgaGFuZGxl ZCBkaXJlY3RseSBieSBleGlzdGluZyBJRCBUb2tlbiBjb2RlLg0KDQpUaGlzIHN0aWxsIGhhcyB0 aGUgZGlzYWR2YW50YWdlIHRoYXQgYW4gU0VUIGNvdWxkIGJlIGNvbmZ1c2VkIGZvciBhbiBJRCBU b2tlbi4NCg0KQy4gTm8tVG9wLUxldmVsIERhdGE6IEluIG9yZGVyIHRvIG1vcmUgYWdncmVzc2l2 ZWx5IGF2b2lkIGNvbmZ1c2lvbiBvZiBTRVRzIGFzIElEIFRva2VucywgbWFrZSBpdCBtYW5kYXRv cnkgdGhhdCBTRVRzIG1heSBub3QgY29udGFpbiBhIOKAnHN1YuKAnSB2YWx1ZSBhdCB0aGUgdG9w IGxldmVsLiAgVGhlIE9JREMgTG9nb3V0IEV2ZW50LCBmb3IgZXhhbXBsZSwgd291bGQgdGhlbiBp bmNsdWRlIGEg4oCcc3Vi4oCdIHZhbHVlIGluIHRoZSBwYXlsb2FkIGFyZWEuIFRoaXMgc2hvdWxk IGNhdXNlIGV4aXN0aW5nIHJlbHlpbmcgcGFydGllcyB0byBmYWlsIGNvcnJlY3RseS4NCg0KVGhp cyB3b3VsZCBwcm92aWRlIGEgbWF4aW1hbCBkaWZmZXJlbmNlIGZvcm0gYSBJRFRva2VuIG9yIGFj Y2VzcyB0b2tlbi4NCg0KVGhpcyB3b3VsZCBoYXZlIHRoZSBhZHZhbnRhZ2UgdGhhdCBlbnZlbG9w ZXMgY29udGFpbiBubyBkYXRhLCBhbmQgdGhhdCBldmVyeSBTRVQgaGFzIGEgcGF5bG9hZCB3aGVy ZSB0aGUgZGF0YSBpcyBmb3VuZC4gSXQgcmVxdWlyZXMgbW9yZSBwYXJzaW5nIGluIHNvbWUgY2Fz ZXMsIGJ1dCBpdCBpcyBhdCBsZWFzdCBjb25zaXN0ZW50LiBXaGlsZSB3ZSBkb27igJl0IGV4cGVj dCBnZW5lcmFsIHByb2Nlc3NvcnMgbGlrZSBpbiBTT0FQIGZvciBkaXN0cmlidXRpb24gKG11Y2gg b2YgaXQgaXMgcG9pbnQgdG8gcG9pbnQgYW5kIHZlcnkgY29udGV4dHVhbGx5IGRyaXZlbiksIEkg cGVyc29uYWxseSBleHBlY3QgdG8gc2VlOg0KICAqICBEZXZlbG9wbWVudCBvZiBnZW5lcmFsIHB1 cnBvc2UgbGlicmFyaWVzIGFuZCB0b29scyB0aGF0IGFyZSB1c2VkIGVuaGFuY2UgcHJvdG9jb2xz IGFuZCBzeXN0ZW1zDQogICogIEF1ZGl0IGFuZCB0aHJlYXQgYW5hbHlzaXMgc3lzdGVtcyB3aWxs IGJlIGxvb2tpbmcgYXQgc29tZSBldmVudHMgaGlzdG9yaWNhbGx5LiBUaGVzZSB3aWxsIHRlbmQg dG8gbWVyZ2UgbXVsdGlwbGUgZXZlbnQgZmVlZHMuDQoNCk1pa2UgSm9uZXMgYWxzbyBzdWdnZXN0 ZWQgdXNpbmcgdGhlIOKAnGN0eeKAnSAoY29udGVudCB0eXBlKSBoZWFkZXIgYXR0cmlidXRlIGZy b20gSldULiAgSSB0aGluayBtb3N0IGNvZGUgdG9kYXkgaGFzIHRoaXMgc2V0IHRvIGlnbm9yZSBv ciBmaXhlZCBhcyDigJxKV1TigJ0uICBJIHdvbmRlciB3aGF0IGN1cnJlbnQgaW1wbGVtZW50cyB3 b3VsZCBmZWVsIGlmIHdlIGludHJvZHVjZWQgYSDigJxjdHnigJ0gdmFsdWUgb2Yg4oCcU0VU4oCd PyAgV291bGQgdGhhdCBoZWxwPw0KDQpJIHRoaW5rIGl0IGlzIHZlcnkgaW1wb3J0YW50IHRvIGJl IGFibGUgdG8gY2xlYXJseSBkaXN0aW5ndWlzaCBkaWZmZXJlbnQgdHlwZXMgb2YgSldUIHRva2Vu cy4gRm9yIGV4YW1wbGUsIG5vdCBiZWluZyBhYmxlIHRvIGNyb3NzIHBvc3QgYSBTZWN1cml0eSBF dmVudCBUb2tlbiBhcyBhbiBJZCBUb2tlbi4NCg0KUmVhZGluZyBSRkMgNzUxOSBJIGRvbid0IHRo aW5rIGN0eSBmaXRzIHRoZSBiaWxsLCBidXQgSSBjb3VsZCBiZSB3cm9uZy4gY3R5IGlzIGEgaGVh ZGVyIHBhcmFtZXRlciB1c2VkIGJ5IHRoZSBjcnlwdG8gYWxnb3JpdGhtIGFuZCB0aGUgZGVmYXVs dCB2YWx1ZSBpcyBKV1QuIFdlIG5lZWQgdG8gZGlzdGluZ3Vpc2ggc3ViLXR5cGVzIG9mIEpXVCwg YW5kIGl0IHNob3VsZCBiZSBhIGNsYWltIGluc2lkZSB0aGUgSldULg0KDQpXaXRoIHRoZSBhYm92 ZSBpc3N1ZSBpbiBtaW5kLCBJIHRoaW5rIG9wdGlvbiBBIGlzIHRoZSBjbGVhbmVzdCBzb2x1dGlv bi4NCg0KDQoNClRoYW5rcyBmb3IgeW91ciBjb21tZW50cy4NCg0KDQpQaGlsDQoNCkBpbmRlcGVu ZGVudGlkDQp3d3cuaW5kZXBlbmRlbnRpZC5jb208aHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNv bT4NCnBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4NCg0K DQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K SWQtZXZlbnQgbWFpbGluZyBsaXN0DQpJZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86SWQtZXZlbnRA aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50 DQoNCg== --_000_SN1PR0301MB16450C7C64DACA2254C9C36CF5EA0SN1PR0301MB1645_ 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 dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uZ21haWwtbTE3MTY3 MzQwMTI4MjYwMTkzMzZhcHBsZS1zdHlsZS1zcGFuDQoJe21zby1zdHlsZS1uYW1lOmdtYWlsLW1f MTcxNjczNDAxMjgyNjAxOTMzNmFwcGxlLXN0eWxlLXNwYW47fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6IzAwMjA2MDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5KdXN0IGZvciBjb21wbGV0ZW5lc3MsIHRo ZSBvdGhlciB3YXkgb2YgZGlzdGluZ3Vpc2hpbmcgYmV0d2VlbiBKV1RzIGlzIHRoZSDigJx0eXDi gJ0gdmFsdWUuJm5ic3A7IChUaGUgZGlmZmVyZW5jZSBiZXR3ZWVuIOKAnGN0eeKAnSBhbmQg4oCc dHlw4oCdIGlzIHRoYXQg4oCcY3R54oCdIGlzIHRoZSB0eXBlIG9mDQogdGhlIGNvbnRlbnQgb2Yg dGhlIEpXUy9KV0UgcGF5bG9hZCB3aGVyZWFzIOKAnHR5cOKAnSBpcyB0aGUgdHlwZSBvZiB0aGUg ZW50aXJlIG9iamVjdC4pJm5ic3A7IFlvdeKAmWxsIHNlZSB0aGF0IOKAnHR5cOKAnSBpcyBldmVu IHVzZWQgaW4gdGhlIEpXUyBleGFtcGxlcy4mbmJzcDsg4oCcdHlw4oCdIGlzIGRlc2NyaWJlZCBh dA0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc1MTUjc2VjdGlvbi00 LjEuOSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc1MTUjc2VjdGlvbi00LjEuOTwv YT4gYW5kDQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzUxOSNzZWN0 aW9uLTUuMSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc1MTkjc2VjdGlvbi01LjE8 L2E+LiZuYnNwOyDigJxjdHnigJ0gaXMgZGVzY3JpYmVkIGF0DQo8YSBocmVmPSJodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvcmZjNzUxNSNzZWN0aW9uLTQuMS4xMCI+aHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL3JmYzc1MTUjc2VjdGlvbi00LjEuMTA8L2E+IGFuZA0KPGEgaHJlZj0iaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc1MTkjc2VjdGlvbi01LjIiPmh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9yZmM3NTE5I3NlY3Rpb24tNS4yPC9hPi48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2 MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEg bmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+UGxh Y2luZyByZXN0cmljdGlvbnMgb24g4oCcc3Vi4oCdIHdvdWxkIHVubmVjZXNzYXJ5IGFuZCBjb3Vu dGVyLXByb2R1Y3RpdmUuJm5ic3A7IEl04oCZcyB0aGUga2luZCBvZiBjb21wbGV4aXR5IHRoYXQg Y291bGQgcmVzdWx0IGluIHRoZSBBRHMgYW5kDQogSUVTRyByYWlzaW5nIHF1ZXN0aW9ucyB0aGF0 IHdvdWxkIHN0YW5kIGluIHRoZSB3YXkgb2YgYWNjZXB0YW5jZSBvZiB0aGUgaW5kaXZpZHVhbCBz dWJtaXNzaW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29t cG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRD b21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9zcGFuPjwvcD4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21w b3NlIj48L3NwYW4+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBJZC1ldmVudCBbbWFpbHRvOmlkLWV2ZW50 LWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPk1hcml1cyBTY3VydGVzY3U8 YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBBdWd1c3QgMjQsIDIwMTYgMTI6NTEgUE08YnI+ DQo8Yj5Ubzo8L2I+IFBoaWwgSHVudCAmbHQ7cGhpbC5odW50QG9yYWNsZS5jb20mZ3Q7PGJyPg0K PGI+Q2M6PC9iPiBpZC1ldmVudEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0lk LWV2ZW50XSBEaXNjdXNzaW9uIG9uIHVzZSBvZiAmcXVvdDtzdWImcXVvdDsgYW5kIGNvbmZ1c2lv biBhcyBJRCBUb2tlbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T24gV2VkLCBBdWcgMjQsIDIwMTYgYXQgMTE6MDcgQU0sIFBoaWwgSHVudCAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+cGhp bC5odW50QG9yYWNsZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBp biI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGF1dGhvcnMgaGF2 ZSBiZWVuIGhhdmluZyBhIGRpc2N1c3Npb24gd2l0aCByZWdhcmRzIHRvIHVzaW5nIHRoZSDigJxz dWLigJ0gY2xhaW0gaW4gdGhlIHRvcCBsZXZlbC4gSSB0aGluayBpdCBpcyBpbXBvcnRhbnQgdG8g dHJ5IGFuZCBnZXQgdGhpcyBkaXNjdXNzaW9uIGJhY2sgdG8gdGhlIG1haW4gZ3JvdXAuIE15IGFw b2xvZ2llcyBmb3IgdGhlIGxvbmcgbm90ZS4gSSB3YW50ZWQgdG8gZ2V0IGFsbCB0aGUgcHJvcw0K IGFuZCBjb25zIG9uIHRoZSB0YWJsZSAoaGludDogJm5ic3A7cGxlYXNlIGFkZCBpZiBJIG1pc3Nl ZCBhbnkpLi4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkEgcXVlc3Rpb24gcmVtYWlucyBzaG91bGQg4oCcc3Vi4oCdIGJlIHVzYWJsZSBhdCB0 aGUgdG9wIGxldmVsLiZuYnNwOyBUaGUgZG93bnNpZGUgb2YgdGhpcyBhcHByb2FjaCBpcyB0aGF0 IGEgU0VUIGNvdWxkIHBvdGVudGlhbGx5IGJlIHByZXNlbnRlZCBhcyBhbiBhY2Nlc3Mgb3IgaUQg dG9rZW4gYW5kIG1pZ2h0IGluaXRpYWxseSBiZSBjb25mdXNlZCBiZWNhdXNlIGV4aXN0aW5nIGNv ZGUgZG9lcyBub3Qga25vdyBpdCBuZWVkcw0KIHRvIGxvb2sgZm9yIGFuIOKAnGV2ZW50c+KAnSBh dHRyaWJ1dGUuJm5ic3A7IFRoZSBTRVQgYW5kIElEIFRva2VuIGZvciBhbGwgaW50ZW5zaXZlIHB1 cnBvc2VzIGFyZSB0aGUgc2FtZSBzaW5jZSBhIFNFVCBqdXN0IGhhcyBzb21ldGhpbmcgZXh0cmEg KHRoZSBldmVudHMgY2xhaW0pLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5UaGVyZSBpcyBhbHNvIHRoZSBxdWVzdGlvbiB0aGF0IGlmIE9JREMg TG9nb3V0IHVzZXMgaXQgaW4gdGhlIHRvcCBsZXZlbCwgbWF5IG90aGVyIGV2ZW50cyB1c2UgaXQ/ IFJGQzc1MTkgZGVmaW5lcyDigJxzdWLigJ0gYXMgYSBTdHJpbmcgb3IgVVJJIHZhbHVlLiBGb3Ig ZXhhbXBsZSwgaW4gU0NJTSBldmVudHMsIHRoZSDigJxzdWLigJ0gdmFsdWUgY291bGQgYmUgYSBT Q0lNIFJlc291cmNlIFVSSSB0aGF0IGluZGljYXRlcyB0aGUNCiByZXNvdXJjZSB3aG9zZSBzdGF0 ZSBoYXMgY2hhbmdlZC4mbmJzcDsgSW4gT0F1dGggaXQgY291bGQgYmUgZGVmaW5lZCBhcyB0aGUg dG9rZW4gaWRlbnRpZmllciBvZiB0aGUgdG9rZW4gdGhhdCBoYXMgYmVlbiByZXZva2VkLiZuYnNw OyBBIFNFVCBhYm91dCBibGFja2xpc3RpbmcgYW4gSVAgYWRkcmVzcyBtaWdodCBwdXQgdGhlIElQ IGFkZHJlc3MgaW4gc3ViLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5TbyB0aGVyZSBhcmUgdGhyZWUgb3B0aW9ucyAoT3B0aW9uIEEgc2VlbXMg dG8gYmUgZmF2b3VyZWQgc28gZmFyKTogJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkEuJm5ic3A7IFN1YiBhdCBUb3AgTGV2ZWw6 PC9iPiAmbmJzcDvigJxzdWLigJ0gZ2VuZXJhbGx5IHVzZWQgdG8gcmVmZXJlbmNlIHRoZSBTZWN1 cml0eSBTdWJqZWN0IHRoZSBTRVQgaXMgdGFsa2luZyBhYm91dC4mbmJzcDsgSXQgdXNlcyBhIG1v cmUgZ2VuZXJhbCBlbmdsaXNoIGxhbmd1YWdlIGludGVudCBvZiBzdWJqZWN0IHJhdGhlciB0aGFu IHRoZSB0cmFkaXRpb25hbCB1c2UgYXMgc2VlbiBpbiBTQU1MIG9yIE9wZW5JRCBDb25uZWN0LiZu YnNwOw0KIFJlZ2FyZGxlc3MgaXQgaXMgc3RpbGwgY29tcGxpYW50IHdpdGggUkZDNzUxOSAoYSBT dHJpbmcgb3IgVVJJKS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhpcyB3b3VsZCB0ZW5kIHRvIGxlYWQgdG8gYSBzdHlsZSBvZiBTRVRzIHdo ZXJlIHRoZSBlbnZlbG9wZSBjYXJyaWVzIHRoZSB2YWxpZGF0aW9uIGluZm9ybWF0aW9uLCB0aGUg dHlwZSBvZiBldmVudCwgYW5kIHRoZSBzdWJqZWN0IG9mIHRoZSBldmVudC4gQWRkaXRpb25hbCBk YXRhIGdvZXMgaW4gdGhlIHBheWxvYWQuIEFuIGFkdmFudGFnZSBvZiB0aGlzIHN0eWxlLCBpcyB0 aGF0IGZvciBtYW55IGV2ZW50cywNCiB0aGUgb25seSB0aGluZyBuZWVkZWQgaXMgdGhlIGV2ZW50 IHR5cGUgYW5kIHRoZSBzdWJqZWN0LiZuYnNwOyBObyBwYXlsb2FkcyB3b3VsZCBiZSBuZWVkZWQu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5Gb3IgZXZlbnRzIHRoYXQgZG9u4oCZdCB3YW50IHBheWxvYWQsIGl0IGlzIHByb2JhYmx5 IG9rIGZvciBwcm9maWxpbmcgZXZlbnQgc3RhbmRhcmRzIHRvIGRlZmluZSBtb3JlIGNsYWltcyBh dCB0aGUgdG9wIGxldmVsLiBUaGV5IE1VU1QgYmUgcmVnaXN0ZXJlZCBpbiB0aGUgSldUIHJlZ2lz dHJ5LiBQcm9maWxpbmcgZXZlbnRzIGNhbiBhdm9pZCByZWdpc3RyYXRpb24gYnkganVzdCBwdXR0 aW5nIHRoZWlyIGF0dHJpYnV0ZXMvY2xhaW1zDQogaW4gdGhlIHBheWxvYWQgYXJlYSBhcyBkZXNj cmliZWQgaW4gdGhlIHNwZWMuJm5ic3A7IEhvd2V2ZXIsIHRoaXMgd291bGQgYmUgaW5jb25zaXN0 ZW50IHdpdGggdGhvc2UgdGhhdCB1c2UgcGF5bG9hZHMgd2l0aCB1bnJlZ2lzdGVyZWQgY2xhaW1z LiZuYnNwOyBJIHBvaW50IG91dCB0aGF0IHdlIHN3aXRjaGVkIGZyb20gcmVnaXN0ZXJlZCBldmVu dCBVUk5zIHRvIFVSSXMgdG8gYXZvaWQgcmVnaXN0cmF0aW9uLiZuYnNwOyBIZW5jZSB0aGUgbW92 ZSB0byBwYXlsb2FkIG9iamVjdHMNCiB0byBlbGltaW5hdGUgcmVnaXN0cmF0aW9uIGZvciBhdHRy aWJ1dGVzL2NsYWltcy4gJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBzdGlsbCBoYXMgdGhlIG5lZ2F0aXZlcyBv ZiBiZWluZyBjb25mdXNhYmxlIGFzIGFuIElEIFRva2VuIGJ5IGV4aXN0aW5nIGNvZGUuIFRoZXJl IGhhcyBiZWVuIGEgZGlzY3Vzc2lvbiB0aGF0IOKAnGlzc+KAnSBhbmQvb3Ig4oCcYXVk4oCdIHNo b3VsZCBhY3R1YWxseSBiZSBkaWZmZXJlbnQgYW5kIHRoZSByZWNlaXZlciBzaG91bGQgZGV0ZWN0 IHRoYXQuJm5ic3A7IEhvd2V2ZXIgaW4gdGhlIE9JREMgTG9nb3V0IGNhc2UsIGJ5DQogZGVzaWdu LCB0aGUg4oCcaXNz4oCdIHZhbHVlIHdvdWxkIGJlIHRoZSBzYW1lLiZuYnNwOyBUaGUg4oCcYXVk 4oCdIHdvdWxkIGFsc28gbGlrZWx5IGJlIHRoZSBzYW1lIHVubGVzcyB0aGUgc3BlYyBpbmRpY2F0 ZXMgdGhhdCBhbiBhbGlhcyDigJxhdWTigJ0gYmUgdXNlZCBldmVuIHRob3VnaCB0aGUgYXVkaWVu Y2UgbWF5IGJlIHRoZSBzYW1lIGVudGl0eSBpbiBib3RoIGNhc2VzLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5CLiBFeGNsdXNpdmUtVXNl IG9mIFN1Yjo8L2I+IOKAnHN1YuKAnSBpcyBpbnRlcnByZXRlZCB0byBieSB0cmFkaXRpb25hbCBk ZWZpbml0aW9uIGFuZCBpcyByZXNlcnZlZCBmb3IgT0F1dGggdG9rZW5zIGFuZCBPSURDIENvbm5l Y3QgdXNhZ2Ugb25seS4mbmJzcDsgSW4gb3JkZXIgdG8gJm5ic3A7YXZvaWQgY29uZnVzaW5nLCBh bGwgcHJvZmlsaW5nIGV2ZW50IHNwZWNzIHNob3VsZCBOT1QgdXNlIOKAnHN1YuKAnSBpbiB0aGUg dG9wIGxldmVsDQogZXhjZXB0IGZvciBPSURDLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGhhcyB0aGUgZGlzYWR2YW50YWdlIHRoYXQg T0lEQyByZXF1aXJlcyBzcGVjaWFsIGhhbmRsaW5nIGluIHRlcm1zIG9mIGEgZ2VuZXJhbCB1c2Ug ZXZlbnQgbGlicmFyeSwgYnV0IG9uIHRoZSBvdGhlciBoYW5kIGEgTG9nb3V0IEV2ZW50IG1pZ2h0 IGJlIGhhbmRsZWQgZGlyZWN0bHkgYnkgZXhpc3RpbmcgSUQgVG9rZW4gY29kZS48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBzdGlsbCBo YXMgdGhlIGRpc2FkdmFudGFnZSB0aGF0IGFuIFNFVCBjb3VsZCBiZSBjb25mdXNlZCBmb3IgYW4g SUQgVG9rZW4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPkMuIE5vLVRvcC1MZXZlbCBEYXRhOjwvYj4gSW4gb3JkZXIgdG8gbW9yZSBhZ2dy ZXNzaXZlbHkgYXZvaWQgY29uZnVzaW9uIG9mIFNFVHMgYXMgSUQgVG9rZW5zLCBtYWtlIGl0IG1h bmRhdG9yeSB0aGF0IFNFVHMgbWF5IG5vdCBjb250YWluIGEg4oCcc3Vi4oCdIHZhbHVlIGF0IHRo ZSB0b3AgbGV2ZWwuJm5ic3A7IFRoZSBPSURDIExvZ291dCBFdmVudCwgZm9yIGV4YW1wbGUsIHdv dWxkIHRoZW4gaW5jbHVkZSBhIOKAnHN1YuKAnQ0KIHZhbHVlIGluIHRoZSBwYXlsb2FkIGFyZWEu IFRoaXMgc2hvdWxkIGNhdXNlIGV4aXN0aW5nIHJlbHlpbmcgcGFydGllcyB0byBmYWlsIGNvcnJl Y3RseS4gJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRoaXMgd291bGQgcHJvdmlkZSBhIG1heGltYWwgZGlmZmVyZW5jZSBmb3JtIGEg SURUb2tlbiBvciBhY2Nlc3MgdG9rZW4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgd291bGQgaGF2ZSB0aGUgYWR2YW50YWdlIHRoYXQg ZW52ZWxvcGVzIGNvbnRhaW4gbm8gZGF0YSwgYW5kIHRoYXQgZXZlcnkgU0VUIGhhcyBhIHBheWxv YWQgd2hlcmUgdGhlIGRhdGEgaXMgZm91bmQuIEl0IHJlcXVpcmVzIG1vcmUgcGFyc2luZyBpbiBz b21lIGNhc2VzLCBidXQgaXQgaXMgYXQgbGVhc3QgY29uc2lzdGVudC4gV2hpbGUgd2UgZG9u4oCZ dCBleHBlY3QgZ2VuZXJhbCBwcm9jZXNzb3JzIGxpa2UNCiBpbiBTT0FQIGZvciBkaXN0cmlidXRp b24gKG11Y2ggb2YgaXQgaXMgcG9pbnQgdG8gcG9pbnQgYW5kIHZlcnkgY29udGV4dHVhbGx5IGRy aXZlbiksIEkgcGVyc29uYWxseSBleHBlY3QgdG8gc2VlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICogJm5ic3A7RGV2ZWxvcG1lbnQg b2YgZ2VuZXJhbCBwdXJwb3NlIGxpYnJhcmllcyBhbmQgdG9vbHMgdGhhdCBhcmUgdXNlZCBlbmhh bmNlIHByb3RvY29scyBhbmQgc3lzdGVtcyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICogJm5ic3A7QXVkaXQgYW5kIHRocmVh dCBhbmFseXNpcyBzeXN0ZW1zIHdpbGwgYmUgbG9va2luZyBhdCBzb21lIGV2ZW50cyBoaXN0b3Jp Y2FsbHkuIFRoZXNlIHdpbGwgdGVuZCB0byBtZXJnZSBtdWx0aXBsZSBldmVudCBmZWVkcy48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWlrZSBK b25lcyBhbHNvIHN1Z2dlc3RlZCB1c2luZyB0aGUgPGI+4oCcY3R54oCdPC9iPiAoY29udGVudCB0 eXBlKSBoZWFkZXIgYXR0cmlidXRlIGZyb20gSldULiZuYnNwOyBJIHRoaW5rIG1vc3QgY29kZSB0 b2RheSBoYXMgdGhpcyBzZXQgdG8gaWdub3JlIG9yIGZpeGVkIGFzIOKAnEpXVOKAnS4mbmJzcDsg SSB3b25kZXIgd2hhdCBjdXJyZW50IGltcGxlbWVudHMgd291bGQgZmVlbCBpZiB3ZSBpbnRyb2R1 Y2VkIGEg4oCcY3R54oCdIHZhbHVlIG9mDQog4oCcU0VU4oCdPyZuYnNwOyBXb3VsZCB0aGF0IGhl bHA/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayBpdCBpcyB2ZXJ5IGltcG9ydGFudCB0byBi ZSBhYmxlIHRvIGNsZWFybHkgZGlzdGluZ3Vpc2ggZGlmZmVyZW50IHR5cGVzIG9mIEpXVCB0b2tl bnMuIEZvciBleGFtcGxlLCBub3QgYmVpbmcgYWJsZSB0byBjcm9zcyBwb3N0IGEgU2VjdXJpdHkg RXZlbnQgVG9rZW4gYXMgYW4gSWQgVG9rZW4uJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlYWRpbmcmbmJzcDtSRkMgNzUxOSBJIGRv bid0IHRoaW5rIGN0eSBmaXRzIHRoZSBiaWxsLCBidXQgSSBjb3VsZCBiZSB3cm9uZy4gY3R5IGlz IGEgaGVhZGVyIHBhcmFtZXRlciB1c2VkIGJ5IHRoZSBjcnlwdG8gYWxnb3JpdGhtIGFuZCB0aGUg ZGVmYXVsdCB2YWx1ZSBpcyBKV1QuIFdlIG5lZWQgdG8gZGlzdGluZ3Vpc2ggc3ViLXR5cGVzIG9m IEpXVCwgYW5kIGl0IHNob3VsZCBiZSBhIGNsYWltIGluc2lkZSB0aGUgSldULjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaXRoIHRoZSBhYm92 ZSBpc3N1ZSBpbiBtaW5kLCBJIHRoaW5rIG9wdGlvbiBBIGlzIHRoZSBjbGVhbmVzdCBzb2x1dGlv bi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5UaGFua3MgZm9yIHlvdXIgY29tbWVudHMuPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij5QaGlsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPkBpbmRlcGVuZGVudGlkPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48 YSBocmVmPSJodHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tIiB0YXJnZXQ9Il9ibGFuayI+d3d3 LmluZGVwZW5kZW50aWQuY29tPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj48YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0i X2JsYW5rIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCklkLWV2ZW50IG1haWxp bmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9yZyI+SWQtZXZlbnRA aWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9pZC1ldmVudCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_SN1PR0301MB16450C7C64DACA2254C9C36CF5EA0SN1PR0301MB1645_-- From nobody Wed Aug 24 13:31:57 2016 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 68E4B12D675 for ; Wed, 24 Aug 2016 13:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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] 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 HLRWJIcaSV-d for ; Wed, 24 Aug 2016 13:31:53 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::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 8D31812D5BE for ; Wed, 24 Aug 2016 13:31:53 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id l2so27132076qkf.3 for ; Wed, 24 Aug 2016 13:31:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=JRWYXzsTdN/ewoZf3daqZkH1smb39VvfmmiavRFW5So=; b=MjETismvLLn8nqYOgvyVGunW8FHtKPOACxrjcTJ6lsEURtMml6yp2+PhSBWcCzuQs2 FWuOaKwOR08ha14fGCVu5s2ySidWFpITyS6SCqS6wciE6c7gVNIgR1Mdy2nJt7dfN/o0 N+/EolDaK7PCjwtFgdvll1A2wxabH78Vve1rtuZkCc9zL3Fwe1uIemdZPDk/nD2wrUPI dIAAOBowdSBPWD5y8cyeVvaqq/VVwVaphMMcmblVq+VxDRFAzdMtwjnJ/MOgN1P4rYXr 3C3nkxrJ5ArZ/99DQ1lE3TZ8K5rXNrbwDR9/bhz8SOb9H0tfQeXeMlA6vkUL2DC9y06/ aZ5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=JRWYXzsTdN/ewoZf3daqZkH1smb39VvfmmiavRFW5So=; b=aY6lchbDnct8liU74ItnWtawCUAfvTWIGJ6YY476mSIAaSyxey6Mk0AVCKZ6NAwSJp //JCicDC5Dz0MLwpUSdq62p9na8cRuYbbQZpUfLoe4cjrnGq2dIzI7pgcac13uBx23iH uLEeNbcLSMkvuAfNtehlBjzrywwnUUro2SS/DnPTsQ8FkKEHp1tl0MzMVofyMW7VUyVz KpMg0Q3N056qT9xrRmFobflDPunYybu+fq32FBlnVXD7CfeuXZzCD8fELCUp/G2QtQeL 72VX5unLjx2QFHdIK9N58FPFpuoXgFv5BTn9gIuQlb1nqxLphQ73fdcdo/sHZH6n56St HiTA== X-Gm-Message-State: AE9vXwPnZowEy4nzecg+0IL8sNXL2rLd02Ft0L835hKsxCeIHbtIpZIKaKB/P3xr2GEA9+rn X-Received: by 10.55.190.68 with SMTP id o65mr5879469qkf.92.1472070712556; Wed, 24 Aug 2016 13:31:52 -0700 (PDT) Received: from [192.168.8.101] ([181.201.108.96]) by smtp.gmail.com with ESMTPSA id f17sm5633243qke.37.2016.08.24.13.31.50 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 24 Aug 2016 13:31:51 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_7C6741E4-8D5F-41F4-BC4A-6CE6A4A647BB" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: John Bradley In-Reply-To: Date: Wed, 24 Aug 2016 17:31:47 -0300 Message-Id: References: To: Marius Scurtescu X-Mailer: Apple Mail (2.3124) Archived-At: Cc: id-event@ietf.org, Phil Hunt Subject: Re: [Id-event] Discussion on use of "sub" and confusion as ID Token X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 24 Aug 2016 20:31:56 -0000 --Apple-Mail=_7C6741E4-8D5F-41F4-BC4A-6CE6A4A647BB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The idea for cty was to allow a JWS to encapsulate things like a binary = GIF as an example. I think using it for Distinguishing subtypes of JWT = would be a stretch. I am most comfortable with A. I think that adding a JWT type claim at = the top level may also be useful going forward to avoid = misinterpretation. John B. > On Aug 24, 2016, at 4:51 PM, Marius Scurtescu = wrote: >=20 > On Wed, Aug 24, 2016 at 11:07 AM, Phil Hunt > wrote: >=20 > The authors have been having a discussion with regards to using the = =E2=80=9Csub=E2=80=9D claim in the top level. I think it is important to = try and get this discussion back to the main group. My apologies for the = long note. I wanted to get all the pros and cons on the table (hint: = please add if I missed any)... >=20 > A question remains should =E2=80=9Csub=E2=80=9D be usable at the top = level. The downside of this approach is that a SET could potentially be = presented as an access or iD token and might initially be confused = because existing code does not know it needs to look for an =E2=80=9Cevent= s=E2=80=9D attribute. The SET and ID Token for all intensive purposes = are the same since a SET just has something extra (the events claim). >=20 > There is also the question that if OIDC Logout uses it in the top = level, may other events use it? RFC7519 defines =E2=80=9Csub=E2=80=9D as = a String or URI value. For example, in SCIM events, the =E2=80=9Csub=E2=80= =9D value could be a SCIM Resource URI that indicates the resource whose = state has changed. In OAuth it could be defined as the token identifier = of the token that has been revoked. A SET about blacklisting an IP = address might put the IP address in sub. >=20 > So there are three options (Option A seems to be favoured so far): =20 >=20 > A. Sub at Top Level: =E2=80=9Csub=E2=80=9D generally used to = reference the Security Subject the SET is talking about. It uses a more = general english language intent of subject rather than the traditional = use as seen in SAML or OpenID Connect. Regardless it is still compliant = with RFC7519 (a String or URI). >=20 > This would tend to lead to a style of SETs where the envelope carries = the validation information, the type of event, and the subject of the = event. Additional data goes in the payload. An advantage of this style, = is that for many events, the only thing needed is the event type and the = subject. No payloads would be needed. >=20 > For events that don=E2=80=99t want payload, it is probably ok for = profiling event standards to define more claims at the top level. They = MUST be registered in the JWT registry. Profiling events can avoid = registration by just putting their attributes/claims in the payload area = as described in the spec. However, this would be inconsistent with = those that use payloads with unregistered claims. I point out that we = switched from registered event URNs to URIs to avoid registration. = Hence the move to payload objects to eliminate registration for = attributes/claims. =20 >=20 > This still has the negatives of being confusable as an ID Token by = existing code. There has been a discussion that =E2=80=9Ciss=E2=80=9D = and/or =E2=80=9Caud=E2=80=9D should actually be different and the = receiver should detect that. However in the OIDC Logout case, by = design, the =E2=80=9Ciss=E2=80=9D value would be the same. The = =E2=80=9Caud=E2=80=9D would also likely be the same unless the spec = indicates that an alias =E2=80=9Caud=E2=80=9D be used even though the = audience may be the same entity in both cases. >=20 > B. Exclusive-Use of Sub: =E2=80=9Csub=E2=80=9D is interpreted to by = traditional definition and is reserved for OAuth tokens and OIDC Connect = usage only. In order to avoid confusing, all profiling event specs = should NOT use =E2=80=9Csub=E2=80=9D in the top level except for OIDC. >=20 > This has the disadvantage that OIDC requires special handling in terms = of a general use event library, but on the other hand a Logout Event = might be handled directly by existing ID Token code. >=20 > This still has the disadvantage that an SET could be confused for an = ID Token. >=20 > C. No-Top-Level Data: In order to more aggressively avoid confusion of = SETs as ID Tokens, make it mandatory that SETs may not contain a = =E2=80=9Csub=E2=80=9D value at the top level. The OIDC Logout Event, = for example, would then include a =E2=80=9Csub=E2=80=9D value in the = payload area. This should cause existing relying parties to fail = correctly. =20 >=20 > This would provide a maximal difference form a IDToken or access = token. >=20 > This would have the advantage that envelopes contain no data, and that = every SET has a payload where the data is found. It requires more = parsing in some cases, but it is at least consistent. While we don=E2=80=99= t expect general processors like in SOAP for distribution (much of it is = point to point and very contextually driven), I personally expect to = see: > * Development of general purpose libraries and tools that are used = enhance protocols and systems=20 > * Audit and threat analysis systems will be looking at some events = historically. These will tend to merge multiple event feeds. >=20 > Mike Jones also suggested using the =E2=80=9Ccty=E2=80=9D (content = type) header attribute from JWT. I think most code today has this set = to ignore or fixed as =E2=80=9CJWT=E2=80=9D. I wonder what current = implements would feel if we introduced a =E2=80=9Ccty=E2=80=9D value of = =E2=80=9CSET=E2=80=9D? Would that help? >=20 > I think it is very important to be able to clearly distinguish = different types of JWT tokens. For example, not being able to cross post = a Security Event Token as an Id Token.=20 >=20 > Reading RFC 7519 I don't think cty fits the bill, but I could be = wrong. cty is a header parameter used by the crypto algorithm and the = default value is JWT. We need to distinguish sub-types of JWT, and it = should be a claim inside the JWT. >=20 > With the above issue in mind, I think option A is the cleanest = solution. >=20 >=20 >=20 > Thanks for your comments. >=20 >=20 > Phil >=20 > @independentid > www.independentid.com = phil.hunt@oracle.com = >=20 >=20 >=20 >=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 = --Apple-Mail=_7C6741E4-8D5F-41F4-BC4A-6CE6A4A647BB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The idea for cty was to allow a JWS to encapsulate things = like a binary GIF as an example.   I think using it for = Distinguishing subtypes of JWT would be a stretch.

I am most comfortable with A.   I = think that adding a JWT type claim at the top level may also be useful = going forward to avoid misinterpretation.

John B.
On Aug 24, 2016, at 4:51 PM, = Marius Scurtescu <mscurtescu@google.com> wrote:

On Wed, Aug 24, 2016 at = 11:07 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

The authors have been having a = discussion with regards to using the =E2=80=9Csub=E2=80=9D claim in the = top level. I think it is important to try and get this discussion back = to the main group. My apologies for the long note. I wanted to get all = the pros and cons on the table (hint:  please add if I missed = any)...

A = question remains should =E2=80=9Csub=E2=80=9D be usable at the top = level.  The downside of this approach is that a SET could = potentially be presented as an access or iD token and might initially be = confused because existing code does not know it needs to look for an = =E2=80=9Cevents=E2=80=9D attribute.  The SET and ID Token for all = intensive purposes are the same since a SET just has something extra = (the events claim).

There is also the question that if OIDC Logout uses it in the = top level, may other events use it? RFC7519 defines =E2=80=9Csub=E2=80=9D = as a String or URI value. For example, in SCIM events, the =E2=80=9Csub=E2= =80=9D value could be a SCIM Resource URI that indicates the resource = whose state has changed.  In OAuth it could be defined as the token = identifier of the token that has been revoked.  A SET about = blacklisting an IP address might put the IP address in sub.

So there are three = options (Option A seems to be favoured so far):  

A.  = Sub at Top Level:  =E2=80=9Csub=E2=80=9D = generally used to reference the Security Subject the SET is talking = about.  It uses a more general english language intent of subject = rather than the traditional use as seen in SAML or OpenID Connect.  = Regardless it is still compliant with RFC7519 (a String or = URI).

This = would tend to lead to a style of SETs where the envelope carries the = validation information, the type of event, and the subject of the event. = Additional data goes in the payload. An advantage of this style, is that = for many events, the only thing needed is the event type and the = subject.  No payloads would be needed.

For events that don=E2=80= =99t want payload, it is probably ok for profiling event standards to = define more claims at the top level. They MUST be registered in the JWT = registry. Profiling events can avoid registration by just putting their = attributes/claims in the payload area as described in the spec.  = However, this would be inconsistent with those that use payloads with = unregistered claims.  I point out that we switched from registered = event URNs to URIs to avoid registration.  Hence the move to = payload objects to eliminate registration for attributes/claims. =  

This still has the negatives of being confusable as an ID = Token by existing code. There has been a discussion that =E2=80=9Ciss=E2=80= =9D and/or =E2=80=9Caud=E2=80=9D should actually be different and the = receiver should detect that.  However in the OIDC Logout case, by = design, the =E2=80=9Ciss=E2=80=9D value would be the same.  The = =E2=80=9Caud=E2=80=9D would also likely be the same unless the spec = indicates that an alias =E2=80=9Caud=E2=80=9D be used even though the = audience may be the same entity in both cases.

B. Exclusive-Use of = Sub: =E2=80=9Csub=E2= =80=9D is interpreted to by traditional definition and is reserved for = OAuth tokens and OIDC Connect usage only.  In order to  avoid = confusing, all profiling event specs should NOT use =E2=80=9Csub=E2=80=9D = in the top level except for OIDC.

This has the disadvantage that OIDC = requires special handling in terms of a general use event library, but = on the other hand a Logout Event might be handled directly by existing = ID Token code.

This still has the disadvantage that an SET could be confused = for an ID Token.

C. No-Top-Level Data: In order to more = aggressively avoid confusion of SETs as ID Tokens, make it mandatory = that SETs may not contain a =E2=80=9Csub=E2=80=9D value at the top = level.  The OIDC Logout Event, for example, would then include a = =E2=80=9Csub=E2=80=9D value in the payload area. This should cause = existing relying parties to fail correctly.  

This would provide a = maximal difference form a IDToken or access token.

This would have the = advantage that envelopes contain no data, and that every SET has a = payload where the data is found. It requires more parsing in some cases, = but it is at least consistent. While we don=E2=80=99t expect general = processors like in SOAP for distribution (much of it is point to point = and very contextually driven), I personally expect to see:
  * =  Development of general purpose libraries and tools that are used = enhance protocols and systems 
  *  Audit and threat = analysis systems will be looking at some events historically. These will = tend to merge multiple event feeds.

Mike Jones also suggested using = the =E2=80=9Ccty=E2=80=9D (content type) header = attribute from JWT.  I think most code today has this set to ignore = or fixed as =E2=80=9CJWT=E2=80=9D.  I wonder what current = implements would feel if we introduced a =E2=80=9Ccty=E2=80=9D value of = =E2=80=9CSET=E2=80=9D?  Would that = help?

I think it is very important to be able to clearly = distinguish different types of JWT tokens. For example, not being able = to cross post a Security Event Token as an Id Token. 

Reading RFC 7519 I = don't think cty fits the bill, but I could be wrong. cty is a header = parameter used by the crypto algorithm and the default value is JWT. We = need to distinguish sub-types of JWT, and it should be a claim inside = the JWT.

With = the above issue in mind, I think option A is the cleanest = solution.



Thanks for your comments.


Phil

@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=_7C6741E4-8D5F-41F4-BC4A-6CE6A4A647BB-- From nobody Wed Aug 24 13:32:41 2016 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 7252A12D685 for ; Wed, 24 Aug 2016 13:32:40 -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 7c3yckg7iCBh for ; Wed, 24 Aug 2016 13:32:38 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0135.outbound.protection.outlook.com [104.47.37.135]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4909F12D5BE for ; Wed, 24 Aug 2016 13:32:38 -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=UKbcUQVQsPMqztOS3FIrfZ/gxPAIaSCHD8P9waFuFXI=; b=QQobLnaSWI/kp5FNS6dMMVkGF5DsTpcWMCShV8z2LrmZyjeeINSt/VLZv+BE6u2SjkQ7+HcZBOTYV0Cw6gaqKU+BMLByCo24/AeN/rN8vnr67dZtrh1fJdUgzl5X6yxqRn1JS8ZF+rg99TOtpohx7jv0EkDC6sbww5PythVUaJc= Received: from SN1PR0301MB1645.namprd03.prod.outlook.com (10.162.130.139) by SN1PR0301MB1645.namprd03.prod.outlook.com (10.162.130.139) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.13; Wed, 24 Aug 2016 20:32:36 +0000 Received: from SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) by SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) with mapi id 15.01.0587.013; Wed, 24 Aug 2016 20:32:36 +0000 From: Mike Jones To: "id-event@ietf.org" Thread-Topic: ID Event Token Simplification Thread-Index: AdH+RIQI/K7I8J4VTqS0zwwP7EWChg== Date: Wed, 24 Aug 2016 20:32:35 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [64.134.242.226] x-ms-office365-filtering-correlation-id: 58645303-f646-4290-0437-08d3cc5dc8c8 x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1645; 6:VwUpur2ROYDTHzlRrGasm7hwK86aFeeKFWApAaV7uNk8H2jkZmv5r8w0DPZmpx/rnPGkhCFFcknz8+ib3nsHw/MfYDQ2aSZ4xpWfiakH4Wp6yviFasvuiXOkASWQ6ivsrGF2w49O3DrQ2llClu1BfbVEMj73Yvg6sstwdaIbwDSKVMFtyITqcHMYaT72E+Rd3c0qNY7S8hdcJTiMOGfcMj7ibOzY4t2odqjcElCxfgRNMoZO1fHTnoJD3A4zSGkEn+St+zWrmgBtnf3iR+yNdFbyRHDjqfZILJUPMS35BIv/uAmMJlwHVR5XwIH/Q3r2FIunsQ8akLmQYWkALslpUg==; 5:12KzGke3STcendCGvp4UNNyY0EVv30SXfqSDCni+JsOKrx25brWCCEuRcexNMvC2mDsbyWo9zxRLBbz/Dt8SSlCsg98vRvS9XT1qVUWVDfhUHDxz39aNJ4cthFUVPZtkHIERh6bTK3PMYpHmaBIcRQ==; 24:Uzp5QTrU76SiTy1Wq5MEBXJ4cj1jq51fGH4h3A5x2jrahxqaE0xT9SoTbMiXR411Rfjd3qpROoghFLXK4/LqKZ/sxtea+YbsykzFAHtfkMQ=; 7:/l/Ruwj6j2s+QMsRGvar/wm773X4zKFW8KN1q/Do5CEPwJtBmHJS1gIL/XQbbBFdZwG6FM1LhSNWoggZZcmOR3zouzciJyO6oXXcHFZvHAG1UoE38svjeltqsM6Dqb5Fo6L7pkhqw0Mqwr2wUwWbxYL65IZWYfglpAqFXRYhs+pj5P37a6k1f7CDDjWBhPzc0jSD4Zj19DOBjXM3W4DcixRh3ZezdZUsFI2lbx/0rwsJ4OA555m+SdytBkQwHJ4l x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1645; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(100405760836317)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:SN1PR0301MB1645; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1645; x-forefront-prvs: 0044C17179 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(189002)(19580395003)(106356001)(110136002)(5002640100001)(77096005)(10090500001)(81156014)(7846002)(7696003)(122556002)(2900100001)(8936002)(3480700004)(7736002)(8676002)(15975445007)(92566002)(11100500001)(5660300001)(8990500004)(2501003)(19300405004)(5005710100001)(10290500002)(81166006)(10400500002)(2906002)(189998001)(97736004)(9686002)(107886002)(790700001)(54356999)(76576001)(50986999)(99286002)(86362001)(102836003)(3846002)(6116002)(33656002)(16236675004)(3280700002)(586003)(105586002)(74316002)(2351001)(3660700001)(5630700001)(19625215002)(68736007)(86612001)(450100001)(101416001)(66066001)(5640700001)(229853001)(87936001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0301MB1645; H:SN1PR0301MB1645.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB1645050B5C84E57ED97009D3F5EA0SN1PR0301MB1645_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Aug 2016 20:32:35.8855 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1645 Archived-At: Subject: [Id-event] ID Event Token Simplification X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 24 Aug 2016 20:32:40 -0000 --_000_SN1PR0301MB1645050B5C84E57ED97009D3F5EA0SN1PR0301MB1645_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A number of the ID Event Token contributors were discussing the ID Event To= ken format yesterday and we came up with what seems like rough consensus on= a way to keep the ID Event Token spec simple enough that it's likely to be= accepted by the security ADs and IESG as an individual submission. The ba= ckground on the agreement is this: * JWTs containing events will contain only one or more related events= in a family of events, and not be a container of sets of unrelated events. * The primary event will be the first event in the "events" list and = the related events will be 2nd, 3rd, etc. * Claims pertaining to the family events should be top-level claims. = These should be registered in the JWT Claims Registry unless they are priv= ate claim names or public claim names (as defined in JWT sections 4.2 and 4= .3). * Claims pertaining only to an individual event should be values with= in a claim using the same name as the event. These values need only be def= ined within the event definition and need not be registered as top-level cl= aim names. * It is up to each event family and individual event what claims are = included with the event family and event. This works well because event listeners are listening for a defined family = of events and those only. Any events that the listeners doesn't recognize = will be either ignored or generate errors, depending upon the application c= ontext. Likewise, receiving a JWT without an "events" claim at an events l= istener should likely generate an error as well. We are explicitly steering clear of the SOAP pattern, in which a general-pu= rpose message dispatcher was the listener. Developers have voted with thei= r feet in avoiding this pattern. We will be wise to do the same. The set of rules above is straightforward and doesn't raise any complicated= questions. It should enable us to get the spec approved soon. I believe that Phil is working on changes for -04 along these lines. Phil = can follow up from here. Thanks all, -- Mike --_000_SN1PR0301MB1645050B5C84E57ED97009D3F5EA0SN1PR0301MB1645_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A number of the ID Event Token contributors were dis= cussing the ID Event Token format yesterday and we came up with what seems = like rough consensus on a way to keep the ID Event Token spec simple enough= that it’s likely to be accepted by the security ADs and IESG as an individual submission.  The backgroun= d on the agreement is this:

 

·       JWTs containing events will contain only one= or more related events in a family of events, and not be a container of se= ts of unrelated events.

·       The primary event will be the first event in= the “events” list and the related events will be 2nd, 3rd, etc.

·       Claims pertaining to the family events shoul= d be top-level claims.  These should be registered in the JWT Claims R= egistry unless they are private claim names or public claim names (as defin= ed in JWT sections 4.2 and 4.3).

·       Claims pertaining only to an individual even= t should be values within a claim using the same name as the event.  T= hese values need only be defined within the event definition and need not b= e registered as top-level claim names.

·       It is up to each event family and individual= event what claims are included with the event family and event.=

 

This works well because event listeners are listenin= g for a defined family of events and those only.  Any events that the = listeners doesn’t recognize will be either ignored or generate errors= , depending upon the application context.  Likewise, receiving a JWT without an “events” claim at an events listene= r should likely generate an error as well.

 

We are explicitly steering clear of the SOAP pattern= , in which a general-purpose message dispatcher was the listener.  Dev= elopers have voted with their feet in avoiding this pattern.  We will = be wise to do the same.

 

The set of rules above is straightforward and doesn&= #8217;t raise any complicated questions.  It should enable us to get t= he spec approved soon.

 

I believe that Phil is working on changes for -04 al= ong these lines.  Phil can follow up from here.

 

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

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

--_000_SN1PR0301MB1645050B5C84E57ED97009D3F5EA0SN1PR0301MB1645_-- From nobody Wed Aug 24 13:48:46 2016 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 32C5C12D76E for ; Wed, 24 Aug 2016 13:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 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=-0.001, RP_MATCHES_RCVD=-0.548, 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 9Zoevt8tubP8 for ; Wed, 24 Aug 2016 13:48:44 -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 D697612D76B for ; Wed, 24 Aug 2016 13:48:43 -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 u7OKmgHO028094 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 24 Aug 2016 20:48:43 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 u7OKmg3j007239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 24 Aug 2016 20:48:42 GMT Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u7OKmfZr019225; Wed, 24 Aug 2016 20:48:42 GMT Received: from [10.0.1.4] (/24.86.208.48) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 24 Aug 2016 13:48:41 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-DA3DC924-A959-4933-9A4F-F20967BAEEEE Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (13G35) In-Reply-To: Date: Wed, 24 Aug 2016 13:48:40 -0700 Content-Transfer-Encoding: 7bit Message-Id: <32B47AE9-83B1-49AF-A8B5-BA5C4A00B647@oracle.com> References: To: Mike Jones X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: "id-event@ietf.org" Subject: Re: [Id-event] ID Event Token Simplification X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 24 Aug 2016 20:48:45 -0000 --Apple-Mail-DA3DC924-A959-4933-9A4F-F20967BAEEEE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yes. This is close to option A.=20 I wanted to make sure the group could see all the options.=20 Thanks Phil > On Aug 24, 2016, at 1:32 PM, Mike Jones wrot= e: >=20 > A number of the ID Event Token contributors were discussing the ID Event T= oken format yesterday and we came up with what seems like rough consensus on= a way to keep the ID Event Token spec simple enough that it=E2=80=99s likel= y to be accepted by the security ADs and IESG as an individual submission. T= he background on the agreement is this: > =20 > =C2=B7 JWTs containing events will contain only one or more related e= vents in a family of events, and not be a container of sets of unrelated eve= nts. > =C2=B7 The primary event will be the first event in the =E2=80=9Ceve= nts=E2=80=9D list and the related events will be 2nd, 3rd, etc. > =C2=B7 Claims pertaining to the family events should be top-level cl= aims. These should be registered in the JWT Claims Registry unless they are= private claim names or public claim names (as defined in JWT sections 4.2 a= nd 4.3). > =C2=B7 Claims pertaining only to an individual event should be value= s within a claim using the same name as the event. These values need only b= e defined within the event definition and need not be registered as top-leve= l claim names. > =C2=B7 It is up to each event family and individual event what claim= s are included with the event family and event. > =20 > This works well because event listeners are listening for a defined family= of events and those only. Any events that the listeners doesn=E2=80=99t re= cognize will be either ignored or generate errors, depending upon the applic= ation context. Likewise, receiving a JWT without an =E2=80=9Cevents=E2=80=9D= claim at an events listener should likely generate an error as well. > =20 > We are explicitly steering clear of the SOAP pattern, in which a general-p= urpose message dispatcher was the listener. Developers have voted with thei= r feet in avoiding this pattern. We will be wise to do the same. > =20 > The set of rules above is straightforward and doesn=E2=80=99t raise any co= mplicated questions. It should enable us to get the spec approved soon. > =20 > I believe that Phil is working on changes for -04 along these lines. Phil= can follow up from here. > =20 > Thanks all, > -- Mike > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event --Apple-Mail-DA3DC924-A959-4933-9A4F-F20967BAEEEE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Yes. This is close to option A. <= /div>

I wanted to make sure the group could see all the options. 

Thanks
=
Phil

On Aug 24, 2016, at 1:32 PM, Mike Jones <Michael.Jones@microsoft.com> wro= te:

=

A number of the ID Event Token contributors were disc= ussing the ID Event Token format yesterday and we came up with what seems li= ke rough consensus on a way to keep the ID Event Token spec simple enough th= at it=E2=80=99s likely to be accepted by the security ADs and IESG as an individual submission.  The background= on the agreement is this:

 

=C2=B7       JWTs containing events will contain only o= ne or more related events in a family of events, and not be a container of s= ets of unrelated events.

=C2=B7       The primary event will be the first event= in the =E2=80=9Cevents=E2=80=9D list and the related events will be 2n= d, 3rd, etc.

=C2=B7       Claims pertaining to the family events sh= ould be top-level claims.  These should be registered in the JWT Claims= Registry unless they are private claim names or public claim names (as defi= ned in JWT sections 4.2 and 4.3).

=C2=B7       Claims pertaining only to an individual e= vent should be values within a claim using the same name as the event. = These values need only be defined within the event definition and need not b= e registered as top-level claim names.

=C2=B7       It is up to each event family and individ= ual event what claims are included with the event family and event.

 

This works well because event listeners are listening= for a defined family of events and those only.  Any events that the li= steners doesn=E2=80=99t recognize will be either ignored or generate errors,= depending upon the application context.  Likewise, receiving a JWT without an =E2=80=9Cevents=E2=80=9D claim at an events list= ener should likely generate an error as well.

 

We are explicitly steering clear of the SOAP pattern,= in which a general-purpose message dispatcher was the listener.  Devel= opers have voted with their feet in avoiding this pattern.  We will be w= ise to do the same.

 

The set of rules above is straightforward and doesn=E2= =80=99t raise any complicated questions.  It should enable us to get th= e spec approved soon.

 

I believe that Phil is working on changes for -04 alo= ng these lines.  Phil can follow up from here.

 

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

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

____________________= ___________________________
Id-event mailing list
= Id-event@ietf.org
<= span>https://www.= ietf.org/mailman/listinfo/id-event
<= /html>= --Apple-Mail-DA3DC924-A959-4933-9A4F-F20967BAEEEE-- From nobody Wed Aug 24 13:49:50 2016 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 AAFDD12D76E for ; Wed, 24 Aug 2016 13:49:48 -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 WX8Wlb0YE_CK for ; Wed, 24 Aug 2016 13:49:45 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0105.outbound.protection.outlook.com [104.47.42.105]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36D0712D76B for ; Wed, 24 Aug 2016 13:49:45 -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=wmM16Fp3VDsb0vq5SXpiciNbruUVPZdRBkeplp3P+l0=; b=CyKMRnnOYxqlkN2H+eFxgIVyXedus0wwjFCSk25AsVSax2hqK5HWMiwOeosdtF9A16JV6wn4VnaSnF6NHXjW9gBZ1zIoyIGXkkFUZ7qj+H6MKgS7IuMmowtnYFDIj6J2WDZIRk57cgqP2f6G2eAOI4EtlLht2XHkGTWFpxI+24g= Received: from SN1PR0301MB1645.namprd03.prod.outlook.com (10.162.130.139) by SN1PR0301MB1645.namprd03.prod.outlook.com (10.162.130.139) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.13; Wed, 24 Aug 2016 20:49:44 +0000 Received: from SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) by SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) with mapi id 15.01.0587.013; Wed, 24 Aug 2016 20:49:44 +0000 From: Mike Jones To: John Bradley , Marius Scurtescu Thread-Topic: [Id-event] Discussion on use of "sub" and confusion as ID Token Thread-Index: AQHR/jJ6Kzu5WyrJDU6lijc1KOHPZaBYhVKAgAALW4CAAALdcA== Date: Wed, 24 Aug 2016 20:49:43 +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: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [64.134.242.226] x-ms-office365-filtering-correlation-id: ce7086a4-f26e-4767-a528-08d3cc602d76 x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1645; 6:2hap8v5scba51fMSLApJ4GHJbneSUIsasz7vY8zKHiXdWP0Ko7HvOkDuqga3UCVg+Z5tkCQNGj4eyX1QvaUXYpKueALP9xcjs7TB8D1EdwxcLJNXPrCr+kXol409LfVuIALeKqE2CJdp5vjTIUxiUbjjScNDrUZR6lgcLzwlK3vFyzexntcHgcCwnQerCXPXwuqiid7yKWR4PMYOMSyz6lDl00ImtxzZxTLpVVGkn8wH4cOncMAy07eZQo+b5V/fFCpKg/BwX0IGeP/5AxRM1zL0ek9DY7B5k7U4/Aueh573mDBotx1ilBVMwmLnKl9z1CxsLCXMWieAVfMGY8CHOg==; 5:DxRxDcVLB5bIc+0ZEldDkf40IMw7CPCvJ7Tp65bepjHjdbz8rSvzJngjvy/T3fknJLbUuD4iCUp/q7bNmi/yQdyF52U/PTsfLyPApjgO0hnEnsnDCc8QM7zhG2sR6Ml5kiCla7luDTV0eYABkxKnWA==; 24:8luPuKQ7O8WhpOcF0uc2mDo1UlY67Df1AV4lm34a8JaqzzHad/autsTzcVZzs9VHS6sCEY4fLEmqIdKNxU8pxVef+9z7FTCYToAJ87c9Gp0=; 7:RE2TVzNc66ES3HoFvBpQtopqlZrcHmvBsH70CrkgTxWxZFZrZ3t1TF2TnkP/ArEAOj1cbu6C+7nzUdVvaj4ffSQNKzI97zmbfMs/3/ROsLJROQh4q+3G3NY5L8r3tP3CghaP2YX2l1inMB0xejkInn6xAA7hiUJ/eJGt4/AR7OlbXBzkF98vBJu01GZm7I/hyl6J2jPSPr8Qt/gN6xDauEAdcd/xDwDadM0YrzOUAivZVguz49yYhBRS9Sg5O2Vs x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1645; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(211936372134217)(21748063052155)(21532816269658)(146099531331640)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:SN1PR0301MB1645; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1645; x-forefront-prvs: 0044C17179 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(24454002)(199003)(51444003)(377454003)(189002)(106116001)(3846002)(6116002)(102836003)(16236675004)(33656002)(76576001)(76176999)(54356999)(86362001)(50986999)(99286002)(101416001)(66066001)(68736007)(86612001)(87936001)(19617315012)(74316002)(586003)(3280700002)(105586002)(3660700001)(19625215002)(122556002)(7696003)(7846002)(7906003)(15975445007)(8676002)(11100500001)(5660300001)(92566002)(2900100001)(8936002)(7736002)(106356001)(5002640100001)(19580395003)(790700001)(77096005)(2950100001)(10090500001)(81156014)(19609705001)(189998001)(97736004)(5001770100001)(2906002)(4326007)(9686002)(19300405004)(19580405001)(8990500004)(10400500002)(5005710100001)(81166006)(10290500002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0301MB1645; H:SN1PR0301MB1645.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB164572638A746F5E44157992F5EA0SN1PR0301MB1645_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Aug 2016 20:49:43.9647 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1645 Archived-At: Cc: "id-event@ietf.org" , Phil Hunt Subject: Re: [Id-event] Discussion on use of "sub" and confusion as ID Token X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 24 Aug 2016 20:49:49 -0000 --_000_SN1PR0301MB164572638A746F5E44157992F5EA0SN1PR0301MB1645_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gbm90IGFkdm9jYXRpbmcg4oCcdHlw4oCdIG9yIOKAnGN0eeKAnSBmb3IgYW55IHBhcnRp Y3VsYXIgdXNlIGNhc2UuICBJIHdhcyBqdXN0IGJyaW5naW5nIHRoZW0gaW50byB0aGUgZGlzY3Vz c2lvbiBiZWNhdXNlIHBlb3BsZSB3ZXJlIHRhbGtpbmcgYWJvdXQgdHlwZSBmaWVsZHMgYW5kIHNv bWUgbWlnaHQgbm90IGJlIGF3YXJlIG9mIHRoZSB0eXBlIGZpZWxkcyB0aGF0IGFscmVhZHkgcGFy dCBvZiB0aGUgc3RhbmRhcmRzLg0KDQpBIGdlbmVyYWwtcHVycG9zZSBKV1QgdHlwZSBjbGFpbSBz ZWVtcyBvbmx5IHRvIGJlIHVzZWZ1bCB0byBtZSBpbiB1c2UgY2FzZXMgaW4gd2hpY2ggbXVsdGlw bGUga2luZHMgb2YgdW5yZWxhdGVkIEpXVHMgYXJlIHZhbGlkIGluIHRoZSBzYW1lIGNvbnRleHQg KHRoZSBTT0FQIHBhdHRlcm4pLiAgQWdhaW4sIHRoZXJlIG1heSBiZSB2YWxpZCBzdWNoIHVzZSBj YXNlcywgYnV0IHRoZXkgZG9u4oCZdCBjb21lIHVwIGluIGV2ZW50cyB1c2UgY2FzZXMsIGluIHdo aWNoIGV2ZW50cyBsaXN0ZW5lcnMgc2hvdWxkIG9ubHkgYmUgbGlzdGVuaW5nIGZvciBzcGVjaWZp YyBmYW1pbGllcyBvZiBldmVudHMgYW5kIG5vdCBhcmJpdHJhcnkgSldUcy4NCg0KVG8gdGhlIHBh cnRpY3VsYXIgcG9pbnQgYWJvdXQgd2hldGhlciBhbiBldmVudCBKV1QgY2FuIGJlIGNvbmZ1c2Vk IHdpdGggYW4gSUQgVG9rZW4sIHR3byBjb21wbGVtZW50YXJ5IHByZXZlbnRpb25zIHNlZW0gcGVy dGluZW50Og0KDQrCtyAgICAgICBSZXF1aXJlIHRoYXQgYW55IE9QIHRoYXQgaXNzdWVzIGV2ZW50 cyAoc3VjaCBhcyBsb2dvdXQgdG9rZW5zKSAqYWxzbyogcmVqZWN0IGFueSBwdXJwb3J0ZWQgSUQg VG9rZW5zIHRoYXQgY29udGFpbiBhbiDigJxldmVudHPigJ0gY2xhaW0uICBUaGlzIG5ldyBydWxl IG5lZWRzIHRvIG9ubHkgYmUgcHV0IGluIHBsYWNlIGF0IHRoZSB0aW1lIHRoZSBPUCBzdGFydHMg aXNzdWluZyBKV1RzIHRoYXQgYXJlIG5vdCBJRCBUb2tlbnMuICBUaGUgcHJvYmxlbSBjYW7igJl0 IG9jY3VyIGJlZm9yZSB0aGF0Lg0KDQrCtyAgICAgICBSZXF1aXJlIHRoYXQgbm9uLUlEIFRva2Vu cyBub3QgY29udGFpbiBhIOKAnG5vbmNl4oCdLCBhcyBpcyBhbHJlYWR5IHRoZSBjYXNlIGZvciBs b2dvdXQgdG9rZW5zLg0KDQpFaXRoZXIgb2YgdGhlc2Ugd291bGQgZG8gdGhlIGpvYi4gIERvaW5n IGJvdGggaXMgZGVmZW5zZSBpbiBkZXB0aC4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogSWQtZXZlbnQgW21h aWx0bzppZC1ldmVudC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSm9obiBCcmFkbGV5 DQpTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAyNCwgMjAxNiAxOjMyIFBNDQpUbzogTWFyaXVzIFNj dXJ0ZXNjdSA8bXNjdXJ0ZXNjdUBnb29nbGUuY29tPg0KQ2M6IGlkLWV2ZW50QGlldGYub3JnOyBQ aGlsIEh1bnQgPHBoaWwuaHVudEBvcmFjbGUuY29tPg0KU3ViamVjdDogUmU6IFtJZC1ldmVudF0g RGlzY3Vzc2lvbiBvbiB1c2Ugb2YgInN1YiIgYW5kIGNvbmZ1c2lvbiBhcyBJRCBUb2tlbg0KDQpU aGUgaWRlYSBmb3IgY3R5IHdhcyB0byBhbGxvdyBhIEpXUyB0byBlbmNhcHN1bGF0ZSB0aGluZ3Mg bGlrZSBhIGJpbmFyeSBHSUYgYXMgYW4gZXhhbXBsZS4gICBJIHRoaW5rIHVzaW5nIGl0IGZvciBE aXN0aW5ndWlzaGluZyBzdWJ0eXBlcyBvZiBKV1Qgd291bGQgYmUgYSBzdHJldGNoLg0KDQpJIGFt IG1vc3QgY29tZm9ydGFibGUgd2l0aCBBLiAgIEkgdGhpbmsgdGhhdCBhZGRpbmcgYSBKV1QgdHlw ZSBjbGFpbSBhdCB0aGUgdG9wIGxldmVsIG1heSBhbHNvIGJlIHVzZWZ1bCBnb2luZyBmb3J3YXJk IHRvIGF2b2lkIG1pc2ludGVycHJldGF0aW9uLg0KDQpKb2huIEIuDQpPbiBBdWcgMjQsIDIwMTYs IGF0IDQ6NTEgUE0sIE1hcml1cyBTY3VydGVzY3UgPG1zY3VydGVzY3VAZ29vZ2xlLmNvbTxtYWls dG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tPj4gd3JvdGU6DQoNCk9uIFdlZCwgQXVnIDI0LCAyMDE2 IGF0IDExOjA3IEFNLCBQaGlsIEh1bnQgPHBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGls Lmh1bnRAb3JhY2xlLmNvbT4+IHdyb3RlOg0KDQpUaGUgYXV0aG9ycyBoYXZlIGJlZW4gaGF2aW5n IGEgZGlzY3Vzc2lvbiB3aXRoIHJlZ2FyZHMgdG8gdXNpbmcgdGhlIOKAnHN1YuKAnSBjbGFpbSBp biB0aGUgdG9wIGxldmVsLiBJIHRoaW5rIGl0IGlzIGltcG9ydGFudCB0byB0cnkgYW5kIGdldCB0 aGlzIGRpc2N1c3Npb24gYmFjayB0byB0aGUgbWFpbiBncm91cC4gTXkgYXBvbG9naWVzIGZvciB0 aGUgbG9uZyBub3RlLiBJIHdhbnRlZCB0byBnZXQgYWxsIHRoZSBwcm9zIGFuZCBjb25zIG9uIHRo ZSB0YWJsZSAoaGludDogIHBsZWFzZSBhZGQgaWYgSSBtaXNzZWQgYW55KS4uLg0KDQpBIHF1ZXN0 aW9uIHJlbWFpbnMgc2hvdWxkIOKAnHN1YuKAnSBiZSB1c2FibGUgYXQgdGhlIHRvcCBsZXZlbC4g IFRoZSBkb3duc2lkZSBvZiB0aGlzIGFwcHJvYWNoIGlzIHRoYXQgYSBTRVQgY291bGQgcG90ZW50 aWFsbHkgYmUgcHJlc2VudGVkIGFzIGFuIGFjY2VzcyBvciBpRCB0b2tlbiBhbmQgbWlnaHQgaW5p dGlhbGx5IGJlIGNvbmZ1c2VkIGJlY2F1c2UgZXhpc3RpbmcgY29kZSBkb2VzIG5vdCBrbm93IGl0 IG5lZWRzIHRvIGxvb2sgZm9yIGFuIOKAnGV2ZW50c+KAnSBhdHRyaWJ1dGUuICBUaGUgU0VUIGFu ZCBJRCBUb2tlbiBmb3IgYWxsIGludGVuc2l2ZSBwdXJwb3NlcyBhcmUgdGhlIHNhbWUgc2luY2Ug YSBTRVQganVzdCBoYXMgc29tZXRoaW5nIGV4dHJhICh0aGUgZXZlbnRzIGNsYWltKS4NCg0KVGhl cmUgaXMgYWxzbyB0aGUgcXVlc3Rpb24gdGhhdCBpZiBPSURDIExvZ291dCB1c2VzIGl0IGluIHRo ZSB0b3AgbGV2ZWwsIG1heSBvdGhlciBldmVudHMgdXNlIGl0PyBSRkM3NTE5IGRlZmluZXMg4oCc c3Vi4oCdIGFzIGEgU3RyaW5nIG9yIFVSSSB2YWx1ZS4gRm9yIGV4YW1wbGUsIGluIFNDSU0gZXZl bnRzLCB0aGUg4oCcc3Vi4oCdIHZhbHVlIGNvdWxkIGJlIGEgU0NJTSBSZXNvdXJjZSBVUkkgdGhh dCBpbmRpY2F0ZXMgdGhlIHJlc291cmNlIHdob3NlIHN0YXRlIGhhcyBjaGFuZ2VkLiAgSW4gT0F1 dGggaXQgY291bGQgYmUgZGVmaW5lZCBhcyB0aGUgdG9rZW4gaWRlbnRpZmllciBvZiB0aGUgdG9r ZW4gdGhhdCBoYXMgYmVlbiByZXZva2VkLiAgQSBTRVQgYWJvdXQgYmxhY2tsaXN0aW5nIGFuIElQ IGFkZHJlc3MgbWlnaHQgcHV0IHRoZSBJUCBhZGRyZXNzIGluIHN1Yi4NCg0KU28gdGhlcmUgYXJl IHRocmVlIG9wdGlvbnMgKE9wdGlvbiBBIHNlZW1zIHRvIGJlIGZhdm91cmVkIHNvIGZhcik6DQoN CkEuICBTdWIgYXQgVG9wIExldmVsOiAg4oCcc3Vi4oCdIGdlbmVyYWxseSB1c2VkIHRvIHJlZmVy ZW5jZSB0aGUgU2VjdXJpdHkgU3ViamVjdCB0aGUgU0VUIGlzIHRhbGtpbmcgYWJvdXQuICBJdCB1 c2VzIGEgbW9yZSBnZW5lcmFsIGVuZ2xpc2ggbGFuZ3VhZ2UgaW50ZW50IG9mIHN1YmplY3QgcmF0 aGVyIHRoYW4gdGhlIHRyYWRpdGlvbmFsIHVzZSBhcyBzZWVuIGluIFNBTUwgb3IgT3BlbklEIENv bm5lY3QuICBSZWdhcmRsZXNzIGl0IGlzIHN0aWxsIGNvbXBsaWFudCB3aXRoIFJGQzc1MTkgKGEg U3RyaW5nIG9yIFVSSSkuDQoNClRoaXMgd291bGQgdGVuZCB0byBsZWFkIHRvIGEgc3R5bGUgb2Yg U0VUcyB3aGVyZSB0aGUgZW52ZWxvcGUgY2FycmllcyB0aGUgdmFsaWRhdGlvbiBpbmZvcm1hdGlv biwgdGhlIHR5cGUgb2YgZXZlbnQsIGFuZCB0aGUgc3ViamVjdCBvZiB0aGUgZXZlbnQuIEFkZGl0 aW9uYWwgZGF0YSBnb2VzIGluIHRoZSBwYXlsb2FkLiBBbiBhZHZhbnRhZ2Ugb2YgdGhpcyBzdHls ZSwgaXMgdGhhdCBmb3IgbWFueSBldmVudHMsIHRoZSBvbmx5IHRoaW5nIG5lZWRlZCBpcyB0aGUg ZXZlbnQgdHlwZSBhbmQgdGhlIHN1YmplY3QuICBObyBwYXlsb2FkcyB3b3VsZCBiZSBuZWVkZWQu DQoNCkZvciBldmVudHMgdGhhdCBkb27igJl0IHdhbnQgcGF5bG9hZCwgaXQgaXMgcHJvYmFibHkg b2sgZm9yIHByb2ZpbGluZyBldmVudCBzdGFuZGFyZHMgdG8gZGVmaW5lIG1vcmUgY2xhaW1zIGF0 IHRoZSB0b3AgbGV2ZWwuIFRoZXkgTVVTVCBiZSByZWdpc3RlcmVkIGluIHRoZSBKV1QgcmVnaXN0 cnkuIFByb2ZpbGluZyBldmVudHMgY2FuIGF2b2lkIHJlZ2lzdHJhdGlvbiBieSBqdXN0IHB1dHRp bmcgdGhlaXIgYXR0cmlidXRlcy9jbGFpbXMgaW4gdGhlIHBheWxvYWQgYXJlYSBhcyBkZXNjcmli ZWQgaW4gdGhlIHNwZWMuICBIb3dldmVyLCB0aGlzIHdvdWxkIGJlIGluY29uc2lzdGVudCB3aXRo IHRob3NlIHRoYXQgdXNlIHBheWxvYWRzIHdpdGggdW5yZWdpc3RlcmVkIGNsYWltcy4gIEkgcG9p bnQgb3V0IHRoYXQgd2Ugc3dpdGNoZWQgZnJvbSByZWdpc3RlcmVkIGV2ZW50IFVSTnMgdG8gVVJJ cyB0byBhdm9pZCByZWdpc3RyYXRpb24uICBIZW5jZSB0aGUgbW92ZSB0byBwYXlsb2FkIG9iamVj dHMgdG8gZWxpbWluYXRlIHJlZ2lzdHJhdGlvbiBmb3IgYXR0cmlidXRlcy9jbGFpbXMuDQoNClRo aXMgc3RpbGwgaGFzIHRoZSBuZWdhdGl2ZXMgb2YgYmVpbmcgY29uZnVzYWJsZSBhcyBhbiBJRCBU b2tlbiBieSBleGlzdGluZyBjb2RlLiBUaGVyZSBoYXMgYmVlbiBhIGRpc2N1c3Npb24gdGhhdCDi gJxpc3PigJ0gYW5kL29yIOKAnGF1ZOKAnSBzaG91bGQgYWN0dWFsbHkgYmUgZGlmZmVyZW50IGFu ZCB0aGUgcmVjZWl2ZXIgc2hvdWxkIGRldGVjdCB0aGF0LiAgSG93ZXZlciBpbiB0aGUgT0lEQyBM b2dvdXQgY2FzZSwgYnkgZGVzaWduLCB0aGUg4oCcaXNz4oCdIHZhbHVlIHdvdWxkIGJlIHRoZSBz YW1lLiAgVGhlIOKAnGF1ZOKAnSB3b3VsZCBhbHNvIGxpa2VseSBiZSB0aGUgc2FtZSB1bmxlc3Mg dGhlIHNwZWMgaW5kaWNhdGVzIHRoYXQgYW4gYWxpYXMg4oCcYXVk4oCdIGJlIHVzZWQgZXZlbiB0 aG91Z2ggdGhlIGF1ZGllbmNlIG1heSBiZSB0aGUgc2FtZSBlbnRpdHkgaW4gYm90aCBjYXNlcy4N Cg0KQi4gRXhjbHVzaXZlLVVzZSBvZiBTdWI6IOKAnHN1YuKAnSBpcyBpbnRlcnByZXRlZCB0byBi eSB0cmFkaXRpb25hbCBkZWZpbml0aW9uIGFuZCBpcyByZXNlcnZlZCBmb3IgT0F1dGggdG9rZW5z IGFuZCBPSURDIENvbm5lY3QgdXNhZ2Ugb25seS4gIEluIG9yZGVyIHRvICBhdm9pZCBjb25mdXNp bmcsIGFsbCBwcm9maWxpbmcgZXZlbnQgc3BlY3Mgc2hvdWxkIE5PVCB1c2Ug4oCcc3Vi4oCdIGlu IHRoZSB0b3AgbGV2ZWwgZXhjZXB0IGZvciBPSURDLg0KDQpUaGlzIGhhcyB0aGUgZGlzYWR2YW50 YWdlIHRoYXQgT0lEQyByZXF1aXJlcyBzcGVjaWFsIGhhbmRsaW5nIGluIHRlcm1zIG9mIGEgZ2Vu ZXJhbCB1c2UgZXZlbnQgbGlicmFyeSwgYnV0IG9uIHRoZSBvdGhlciBoYW5kIGEgTG9nb3V0IEV2 ZW50IG1pZ2h0IGJlIGhhbmRsZWQgZGlyZWN0bHkgYnkgZXhpc3RpbmcgSUQgVG9rZW4gY29kZS4N Cg0KVGhpcyBzdGlsbCBoYXMgdGhlIGRpc2FkdmFudGFnZSB0aGF0IGFuIFNFVCBjb3VsZCBiZSBj b25mdXNlZCBmb3IgYW4gSUQgVG9rZW4uDQoNCkMuIE5vLVRvcC1MZXZlbCBEYXRhOiBJbiBvcmRl ciB0byBtb3JlIGFnZ3Jlc3NpdmVseSBhdm9pZCBjb25mdXNpb24gb2YgU0VUcyBhcyBJRCBUb2tl bnMsIG1ha2UgaXQgbWFuZGF0b3J5IHRoYXQgU0VUcyBtYXkgbm90IGNvbnRhaW4gYSDigJxzdWLi gJ0gdmFsdWUgYXQgdGhlIHRvcCBsZXZlbC4gIFRoZSBPSURDIExvZ291dCBFdmVudCwgZm9yIGV4 YW1wbGUsIHdvdWxkIHRoZW4gaW5jbHVkZSBhIOKAnHN1YuKAnSB2YWx1ZSBpbiB0aGUgcGF5bG9h ZCBhcmVhLiBUaGlzIHNob3VsZCBjYXVzZSBleGlzdGluZyByZWx5aW5nIHBhcnRpZXMgdG8gZmFp bCBjb3JyZWN0bHkuDQoNClRoaXMgd291bGQgcHJvdmlkZSBhIG1heGltYWwgZGlmZmVyZW5jZSBm b3JtIGEgSURUb2tlbiBvciBhY2Nlc3MgdG9rZW4uDQoNClRoaXMgd291bGQgaGF2ZSB0aGUgYWR2 YW50YWdlIHRoYXQgZW52ZWxvcGVzIGNvbnRhaW4gbm8gZGF0YSwgYW5kIHRoYXQgZXZlcnkgU0VU IGhhcyBhIHBheWxvYWQgd2hlcmUgdGhlIGRhdGEgaXMgZm91bmQuIEl0IHJlcXVpcmVzIG1vcmUg cGFyc2luZyBpbiBzb21lIGNhc2VzLCBidXQgaXQgaXMgYXQgbGVhc3QgY29uc2lzdGVudC4gV2hp bGUgd2UgZG9u4oCZdCBleHBlY3QgZ2VuZXJhbCBwcm9jZXNzb3JzIGxpa2UgaW4gU09BUCBmb3Ig ZGlzdHJpYnV0aW9uIChtdWNoIG9mIGl0IGlzIHBvaW50IHRvIHBvaW50IGFuZCB2ZXJ5IGNvbnRl eHR1YWxseSBkcml2ZW4pLCBJIHBlcnNvbmFsbHkgZXhwZWN0IHRvIHNlZToNCiAgKiAgRGV2ZWxv cG1lbnQgb2YgZ2VuZXJhbCBwdXJwb3NlIGxpYnJhcmllcyBhbmQgdG9vbHMgdGhhdCBhcmUgdXNl ZCBlbmhhbmNlIHByb3RvY29scyBhbmQgc3lzdGVtcw0KICAqICBBdWRpdCBhbmQgdGhyZWF0IGFu YWx5c2lzIHN5c3RlbXMgd2lsbCBiZSBsb29raW5nIGF0IHNvbWUgZXZlbnRzIGhpc3RvcmljYWxs eS4gVGhlc2Ugd2lsbCB0ZW5kIHRvIG1lcmdlIG11bHRpcGxlIGV2ZW50IGZlZWRzLg0KDQpNaWtl IEpvbmVzIGFsc28gc3VnZ2VzdGVkIHVzaW5nIHRoZSDigJxjdHnigJ0gKGNvbnRlbnQgdHlwZSkg aGVhZGVyIGF0dHJpYnV0ZSBmcm9tIEpXVC4gIEkgdGhpbmsgbW9zdCBjb2RlIHRvZGF5IGhhcyB0 aGlzIHNldCB0byBpZ25vcmUgb3IgZml4ZWQgYXMg4oCcSldU4oCdLiAgSSB3b25kZXIgd2hhdCBj dXJyZW50IGltcGxlbWVudHMgd291bGQgZmVlbCBpZiB3ZSBpbnRyb2R1Y2VkIGEg4oCcY3R54oCd IHZhbHVlIG9mIOKAnFNFVOKAnT8gIFdvdWxkIHRoYXQgaGVscD8NCg0KSSB0aGluayBpdCBpcyB2 ZXJ5IGltcG9ydGFudCB0byBiZSBhYmxlIHRvIGNsZWFybHkgZGlzdGluZ3Vpc2ggZGlmZmVyZW50 IHR5cGVzIG9mIEpXVCB0b2tlbnMuIEZvciBleGFtcGxlLCBub3QgYmVpbmcgYWJsZSB0byBjcm9z cyBwb3N0IGEgU2VjdXJpdHkgRXZlbnQgVG9rZW4gYXMgYW4gSWQgVG9rZW4uDQoNClJlYWRpbmcg UkZDIDc1MTkgSSBkb24ndCB0aGluayBjdHkgZml0cyB0aGUgYmlsbCwgYnV0IEkgY291bGQgYmUg d3JvbmcuIGN0eSBpcyBhIGhlYWRlciBwYXJhbWV0ZXIgdXNlZCBieSB0aGUgY3J5cHRvIGFsZ29y aXRobSBhbmQgdGhlIGRlZmF1bHQgdmFsdWUgaXMgSldULiBXZSBuZWVkIHRvIGRpc3Rpbmd1aXNo IHN1Yi10eXBlcyBvZiBKV1QsIGFuZCBpdCBzaG91bGQgYmUgYSBjbGFpbSBpbnNpZGUgdGhlIEpX VC4NCg0KV2l0aCB0aGUgYWJvdmUgaXNzdWUgaW4gbWluZCwgSSB0aGluayBvcHRpb24gQSBpcyB0 aGUgY2xlYW5lc3Qgc29sdXRpb24uDQoNCg0KDQpUaGFua3MgZm9yIHlvdXIgY29tbWVudHMuDQoN Cg0KUGhpbA0KDQpAaW5kZXBlbmRlbnRpZA0Kd3d3LmluZGVwZW5kZW50aWQuY29tPGh0dHA6Ly93 d3cuaW5kZXBlbmRlbnRpZC5jb20vPg0KcGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwu aHVudEBvcmFjbGUuY29tPg0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpJZC1ldmVudCBtYWlsaW5nIGxpc3QNCklkLWV2ZW50QGlldGYu b3JnPG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vaWQtZXZlbnQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCklkLWV2ZW50IG1haWxpbmcgbGlzdA0KSWQtZXZlbnRAaWV0Zi5vcmc8 bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9pZC1ldmVudA0KDQo= --_000_SN1PR0301MB164572638A746F5E44157992F5EA0SN1PR0301MB1645_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToy IDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1z b0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGlu Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6 LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uYXBwbGUtY29udmVydGVk LXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLmdt YWlsLW0xNzE2NzM0MDEyODI2MDE5MzM2YXBwbGUtc3R5bGUtc3Bhbg0KCXttc28tc3R5bGUtbmFt ZTpnbWFpbC1tXzE3MTY3MzQwMTI4MjYwMTkzMzZhcHBsZS1zdHlsZS1zcGFuO30NCnNwYW4uRW1h aWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGlu IDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTAzMTEwODE0 Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotNTMzMzI3 MTU0IDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4Njkz IDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxp c3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZl bDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21h cmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+SeKAmW0gbm90IGFk dm9jYXRpbmcg4oCcdHlw4oCdIG9yIOKAnGN0eeKAnSBmb3IgYW55IHBhcnRpY3VsYXIgdXNlIGNh c2UuJm5ic3A7IEkgd2FzIGp1c3QgYnJpbmdpbmcgdGhlbSBpbnRvIHRoZSBkaXNjdXNzaW9uIGJl Y2F1c2UgcGVvcGxlIHdlcmUgdGFsa2luZyBhYm91dCB0eXBlIGZpZWxkcyBhbmQNCiBzb21lIG1p Z2h0IG5vdCBiZSBhd2FyZSBvZiB0aGUgdHlwZSBmaWVsZHMgdGhhdCBhbHJlYWR5IHBhcnQgb2Yg dGhlIHN0YW5kYXJkcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAi PkEgZ2VuZXJhbC1wdXJwb3NlIEpXVCB0eXBlIGNsYWltIHNlZW1zIG9ubHkgdG8gYmUgdXNlZnVs IHRvIG1lIGluIHVzZSBjYXNlcyBpbiB3aGljaCBtdWx0aXBsZSBraW5kcyBvZiB1bnJlbGF0ZWQg SldUcyBhcmUgdmFsaWQgaW4gdGhlIHNhbWUgY29udGV4dCAodGhlIFNPQVANCiBwYXR0ZXJuKS4m bmJzcDsgQWdhaW4sIHRoZXJlIG1heSBiZSB2YWxpZCBzdWNoIHVzZSBjYXNlcywgYnV0IHRoZXkg ZG9u4oCZdCBjb21lIHVwIGluIGV2ZW50cyB1c2UgY2FzZXMsIGluIHdoaWNoIGV2ZW50cyBsaXN0 ZW5lcnMgc2hvdWxkIG9ubHkgYmUgbGlzdGVuaW5nIGZvciBzcGVjaWZpYyBmYW1pbGllcyBvZiBl dmVudHMgYW5kIG5vdCBhcmJpdHJhcnkgSldUcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMwMDIwNjAiPlRvIHRoZSBwYXJ0aWN1bGFyIHBvaW50IGFib3V0IHdoZXRoZXIgYW4g ZXZlbnQgSldUIGNhbiBiZSBjb25mdXNlZCB3aXRoIGFuIElEIFRva2VuLCB0d28gY29tcGxlbWVu dGFyeSBwcmV2ZW50aW9ucyBzZWVtIHBlcnRpbmVudDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28t bGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOiMwMDIwNjAiPjxzcGFuIHN0 eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsN Cjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAw MjA2MCI+UmVxdWlyZSB0aGF0IGFueSBPUCB0aGF0IGlzc3VlcyBldmVudHMgKHN1Y2ggYXMgbG9n b3V0IHRva2VucykgKjxiPmFsc288L2I+KiByZWplY3QgYW55IHB1cnBvcnRlZCBJRCBUb2tlbnMg dGhhdCBjb250YWluIGFuIOKAnGV2ZW50c+KAnSBjbGFpbS4mbmJzcDsgVGhpcyBuZXcNCiBydWxl IG5lZWRzIHRvIG9ubHkgYmUgcHV0IGluIHBsYWNlIGF0IHRoZSB0aW1lIHRoZSBPUCBzdGFydHMg aXNzdWluZyBKV1RzIHRoYXQgYXJlIG5vdCBJRCBUb2tlbnMuJm5ic3A7IFRoZSBwcm9ibGVtIGNh buKAmXQgb2NjdXIgYmVmb3JlIHRoYXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAg bGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xvcjojMDAyMDYwIj48c3BhbiBzdHlsZT0ibXNv LWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+ PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPlJl cXVpcmUgdGhhdCBub24tSUQgVG9rZW5zIG5vdCBjb250YWluIGEg4oCcbm9uY2XigJ0sIGFzIGlz IGFscmVhZHkgdGhlIGNhc2UgZm9yIGxvZ291dCB0b2tlbnMuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMDAyMDYwIj5FaXRoZXIgb2YgdGhlc2Ugd291bGQgZG8gdGhlIGpvYi4m bmJzcDsgRG9pbmcgYm90aCBpcyBkZWZlbnNlIGluIGRlcHRoLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYw Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHNwYW4gc3R5bGU9Im1zby1ib29r bWFyazpfTWFpbEVuZENvbXBvc2UiPjwvc3Bhbj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu IDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBJZC1ldmVudCBbbWFpbHRvOmlkLWV2ZW50LWJvdW5j ZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkpvaG4gQnJhZGxleTxicj4NCjxiPlNl bnQ6PC9iPiBXZWRuZXNkYXksIEF1Z3VzdCAyNCwgMjAxNiAxOjMyIFBNPGJyPg0KPGI+VG86PC9i PiBNYXJpdXMgU2N1cnRlc2N1ICZsdDttc2N1cnRlc2N1QGdvb2dsZS5jb20mZ3Q7PGJyPg0KPGI+ Q2M6PC9iPiBpZC1ldmVudEBpZXRmLm9yZzsgUGhpbCBIdW50ICZsdDtwaGlsLmh1bnRAb3JhY2xl LmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtJZC1ldmVudF0gRGlzY3Vzc2lvbiBv biB1c2Ugb2YgJnF1b3Q7c3ViJnF1b3Q7IGFuZCBjb25mdXNpb24gYXMgSUQgVG9rZW48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgaWRlYSBmb3IgY3R5 IHdhcyB0byBhbGxvdyBhIEpXUyB0byBlbmNhcHN1bGF0ZSB0aGluZ3MgbGlrZSBhIGJpbmFyeSBH SUYgYXMgYW4gZXhhbXBsZS4gJm5ic3A7IEkgdGhpbmsgdXNpbmcgaXQgZm9yIERpc3Rpbmd1aXNo aW5nIHN1YnR5cGVzIG9mIEpXVCB3b3VsZCBiZSBhIHN0cmV0Y2guPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFtIG1vc3QgY29tZm9ydGFibGUgd2l0aCBB LiAmbmJzcDsgSSB0aGluayB0aGF0IGFkZGluZyBhIEpXVCB0eXBlIGNsYWltIGF0IHRoZSB0b3Ag bGV2ZWwgbWF5IGFsc28gYmUgdXNlZnVsIGdvaW5nIGZvcndhcmQgdG8gYXZvaWQgbWlzaW50ZXJw cmV0YXRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkpvaG4gQi48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PbiBBdWcgMjQsIDIwMTYsIGF0IDQ6NTEgUE0sIE1hcml1cyBTY3VydGVzY3Ug Jmx0OzxhIGhyZWY9Im1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb20iPm1zY3VydGVzY3VAZ29v Z2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5PbiBXZWQsIEF1ZyAy NCwgMjAxNiBhdCAxMTowNyBBTSwgUGhpbCBIdW50PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPiZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNs ZS5jb20iIHRhcmdldD0iX2JsYW5rIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT4mZ3Q7PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPndyb3RlOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZSBh dXRob3JzIGhhdmUgYmVlbiBoYXZpbmcgYSBkaXNjdXNzaW9uIHdpdGggcmVnYXJkcyB0byB1c2lu ZyB0aGUg4oCcc3Vi4oCdIGNsYWltIGluIHRoZSB0b3AgbGV2ZWwuIEkgdGhpbmsgaXQgaXMgaW1w b3J0YW50IHRvIHRyeSBhbmQgZ2V0IHRoaXMgZGlzY3Vzc2lvbiBiYWNrIHRvIHRoZSBtYWluIGdy b3VwLg0KIE15IGFwb2xvZ2llcyBmb3IgdGhlIGxvbmcgbm90ZS4gSSB3YW50ZWQgdG8gZ2V0IGFs bCB0aGUgcHJvcyBhbmQgY29ucyBvbiB0aGUgdGFibGUgKGhpbnQ6ICZuYnNwO3BsZWFzZSBhZGQg aWYgSSBtaXNzZWQgYW55KS4uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPkEgcXVlc3Rpb24gcmVtYWlucyBzaG91bGQg4oCcc3Vi4oCdIGJlIHVzYWJsZSBh dCB0aGUgdG9wIGxldmVsLiZuYnNwOyBUaGUgZG93bnNpZGUgb2YgdGhpcyBhcHByb2FjaCBpcyB0 aGF0IGEgU0VUIGNvdWxkIHBvdGVudGlhbGx5IGJlIHByZXNlbnRlZCBhcyBhbiBhY2Nlc3Mgb3Ig aUQgdG9rZW4gYW5kIG1pZ2h0DQogaW5pdGlhbGx5IGJlIGNvbmZ1c2VkIGJlY2F1c2UgZXhpc3Rp bmcgY29kZSBkb2VzIG5vdCBrbm93IGl0IG5lZWRzIHRvIGxvb2sgZm9yIGFuIOKAnGV2ZW50c+KA nSBhdHRyaWJ1dGUuJm5ic3A7IFRoZSBTRVQgYW5kIElEIFRva2VuIGZvciBhbGwgaW50ZW5zaXZl IHB1cnBvc2VzIGFyZSB0aGUgc2FtZSBzaW5jZSBhIFNFVCBqdXN0IGhhcyBzb21ldGhpbmcgZXh0 cmEgKHRoZSBldmVudHMgY2xhaW0pLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPlRoZXJlIGlzIGFsc28gdGhlIHF1ZXN0aW9uIHRoYXQgaWYgT0lEQyBMb2dv dXQgdXNlcyBpdCBpbiB0aGUgdG9wIGxldmVsLCBtYXkgb3RoZXIgZXZlbnRzIHVzZSBpdD8gUkZD NzUxOSBkZWZpbmVzIOKAnHN1YuKAnSBhcyBhIFN0cmluZyBvciBVUkkgdmFsdWUuIEZvciBleGFt cGxlLCBpbiBTQ0lNIGV2ZW50cywNCiB0aGUg4oCcc3Vi4oCdIHZhbHVlIGNvdWxkIGJlIGEgU0NJ TSBSZXNvdXJjZSBVUkkgdGhhdCBpbmRpY2F0ZXMgdGhlIHJlc291cmNlIHdob3NlIHN0YXRlIGhh cyBjaGFuZ2VkLiZuYnNwOyBJbiBPQXV0aCBpdCBjb3VsZCBiZSBkZWZpbmVkIGFzIHRoZSB0b2tl biBpZGVudGlmaWVyIG9mIHRoZSB0b2tlbiB0aGF0IGhhcyBiZWVuIHJldm9rZWQuJm5ic3A7IEEg U0VUIGFib3V0IGJsYWNrbGlzdGluZyBhbiBJUCBhZGRyZXNzIG1pZ2h0IHB1dCB0aGUgSVAgYWRk cmVzcyBpbg0KIHN1Yi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj5TbyB0aGVyZSBhcmUgdGhyZWUgb3B0aW9ucyAoT3B0aW9uIEEgc2VlbXMgdG8gYmUgZmF2 b3VyZWQgc28gZmFyKTogJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+QS4mbmJzcDsgU3ViIGF0IFRvcCBMZXZlbDo8L3NwYW4+PC9iPjxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwv c3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A74oCcc3Vi4oCdDQogZ2VuZXJhbGx5 IHVzZWQgdG8gcmVmZXJlbmNlIHRoZSBTZWN1cml0eSBTdWJqZWN0IHRoZSBTRVQgaXMgdGFsa2lu ZyBhYm91dC4mbmJzcDsgSXQgdXNlcyBhIG1vcmUgZ2VuZXJhbCBlbmdsaXNoIGxhbmd1YWdlIGlu dGVudCBvZiBzdWJqZWN0IHJhdGhlciB0aGFuIHRoZSB0cmFkaXRpb25hbCB1c2UgYXMgc2VlbiBp biBTQU1MIG9yIE9wZW5JRCBDb25uZWN0LiZuYnNwOyBSZWdhcmRsZXNzIGl0IGlzIHN0aWxsIGNv bXBsaWFudCB3aXRoIFJGQzc1MTkgKGEgU3RyaW5nDQogb3IgVVJJKS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5UaGlzIHdvdWxkIHRlbmQgdG8gbGVhZCB0 byBhIHN0eWxlIG9mIFNFVHMgd2hlcmUgdGhlIGVudmVsb3BlIGNhcnJpZXMgdGhlIHZhbGlkYXRp b24gaW5mb3JtYXRpb24sIHRoZSB0eXBlIG9mIGV2ZW50LCBhbmQgdGhlIHN1YmplY3Qgb2YgdGhl IGV2ZW50LiBBZGRpdGlvbmFsIGRhdGEgZ29lcyBpbg0KIHRoZSBwYXlsb2FkLiBBbiBhZHZhbnRh Z2Ugb2YgdGhpcyBzdHlsZSwgaXMgdGhhdCBmb3IgbWFueSBldmVudHMsIHRoZSBvbmx5IHRoaW5n IG5lZWRlZCBpcyB0aGUgZXZlbnQgdHlwZSBhbmQgdGhlIHN1YmplY3QuJm5ic3A7IE5vIHBheWxv YWRzIHdvdWxkIGJlIG5lZWRlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+Rm9yIGV2ZW50cyB0aGF0IGRvbuKAmXQgd2FudCBwYXlsb2FkLCBp dCBpcyBwcm9iYWJseSBvayBmb3IgcHJvZmlsaW5nIGV2ZW50IHN0YW5kYXJkcyB0byBkZWZpbmUg bW9yZSBjbGFpbXMgYXQgdGhlIHRvcCBsZXZlbC4gVGhleSBNVVNUIGJlIHJlZ2lzdGVyZWQgaW4g dGhlIEpXVCByZWdpc3RyeS4gUHJvZmlsaW5nDQogZXZlbnRzIGNhbiBhdm9pZCByZWdpc3RyYXRp b24gYnkganVzdCBwdXR0aW5nIHRoZWlyIGF0dHJpYnV0ZXMvY2xhaW1zIGluIHRoZSBwYXlsb2Fk IGFyZWEgYXMgZGVzY3JpYmVkIGluIHRoZSBzcGVjLiZuYnNwOyBIb3dldmVyLCB0aGlzIHdvdWxk IGJlIGluY29uc2lzdGVudCB3aXRoIHRob3NlIHRoYXQgdXNlIHBheWxvYWRzIHdpdGggdW5yZWdp c3RlcmVkIGNsYWltcy4mbmJzcDsgSSBwb2ludCBvdXQgdGhhdCB3ZSBzd2l0Y2hlZCBmcm9tIHJl Z2lzdGVyZWQgZXZlbnQNCiBVUk5zIHRvIFVSSXMgdG8gYXZvaWQgcmVnaXN0cmF0aW9uLiZuYnNw OyBIZW5jZSB0aGUgbW92ZSB0byBwYXlsb2FkIG9iamVjdHMgdG8gZWxpbWluYXRlIHJlZ2lzdHJh dGlvbiBmb3IgYXR0cmlidXRlcy9jbGFpbXMuICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VGhpcyBzdGlsbCBoYXMgdGhlIG5lZ2F0 aXZlcyBvZiBiZWluZyBjb25mdXNhYmxlIGFzIGFuIElEIFRva2VuIGJ5IGV4aXN0aW5nIGNvZGUu IFRoZXJlIGhhcyBiZWVuIGEgZGlzY3Vzc2lvbiB0aGF0IOKAnGlzc+KAnSBhbmQvb3Ig4oCcYXVk 4oCdIHNob3VsZCBhY3R1YWxseSBiZSBkaWZmZXJlbnQgYW5kIHRoZQ0KIHJlY2VpdmVyIHNob3Vs ZCBkZXRlY3QgdGhhdC4mbmJzcDsgSG93ZXZlciBpbiB0aGUgT0lEQyBMb2dvdXQgY2FzZSwgYnkg ZGVzaWduLCB0aGUg4oCcaXNz4oCdIHZhbHVlIHdvdWxkIGJlIHRoZSBzYW1lLiZuYnNwOyBUaGUg 4oCcYXVk4oCdIHdvdWxkIGFsc28gbGlrZWx5IGJlIHRoZSBzYW1lIHVubGVzcyB0aGUgc3BlYyBp bmRpY2F0ZXMgdGhhdCBhbiBhbGlhcyDigJxhdWTigJ0gYmUgdXNlZCBldmVuIHRob3VnaCB0aGUg YXVkaWVuY2UgbWF5IGJlIHRoZSBzYW1lIGVudGl0eSBpbiBib3RoDQogY2FzZXMuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Qi4gRXhjbHVzaXZlLVVz ZSBvZiBTdWI6PC9zcGFuPjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPuKA nHN1YuKAnQ0KIGlzIGludGVycHJldGVkIHRvIGJ5IHRyYWRpdGlvbmFsIGRlZmluaXRpb24gYW5k IGlzIHJlc2VydmVkIGZvciBPQXV0aCB0b2tlbnMgYW5kIE9JREMgQ29ubmVjdCB1c2FnZSBvbmx5 LiZuYnNwOyBJbiBvcmRlciB0byAmbmJzcDthdm9pZCBjb25mdXNpbmcsIGFsbCBwcm9maWxpbmcg ZXZlbnQgc3BlY3Mgc2hvdWxkIE5PVCB1c2Ug4oCcc3Vi4oCdIGluIHRoZSB0b3AgbGV2ZWwgZXhj ZXB0IGZvciBPSURDLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWYiPlRoaXMgaGFzIHRoZSBkaXNhZHZhbnRhZ2UgdGhhdCBPSURDIHJlcXVpcmVzIHNwZWNpYWwg aGFuZGxpbmcgaW4gdGVybXMgb2YgYSBnZW5lcmFsIHVzZSBldmVudCBsaWJyYXJ5LCBidXQgb24g dGhlIG90aGVyIGhhbmQgYSBMb2dvdXQgRXZlbnQgbWlnaHQgYmUgaGFuZGxlZCBkaXJlY3RseSBi eSBleGlzdGluZw0KIElEIFRva2VuIGNvZGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+VGhpcyBzdGlsbCBoYXMgdGhlIGRpc2FkdmFudGFnZSB0aGF0IGFu IFNFVCBjb3VsZCBiZSBjb25mdXNlZCBmb3IgYW4gSUQgVG9rZW4uPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp ZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Qy4gTm8tVG9wLUxldmVsIERhdGE6PC9z cGFuPjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkluDQogb3JkZXIgdG8g bW9yZSBhZ2dyZXNzaXZlbHkgYXZvaWQgY29uZnVzaW9uIG9mIFNFVHMgYXMgSUQgVG9rZW5zLCBt YWtlIGl0IG1hbmRhdG9yeSB0aGF0IFNFVHMgbWF5IG5vdCBjb250YWluIGEg4oCcc3Vi4oCdIHZh bHVlIGF0IHRoZSB0b3AgbGV2ZWwuJm5ic3A7IFRoZSBPSURDIExvZ291dCBFdmVudCwgZm9yIGV4 YW1wbGUsIHdvdWxkIHRoZW4gaW5jbHVkZSBhIOKAnHN1YuKAnSB2YWx1ZSBpbiB0aGUgcGF5bG9h ZCBhcmVhLiBUaGlzIHNob3VsZCBjYXVzZSBleGlzdGluZw0KIHJlbHlpbmcgcGFydGllcyB0byBm YWlsIGNvcnJlY3RseS4gJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+VGhpcyB3b3VsZCBwcm92aWRlIGEgbWF4aW1hbCBkaWZmZXJlbmNlIGZvcm0g YSBJRFRva2VuIG9yIGFjY2VzcyB0b2tlbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj5UaGlzIHdvdWxkIGhhdmUgdGhlIGFkdmFudGFnZSB0aGF0IGVudmVs b3BlcyBjb250YWluIG5vIGRhdGEsIGFuZCB0aGF0IGV2ZXJ5IFNFVCBoYXMgYSBwYXlsb2FkIHdo ZXJlIHRoZSBkYXRhIGlzIGZvdW5kLiBJdCByZXF1aXJlcyBtb3JlIHBhcnNpbmcgaW4gc29tZSBj YXNlcywgYnV0IGl0IGlzIGF0DQogbGVhc3QgY29uc2lzdGVudC4gV2hpbGUgd2UgZG9u4oCZdCBl eHBlY3QgZ2VuZXJhbCBwcm9jZXNzb3JzIGxpa2UgaW4gU09BUCBmb3IgZGlzdHJpYnV0aW9uICht dWNoIG9mIGl0IGlzIHBvaW50IHRvIHBvaW50IGFuZCB2ZXJ5IGNvbnRleHR1YWxseSBkcml2ZW4p LCBJIHBlcnNvbmFsbHkgZXhwZWN0IHRvIHNlZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+KiAmbmJzcDtE ZXZlbG9wbWVudCBvZiBnZW5lcmFsIHB1cnBvc2UgbGlicmFyaWVzIGFuZCB0b29scyB0aGF0IGFy ZSB1c2VkIGVuaGFuY2UgcHJvdG9jb2xzIGFuZCBzeXN0ZW1zJm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZiI+Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPiogJm5ic3A7QXVkaXQgYW5kIHRocmVhdCBhbmFseXNpcyBzeXN0ZW1zIHdpbGwgYmUgbG9v a2luZyBhdCBzb21lIGV2ZW50cyBoaXN0b3JpY2FsbHkuIFRoZXNlIHdpbGwgdGVuZCB0byBtZXJn ZSBtdWx0aXBsZSBldmVudCBmZWVkcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj5NaWtlIEpvbmVzIGFsc28gc3VnZ2VzdGVkIHVzaW5nIHRoZTxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48Yj7igJxjdHnigJ08L2I+ PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPihjb250ZW50 IHR5cGUpIGhlYWRlciBhdHRyaWJ1dGUgZnJvbQ0KIEpXVC4mbmJzcDsgSSB0aGluayBtb3N0IGNv ZGUgdG9kYXkgaGFzIHRoaXMgc2V0IHRvIGlnbm9yZSBvciBmaXhlZCBhcyDigJxKV1TigJ0uJm5i c3A7IEkgd29uZGVyIHdoYXQgY3VycmVudCBpbXBsZW1lbnRzIHdvdWxkIGZlZWwgaWYgd2UgaW50 cm9kdWNlZCBhIOKAnGN0eeKAnSB2YWx1ZSBvZiDigJxTRVTigJ0/Jm5ic3A7IFdvdWxkIHRoYXQg aGVscD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWYiPkkgdGhpbmsgaXQgaXMgdmVyeSBpbXBvcnRhbnQgdG8gYmUgYWJs ZSB0byBjbGVhcmx5IGRpc3Rpbmd1aXNoIGRpZmZlcmVudCB0eXBlcyBvZiBKV1QgdG9rZW5zLiBG b3IgZXhhbXBsZSwgbm90IGJlaW5nIGFibGUgdG8gY3Jvc3MgcG9zdCBhIFNlY3VyaXR5IEV2ZW50 IFRva2VuIGFzIGFuIElkIFRva2VuLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWYiPlJlYWRpbmcmbmJzcDtSRkMgNzUxOSBJIGRvbid0IHRoaW5rIGN0 eSBmaXRzIHRoZSBiaWxsLCBidXQgSSBjb3VsZCBiZSB3cm9uZy4gY3R5IGlzIGEgaGVhZGVyIHBh cmFtZXRlciB1c2VkIGJ5IHRoZSBjcnlwdG8gYWxnb3JpdGhtIGFuZCB0aGUgZGVmYXVsdCB2YWx1 ZSBpcyBKV1QuIFdlIG5lZWQgdG8gZGlzdGluZ3Vpc2gNCiBzdWItdHlwZXMgb2YgSldULCBhbmQg aXQgc2hvdWxkIGJlIGEgY2xhaW0gaW5zaWRlIHRoZSBKV1QuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+V2l0aCB0aGUgYWJvdmUgaXNzdWUgaW4gbWluZCwg SSB0aGluayBvcHRpb24gQSBpcyB0aGUgY2xlYW5lc3Qgc29sdXRpb24uPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlRoYW5rcyBmb3IgeW91 ciBjb21tZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmIj5QaGlsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+QGluZGVwZW5kZW50aWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48YSBocmVm PSJodHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tLyIgdGFyZ2V0PSJfYmxhbmsiPnd3dy5pbmRl cGVuZGVudGlkLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxh IGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBoaWwu aHVudEBvcmFjbGUuY29tPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp ZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCklkLWV2ZW50IG1haWxpbmcgbGlzdDxicj4NCjxhIGhy ZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9yZyI+SWQtZXZlbnRAaWV0Zi5vcmc8L2E+PGJyPg0K PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudCIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQt ZXZlbnQ8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQpJZC1ldmVudCBtYWlsaW5nIGxpc3Q8YnI+DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOklk LWV2ZW50QGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5JZC1ldmVudEBpZXRmLm9yZzwvc3Bh bj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ8L3NwYW4+PC9hPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_SN1PR0301MB164572638A746F5E44157992F5EA0SN1PR0301MB1645_-- From nobody Wed Aug 24 13:59:59 2016 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 93FE212D756 for ; Wed, 24 Aug 2016 13:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.548, 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 GYu5htwOZNU0 for ; Wed, 24 Aug 2016 13:59:54 -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 EB15912D0D9 for ; Wed, 24 Aug 2016 13:59:53 -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 u7OKxmQG030070 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 24 Aug 2016 20:59:49 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u7OKxmZi001270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 24 Aug 2016 20:59:48 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u7OKxlHf032457; Wed, 24 Aug 2016 20:59:47 GMT Received: from [10.0.1.5] (/24.86.208.48) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 24 Aug 2016 13:59:46 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_6467962D-055F-4ECD-92F2-969DDC11EE63" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Phil Hunt In-Reply-To: Date: Wed, 24 Aug 2016 13:59:45 -0700 Message-Id: <3D5305B0-0365-4B07-9D35-81F0B7B04FF2@oracle.com> References: To: John Bradley X-Mailer: Apple Mail (2.3124) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: id-event@ietf.org, Marius Scurtescu Subject: Re: [Id-event] Discussion on use of "sub" and confusion as ID Token X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 24 Aug 2016 20:59:56 -0000 --Apple-Mail=_6467962D-055F-4ECD-92F2-969DDC11EE63 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 John, Did you mean adding a =E2=80=9Cjwt_type=E2=80=9D attribute (that becomes = a registered JWT claim) OR adding a new type value for the JWT header = =E2=80=9Ctyp=E2=80=9D? Note for everyone=E2=80=99s convenience from = 7519: The "typ" (type) Header Parameter defined by [JWS = ] and [JWE = ] is used by JWT applications to declare the media type [IANA.MediaTypes = ] of this complete JWT. This is intended for use by the JWT application when values that are not JWTs could also be present in an application data structure that can contain a JWT object; the application can use this value to disambiguate among the different kinds of objects that might be present. It will typically not be used by applications when it is already known that the object is a JWT. This parameter is ignored by JWT implementations; any processing of this parameter is performed by the JWT application. If present, it is RECOMMENDED that its value be "JWT" to indicate that this object is a JWT. While media type names are not case sensitive, it is RECOMMENDED that "JWT" always be spelled using uppercase characters for compatibility with legacy implementations. Use of this Header Parameter is OPTIONAL. What is concerning is the line that says:=20 It will typically not be used by applications when it is already known that the object is a JWT. This parameter is ignored by JWT implementations; any processing of this parameter is performed by the JWT application. If present, it is RECOMMENDED that its value be "JWT" to indicate that this object is a JWT. If it is typically ignored, then having it =E2=80=9Ctyp=E2=80=9D be = =E2=80=9CSET=E2=80=9D may not help much initially. But at least it is = more definitive. If the group is comfortable, I am ok with making =E2=80=9Ctyp=E2=80=9D = be =E2=80=9CSET=E2=80=9D. It is one more distinguishing item. =20 Regardless, I will also put a cautionary note in the security = considerations that if issuing SETs to audiences that also receive JWTs, = that appropriate care be taken not to confuse if somehow a hacker is = able to present the SET as if it were a JWT to gain access (e.g. in an = authorization header). Normally this should not be possible as I would = assume SETs are passed via something like an HTTP POST back-channel. Phil @independentid www.independentid.com = phil.hunt@oracle.com = > On Aug 24, 2016, at 1:31 PM, John Bradley wrote: >=20 > The idea for cty was to allow a JWS to encapsulate things like a = binary GIF as an example. I think using it for Distinguishing subtypes = of JWT would be a stretch. >=20 > I am most comfortable with A. I think that adding a JWT type claim = at the top level may also be useful going forward to avoid = misinterpretation. >=20 > John B. >> On Aug 24, 2016, at 4:51 PM, Marius Scurtescu > wrote: >>=20 >> On Wed, Aug 24, 2016 at 11:07 AM, Phil Hunt > wrote: >>=20 >> The authors have been having a discussion with regards to using the = =E2=80=9Csub=E2=80=9D claim in the top level. I think it is important to = try and get this discussion back to the main group. My apologies for the = long note. I wanted to get all the pros and cons on the table (hint: = please add if I missed any)... >>=20 >> A question remains should =E2=80=9Csub=E2=80=9D be usable at the top = level. The downside of this approach is that a SET could potentially be = presented as an access or iD token and might initially be confused = because existing code does not know it needs to look for an =E2=80=9Cevent= s=E2=80=9D attribute. The SET and ID Token for all intensive purposes = are the same since a SET just has something extra (the events claim). >>=20 >> There is also the question that if OIDC Logout uses it in the top = level, may other events use it? RFC7519 defines =E2=80=9Csub=E2=80=9D as = a String or URI value. For example, in SCIM events, the =E2=80=9Csub=E2=80= =9D value could be a SCIM Resource URI that indicates the resource whose = state has changed. In OAuth it could be defined as the token identifier = of the token that has been revoked. A SET about blacklisting an IP = address might put the IP address in sub. >>=20 >> So there are three options (Option A seems to be favoured so far): =20= >>=20 >> A. Sub at Top Level: =E2=80=9Csub=E2=80=9D generally used to = reference the Security Subject the SET is talking about. It uses a more = general english language intent of subject rather than the traditional = use as seen in SAML or OpenID Connect. Regardless it is still compliant = with RFC7519 (a String or URI). >>=20 >> This would tend to lead to a style of SETs where the envelope carries = the validation information, the type of event, and the subject of the = event. Additional data goes in the payload. An advantage of this style, = is that for many events, the only thing needed is the event type and the = subject. No payloads would be needed. >>=20 >> For events that don=E2=80=99t want payload, it is probably ok for = profiling event standards to define more claims at the top level. They = MUST be registered in the JWT registry. Profiling events can avoid = registration by just putting their attributes/claims in the payload area = as described in the spec. However, this would be inconsistent with = those that use payloads with unregistered claims. I point out that we = switched from registered event URNs to URIs to avoid registration. = Hence the move to payload objects to eliminate registration for = attributes/claims. =20 >>=20 >> This still has the negatives of being confusable as an ID Token by = existing code. There has been a discussion that =E2=80=9Ciss=E2=80=9D = and/or =E2=80=9Caud=E2=80=9D should actually be different and the = receiver should detect that. However in the OIDC Logout case, by = design, the =E2=80=9Ciss=E2=80=9D value would be the same. The = =E2=80=9Caud=E2=80=9D would also likely be the same unless the spec = indicates that an alias =E2=80=9Caud=E2=80=9D be used even though the = audience may be the same entity in both cases. >>=20 >> B. Exclusive-Use of Sub: =E2=80=9Csub=E2=80=9D is interpreted to by = traditional definition and is reserved for OAuth tokens and OIDC Connect = usage only. In order to avoid confusing, all profiling event specs = should NOT use =E2=80=9Csub=E2=80=9D in the top level except for OIDC. >>=20 >> This has the disadvantage that OIDC requires special handling in = terms of a general use event library, but on the other hand a Logout = Event might be handled directly by existing ID Token code. >>=20 >> This still has the disadvantage that an SET could be confused for an = ID Token. >>=20 >> C. No-Top-Level Data: In order to more aggressively avoid confusion = of SETs as ID Tokens, make it mandatory that SETs may not contain a = =E2=80=9Csub=E2=80=9D value at the top level. The OIDC Logout Event, = for example, would then include a =E2=80=9Csub=E2=80=9D value in the = payload area. This should cause existing relying parties to fail = correctly. =20 >>=20 >> This would provide a maximal difference form a IDToken or access = token. >>=20 >> This would have the advantage that envelopes contain no data, and = that every SET has a payload where the data is found. It requires more = parsing in some cases, but it is at least consistent. While we don=E2=80=99= t expect general processors like in SOAP for distribution (much of it is = point to point and very contextually driven), I personally expect to = see: >> * Development of general purpose libraries and tools that are used = enhance protocols and systems=20 >> * Audit and threat analysis systems will be looking at some events = historically. These will tend to merge multiple event feeds. >>=20 >> Mike Jones also suggested using the =E2=80=9Ccty=E2=80=9D (content = type) header attribute from JWT. I think most code today has this set = to ignore or fixed as =E2=80=9CJWT=E2=80=9D. I wonder what current = implements would feel if we introduced a =E2=80=9Ccty=E2=80=9D value of = =E2=80=9CSET=E2=80=9D? Would that help? >>=20 >> I think it is very important to be able to clearly distinguish = different types of JWT tokens. For example, not being able to cross post = a Security Event Token as an Id Token.=20 >>=20 >> Reading RFC 7519 I don't think cty fits the bill, but I could be = wrong. cty is a header parameter used by the crypto algorithm and the = default value is JWT. We need to distinguish sub-types of JWT, and it = should be a claim inside the JWT. >>=20 >> With the above issue in mind, I think option A is the cleanest = solution. >>=20 >>=20 >>=20 >> Thanks for your comments. >>=20 >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com = phil.hunt@oracle.com = >>=20 >>=20 >>=20 >>=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 = > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event --Apple-Mail=_6467962D-055F-4ECD-92F2-969DDC11EE63 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 John,

Did = you mean adding a =E2=80=9Cjwt_type=E2=80=9D attribute (that becomes a = registered JWT claim) OR adding a new type value for the JWT header = =E2=80=9Ctyp=E2=80=9D?  Note for everyone=E2=80=99s convenience = from 7519:

The "typ" (type) Header =
Parameter defined by [JWS] and [JWE] is used
   by JWT applications to declare the media type [IANA.MediaTypes] of
   this complete JWT.  This is intended for use by the JWT application
   when values that are not JWTs could also be present in an application
   data structure that can contain a JWT object; the application can use
   this value to disambiguate among the different kinds of objects that
   might be present.  It will typically not be used by applications when
   it is already known that the object is a JWT.  This parameter is
   ignored by JWT implementations; any processing of this parameter is
   performed by the JWT application.  If present, it is RECOMMENDED that
   its value be "JWT" to indicate that this object is a JWT.  While
   media type names are not case sensitive, it is RECOMMENDED that "JWT"
   always be spelled using uppercase characters for compatibility with
   legacy implementations.  Use of this Header Parameter is =
OPTIONAL.


What is concerning is = the line that says: 
It will typically not be used by =
applications when
   it is already known that the object is a JWT.  This parameter is
   ignored by JWT implementations; any processing of this =
parameter is
   performed by the JWT application.  If present, it is RECOMMENDED that
   its value be "JWT" to indicate that this object is a JWT.

If it is typically = ignored, then having it =E2=80=9Ctyp=E2=80=9D be =E2=80=9CSET=E2=80=9D = may not help much initially. But at least it is more = definitive.

If = the group is comfortable, I am ok with making =E2=80=9Ctyp=E2=80=9D be = =E2=80=9CSET=E2=80=9D.  It is one more distinguishing item. =  

Regardless, I will also put a cautionary note in the security = considerations that if issuing SETs to audiences that also receive JWTs, = that appropriate care be taken not to confuse if somehow a hacker is = able to present the SET as if it were a JWT to gain access (e.g. in an = authorization header).  Normally this should not be possible as I = would assume SETs are passed via something like an HTTP POST = back-channel.




On Aug 24, 2016, at 1:31 PM, John Bradley <ve7jtb@ve7jtb.com> = wrote:

The idea for = cty was to allow a JWS to encapsulate things like a binary GIF as an = example.   I think using it for Distinguishing subtypes of JWT = would be a stretch.

I = am most comfortable with A.   I think that adding a JWT type claim = at the top level may also be useful going forward to avoid = misinterpretation.

John B.
On Aug 24, 2016, at 4:51 PM, Marius = Scurtescu <mscurtescu@google.com> wrote:

On Wed, Aug 24, 2016 at = 11:07 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

The authors have been having a = discussion with regards to using the =E2=80=9Csub=E2=80=9D claim in the = top level. I think it is important to try and get this discussion back = to the main group. My apologies for the long note. I wanted to get all = the pros and cons on the table (hint:  please add if I missed = any)...

A = question remains should =E2=80=9Csub=E2=80=9D be usable at the top = level.  The downside of this approach is that a SET could = potentially be presented as an access or iD token and might initially be = confused because existing code does not know it needs to look for an = =E2=80=9Cevents=E2=80=9D attribute.  The SET and ID Token for all = intensive purposes are the same since a SET just has something extra = (the events claim).

There is also the question that if OIDC Logout uses it in the = top level, may other events use it? RFC7519 defines =E2=80=9Csub=E2=80=9D = as a String or URI value. For example, in SCIM events, the =E2=80=9Csub=E2= =80=9D value could be a SCIM Resource URI that indicates the resource = whose state has changed.  In OAuth it could be defined as the token = identifier of the token that has been revoked.  A SET about = blacklisting an IP address might put the IP address in sub.

So there are three = options (Option A seems to be favoured so far):  

A.  = Sub at Top Level:  =E2=80=9Csub=E2=80=9D = generally used to reference the Security Subject the SET is talking = about.  It uses a more general english language intent of subject = rather than the traditional use as seen in SAML or OpenID Connect.  = Regardless it is still compliant with RFC7519 (a String or = URI).

This = would tend to lead to a style of SETs where the envelope carries the = validation information, the type of event, and the subject of the event. = Additional data goes in the payload. An advantage of this style, is that = for many events, the only thing needed is the event type and the = subject.  No payloads would be needed.

For events that don=E2=80= =99t want payload, it is probably ok for profiling event standards to = define more claims at the top level. They MUST be registered in the JWT = registry. Profiling events can avoid registration by just putting their = attributes/claims in the payload area as described in the spec.  = However, this would be inconsistent with those that use payloads with = unregistered claims.  I point out that we switched from registered = event URNs to URIs to avoid registration.  Hence the move to = payload objects to eliminate registration for attributes/claims. =  

This still has the negatives of being confusable as an ID = Token by existing code. There has been a discussion that =E2=80=9Ciss=E2=80= =9D and/or =E2=80=9Caud=E2=80=9D should actually be different and the = receiver should detect that.  However in the OIDC Logout case, by = design, the =E2=80=9Ciss=E2=80=9D value would be the same.  The = =E2=80=9Caud=E2=80=9D would also likely be the same unless the spec = indicates that an alias =E2=80=9Caud=E2=80=9D be used even though the = audience may be the same entity in both cases.

B. Exclusive-Use of = Sub: =E2=80=9Csub=E2= =80=9D is interpreted to by traditional definition and is reserved for = OAuth tokens and OIDC Connect usage only.  In order to  avoid = confusing, all profiling event specs should NOT use =E2=80=9Csub=E2=80=9D = in the top level except for OIDC.

This has the disadvantage that OIDC = requires special handling in terms of a general use event library, but = on the other hand a Logout Event might be handled directly by existing = ID Token code.

This still has the disadvantage that an SET could be confused = for an ID Token.

C. No-Top-Level Data: In order to more = aggressively avoid confusion of SETs as ID Tokens, make it mandatory = that SETs may not contain a =E2=80=9Csub=E2=80=9D value at the top = level.  The OIDC Logout Event, for example, would then include a = =E2=80=9Csub=E2=80=9D value in the payload area. This should cause = existing relying parties to fail correctly.  

This would provide a = maximal difference form a IDToken or access token.

This would have the = advantage that envelopes contain no data, and that every SET has a = payload where the data is found. It requires more parsing in some cases, = but it is at least consistent. While we don=E2=80=99t expect general = processors like in SOAP for distribution (much of it is point to point = and very contextually driven), I personally expect to see:
  * =  Development of general purpose libraries and tools that are used = enhance protocols and systems 
  *  Audit and threat = analysis systems will be looking at some events historically. These will = tend to merge multiple event feeds.

Mike Jones also suggested using = the =E2=80=9Ccty=E2=80=9D (content type) header = attribute from JWT.  I think most code today has this set to ignore = or fixed as =E2=80=9CJWT=E2=80=9D.  I wonder what current = implements would feel if we introduced a =E2=80=9Ccty=E2=80=9D value of = =E2=80=9CSET=E2=80=9D?  Would that = help?

I think it is very important to be able to clearly = distinguish different types of JWT tokens. For example, not being able = to cross post a Security Event Token as an Id Token. 

Reading RFC 7519 I = don't think cty fits the bill, but I could be wrong. cty is a header = parameter used by the crypto algorithm and the default value is JWT. We = need to distinguish sub-types of JWT, and it should be a claim inside = the JWT.

With = the above issue in mind, I think option A is the cleanest = solution.



Thanks for your comments.


Phil

@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

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

= --Apple-Mail=_6467962D-055F-4ECD-92F2-969DDC11EE63-- From nobody Wed Aug 24 14:24:24 2016 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 A037D12D5D7 for ; Wed, 24 Aug 2016 14:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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] 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 gqXNQMs7cAea for ; Wed, 24 Aug 2016 14:24:17 -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 11C4F12D124 for ; Wed, 24 Aug 2016 14:24:16 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id z190so28489664qkc.0 for ; Wed, 24 Aug 2016 14:24:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=r/3wj9+eDeBsN/yos45atdrBbsjTIQWPPR+NylTvjfg=; b=LB2ZXQb97ja7yXJfhZa6V2efPGidkFQc+UpBiaCT42vgBZrslDwt0ntsyerx7bxCkI FSbc6X/wDw5brBQJh7g/+pMSl3K+RM6g0uH71l06Q4+qTJPJdPQHYghvxxPHqRTWDjCu 1b0agi7Sj79sSfMjyR0Jht2pFxRi8RUSZnzYYYQWAiMi93ljqg1q56JEX17WmL9jAnXL WJ4SSra1uGi5BFre6IOmZgybHqetElfHkcQ7RWW06MNFMNjhHNxsBOuyM6RvOWenU5PX 1jmWPlDuaBnlJCnGg+VFpQp8D6tuv/Zeqrwgx0x/zID6WsuthZoHnzd9PaekMfuB3XNQ nlvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=r/3wj9+eDeBsN/yos45atdrBbsjTIQWPPR+NylTvjfg=; b=NKJYk8JvRp28mdqm4orblVXEb2ubDgdaGwuExqZgaGq0VoaarpxLaThegzQVV1SEYO TN6l3eHmRWSQ7Pb783FM1gFaDM95SuerufsPWUF9AjqYLpdi67fSKnYhyclhYviF8veN 9ACef08gdVyK2Q+qmUx4dWufMIm8LNEf1kSDYQ999MydMAzsjZ1ui+2WSqgPXr4qeXVg CxhcISqH3rbvBrzlQCY7u8fszbCn+GdFyQRIyApcx41w7IZopphltyC09c43xUUVBCi2 AZ8S4pYCfW7FxCqAAvZCslWoqvppvDottEr11tDyTKRsOAmMk12YPwnGaLhH4J+lLmZj FAqQ== X-Gm-Message-State: AE9vXwPyU+Kuw1wMNL0HIEFfwuT5E5Gr666fE0+XWFCDdCkpEBZ8u3TAPEfg8vaINSYRi9t6 X-Received: by 10.55.129.1 with SMTP id c1mr6022178qkd.53.1472073856052; Wed, 24 Aug 2016 14:24:16 -0700 (PDT) Received: from [192.168.8.101] ([181.201.108.96]) by smtp.gmail.com with ESMTPSA id h7sm5764612qke.35.2016.08.24.14.24.14 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 24 Aug 2016 14:24:15 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_42365CEC-371D-4E97-AABC-AD8BBD404E16" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: John Bradley In-Reply-To: <3D5305B0-0365-4B07-9D35-81F0B7B04FF2@oracle.com> Date: Wed, 24 Aug 2016 18:24:11 -0300 Message-Id: <382F27DF-A35A-43F3-8C2E-CE3D8ABC4ADB@ve7jtb.com> References: <3D5305B0-0365-4B07-9D35-81F0B7B04FF2@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.3124) Archived-At: Cc: id-event@ietf.org, Marius Scurtescu Subject: Re: [Id-event] Discussion on use of "sub" and confusion as ID Token X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 24 Aug 2016 21:24:20 -0000 --Apple-Mail=_42365CEC-371D-4E97-AABC-AD8BBD404E16 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I was saying that cty was wrong for this. =20 If you look at the definition of typ in JWS = https://tools.ietf.org/html/rfc7515#page-13 = you can see that it is = really intended to be the media type of the complete JWS/JWE and is = omitted or set to JWT if it is a compact JWT. Setting it to SET = seems wrong as it is still a JWT. I was recommending considering a JWT = top level claim in the JWT registry. John B. > On Aug 24, 2016, at 5:59 PM, Phil Hunt wrote: >=20 > John, >=20 > Did you mean adding a =E2=80=9Cjwt_type=E2=80=9D attribute (that = becomes a registered JWT claim) OR adding a new type value for the JWT = header =E2=80=9Ctyp=E2=80=9D? Note for everyone=E2=80=99s convenience = from 7519: >=20 > The "typ" (type) Header Parameter defined by [JWS = ] and [JWE = ] is used > by JWT applications to declare the media type [IANA.MediaTypes = ] of > this complete JWT. This is intended for use by the JWT application > when values that are not JWTs could also be present in an = application > data structure that can contain a JWT object; the application can = use > this value to disambiguate among the different kinds of objects = that > might be present. It will typically not be used by applications = when > it is already known that the object is a JWT. This parameter is > ignored by JWT implementations; any processing of this parameter is > performed by the JWT application. If present, it is RECOMMENDED = that > its value be "JWT" to indicate that this object is a JWT. While > media type names are not case sensitive, it is RECOMMENDED that = "JWT" > always be spelled using uppercase characters for compatibility with > legacy implementations. Use of this Header Parameter is OPTIONAL. >=20 >=20 > What is concerning is the line that says:=20 > It will typically not be used by applications when > it is already known that the object is a JWT. This parameter is > ignored by JWT implementations; any processing of this parameter is > performed by the JWT application. If present, it is RECOMMENDED = that > its value be "JWT" to indicate that this object is a JWT. >=20 > If it is typically ignored, then having it =E2=80=9Ctyp=E2=80=9D be = =E2=80=9CSET=E2=80=9D may not help much initially. But at least it is = more definitive. >=20 > If the group is comfortable, I am ok with making =E2=80=9Ctyp=E2=80=9D = be =E2=80=9CSET=E2=80=9D. It is one more distinguishing item. =20 >=20 > Regardless, I will also put a cautionary note in the security = considerations that if issuing SETs to audiences that also receive JWTs, = that appropriate care be taken not to confuse if somehow a hacker is = able to present the SET as if it were a JWT to gain access (e.g. in an = authorization header). Normally this should not be possible as I would = assume SETs are passed via something like an HTTP POST back-channel. >=20 > Phil >=20 > @independentid > www.independentid.com = phil.hunt@oracle.com = >=20 >=20 >=20 >=20 >=20 >> On Aug 24, 2016, at 1:31 PM, John Bradley > wrote: >>=20 >> The idea for cty was to allow a JWS to encapsulate things like a = binary GIF as an example. I think using it for Distinguishing subtypes = of JWT would be a stretch. >>=20 >> I am most comfortable with A. I think that adding a JWT type claim = at the top level may also be useful going forward to avoid = misinterpretation. >>=20 >> John B. >>> On Aug 24, 2016, at 4:51 PM, Marius Scurtescu > wrote: >>>=20 >>> On Wed, Aug 24, 2016 at 11:07 AM, Phil Hunt > wrote: >>>=20 >>> The authors have been having a discussion with regards to using the = =E2=80=9Csub=E2=80=9D claim in the top level. I think it is important to = try and get this discussion back to the main group. My apologies for the = long note. I wanted to get all the pros and cons on the table (hint: = please add if I missed any)... >>>=20 >>> A question remains should =E2=80=9Csub=E2=80=9D be usable at the top = level. The downside of this approach is that a SET could potentially be = presented as an access or iD token and might initially be confused = because existing code does not know it needs to look for an =E2=80=9Cevent= s=E2=80=9D attribute. The SET and ID Token for all intensive purposes = are the same since a SET just has something extra (the events claim). >>>=20 >>> There is also the question that if OIDC Logout uses it in the top = level, may other events use it? RFC7519 defines =E2=80=9Csub=E2=80=9D as = a String or URI value. For example, in SCIM events, the =E2=80=9Csub=E2=80= =9D value could be a SCIM Resource URI that indicates the resource whose = state has changed. In OAuth it could be defined as the token identifier = of the token that has been revoked. A SET about blacklisting an IP = address might put the IP address in sub. >>>=20 >>> So there are three options (Option A seems to be favoured so far): =20= >>>=20 >>> A. Sub at Top Level: =E2=80=9Csub=E2=80=9D generally used to = reference the Security Subject the SET is talking about. It uses a more = general english language intent of subject rather than the traditional = use as seen in SAML or OpenID Connect. Regardless it is still compliant = with RFC7519 (a String or URI). >>>=20 >>> This would tend to lead to a style of SETs where the envelope = carries the validation information, the type of event, and the subject = of the event. Additional data goes in the payload. An advantage of this = style, is that for many events, the only thing needed is the event type = and the subject. No payloads would be needed. >>>=20 >>> For events that don=E2=80=99t want payload, it is probably ok for = profiling event standards to define more claims at the top level. They = MUST be registered in the JWT registry. Profiling events can avoid = registration by just putting their attributes/claims in the payload area = as described in the spec. However, this would be inconsistent with = those that use payloads with unregistered claims. I point out that we = switched from registered event URNs to URIs to avoid registration. = Hence the move to payload objects to eliminate registration for = attributes/claims. =20 >>>=20 >>> This still has the negatives of being confusable as an ID Token by = existing code. There has been a discussion that =E2=80=9Ciss=E2=80=9D = and/or =E2=80=9Caud=E2=80=9D should actually be different and the = receiver should detect that. However in the OIDC Logout case, by = design, the =E2=80=9Ciss=E2=80=9D value would be the same. The = =E2=80=9Caud=E2=80=9D would also likely be the same unless the spec = indicates that an alias =E2=80=9Caud=E2=80=9D be used even though the = audience may be the same entity in both cases. >>>=20 >>> B. Exclusive-Use of Sub: =E2=80=9Csub=E2=80=9D is interpreted to by = traditional definition and is reserved for OAuth tokens and OIDC Connect = usage only. In order to avoid confusing, all profiling event specs = should NOT use =E2=80=9Csub=E2=80=9D in the top level except for OIDC. >>>=20 >>> This has the disadvantage that OIDC requires special handling in = terms of a general use event library, but on the other hand a Logout = Event might be handled directly by existing ID Token code. >>>=20 >>> This still has the disadvantage that an SET could be confused for an = ID Token. >>>=20 >>> C. No-Top-Level Data: In order to more aggressively avoid confusion = of SETs as ID Tokens, make it mandatory that SETs may not contain a = =E2=80=9Csub=E2=80=9D value at the top level. The OIDC Logout Event, = for example, would then include a =E2=80=9Csub=E2=80=9D value in the = payload area. This should cause existing relying parties to fail = correctly. =20 >>>=20 >>> This would provide a maximal difference form a IDToken or access = token. >>>=20 >>> This would have the advantage that envelopes contain no data, and = that every SET has a payload where the data is found. It requires more = parsing in some cases, but it is at least consistent. While we don=E2=80=99= t expect general processors like in SOAP for distribution (much of it is = point to point and very contextually driven), I personally expect to = see: >>> * Development of general purpose libraries and tools that are = used enhance protocols and systems=20 >>> * Audit and threat analysis systems will be looking at some = events historically. These will tend to merge multiple event feeds. >>>=20 >>> Mike Jones also suggested using the =E2=80=9Ccty=E2=80=9D (content = type) header attribute from JWT. I think most code today has this set = to ignore or fixed as =E2=80=9CJWT=E2=80=9D. I wonder what current = implements would feel if we introduced a =E2=80=9Ccty=E2=80=9D value of = =E2=80=9CSET=E2=80=9D? Would that help? >>>=20 >>> I think it is very important to be able to clearly distinguish = different types of JWT tokens. For example, not being able to cross post = a Security Event Token as an Id Token.=20 >>>=20 >>> Reading RFC 7519 I don't think cty fits the bill, but I could be = wrong. cty is a header parameter used by the crypto algorithm and the = default value is JWT. We need to distinguish sub-types of JWT, and it = should be a claim inside the JWT. >>>=20 >>> With the above issue in mind, I think option A is the cleanest = solution. >>>=20 >>>=20 >>>=20 >>> Thanks for your comments. >>>=20 >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com = phil.hunt@oracle.com = >>>=20 >>>=20 >>>=20 >>>=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 = >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >=20 --Apple-Mail=_42365CEC-371D-4E97-AABC-AD8BBD404E16 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I was saying that cty was wrong for this.  

If you look at the = definition of typ in JWS https://tools.ietf.org/html/rfc7515#page-13  you can = see that it is really intended to be the media type of the complete = JWS/JWE and is omitted or set to JWT if it is a compact JWT.   =   Setting it to SET seems wrong as it is still a JWT.   I was = recommending considering a JWT top level claim in the JWT = registry.

John = B.


On = Aug 24, 2016, at 5:59 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

John,

Did you mean adding a = =E2=80=9Cjwt_type=E2=80=9D attribute (that becomes a registered JWT = claim) OR adding a new type value for the JWT header =E2=80=9Ctyp=E2=80=9D= ?  Note for everyone=E2=80=99s convenience from 7519:

The "typ" (type) Header Parameter defined by =
[JWS] and =
[JWE] is =
used
   by JWT applications to declare the media type [IANA.MediaTypes] of
   this complete JWT.  This is intended for use by the JWT application
   when values that are not JWTs could also be present in an application
   data structure that can contain a JWT object; the application can use
   this value to disambiguate among the different kinds of objects that
   might be present.  It will typically not be used by applications when
   it is already known that the object is a JWT.  This parameter is
   ignored by JWT implementations; any processing of this parameter is
   performed by the JWT application.  If present, it is RECOMMENDED that
   its value be "JWT" to indicate that this object is a JWT.  While
   media type names are not case sensitive, it is RECOMMENDED that "JWT"
   always be spelled using uppercase characters for compatibility with
   legacy implementations.  Use of this Header Parameter is =
OPTIONAL.


What is concerning is = the line that says: 
It will typically not be used by =
applications when
   it is already known that the object is a JWT.  This parameter is
   ignored by JWT implementations; any processing of this =
parameter is
   performed by the JWT application.  If present, it is RECOMMENDED that
   its value be "JWT" to indicate that this object is a JWT.

If it is typically = ignored, then having it =E2=80=9Ctyp=E2=80=9D be =E2=80=9CSET=E2=80=9D = may not help much initially. But at least it is more = definitive.

If = the group is comfortable, I am ok with making =E2=80=9Ctyp=E2=80=9D be = =E2=80=9CSET=E2=80=9D.  It is one more distinguishing item. =  

Regardless, I will also put a cautionary note in the security = considerations that if issuing SETs to audiences that also receive JWTs, = that appropriate care be taken not to confuse if somehow a hacker is = able to present the SET as if it were a JWT to gain access (e.g. in an = authorization header).  Normally this should not be possible as I = would assume SETs are passed via something like an HTTP POST = back-channel.





On Aug 24, 2016, at 1:31 PM, John Bradley <ve7jtb@ve7jtb.com> = wrote:

The idea for = cty was to allow a JWS to encapsulate things like a binary GIF as an = example.   I think using it for Distinguishing subtypes of JWT = would be a stretch.

I = am most comfortable with A.   I think that adding a JWT type claim = at the top level may also be useful going forward to avoid = misinterpretation.

John B.
On Aug 24, 2016, at 4:51 PM, Marius = Scurtescu <mscurtescu@google.com> wrote:

On Wed, Aug 24, 2016 at = 11:07 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

The authors have been having a = discussion with regards to using the =E2=80=9Csub=E2=80=9D claim in the = top level. I think it is important to try and get this discussion back = to the main group. My apologies for the long note. I wanted to get all = the pros and cons on the table (hint:  please add if I missed = any)...

A = question remains should =E2=80=9Csub=E2=80=9D be usable at the top = level.  The downside of this approach is that a SET could = potentially be presented as an access or iD token and might initially be = confused because existing code does not know it needs to look for an = =E2=80=9Cevents=E2=80=9D attribute.  The SET and ID Token for all = intensive purposes are the same since a SET just has something extra = (the events claim).

There is also the question that if OIDC Logout uses it in the = top level, may other events use it? RFC7519 defines =E2=80=9Csub=E2=80=9D = as a String or URI value. For example, in SCIM events, the =E2=80=9Csub=E2= =80=9D value could be a SCIM Resource URI that indicates the resource = whose state has changed.  In OAuth it could be defined as the token = identifier of the token that has been revoked.  A SET about = blacklisting an IP address might put the IP address in sub.

So there are three = options (Option A seems to be favoured so far):  

A.  = Sub at Top Level:  =E2=80=9Csub=E2=80=9D = generally used to reference the Security Subject the SET is talking = about.  It uses a more general english language intent of subject = rather than the traditional use as seen in SAML or OpenID Connect.  = Regardless it is still compliant with RFC7519 (a String or = URI).

This = would tend to lead to a style of SETs where the envelope carries the = validation information, the type of event, and the subject of the event. = Additional data goes in the payload. An advantage of this style, is that = for many events, the only thing needed is the event type and the = subject.  No payloads would be needed.

For events that don=E2=80= =99t want payload, it is probably ok for profiling event standards to = define more claims at the top level. They MUST be registered in the JWT = registry. Profiling events can avoid registration by just putting their = attributes/claims in the payload area as described in the spec.  = However, this would be inconsistent with those that use payloads with = unregistered claims.  I point out that we switched from registered = event URNs to URIs to avoid registration.  Hence the move to = payload objects to eliminate registration for attributes/claims. =  

This still has the negatives of being confusable as an ID = Token by existing code. There has been a discussion that =E2=80=9Ciss=E2=80= =9D and/or =E2=80=9Caud=E2=80=9D should actually be different and the = receiver should detect that.  However in the OIDC Logout case, by = design, the =E2=80=9Ciss=E2=80=9D value would be the same.  The = =E2=80=9Caud=E2=80=9D would also likely be the same unless the spec = indicates that an alias =E2=80=9Caud=E2=80=9D be used even though the = audience may be the same entity in both cases.

B. Exclusive-Use of = Sub: =E2=80=9Csub=E2= =80=9D is interpreted to by traditional definition and is reserved for = OAuth tokens and OIDC Connect usage only.  In order to  avoid = confusing, all profiling event specs should NOT use =E2=80=9Csub=E2=80=9D = in the top level except for OIDC.

This has the disadvantage that OIDC = requires special handling in terms of a general use event library, but = on the other hand a Logout Event might be handled directly by existing = ID Token code.

This still has the disadvantage that an SET could be confused = for an ID Token.

C. No-Top-Level Data: In order to more = aggressively avoid confusion of SETs as ID Tokens, make it mandatory = that SETs may not contain a =E2=80=9Csub=E2=80=9D value at the top = level.  The OIDC Logout Event, for example, would then include a = =E2=80=9Csub=E2=80=9D value in the payload area. This should cause = existing relying parties to fail correctly.  

This would provide a = maximal difference form a IDToken or access token.

This would have the = advantage that envelopes contain no data, and that every SET has a = payload where the data is found. It requires more parsing in some cases, = but it is at least consistent. While we don=E2=80=99t expect general = processors like in SOAP for distribution (much of it is point to point = and very contextually driven), I personally expect to see:
  * =  Development of general purpose libraries and tools that are used = enhance protocols and systems 
  *  Audit and threat = analysis systems will be looking at some events historically. These will = tend to merge multiple event feeds.

Mike Jones also suggested using = the =E2=80=9Ccty=E2=80=9D (content type) header = attribute from JWT.  I think most code today has this set to ignore = or fixed as =E2=80=9CJWT=E2=80=9D.  I wonder what current = implements would feel if we introduced a =E2=80=9Ccty=E2=80=9D value of = =E2=80=9CSET=E2=80=9D?  Would that = help?

I think it is very important to be able to clearly = distinguish different types of JWT tokens. For example, not being able = to cross post a Security Event Token as an Id Token. 

Reading RFC 7519 I = don't think cty fits the bill, but I could be wrong. cty is a header = parameter used by the crypto algorithm and the default value is JWT. We = need to distinguish sub-types of JWT, and it should be a claim inside = the JWT.

With = the above issue in mind, I think option A is the cleanest = solution.



Thanks for your comments.


Phil

@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

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


= --Apple-Mail=_42365CEC-371D-4E97-AABC-AD8BBD404E16-- From nobody Wed Aug 24 14:31:13 2016 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 EA09912D188 for ; Wed, 24 Aug 2016 14:31:10 -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 X_IDj1_1i-FM for ; Wed, 24 Aug 2016 14:31:07 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0104.outbound.protection.outlook.com [104.47.33.104]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB02D12D0AF for ; Wed, 24 Aug 2016 14:31: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=BiSfm7c7CnxUP6Y+9GDTgcRbnYdGgVWQu7IEo+GYtGY=; b=FbdVPwx866z9dmIU/yIpfqM64hbmmnJTlKTNROl619CLqIh2NXcCu1cTxu0ZRO5iSzxI0E+OGMkuv37gJitMjs3sa2kGySucV5Nby8O6O9+NXvMdrnPbeZBs2lnOpjmUYbFS63XY/xmlNuYoZ0g1D1YUYAguDNCmjPCPfFiKbWk= Received: from SN1PR0301MB1645.namprd03.prod.outlook.com (10.162.130.139) by SN1PR0301MB1645.namprd03.prod.outlook.com (10.162.130.139) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.13; Wed, 24 Aug 2016 21:31:05 +0000 Received: from SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) by SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) with mapi id 15.01.0587.013; Wed, 24 Aug 2016 21:31:05 +0000 From: Mike Jones To: John Bradley , Phil Hunt Thread-Topic: [Id-event] Discussion on use of "sub" and confusion as ID Token Thread-Index: AQHR/jJ6Kzu5WyrJDU6lijc1KOHPZaBYhVKAgAALW4CAAAfQgIAABtOAgAABn1A= Date: Wed, 24 Aug 2016 21:31:04 +0000 Message-ID: References: <3D5305B0-0365-4B07-9D35-81F0B7B04FF2@oracle.com> <382F27DF-A35A-43F3-8C2E-CE3D8ABC4ADB@ve7jtb.com> In-Reply-To: <382F27DF-A35A-43F3-8C2E-CE3D8ABC4ADB@ve7jtb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [64.134.242.226] x-ms-office365-filtering-correlation-id: 7b493978-de64-4335-dcdc-08d3cc65f449 x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1645; 6:kVb2P0X7TPTh3Xv5sXl3tL69QvYlpCuKtgSS8b5hNA1BzJDRND6bxHbU6TkZHSJt0Qj+7EkBKMz8krojG4RnZBrgOKoDVFSdu8R6RXeVGiH/ZUHvMVxYSnUT8P3xuGQj+l+5yjcNlNRbYYZai+N2Nc+0KWQxXMhurVtR+FaSMh5Bbh3pAUBMqpngl1HNqjwbpmvKfl7CpzkJvcPAnJGbyP93XUjw9uP0ctAvnK0+RR8MHmiiuUUqvb73CgufhYZ9Z/tFoT1zCFVAeUccfh1cc8eHZZQpvgN4mnRquNlgK26PDNk12ao9ThMa6AXyY8Mwhf39KiCO1AVRyK37JIRe/A==; 5:5dhl7LpXSxPXW4pO/a+FxfVo48uEYN2tGazEQC+Wf2Ly4qoemmgyOGfYF/UzTSujzuCzkUlVB8Rw2Tn+rpLQoAfbqJbRa6tHfjIw1zARaeMRWG/1ZgEVd/u5B8eAgNSML6Zu28tJKDJcjyW09AMCGA==; 24:7wSB0a0ULdYN+cvWzzbs7zI7wnHq2XULyahMSOMWY25Ty89gnl3ukQLXf6RLds3BXtWYjNmAYTKEv+7oQUZ8g1+hmhfts4x+Hp++Sg9d1Ik=; 7:ZwQF8l8d7Ukne59I8RNJutSJwP3GodiRfvvw6LvAF6QwE8N0eLQtl1iIPZTFPchDOVIf/E+sUdkzLCLL2wHgjWlBkWUD9+sYaMuktrkXZVFbMHs+YjTv0GTtISEkg7QmX4zKNCe1meVy1xHCmiTAc4p46nxNyELWX1f9bc+DMLRECHzPnobinW3OXRSyCopTUL+BT75Mtcn1jw+9Wkxhc2cbbtXTpk1tTZ0jxOmWZy4SFwF3xI1Xsqdc+WrPLOlm x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1645; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(192374486261705)(211936372134217)(21748063052155)(21532816269658)(146099531331640)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:SN1PR0301MB1645; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1645; x-forefront-prvs: 0044C17179 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(377454003)(51444003)(199003)(189002)(24454002)(19580395003)(790700001)(106356001)(5002640100001)(2950100001)(77096005)(19609705001)(81156014)(10090500001)(7846002)(7906003)(7696003)(122556002)(2900100001)(8936002)(7736002)(8676002)(15975445007)(92566002)(11100500001)(5660300001)(19580405001)(8990500004)(19300405004)(5005710100001)(10290500002)(81166006)(10400500002)(2906002)(189998001)(97736004)(5001770100001)(4326007)(1680700002)(9686002)(76176999)(54356999)(76576001)(50986999)(99286002)(86362001)(102836003)(93886004)(6116002)(3846002)(106116001)(33656002)(16236675004)(3280700002)(586003)(105586002)(74316002)(3660700001)(19625215002)(68736007)(86612001)(101416001)(66066001)(19617315012)(87936001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0301MB1645; H:SN1PR0301MB1645.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB1645223021A8FC4C0ECC8D7CF5EA0SN1PR0301MB1645_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Aug 2016 21:31:04.9684 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1645 Archived-At: Cc: "id-event@ietf.org" , Marius Scurtescu Subject: Re: [Id-event] Discussion on use of "sub" and confusion as ID Token X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 24 Aug 2016 21:31:11 -0000 --_000_SN1PR0301MB1645223021A8FC4C0ECC8D7CF5EA0SN1PR0301MB1645_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QSBzcGVjIGNvdWxkIGNyZWF0ZSBhIHRvcC1sZXZlbCBKV1QgdHlwZSBjbGFpbSwgYnV0IEnigJlk IGFzc2VydCB0aGF0IGl04oCZcyBvdXQgb2Ygc2NvcGUgZm9yIHRoZSBFdmVudHMgc3BlYy4gIEl0 IHdvdWxkIHByb2JhYmx5IG5lZWQgdG8gYmUgaXRzIG93biBzcGVjIGFuZCBzYXkgYmFzaWNhbGx5 IOKAnHVzZSBpdCBpZiB5b3XigJlyZSBpbiB1c2UgY2FzZXMgaW4gd2hpY2ggaXTigJlzIHVzZWZ1 bCB0byBkaXN0aW5ndWlzaCBiZXR3ZWVuIHRoaW5nc+KAnS4NCg0KRnJvbTogSWQtZXZlbnQgW21h aWx0bzppZC1ldmVudC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSm9obiBCcmFkbGV5 DQpTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAyNCwgMjAxNiAyOjI0IFBNDQpUbzogUGhpbCBIdW50 IDxwaGlsLmh1bnRAb3JhY2xlLmNvbT4NCkNjOiBpZC1ldmVudEBpZXRmLm9yZzsgTWFyaXVzIFNj dXJ0ZXNjdSA8bXNjdXJ0ZXNjdUBnb29nbGUuY29tPg0KU3ViamVjdDogUmU6IFtJZC1ldmVudF0g RGlzY3Vzc2lvbiBvbiB1c2Ugb2YgInN1YiIgYW5kIGNvbmZ1c2lvbiBhcyBJRCBUb2tlbg0KDQpJ IHdhcyBzYXlpbmcgdGhhdCBjdHkgd2FzIHdyb25nIGZvciB0aGlzLg0KDQpJZiB5b3UgbG9vayBh dCB0aGUgZGVmaW5pdGlvbiBvZiB0eXAgaW4gSldTIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9yZmM3NTE1I3BhZ2UtMTMgIHlvdSBjYW4gc2VlIHRoYXQgaXQgaXMgcmVhbGx5IGludGVuZGVk IHRvIGJlIHRoZSBtZWRpYSB0eXBlIG9mIHRoZSBjb21wbGV0ZSBKV1MvSldFIGFuZCBpcyBvbWl0 dGVkIG9yIHNldCB0byBKV1QgaWYgaXQgaXMgYSBjb21wYWN0IEpXVC4gICAgIFNldHRpbmcgaXQg dG8gU0VUIHNlZW1zIHdyb25nIGFzIGl0IGlzIHN0aWxsIGEgSldULiAgIEkgd2FzIHJlY29tbWVu ZGluZyBjb25zaWRlcmluZyBhIEpXVCB0b3AgbGV2ZWwgY2xhaW0gaW4gdGhlIEpXVCByZWdpc3Ry eS4NCg0KSm9obiBCLg0KDQoNCk9uIEF1ZyAyNCwgMjAxNiwgYXQgNTo1OSBQTSwgUGhpbCBIdW50 IDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+PiB3cm90 ZToNCg0KSm9obiwNCg0KRGlkIHlvdSBtZWFuIGFkZGluZyBhIOKAnGp3dF90eXBl4oCdIGF0dHJp YnV0ZSAodGhhdCBiZWNvbWVzIGEgcmVnaXN0ZXJlZCBKV1QgY2xhaW0pIE9SIGFkZGluZyBhIG5l dyB0eXBlIHZhbHVlIGZvciB0aGUgSldUIGhlYWRlciDigJx0eXDigJ0/ICBOb3RlIGZvciBldmVy eW9uZeKAmXMgY29udmVuaWVuY2UgZnJvbSA3NTE5Og0KDQoNClRoZSAidHlwIiAodHlwZSkgSGVh ZGVyIFBhcmFtZXRlciBkZWZpbmVkIGJ5IFtKV1M8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L3JmYzc1MTkjcmVmLUpXUz5dIGFuZCBbSldFPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9y ZmM3NTE5I3JlZi1KV0U+XSBpcyB1c2VkDQoNCiAgIGJ5IEpXVCBhcHBsaWNhdGlvbnMgdG8gZGVj bGFyZSB0aGUgbWVkaWEgdHlwZSBbSUFOQS5NZWRpYVR5cGVzPGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9yZmM3NTE5I3JlZi1JQU5BLk1lZGlhVHlwZXM+XSBvZg0KDQogICB0aGlzIGNvbXBs ZXRlIEpXVC4gIFRoaXMgaXMgaW50ZW5kZWQgZm9yIHVzZSBieSB0aGUgSldUIGFwcGxpY2F0aW9u DQoNCiAgIHdoZW4gdmFsdWVzIHRoYXQgYXJlIG5vdCBKV1RzIGNvdWxkIGFsc28gYmUgcHJlc2Vu dCBpbiBhbiBhcHBsaWNhdGlvbg0KDQogICBkYXRhIHN0cnVjdHVyZSB0aGF0IGNhbiBjb250YWlu IGEgSldUIG9iamVjdDsgdGhlIGFwcGxpY2F0aW9uIGNhbiB1c2UNCg0KICAgdGhpcyB2YWx1ZSB0 byBkaXNhbWJpZ3VhdGUgYW1vbmcgdGhlIGRpZmZlcmVudCBraW5kcyBvZiBvYmplY3RzIHRoYXQN Cg0KICAgbWlnaHQgYmUgcHJlc2VudC4gIEl0IHdpbGwgdHlwaWNhbGx5IG5vdCBiZSB1c2VkIGJ5 IGFwcGxpY2F0aW9ucyB3aGVuDQoNCiAgIGl0IGlzIGFscmVhZHkga25vd24gdGhhdCB0aGUgb2Jq ZWN0IGlzIGEgSldULiAgVGhpcyBwYXJhbWV0ZXIgaXMNCg0KICAgaWdub3JlZCBieSBKV1QgaW1w bGVtZW50YXRpb25zOyBhbnkgcHJvY2Vzc2luZyBvZiB0aGlzIHBhcmFtZXRlciBpcw0KDQogICBw ZXJmb3JtZWQgYnkgdGhlIEpXVCBhcHBsaWNhdGlvbi4gIElmIHByZXNlbnQsIGl0IGlzIFJFQ09N TUVOREVEIHRoYXQNCg0KICAgaXRzIHZhbHVlIGJlICJKV1QiIHRvIGluZGljYXRlIHRoYXQgdGhp cyBvYmplY3QgaXMgYSBKV1QuICBXaGlsZQ0KDQogICBtZWRpYSB0eXBlIG5hbWVzIGFyZSBub3Qg Y2FzZSBzZW5zaXRpdmUsIGl0IGlzIFJFQ09NTUVOREVEIHRoYXQgIkpXVCINCg0KICAgYWx3YXlz IGJlIHNwZWxsZWQgdXNpbmcgdXBwZXJjYXNlIGNoYXJhY3RlcnMgZm9yIGNvbXBhdGliaWxpdHkg d2l0aA0KDQogICBsZWdhY3kgaW1wbGVtZW50YXRpb25zLiAgVXNlIG9mIHRoaXMgSGVhZGVyIFBh cmFtZXRlciBpcyBPUFRJT05BTC4NCg0KDQpXaGF0IGlzIGNvbmNlcm5pbmcgaXMgdGhlIGxpbmUg dGhhdCBzYXlzOg0KDQpJdCB3aWxsIHR5cGljYWxseSBub3QgYmUgdXNlZCBieSBhcHBsaWNhdGlv bnMgd2hlbg0KDQogICBpdCBpcyBhbHJlYWR5IGtub3duIHRoYXQgdGhlIG9iamVjdCBpcyBhIEpX VC4gIFRoaXMgcGFyYW1ldGVyIGlzDQoNCiAgIGlnbm9yZWQgYnkgSldUIGltcGxlbWVudGF0aW9u czsgYW55IHByb2Nlc3Npbmcgb2YgdGhpcyBwYXJhbWV0ZXIgaXMNCg0KICAgcGVyZm9ybWVkIGJ5 IHRoZSBKV1QgYXBwbGljYXRpb24uICBJZiBwcmVzZW50LCBpdCBpcyBSRUNPTU1FTkRFRCB0aGF0 DQoNCiAgIGl0cyB2YWx1ZSBiZSAiSldUIiB0byBpbmRpY2F0ZSB0aGF0IHRoaXMgb2JqZWN0IGlz IGEgSldULg0KDQpJZiBpdCBpcyB0eXBpY2FsbHkgaWdub3JlZCwgdGhlbiBoYXZpbmcgaXQg4oCc dHlw4oCdIGJlIOKAnFNFVOKAnSBtYXkgbm90IGhlbHAgbXVjaCBpbml0aWFsbHkuIEJ1dCBhdCBs ZWFzdCBpdCBpcyBtb3JlIGRlZmluaXRpdmUuDQoNCklmIHRoZSBncm91cCBpcyBjb21mb3J0YWJs ZSwgSSBhbSBvayB3aXRoIG1ha2luZyDigJx0eXDigJ0gYmUg4oCcU0VU4oCdLiAgSXQgaXMgb25l IG1vcmUgZGlzdGluZ3Vpc2hpbmcgaXRlbS4NCg0KUmVnYXJkbGVzcywgSSB3aWxsIGFsc28gcHV0 IGEgY2F1dGlvbmFyeSBub3RlIGluIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyB0aGF0IGlm IGlzc3VpbmcgU0VUcyB0byBhdWRpZW5jZXMgdGhhdCBhbHNvIHJlY2VpdmUgSldUcywgdGhhdCBh cHByb3ByaWF0ZSBjYXJlIGJlIHRha2VuIG5vdCB0byBjb25mdXNlIGlmIHNvbWVob3cgYSBoYWNr ZXIgaXMgYWJsZSB0byBwcmVzZW50IHRoZSBTRVQgYXMgaWYgaXQgd2VyZSBhIEpXVCB0byBnYWlu IGFjY2VzcyAoZS5nLiBpbiBhbiBhdXRob3JpemF0aW9uIGhlYWRlcikuICBOb3JtYWxseSB0aGlz IHNob3VsZCBub3QgYmUgcG9zc2libGUgYXMgSSB3b3VsZCBhc3N1bWUgU0VUcyBhcmUgcGFzc2Vk IHZpYSBzb21ldGhpbmcgbGlrZSBhbiBIVFRQIFBPU1QgYmFjay1jaGFubmVsLg0KDQpQaGlsDQoN CkBpbmRlcGVuZGVudGlkDQp3d3cuaW5kZXBlbmRlbnRpZC5jb208aHR0cDovL3d3dy5pbmRlcGVu ZGVudGlkLmNvbS8+DQpwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNs ZS5jb20+DQoNCg0KDQoNCk9uIEF1ZyAyNCwgMjAxNiwgYXQgMTozMSBQTSwgSm9obiBCcmFkbGV5 IDx2ZTdqdGJAdmU3anRiLmNvbTxtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20+PiB3cm90ZToNCg0K VGhlIGlkZWEgZm9yIGN0eSB3YXMgdG8gYWxsb3cgYSBKV1MgdG8gZW5jYXBzdWxhdGUgdGhpbmdz IGxpa2UgYSBiaW5hcnkgR0lGIGFzIGFuIGV4YW1wbGUuICAgSSB0aGluayB1c2luZyBpdCBmb3Ig RGlzdGluZ3Vpc2hpbmcgc3VidHlwZXMgb2YgSldUIHdvdWxkIGJlIGEgc3RyZXRjaC4NCg0KSSBh bSBtb3N0IGNvbWZvcnRhYmxlIHdpdGggQS4gICBJIHRoaW5rIHRoYXQgYWRkaW5nIGEgSldUIHR5 cGUgY2xhaW0gYXQgdGhlIHRvcCBsZXZlbCBtYXkgYWxzbyBiZSB1c2VmdWwgZ29pbmcgZm9yd2Fy ZCB0byBhdm9pZCBtaXNpbnRlcnByZXRhdGlvbi4NCg0KSm9obiBCLg0KT24gQXVnIDI0LCAyMDE2 LCBhdCA0OjUxIFBNLCBNYXJpdXMgU2N1cnRlc2N1IDxtc2N1cnRlc2N1QGdvb2dsZS5jb208bWFp bHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbT4+IHdyb3RlOg0KDQpPbiBXZWQsIEF1ZyAyNCwgMjAx NiBhdCAxMTowNyBBTSwgUGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhp bC5odW50QG9yYWNsZS5jb20+PiB3cm90ZToNCg0KVGhlIGF1dGhvcnMgaGF2ZSBiZWVuIGhhdmlu ZyBhIGRpc2N1c3Npb24gd2l0aCByZWdhcmRzIHRvIHVzaW5nIHRoZSDigJxzdWLigJ0gY2xhaW0g aW4gdGhlIHRvcCBsZXZlbC4gSSB0aGluayBpdCBpcyBpbXBvcnRhbnQgdG8gdHJ5IGFuZCBnZXQg dGhpcyBkaXNjdXNzaW9uIGJhY2sgdG8gdGhlIG1haW4gZ3JvdXAuIE15IGFwb2xvZ2llcyBmb3Ig dGhlIGxvbmcgbm90ZS4gSSB3YW50ZWQgdG8gZ2V0IGFsbCB0aGUgcHJvcyBhbmQgY29ucyBvbiB0 aGUgdGFibGUgKGhpbnQ6ICBwbGVhc2UgYWRkIGlmIEkgbWlzc2VkIGFueSkuLi4NCg0KQSBxdWVz dGlvbiByZW1haW5zIHNob3VsZCDigJxzdWLigJ0gYmUgdXNhYmxlIGF0IHRoZSB0b3AgbGV2ZWwu ICBUaGUgZG93bnNpZGUgb2YgdGhpcyBhcHByb2FjaCBpcyB0aGF0IGEgU0VUIGNvdWxkIHBvdGVu dGlhbGx5IGJlIHByZXNlbnRlZCBhcyBhbiBhY2Nlc3Mgb3IgaUQgdG9rZW4gYW5kIG1pZ2h0IGlu aXRpYWxseSBiZSBjb25mdXNlZCBiZWNhdXNlIGV4aXN0aW5nIGNvZGUgZG9lcyBub3Qga25vdyBp dCBuZWVkcyB0byBsb29rIGZvciBhbiDigJxldmVudHPigJ0gYXR0cmlidXRlLiAgVGhlIFNFVCBh bmQgSUQgVG9rZW4gZm9yIGFsbCBpbnRlbnNpdmUgcHVycG9zZXMgYXJlIHRoZSBzYW1lIHNpbmNl IGEgU0VUIGp1c3QgaGFzIHNvbWV0aGluZyBleHRyYSAodGhlIGV2ZW50cyBjbGFpbSkuDQoNClRo ZXJlIGlzIGFsc28gdGhlIHF1ZXN0aW9uIHRoYXQgaWYgT0lEQyBMb2dvdXQgdXNlcyBpdCBpbiB0 aGUgdG9wIGxldmVsLCBtYXkgb3RoZXIgZXZlbnRzIHVzZSBpdD8gUkZDNzUxOSBkZWZpbmVzIOKA nHN1YuKAnSBhcyBhIFN0cmluZyBvciBVUkkgdmFsdWUuIEZvciBleGFtcGxlLCBpbiBTQ0lNIGV2 ZW50cywgdGhlIOKAnHN1YuKAnSB2YWx1ZSBjb3VsZCBiZSBhIFNDSU0gUmVzb3VyY2UgVVJJIHRo YXQgaW5kaWNhdGVzIHRoZSByZXNvdXJjZSB3aG9zZSBzdGF0ZSBoYXMgY2hhbmdlZC4gIEluIE9B dXRoIGl0IGNvdWxkIGJlIGRlZmluZWQgYXMgdGhlIHRva2VuIGlkZW50aWZpZXIgb2YgdGhlIHRv a2VuIHRoYXQgaGFzIGJlZW4gcmV2b2tlZC4gIEEgU0VUIGFib3V0IGJsYWNrbGlzdGluZyBhbiBJ UCBhZGRyZXNzIG1pZ2h0IHB1dCB0aGUgSVAgYWRkcmVzcyBpbiBzdWIuDQoNClNvIHRoZXJlIGFy ZSB0aHJlZSBvcHRpb25zIChPcHRpb24gQSBzZWVtcyB0byBiZSBmYXZvdXJlZCBzbyBmYXIpOg0K DQpBLiAgU3ViIGF0IFRvcCBMZXZlbDogIOKAnHN1YuKAnSBnZW5lcmFsbHkgdXNlZCB0byByZWZl cmVuY2UgdGhlIFNlY3VyaXR5IFN1YmplY3QgdGhlIFNFVCBpcyB0YWxraW5nIGFib3V0LiAgSXQg dXNlcyBhIG1vcmUgZ2VuZXJhbCBlbmdsaXNoIGxhbmd1YWdlIGludGVudCBvZiBzdWJqZWN0IHJh dGhlciB0aGFuIHRoZSB0cmFkaXRpb25hbCB1c2UgYXMgc2VlbiBpbiBTQU1MIG9yIE9wZW5JRCBD b25uZWN0LiAgUmVnYXJkbGVzcyBpdCBpcyBzdGlsbCBjb21wbGlhbnQgd2l0aCBSRkM3NTE5IChh IFN0cmluZyBvciBVUkkpLg0KDQpUaGlzIHdvdWxkIHRlbmQgdG8gbGVhZCB0byBhIHN0eWxlIG9m IFNFVHMgd2hlcmUgdGhlIGVudmVsb3BlIGNhcnJpZXMgdGhlIHZhbGlkYXRpb24gaW5mb3JtYXRp b24sIHRoZSB0eXBlIG9mIGV2ZW50LCBhbmQgdGhlIHN1YmplY3Qgb2YgdGhlIGV2ZW50LiBBZGRp dGlvbmFsIGRhdGEgZ29lcyBpbiB0aGUgcGF5bG9hZC4gQW4gYWR2YW50YWdlIG9mIHRoaXMgc3R5 bGUsIGlzIHRoYXQgZm9yIG1hbnkgZXZlbnRzLCB0aGUgb25seSB0aGluZyBuZWVkZWQgaXMgdGhl IGV2ZW50IHR5cGUgYW5kIHRoZSBzdWJqZWN0LiAgTm8gcGF5bG9hZHMgd291bGQgYmUgbmVlZGVk Lg0KDQpGb3IgZXZlbnRzIHRoYXQgZG9u4oCZdCB3YW50IHBheWxvYWQsIGl0IGlzIHByb2JhYmx5 IG9rIGZvciBwcm9maWxpbmcgZXZlbnQgc3RhbmRhcmRzIHRvIGRlZmluZSBtb3JlIGNsYWltcyBh dCB0aGUgdG9wIGxldmVsLiBUaGV5IE1VU1QgYmUgcmVnaXN0ZXJlZCBpbiB0aGUgSldUIHJlZ2lz dHJ5LiBQcm9maWxpbmcgZXZlbnRzIGNhbiBhdm9pZCByZWdpc3RyYXRpb24gYnkganVzdCBwdXR0 aW5nIHRoZWlyIGF0dHJpYnV0ZXMvY2xhaW1zIGluIHRoZSBwYXlsb2FkIGFyZWEgYXMgZGVzY3Jp YmVkIGluIHRoZSBzcGVjLiAgSG93ZXZlciwgdGhpcyB3b3VsZCBiZSBpbmNvbnNpc3RlbnQgd2l0 aCB0aG9zZSB0aGF0IHVzZSBwYXlsb2FkcyB3aXRoIHVucmVnaXN0ZXJlZCBjbGFpbXMuICBJIHBv aW50IG91dCB0aGF0IHdlIHN3aXRjaGVkIGZyb20gcmVnaXN0ZXJlZCBldmVudCBVUk5zIHRvIFVS SXMgdG8gYXZvaWQgcmVnaXN0cmF0aW9uLiAgSGVuY2UgdGhlIG1vdmUgdG8gcGF5bG9hZCBvYmpl Y3RzIHRvIGVsaW1pbmF0ZSByZWdpc3RyYXRpb24gZm9yIGF0dHJpYnV0ZXMvY2xhaW1zLg0KDQpU aGlzIHN0aWxsIGhhcyB0aGUgbmVnYXRpdmVzIG9mIGJlaW5nIGNvbmZ1c2FibGUgYXMgYW4gSUQg VG9rZW4gYnkgZXhpc3RpbmcgY29kZS4gVGhlcmUgaGFzIGJlZW4gYSBkaXNjdXNzaW9uIHRoYXQg 4oCcaXNz4oCdIGFuZC9vciDigJxhdWTigJ0gc2hvdWxkIGFjdHVhbGx5IGJlIGRpZmZlcmVudCBh bmQgdGhlIHJlY2VpdmVyIHNob3VsZCBkZXRlY3QgdGhhdC4gIEhvd2V2ZXIgaW4gdGhlIE9JREMg TG9nb3V0IGNhc2UsIGJ5IGRlc2lnbiwgdGhlIOKAnGlzc+KAnSB2YWx1ZSB3b3VsZCBiZSB0aGUg c2FtZS4gIFRoZSDigJxhdWTigJ0gd291bGQgYWxzbyBsaWtlbHkgYmUgdGhlIHNhbWUgdW5sZXNz IHRoZSBzcGVjIGluZGljYXRlcyB0aGF0IGFuIGFsaWFzIOKAnGF1ZOKAnSBiZSB1c2VkIGV2ZW4g dGhvdWdoIHRoZSBhdWRpZW5jZSBtYXkgYmUgdGhlIHNhbWUgZW50aXR5IGluIGJvdGggY2FzZXMu DQoNCkIuIEV4Y2x1c2l2ZS1Vc2Ugb2YgU3ViOiDigJxzdWLigJ0gaXMgaW50ZXJwcmV0ZWQgdG8g YnkgdHJhZGl0aW9uYWwgZGVmaW5pdGlvbiBhbmQgaXMgcmVzZXJ2ZWQgZm9yIE9BdXRoIHRva2Vu cyBhbmQgT0lEQyBDb25uZWN0IHVzYWdlIG9ubHkuICBJbiBvcmRlciB0byAgYXZvaWQgY29uZnVz aW5nLCBhbGwgcHJvZmlsaW5nIGV2ZW50IHNwZWNzIHNob3VsZCBOT1QgdXNlIOKAnHN1YuKAnSBp biB0aGUgdG9wIGxldmVsIGV4Y2VwdCBmb3IgT0lEQy4NCg0KVGhpcyBoYXMgdGhlIGRpc2FkdmFu dGFnZSB0aGF0IE9JREMgcmVxdWlyZXMgc3BlY2lhbCBoYW5kbGluZyBpbiB0ZXJtcyBvZiBhIGdl bmVyYWwgdXNlIGV2ZW50IGxpYnJhcnksIGJ1dCBvbiB0aGUgb3RoZXIgaGFuZCBhIExvZ291dCBF dmVudCBtaWdodCBiZSBoYW5kbGVkIGRpcmVjdGx5IGJ5IGV4aXN0aW5nIElEIFRva2VuIGNvZGUu DQoNClRoaXMgc3RpbGwgaGFzIHRoZSBkaXNhZHZhbnRhZ2UgdGhhdCBhbiBTRVQgY291bGQgYmUg Y29uZnVzZWQgZm9yIGFuIElEIFRva2VuLg0KDQpDLiBOby1Ub3AtTGV2ZWwgRGF0YTogSW4gb3Jk ZXIgdG8gbW9yZSBhZ2dyZXNzaXZlbHkgYXZvaWQgY29uZnVzaW9uIG9mIFNFVHMgYXMgSUQgVG9r ZW5zLCBtYWtlIGl0IG1hbmRhdG9yeSB0aGF0IFNFVHMgbWF5IG5vdCBjb250YWluIGEg4oCcc3Vi 4oCdIHZhbHVlIGF0IHRoZSB0b3AgbGV2ZWwuICBUaGUgT0lEQyBMb2dvdXQgRXZlbnQsIGZvciBl eGFtcGxlLCB3b3VsZCB0aGVuIGluY2x1ZGUgYSDigJxzdWLigJ0gdmFsdWUgaW4gdGhlIHBheWxv YWQgYXJlYS4gVGhpcyBzaG91bGQgY2F1c2UgZXhpc3RpbmcgcmVseWluZyBwYXJ0aWVzIHRvIGZh aWwgY29ycmVjdGx5Lg0KDQpUaGlzIHdvdWxkIHByb3ZpZGUgYSBtYXhpbWFsIGRpZmZlcmVuY2Ug Zm9ybSBhIElEVG9rZW4gb3IgYWNjZXNzIHRva2VuLg0KDQpUaGlzIHdvdWxkIGhhdmUgdGhlIGFk dmFudGFnZSB0aGF0IGVudmVsb3BlcyBjb250YWluIG5vIGRhdGEsIGFuZCB0aGF0IGV2ZXJ5IFNF VCBoYXMgYSBwYXlsb2FkIHdoZXJlIHRoZSBkYXRhIGlzIGZvdW5kLiBJdCByZXF1aXJlcyBtb3Jl IHBhcnNpbmcgaW4gc29tZSBjYXNlcywgYnV0IGl0IGlzIGF0IGxlYXN0IGNvbnNpc3RlbnQuIFdo aWxlIHdlIGRvbuKAmXQgZXhwZWN0IGdlbmVyYWwgcHJvY2Vzc29ycyBsaWtlIGluIFNPQVAgZm9y IGRpc3RyaWJ1dGlvbiAobXVjaCBvZiBpdCBpcyBwb2ludCB0byBwb2ludCBhbmQgdmVyeSBjb250 ZXh0dWFsbHkgZHJpdmVuKSwgSSBwZXJzb25hbGx5IGV4cGVjdCB0byBzZWU6DQogICogIERldmVs b3BtZW50IG9mIGdlbmVyYWwgcHVycG9zZSBsaWJyYXJpZXMgYW5kIHRvb2xzIHRoYXQgYXJlIHVz ZWQgZW5oYW5jZSBwcm90b2NvbHMgYW5kIHN5c3RlbXMNCiAgKiAgQXVkaXQgYW5kIHRocmVhdCBh bmFseXNpcyBzeXN0ZW1zIHdpbGwgYmUgbG9va2luZyBhdCBzb21lIGV2ZW50cyBoaXN0b3JpY2Fs bHkuIFRoZXNlIHdpbGwgdGVuZCB0byBtZXJnZSBtdWx0aXBsZSBldmVudCBmZWVkcy4NCg0KTWlr ZSBKb25lcyBhbHNvIHN1Z2dlc3RlZCB1c2luZyB0aGUg4oCcY3R54oCdIChjb250ZW50IHR5cGUp IGhlYWRlciBhdHRyaWJ1dGUgZnJvbSBKV1QuICBJIHRoaW5rIG1vc3QgY29kZSB0b2RheSBoYXMg dGhpcyBzZXQgdG8gaWdub3JlIG9yIGZpeGVkIGFzIOKAnEpXVOKAnS4gIEkgd29uZGVyIHdoYXQg Y3VycmVudCBpbXBsZW1lbnRzIHdvdWxkIGZlZWwgaWYgd2UgaW50cm9kdWNlZCBhIOKAnGN0eeKA nSB2YWx1ZSBvZiDigJxTRVTigJ0/ICBXb3VsZCB0aGF0IGhlbHA/DQoNCkkgdGhpbmsgaXQgaXMg dmVyeSBpbXBvcnRhbnQgdG8gYmUgYWJsZSB0byBjbGVhcmx5IGRpc3Rpbmd1aXNoIGRpZmZlcmVu dCB0eXBlcyBvZiBKV1QgdG9rZW5zLiBGb3IgZXhhbXBsZSwgbm90IGJlaW5nIGFibGUgdG8gY3Jv c3MgcG9zdCBhIFNlY3VyaXR5IEV2ZW50IFRva2VuIGFzIGFuIElkIFRva2VuLg0KDQpSZWFkaW5n IFJGQyA3NTE5IEkgZG9uJ3QgdGhpbmsgY3R5IGZpdHMgdGhlIGJpbGwsIGJ1dCBJIGNvdWxkIGJl IHdyb25nLiBjdHkgaXMgYSBoZWFkZXIgcGFyYW1ldGVyIHVzZWQgYnkgdGhlIGNyeXB0byBhbGdv cml0aG0gYW5kIHRoZSBkZWZhdWx0IHZhbHVlIGlzIEpXVC4gV2UgbmVlZCB0byBkaXN0aW5ndWlz aCBzdWItdHlwZXMgb2YgSldULCBhbmQgaXQgc2hvdWxkIGJlIGEgY2xhaW0gaW5zaWRlIHRoZSBK V1QuDQoNCldpdGggdGhlIGFib3ZlIGlzc3VlIGluIG1pbmQsIEkgdGhpbmsgb3B0aW9uIEEgaXMg dGhlIGNsZWFuZXN0IHNvbHV0aW9uLg0KDQoNCg0KVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLg0K DQoNClBoaWwNCg0KQGluZGVwZW5kZW50aWQNCnd3dy5pbmRlcGVuZGVudGlkLmNvbTxodHRwOi8v d3d3LmluZGVwZW5kZW50aWQuY29tLz4NCnBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGls Lmh1bnRAb3JhY2xlLmNvbT4NCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KSWQtZXZlbnQgbWFpbGluZyBsaXN0DQpJZC1ldmVudEBpZXRm Lm9yZzxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2lkLWV2ZW50DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpJZC1ldmVudCBtYWlsaW5nIGxpc3QNCklkLWV2ZW50QGlldGYub3Jn PG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vaWQtZXZlbnQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCklkLWV2ZW50IG1haWxpbmcgbGlzdA0KSWQtZXZlbnRAaWV0Zi5vcmc8bWFp bHRvOklkLWV2ZW50QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9pZC1ldmVudA0KDQoNCg== --_000_SN1PR0301MB1645223021A8FC4C0ECC8D7CF5EA0SN1PR0301MB1645_ 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 Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHls ZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmln aHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlm O30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJl Zm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uYXBw bGUtc3R5bGUtc3Bhbg0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1zdHlsZS1zcGFuO30NCnNwYW4u YXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1z cGFjZTt9DQpzcGFuLmdtYWlsLW0xNzE2NzM0MDEyODI2MDE5MzM2YXBwbGUtc3R5bGUtc3Bhbg0K CXttc28tc3R5bGUtbmFtZTpnbWFpbC1tXzE3MTY3MzQwMTI4MjYwMTkzMzZhcHBsZS1zdHlsZS1z cGFuO30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXpl OjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFy Z2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5BIHNwZWMgY291bGQgY3Jl YXRlIGEgdG9wLWxldmVsIEpXVCB0eXBlIGNsYWltLCBidXQgSeKAmWQgYXNzZXJ0IHRoYXQgaXTi gJlzIG91dCBvZiBzY29wZSBmb3IgdGhlIEV2ZW50cyBzcGVjLiZuYnNwOyBJdCB3b3VsZCBwcm9i YWJseSBuZWVkIHRvIGJlIGl0cyBvd24gc3BlYyBhbmQgc2F5DQogYmFzaWNhbGx5IOKAnHVzZSBp dCBpZiB5b3XigJlyZSBpbiB1c2UgY2FzZXMgaW4gd2hpY2ggaXTigJlzIHVzZWZ1bCB0byBkaXN0 aW5ndWlzaCBiZXR3ZWVuIHRoaW5nc+KAnS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHNwYW4gc3R5 bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjwvc3Bhbj4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzoz LjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBJZC1ldmVudCBbbWFpbHRvOmlk LWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkpvaG4gQnJhZGxl eTxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEF1Z3VzdCAyNCwgMjAxNiAyOjI0IFBNPGJy Pg0KPGI+VG86PC9iPiBQaGlsIEh1bnQgJmx0O3BoaWwuaHVudEBvcmFjbGUuY29tJmd0Ozxicj4N CjxiPkNjOjwvYj4gaWQtZXZlbnRAaWV0Zi5vcmc7IE1hcml1cyBTY3VydGVzY3UgJmx0O21zY3Vy dGVzY3VAZ29vZ2xlLmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtJZC1ldmVudF0g RGlzY3Vzc2lvbiBvbiB1c2Ugb2YgJnF1b3Q7c3ViJnF1b3Q7IGFuZCBjb25mdXNpb24gYXMgSUQg VG9rZW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHdh cyBzYXlpbmcgdGhhdCBjdHkgd2FzIHdyb25nIGZvciB0aGlzLiAmbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHlvdSBsb29rIGF0IHRoZSBkZWZp bml0aW9uIG9mIHR5cCBpbiBKV1MmbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvcmZjNzUxNSNwYWdlLTEzIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzUx NSNwYWdlLTEzPC9hPiZuYnNwOyB5b3UgY2FuIHNlZSB0aGF0IGl0IGlzIHJlYWxseSBpbnRlbmRl ZCB0byBiZSB0aGUgbWVkaWEgdHlwZSBvZiB0aGUgY29tcGxldGUgSldTL0pXRSBhbmQgaXMNCiBv bWl0dGVkIG9yIHNldCB0byBKV1QgaWYgaXQgaXMgYSBjb21wYWN0IEpXVC4gJm5ic3A7ICZuYnNw OyBTZXR0aW5nIGl0IHRvIFNFVCBzZWVtcyB3cm9uZyBhcyBpdCBpcyBzdGlsbCBhIEpXVC4gJm5i c3A7IEkgd2FzIHJlY29tbWVuZGluZyBjb25zaWRlcmluZyBhIEpXVCB0b3AgbGV2ZWwgY2xhaW0g aW4gdGhlIEpXVCByZWdpc3RyeS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Sm9obiBCLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gQXVnIDI0LCAyMDE2LCBhdCA1OjU5IFBNLCBQaGlsIEh1bnQg Jmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSI+cGhpbC5odW50QG9yYWNs ZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkpvaG4sPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5EaWQgeW91IG1lYW4gYWRkaW5nIGEg4oCcand0X3R5cGXigJ0gYXR0cmlidXRlICh0aGF0 IGJlY29tZXMgYSByZWdpc3RlcmVkIEpXVCBjbGFpbSkgT1IgYWRkaW5nIGEgbmV3IHR5cGUgdmFs dWUgZm9yIHRoZSBKV1QgaGVhZGVyIOKAnHR5cOKAnT8gJm5ic3A7Tm90ZSBmb3IgZXZlcnlvbmXi gJlzIGNvbnZlbmllbmNlIGZyb20gNzUxOTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj5UaGUgJnF1b3Q7dHlwJnF1 b3Q7ICh0eXBlKSBIZWFkZXIgUGFyYW1ldGVyIGRlZmluZWQgYnkgWzxhIGhyZWY9Imh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NTE5I3JlZi1KV1MiIHRpdGxlPSImcXVvdDtKU09OIFdl YiBTaWduYXR1cmUgKEpXUykmcXVvdDsiPkpXUzwvYT5dIGFuZCBbPGEgaHJlZj0iaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL3JmYzc1MTkjcmVmLUpXRSIgdGl0bGU9IiZxdW90O0pTT04gV2Vi IEVuY3J5cHRpb24gKEpXRSkmcXVvdDsiPkpXRTwvYT5dIGlzIHVzZWQ8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj4mbmJzcDsmbmJzcDsgYnkg SldUIGFwcGxpY2F0aW9ucyB0byBkZWNsYXJlIHRoZSBtZWRpYSB0eXBlIFs8YSBocmVmPSJodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzUxOSNyZWYtSUFOQS5NZWRpYVR5cGVzIj5JQU5B Lk1lZGlhVHlwZXM8L2E+XSBvZjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJy ZWFrLWJlZm9yZTphbHdheXMiPiZuYnNwOyZuYnNwOyB0aGlzIGNvbXBsZXRlIEpXVC4mbmJzcDsg VGhpcyBpcyBpbnRlbmRlZCBmb3IgdXNlIGJ5IHRoZSBKV1QgYXBwbGljYXRpb248bzpwPjwvbzpw PjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj4mbmJzcDsmbmJz cDsgd2hlbiB2YWx1ZXMgdGhhdCBhcmUgbm90IEpXVHMgY291bGQgYWxzbyBiZSBwcmVzZW50IGlu IGFuIGFwcGxpY2F0aW9uPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWst YmVmb3JlOmFsd2F5cyI+Jm5ic3A7Jm5ic3A7IGRhdGEgc3RydWN0dXJlIHRoYXQgY2FuIGNvbnRh aW4gYSBKV1Qgb2JqZWN0OyB0aGUgYXBwbGljYXRpb24gY2FuIHVzZTxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPiZuYnNwOyZuYnNwOyB0aGlz IHZhbHVlIHRvIGRpc2FtYmlndWF0ZSBhbW9uZyB0aGUgZGlmZmVyZW50IGtpbmRzIG9mIG9iamVj dHMgdGhhdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTph bHdheXMiPiZuYnNwOyZuYnNwOyBtaWdodCBiZSBwcmVzZW50LiZuYnNwOyBJdCB3aWxsIHR5cGlj YWxseSBub3QgYmUgdXNlZCBieSBhcHBsaWNhdGlvbnMgd2hlbjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPiZuYnNwOyZuYnNwOyBpdCBpcyBh bHJlYWR5IGtub3duIHRoYXQgdGhlIG9iamVjdCBpcyBhIEpXVC4mbmJzcDsgVGhpcyBwYXJhbWV0 ZXIgaXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3 YXlzIj4mbmJzcDsmbmJzcDsgaWdub3JlZCBieSBKV1QgaW1wbGVtZW50YXRpb25zOyBhbnkgcHJv Y2Vzc2luZyBvZiB0aGlzIHBhcmFtZXRlciBpczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxl PSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPiZuYnNwOyZuYnNwOyBwZXJmb3JtZWQgYnkgdGhl IEpXVCBhcHBsaWNhdGlvbi4mbmJzcDsgSWYgcHJlc2VudCwgaXQgaXMgUkVDT01NRU5ERUQgdGhh dDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMi PiZuYnNwOyZuYnNwOyBpdHMgdmFsdWUgYmUgJnF1b3Q7SldUJnF1b3Q7IHRvIGluZGljYXRlIHRo YXQgdGhpcyBvYmplY3QgaXMgYSBKV1QuJm5ic3A7IFdoaWxlPG86cD48L286cD48L3ByZT4NCjxw cmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+Jm5ic3A7Jm5ic3A7IG1lZGlhIHR5 cGUgbmFtZXMgYXJlIG5vdCBjYXNlIHNlbnNpdGl2ZSwgaXQgaXMgUkVDT01NRU5ERUQgdGhhdCAm cXVvdDtKV1QmcXVvdDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1i ZWZvcmU6YWx3YXlzIj4mbmJzcDsmbmJzcDsgYWx3YXlzIGJlIHNwZWxsZWQgdXNpbmcgdXBwZXJj YXNlIGNoYXJhY3RlcnMgZm9yIGNvbXBhdGliaWxpdHkgd2l0aDxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPiZuYnNwOyZuYnNwOyBsZWdhY3kg aW1wbGVtZW50YXRpb25zLiZuYnNwOyBVc2Ugb2YgdGhpcyBIZWFkZXIgUGFyYW1ldGVyIGlzIE9Q VElPTkFMLjxvOnA+PC9vOnA+PC9wcmU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+V2hhdCBpcyBjb25jZXJuaW5nIGlzIHRoZSBsaW5lIHRoYXQgc2F5czombmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVm b3JlOmFsd2F5cyI+SXQgd2lsbCB0eXBpY2FsbHkgbm90IGJlIHVzZWQgYnkgYXBwbGljYXRpb25z IHdoZW48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3 YXlzIj4mbmJzcDsmbmJzcDsgaXQgaXMgYWxyZWFkeSBrbm93biB0aGF0IHRoZSBvYmplY3QgaXMg YSBKV1QuJm5ic3A7IDxiPjx1PlRoaXMgcGFyYW1ldGVyIGlzPG86cD48L286cD48L3U+PC9iPjwv cHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48Yj48dT4mbmJzcDsm bmJzcDsgaWdub3JlZCBieSBKV1QgaW1wbGVtZW50YXRpb25zPC91PjwvYj47IGFueSBwcm9jZXNz aW5nIG9mIHRoaXMgcGFyYW1ldGVyIGlzPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9InBh Z2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+Jm5ic3A7Jm5ic3A7IHBlcmZvcm1lZCBieSB0aGUgSldU IGFwcGxpY2F0aW9uLiZuYnNwOyBJZiBwcmVzZW50LCBpdCBpcyBSRUNPTU1FTkRFRCB0aGF0PG86 cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+Jm5i c3A7Jm5ic3A7IGl0cyB2YWx1ZSBiZSAmcXVvdDtKV1QmcXVvdDsgdG8gaW5kaWNhdGUgdGhhdCB0 aGlzIG9iamVjdCBpcyBhIEpXVC48bzpwPjwvbzpwPjwvcHJlPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SWYgaXQgaXMgdHlwaWNhbGx5IGlnbm9yZWQsIHRoZW4gaGF2aW5nIGl0IOKA nHR5cOKAnSBiZSDigJxTRVTigJ0gbWF5IG5vdCBoZWxwIG11Y2ggaW5pdGlhbGx5LiBCdXQgYXQg bGVhc3QgaXQgaXMgbW9yZSBkZWZpbml0aXZlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB0aGUgZ3JvdXAgaXMgY29tZm9ydGFibGUsIEkg YW0gb2sgd2l0aCBtYWtpbmcg4oCcdHlw4oCdIGJlIOKAnFNFVOKAnS4gJm5ic3A7SXQgaXMgb25l IG1vcmUgZGlzdGluZ3Vpc2hpbmcgaXRlbS4gJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZGxlc3MsIEkgd2lsbCBhbHNvIHB1 dCBhIGNhdXRpb25hcnkgbm90ZSBpbiB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgdGhhdCBp ZiBpc3N1aW5nIFNFVHMgdG8gYXVkaWVuY2VzIHRoYXQgYWxzbyByZWNlaXZlIEpXVHMsIHRoYXQg YXBwcm9wcmlhdGUgY2FyZSBiZSB0YWtlbiBub3QgdG8gY29uZnVzZSBpZiBzb21laG93IGEgaGFj a2VyIGlzIGFibGUgdG8gcHJlc2VudCB0aGUgU0VUIGFzIGlmIGl0DQogd2VyZSBhIEpXVCB0byBn YWluIGFjY2VzcyAoZS5nLiBpbiBhbiBhdXRob3JpemF0aW9uIGhlYWRlcikuICZuYnNwO05vcm1h bGx5IHRoaXMgc2hvdWxkIG5vdCBiZSBwb3NzaWJsZSBhcyBJIHdvdWxkIGFzc3VtZSBTRVRzIGFy ZSBwYXNzZWQgdmlhIHNvbWV0aGluZyBsaWtlIGFuIEhUVFAgUE9TVCBiYWNrLWNoYW5uZWwuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QaGlsPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkBpbmRlcGVuZGVu dGlkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 YSBocmVmPSJodHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tLyI+d3d3LmluZGVwZW5kZW50aWQu Y29tPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20i PnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEF1ZyAyNCwg MjAxNiwgYXQgMTozMSBQTSwgSm9obiBCcmFkbGV5ICZsdDs8YSBocmVmPSJtYWlsdG86dmU3anRi QHZlN2p0Yi5jb20iPnZlN2p0YkB2ZTdqdGIuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgaWRlYSBmb3IgY3R5IHdhcyB0 byBhbGxvdyBhIEpXUyB0byBlbmNhcHN1bGF0ZSB0aGluZ3MgbGlrZSBhIGJpbmFyeSBHSUYgYXMg YW4gZXhhbXBsZS4gJm5ic3A7IEkgdGhpbmsgdXNpbmcgaXQgZm9yIERpc3Rpbmd1aXNoaW5nIHN1 YnR5cGVzIG9mIEpXVCB3b3VsZCBiZSBhIHN0cmV0Y2guPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFtIG1vc3QgY29tZm9ydGFibGUgd2l0aCBBLiAmbmJz cDsgSSB0aGluayB0aGF0IGFkZGluZyBhIEpXVCB0eXBlIGNsYWltIGF0IHRoZSB0b3AgbGV2ZWwg bWF5IGFsc28gYmUgdXNlZnVsIGdvaW5nIGZvcndhcmQgdG8gYXZvaWQgbWlzaW50ZXJwcmV0YXRp b24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkpvaG4gQi48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiBBdWcgMjQsIDIwMTYsIGF0IDQ6NTEgUE0sIE1hcml1cyBTY3VydGVzY3UgJmx0Ozxh IGhyZWY9Im1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb20iPm1zY3VydGVzY3VAZ29vZ2xlLmNv bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5PbiBXZWQsIEF1ZyAyNCwgMjAx NiBhdCAxMTowNyBBTSwgUGhpbCBIdW50PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPiZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20i IHRhcmdldD0iX2JsYW5rIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT4mZ3Q7PHNwYW4gY2xhc3M9 ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPndyb3RlOjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZSBhdXRob3Jz IGhhdmUgYmVlbiBoYXZpbmcgYSBkaXNjdXNzaW9uIHdpdGggcmVnYXJkcyB0byB1c2luZyB0aGUg 4oCcc3Vi4oCdIGNsYWltIGluIHRoZSB0b3AgbGV2ZWwuIEkgdGhpbmsgaXQgaXMgaW1wb3J0YW50 IHRvIHRyeSBhbmQgZ2V0IHRoaXMgZGlzY3Vzc2lvbiBiYWNrIHRvIHRoZSBtYWluIGdyb3VwLg0K IE15IGFwb2xvZ2llcyBmb3IgdGhlIGxvbmcgbm90ZS4gSSB3YW50ZWQgdG8gZ2V0IGFsbCB0aGUg cHJvcyBhbmQgY29ucyBvbiB0aGUgdGFibGUgKGhpbnQ6ICZuYnNwO3BsZWFzZSBhZGQgaWYgSSBt aXNzZWQgYW55KS4uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWYiPkEgcXVlc3Rpb24gcmVtYWlucyBzaG91bGQg4oCcc3Vi4oCdIGJlIHVzYWJsZSBhdCB0aGUg dG9wIGxldmVsLiZuYnNwOyBUaGUgZG93bnNpZGUgb2YgdGhpcyBhcHByb2FjaCBpcyB0aGF0IGEg U0VUIGNvdWxkIHBvdGVudGlhbGx5IGJlIHByZXNlbnRlZCBhcyBhbiBhY2Nlc3Mgb3IgaUQgdG9r ZW4gYW5kIG1pZ2h0DQogaW5pdGlhbGx5IGJlIGNvbmZ1c2VkIGJlY2F1c2UgZXhpc3RpbmcgY29k ZSBkb2VzIG5vdCBrbm93IGl0IG5lZWRzIHRvIGxvb2sgZm9yIGFuIOKAnGV2ZW50c+KAnSBhdHRy aWJ1dGUuJm5ic3A7IFRoZSBTRVQgYW5kIElEIFRva2VuIGZvciBhbGwgaW50ZW5zaXZlIHB1cnBv c2VzIGFyZSB0aGUgc2FtZSBzaW5jZSBhIFNFVCBqdXN0IGhhcyBzb21ldGhpbmcgZXh0cmEgKHRo ZSBldmVudHMgY2xhaW0pLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPlRoZXJlIGlzIGFsc28gdGhlIHF1ZXN0aW9uIHRoYXQgaWYgT0lEQyBMb2dvdXQgdXNl cyBpdCBpbiB0aGUgdG9wIGxldmVsLCBtYXkgb3RoZXIgZXZlbnRzIHVzZSBpdD8gUkZDNzUxOSBk ZWZpbmVzIOKAnHN1YuKAnSBhcyBhIFN0cmluZyBvciBVUkkgdmFsdWUuIEZvciBleGFtcGxlLCBp biBTQ0lNIGV2ZW50cywNCiB0aGUg4oCcc3Vi4oCdIHZhbHVlIGNvdWxkIGJlIGEgU0NJTSBSZXNv dXJjZSBVUkkgdGhhdCBpbmRpY2F0ZXMgdGhlIHJlc291cmNlIHdob3NlIHN0YXRlIGhhcyBjaGFu Z2VkLiZuYnNwOyBJbiBPQXV0aCBpdCBjb3VsZCBiZSBkZWZpbmVkIGFzIHRoZSB0b2tlbiBpZGVu dGlmaWVyIG9mIHRoZSB0b2tlbiB0aGF0IGhhcyBiZWVuIHJldm9rZWQuJm5ic3A7IEEgU0VUIGFi b3V0IGJsYWNrbGlzdGluZyBhbiBJUCBhZGRyZXNzIG1pZ2h0IHB1dCB0aGUgSVAgYWRkcmVzcyBp bg0KIHN1Yi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5T byB0aGVyZSBhcmUgdGhyZWUgb3B0aW9ucyAoT3B0aW9uIEEgc2VlbXMgdG8gYmUgZmF2b3VyZWQg c28gZmFyKTogJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+QS4mbmJzcDsgU3ViIGF0IFRvcCBMZXZlbDo8L3NwYW4+PC9iPjxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A74oCcc3Vi4oCdDQogZ2VuZXJhbGx5IHVzZWQg dG8gcmVmZXJlbmNlIHRoZSBTZWN1cml0eSBTdWJqZWN0IHRoZSBTRVQgaXMgdGFsa2luZyBhYm91 dC4mbmJzcDsgSXQgdXNlcyBhIG1vcmUgZ2VuZXJhbCBlbmdsaXNoIGxhbmd1YWdlIGludGVudCBv ZiBzdWJqZWN0IHJhdGhlciB0aGFuIHRoZSB0cmFkaXRpb25hbCB1c2UgYXMgc2VlbiBpbiBTQU1M IG9yIE9wZW5JRCBDb25uZWN0LiZuYnNwOyBSZWdhcmRsZXNzIGl0IGlzIHN0aWxsIGNvbXBsaWFu dCB3aXRoIFJGQzc1MTkgKGEgU3RyaW5nDQogb3IgVVJJKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5UaGlzIHdvdWxkIHRlbmQgdG8gbGVhZCB0byBhIHN0 eWxlIG9mIFNFVHMgd2hlcmUgdGhlIGVudmVsb3BlIGNhcnJpZXMgdGhlIHZhbGlkYXRpb24gaW5m b3JtYXRpb24sIHRoZSB0eXBlIG9mIGV2ZW50LCBhbmQgdGhlIHN1YmplY3Qgb2YgdGhlIGV2ZW50 LiBBZGRpdGlvbmFsIGRhdGEgZ29lcyBpbg0KIHRoZSBwYXlsb2FkLiBBbiBhZHZhbnRhZ2Ugb2Yg dGhpcyBzdHlsZSwgaXMgdGhhdCBmb3IgbWFueSBldmVudHMsIHRoZSBvbmx5IHRoaW5nIG5lZWRl ZCBpcyB0aGUgZXZlbnQgdHlwZSBhbmQgdGhlIHN1YmplY3QuJm5ic3A7IE5vIHBheWxvYWRzIHdv dWxkIGJlIG5lZWRlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+Rm9yIGV2ZW50cyB0aGF0IGRvbuKAmXQgd2FudCBwYXlsb2FkLCBpdCBpcyBw cm9iYWJseSBvayBmb3IgcHJvZmlsaW5nIGV2ZW50IHN0YW5kYXJkcyB0byBkZWZpbmUgbW9yZSBj bGFpbXMgYXQgdGhlIHRvcCBsZXZlbC4gVGhleSBNVVNUIGJlIHJlZ2lzdGVyZWQgaW4gdGhlIEpX VCByZWdpc3RyeS4gUHJvZmlsaW5nDQogZXZlbnRzIGNhbiBhdm9pZCByZWdpc3RyYXRpb24gYnkg anVzdCBwdXR0aW5nIHRoZWlyIGF0dHJpYnV0ZXMvY2xhaW1zIGluIHRoZSBwYXlsb2FkIGFyZWEg YXMgZGVzY3JpYmVkIGluIHRoZSBzcGVjLiZuYnNwOyBIb3dldmVyLCB0aGlzIHdvdWxkIGJlIGlu Y29uc2lzdGVudCB3aXRoIHRob3NlIHRoYXQgdXNlIHBheWxvYWRzIHdpdGggdW5yZWdpc3RlcmVk IGNsYWltcy4mbmJzcDsgSSBwb2ludCBvdXQgdGhhdCB3ZSBzd2l0Y2hlZCBmcm9tIHJlZ2lzdGVy ZWQgZXZlbnQNCiBVUk5zIHRvIFVSSXMgdG8gYXZvaWQgcmVnaXN0cmF0aW9uLiZuYnNwOyBIZW5j ZSB0aGUgbW92ZSB0byBwYXlsb2FkIG9iamVjdHMgdG8gZWxpbWluYXRlIHJlZ2lzdHJhdGlvbiBm b3IgYXR0cmlidXRlcy9jbGFpbXMuICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VGhpcyBzdGlsbCBoYXMgdGhlIG5lZ2F0aXZlcyBv ZiBiZWluZyBjb25mdXNhYmxlIGFzIGFuIElEIFRva2VuIGJ5IGV4aXN0aW5nIGNvZGUuIFRoZXJl IGhhcyBiZWVuIGEgZGlzY3Vzc2lvbiB0aGF0IOKAnGlzc+KAnSBhbmQvb3Ig4oCcYXVk4oCdIHNo b3VsZCBhY3R1YWxseSBiZSBkaWZmZXJlbnQgYW5kIHRoZQ0KIHJlY2VpdmVyIHNob3VsZCBkZXRl Y3QgdGhhdC4mbmJzcDsgSG93ZXZlciBpbiB0aGUgT0lEQyBMb2dvdXQgY2FzZSwgYnkgZGVzaWdu LCB0aGUg4oCcaXNz4oCdIHZhbHVlIHdvdWxkIGJlIHRoZSBzYW1lLiZuYnNwOyBUaGUg4oCcYXVk 4oCdIHdvdWxkIGFsc28gbGlrZWx5IGJlIHRoZSBzYW1lIHVubGVzcyB0aGUgc3BlYyBpbmRpY2F0 ZXMgdGhhdCBhbiBhbGlhcyDigJxhdWTigJ0gYmUgdXNlZCBldmVuIHRob3VnaCB0aGUgYXVkaWVu Y2UgbWF5IGJlIHRoZSBzYW1lIGVudGl0eSBpbiBib3RoDQogY2FzZXMuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Qi4gRXhjbHVzaXZlLVVzZSBvZiBT dWI6PC9zcGFuPjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPuKAnHN1YuKA nQ0KIGlzIGludGVycHJldGVkIHRvIGJ5IHRyYWRpdGlvbmFsIGRlZmluaXRpb24gYW5kIGlzIHJl c2VydmVkIGZvciBPQXV0aCB0b2tlbnMgYW5kIE9JREMgQ29ubmVjdCB1c2FnZSBvbmx5LiZuYnNw OyBJbiBvcmRlciB0byAmbmJzcDthdm9pZCBjb25mdXNpbmcsIGFsbCBwcm9maWxpbmcgZXZlbnQg c3BlY3Mgc2hvdWxkIE5PVCB1c2Ug4oCcc3Vi4oCdIGluIHRoZSB0b3AgbGV2ZWwgZXhjZXB0IGZv ciBPSURDLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlRo aXMgaGFzIHRoZSBkaXNhZHZhbnRhZ2UgdGhhdCBPSURDIHJlcXVpcmVzIHNwZWNpYWwgaGFuZGxp bmcgaW4gdGVybXMgb2YgYSBnZW5lcmFsIHVzZSBldmVudCBsaWJyYXJ5LCBidXQgb24gdGhlIG90 aGVyIGhhbmQgYSBMb2dvdXQgRXZlbnQgbWlnaHQgYmUgaGFuZGxlZCBkaXJlY3RseSBieSBleGlz dGluZw0KIElEIFRva2VuIGNvZGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+VGhpcyBzdGlsbCBoYXMgdGhlIGRpc2FkdmFudGFnZSB0aGF0IGFuIFNFVCBj b3VsZCBiZSBjb25mdXNlZCBmb3IgYW4gSUQgVG9rZW4uPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Qy4gTm8tVG9wLUxldmVsIERhdGE6PC9zcGFuPjwv Yj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4m bmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkluDQogb3JkZXIgdG8gbW9yZSBh Z2dyZXNzaXZlbHkgYXZvaWQgY29uZnVzaW9uIG9mIFNFVHMgYXMgSUQgVG9rZW5zLCBtYWtlIGl0 IG1hbmRhdG9yeSB0aGF0IFNFVHMgbWF5IG5vdCBjb250YWluIGEg4oCcc3Vi4oCdIHZhbHVlIGF0 IHRoZSB0b3AgbGV2ZWwuJm5ic3A7IFRoZSBPSURDIExvZ291dCBFdmVudCwgZm9yIGV4YW1wbGUs IHdvdWxkIHRoZW4gaW5jbHVkZSBhIOKAnHN1YuKAnSB2YWx1ZSBpbiB0aGUgcGF5bG9hZCBhcmVh LiBUaGlzIHNob3VsZCBjYXVzZSBleGlzdGluZw0KIHJlbHlpbmcgcGFydGllcyB0byBmYWlsIGNv cnJlY3RseS4gJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZiI+VGhpcyB3b3VsZCBwcm92aWRlIGEgbWF4aW1hbCBkaWZmZXJlbmNlIGZvcm0gYSBJRFRv a2VuIG9yIGFjY2VzcyB0b2tlbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmIj5UaGlzIHdvdWxkIGhhdmUgdGhlIGFkdmFudGFnZSB0aGF0IGVudmVsb3BlcyBj b250YWluIG5vIGRhdGEsIGFuZCB0aGF0IGV2ZXJ5IFNFVCBoYXMgYSBwYXlsb2FkIHdoZXJlIHRo ZSBkYXRhIGlzIGZvdW5kLiBJdCByZXF1aXJlcyBtb3JlIHBhcnNpbmcgaW4gc29tZSBjYXNlcywg YnV0IGl0IGlzIGF0DQogbGVhc3QgY29uc2lzdGVudC4gV2hpbGUgd2UgZG9u4oCZdCBleHBlY3Qg Z2VuZXJhbCBwcm9jZXNzb3JzIGxpa2UgaW4gU09BUCBmb3IgZGlzdHJpYnV0aW9uIChtdWNoIG9m IGl0IGlzIHBvaW50IHRvIHBvaW50IGFuZCB2ZXJ5IGNvbnRleHR1YWxseSBkcml2ZW4pLCBJIHBl cnNvbmFsbHkgZXhwZWN0IHRvIHNlZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+KiAmbmJzcDtEZXZlbG9w bWVudCBvZiBnZW5lcmFsIHB1cnBvc2UgbGlicmFyaWVzIGFuZCB0b29scyB0aGF0IGFyZSB1c2Vk IGVuaGFuY2UgcHJvdG9jb2xzIGFuZCBzeXN0ZW1zJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPiog Jm5ic3A7QXVkaXQgYW5kIHRocmVhdCBhbmFseXNpcyBzeXN0ZW1zIHdpbGwgYmUgbG9va2luZyBh dCBzb21lIGV2ZW50cyBoaXN0b3JpY2FsbHkuIFRoZXNlIHdpbGwgdGVuZCB0byBtZXJnZSBtdWx0 aXBsZSBldmVudCBmZWVkcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj5NaWtlIEpvbmVzIGFsc28gc3VnZ2VzdGVkIHVzaW5nIHRoZTxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48Yj7igJxjdHnigJ08L2I+PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPihjb250ZW50IHR5cGUp IGhlYWRlciBhdHRyaWJ1dGUgZnJvbQ0KIEpXVC4mbmJzcDsgSSB0aGluayBtb3N0IGNvZGUgdG9k YXkgaGFzIHRoaXMgc2V0IHRvIGlnbm9yZSBvciBmaXhlZCBhcyDigJxKV1TigJ0uJm5ic3A7IEkg d29uZGVyIHdoYXQgY3VycmVudCBpbXBsZW1lbnRzIHdvdWxkIGZlZWwgaWYgd2UgaW50cm9kdWNl ZCBhIOKAnGN0eeKAnSB2YWx1ZSBvZiDigJxTRVTigJ0/Jm5ic3A7IFdvdWxkIHRoYXQgaGVscD88 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPkkgdGhpbmsgaXQgaXMgdmVyeSBpbXBvcnRhbnQgdG8gYmUgYWJsZSB0byBj bGVhcmx5IGRpc3Rpbmd1aXNoIGRpZmZlcmVudCB0eXBlcyBvZiBKV1QgdG9rZW5zLiBGb3IgZXhh bXBsZSwgbm90IGJlaW5nIGFibGUgdG8gY3Jvc3MgcG9zdCBhIFNlY3VyaXR5IEV2ZW50IFRva2Vu IGFzIGFuIElkIFRva2VuLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPlJlYWRpbmcmbmJzcDtSRkMgNzUxOSBJIGRvbid0IHRoaW5rIGN0eSBmaXRz IHRoZSBiaWxsLCBidXQgSSBjb3VsZCBiZSB3cm9uZy4gY3R5IGlzIGEgaGVhZGVyIHBhcmFtZXRl ciB1c2VkIGJ5IHRoZSBjcnlwdG8gYWxnb3JpdGhtIGFuZCB0aGUgZGVmYXVsdCB2YWx1ZSBpcyBK V1QuIFdlIG5lZWQgdG8gZGlzdGluZ3Vpc2gNCiBzdWItdHlwZXMgb2YgSldULCBhbmQgaXQgc2hv dWxkIGJlIGEgY2xhaW0gaW5zaWRlIHRoZSBKV1QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZiI+V2l0aCB0aGUgYWJvdmUgaXNzdWUgaW4gbWluZCwgSSB0aGlu ayBvcHRpb24gQSBpcyB0aGUgY2xlYW5lc3Qgc29sdXRpb24uPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlRoYW5rcyBmb3IgeW91ciBjb21t ZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj5QaGlsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+QGluZGVwZW5kZW50aWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48YSBocmVmPSJodHRw Oi8vd3d3LmluZGVwZW5kZW50aWQuY29tLyIgdGFyZ2V0PSJfYmxhbmsiPnd3dy5pbmRlcGVuZGVu dGlkLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxhIGhyZWY9 Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBoaWwuaHVudEBv cmFjbGUuY29tPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCklkLWV2ZW50IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1h aWx0bzpJZC1ldmVudEBpZXRmLm9yZyI+SWQtZXZlbnRAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudCIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ8 L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp ZiI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJ ZC1ldmVudCBtYWlsaW5nIGxpc3Q8YnI+DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50 QGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5JZC1ldmVudEBpZXRmLm9yZzwvc3Bhbj48L2E+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ8L3NwYW4+PC9hPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KSWQtZXZlbnQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGll dGYub3JnIj5JZC1ldmVudEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50Ij5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_SN1PR0301MB1645223021A8FC4C0ECC8D7CF5EA0SN1PR0301MB1645_-- From nobody Wed Aug 24 14:32:50 2016 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 B72D612D0AF for ; Wed, 24 Aug 2016 14:32:48 -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, 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 Z2cNnrjS_6NK for ; Wed, 24 Aug 2016 14:32:45 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::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 C620112D188 for ; Wed, 24 Aug 2016 14:32:44 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id t7so28662294qkh.1 for ; Wed, 24 Aug 2016 14:32:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=e9Xm5l4iDRkgWWD78gEacWrLZqBbjJFzgADBSuS4MBk=; b=CK5VjCi0vmsAAVmO3Y1k5aWQ7lWjqrHmiDtR7Qz6RNWLw+NudRSxljYTi1llpR2TuT +ohBEZUv0DCS6TtPk2FUv6G9kDw/qe/Lyq9Cwzqp4+X7227zWe7IXO6za30GvIwzlUz3 bR9TiO3d+QUETQVWrpCYWBImR+OUp6fKVYTpBLOgxhSvAHdEkfLLDoIgSDlN8jPFH0jd toW1Zk0jssWlWAStgYyZL41P5SODaseM0Lm3UWBmcibiikbwHABPI/02QHZBGxRq4rdG 9gBMngWzcOxi9kH/VaqvSGDWBX+uirl8u+WTJukaNpDzE4neVuZJQynUHXGndCgEPGzA dvyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=e9Xm5l4iDRkgWWD78gEacWrLZqBbjJFzgADBSuS4MBk=; b=LRVVmlE2k3yiRTCgNKn9wKg/4HudXZ+yGmPK61QUxelJDuV2ZRmoR9M5t8ffAg256P rG309QbGv0Xo1WK5DXjGwcZku3E2bpxNa1XrtylgShYGCeOsjyt14uf8E8CaOBUPGgyS +bNSymRlAgJ90H6DjA3x5FfC2Kcdfb6MUBfuR7/d4vwI+VggyONzGrm/y4gqcGq6SG6z FMiLEyQneu9c6htQOBHmel47GD4AG1gaBmQ9e+EBJZ6q2VVjkayXESUEPek3kmYtfh9H dNqzHr1BpKvnhtrXfPDLRUI0EZFHvn3lkVnH27bSUzcXgv7977gZ39/XSPpbTHduAYoN Y0zA== X-Gm-Message-State: AE9vXwMM2w3JGj6I2rRwt/r6kAZOVRqydRB+n52bPPhrHwr+TEgln2Vu0SlFAnmDtKqzNJKR X-Received: by 10.55.26.99 with SMTP id a96mr6531139qka.241.1472074363792; Wed, 24 Aug 2016 14:32:43 -0700 (PDT) Received: from [192.168.8.101] ([181.201.108.96]) by smtp.gmail.com with ESMTPSA id d38sm5779103qte.17.2016.08.24.14.32.41 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 24 Aug 2016 14:32:43 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_9EB8E239-4327-4F59-A91C-7C496506DB4D" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: John Bradley In-Reply-To: Date: Wed, 24 Aug 2016 18:32:39 -0300 Message-Id: <0C0D92BD-BF87-4892-8AAB-6C4F57F64BC6@ve7jtb.com> References: To: Michael Jones X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Phil Hunt , "id-event@ietf.org" , Marius Scurtescu Subject: Re: [Id-event] Discussion on use of "sub" and confusion as ID Token X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 24 Aug 2016 21:32:49 -0000 --Apple-Mail=_9EB8E239-4327-4F59-A91C-7C496506DB4D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The possible rational for a JWT type claim is not for multiplexing = multiple types in the same channel but to prevent having one protocol = get the AS to sign a JWT that could be mis interpreted by another = protocol in a different channel. These sorts of attacks have happened = to other things in the past. It is true that the lack of a nonce now and token binding in the future = would stop a Connect client from accepting a events token. =20 The audience could also be different and that would also stop them from = being accepted. (I am not recommending that but it is possible) I think we have ways to deal with it for connect id_tokens. My concern = going forward is that there will be a lot of other protocols using JWT = so it may be useful for SET and others to have a jwt_type claim that = could be used to prevent cross channel attacks. It is also possible = for other things to mistakenly process id_tokens if audiences are = reused. It may stop some horrible mistake down the road, that potentially has = nothing to do with Connect.=20 In some ways the simple thing is for clients to use district audiences = across protocols, but that would add some complexity to logout as we all = ready have a logical audience for the event. John B. > On Aug 24, 2016, at 5:49 PM, Mike Jones = wrote: >=20 > I=E2=80=99m not advocating =E2=80=9Ctyp=E2=80=9D or =E2=80=9Ccty=E2=80=9D= for any particular use case. I was just bringing them into the = discussion because people were talking about type fields and some might = not be aware of the type fields that already part of the standards. > =20 > A general-purpose JWT type claim seems only to be useful to me in use = cases in which multiple kinds of unrelated JWTs are valid in the same = context (the SOAP pattern). Again, there may be valid such use cases, = but they don=E2=80=99t come up in events use cases, in which events = listeners should only be listening for specific families of events and = not arbitrary JWTs. > =20 > To the particular point about whether an event JWT can be confused = with an ID Token, two complementary preventions seem pertinent: > =C2=B7 Require that any OP that issues events (such as logout = tokens) *also* reject any purported ID Tokens that contain an = =E2=80=9Cevents=E2=80=9D claim. This new rule needs to only be put in = place at the time the OP starts issuing JWTs that are not ID Tokens. = The problem can=E2=80=99t occur before that. > =C2=B7 Require that non-ID Tokens not contain a =E2=80=9Cnonce=E2=80= =9D, as is already the case for logout tokens. > =20 > Either of these would do the job. Doing both is defense in depth. > =20 > -- Mike > =C2=A0 <> > From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of John = Bradley > Sent: Wednesday, August 24, 2016 1:32 PM > To: Marius Scurtescu > Cc: id-event@ietf.org; Phil Hunt > Subject: Re: [Id-event] Discussion on use of "sub" and confusion as ID = Token > =20 > The idea for cty was to allow a JWS to encapsulate things like a = binary GIF as an example. I think using it for Distinguishing subtypes = of JWT would be a stretch. > =20 > I am most comfortable with A. I think that adding a JWT type claim = at the top level may also be useful going forward to avoid = misinterpretation. > =20 > John B. > On Aug 24, 2016, at 4:51 PM, Marius Scurtescu > wrote: > =20 > On Wed, Aug 24, 2016 at 11:07 AM, Phil Hunt > wrote: > =20 > The authors have been having a discussion with regards to using the = =E2=80=9Csub=E2=80=9D claim in the top level. I think it is important to = try and get this discussion back to the main group. My apologies for the = long note. I wanted to get all the pros and cons on the table (hint: = please add if I missed any)... > =20 > A question remains should =E2=80=9Csub=E2=80=9D be usable at the top = level. The downside of this approach is that a SET could potentially be = presented as an access or iD token and might initially be confused = because existing code does not know it needs to look for an =E2=80=9Cevent= s=E2=80=9D attribute. The SET and ID Token for all intensive purposes = are the same since a SET just has something extra (the events claim). > =20 > There is also the question that if OIDC Logout uses it in the top = level, may other events use it? RFC7519 defines =E2=80=9Csub=E2=80=9D as = a String or URI value. For example, in SCIM events, the =E2=80=9Csub=E2=80= =9D value could be a SCIM Resource URI that indicates the resource whose = state has changed. In OAuth it could be defined as the token identifier = of the token that has been revoked. A SET about blacklisting an IP = address might put the IP address in sub. > =20 > So there are three options (Option A seems to be favoured so far): =20 > =20 > A. Sub at Top Level: =E2=80=9Csub=E2=80=9D generally used to = reference the Security Subject the SET is talking about. It uses a more = general english language intent of subject rather than the traditional = use as seen in SAML or OpenID Connect. Regardless it is still compliant = with RFC7519 (a String or URI). > =20 > This would tend to lead to a style of SETs where the envelope carries = the validation information, the type of event, and the subject of the = event. Additional data goes in the payload. An advantage of this style, = is that for many events, the only thing needed is the event type and the = subject. No payloads would be needed. > =20 > For events that don=E2=80=99t want payload, it is probably ok for = profiling event standards to define more claims at the top level. They = MUST be registered in the JWT registry. Profiling events can avoid = registration by just putting their attributes/claims in the payload area = as described in the spec. However, this would be inconsistent with = those that use payloads with unregistered claims. I point out that we = switched from registered event URNs to URIs to avoid registration. = Hence the move to payload objects to eliminate registration for = attributes/claims. =20 > =20 > This still has the negatives of being confusable as an ID Token by = existing code. There has been a discussion that =E2=80=9Ciss=E2=80=9D = and/or =E2=80=9Caud=E2=80=9D should actually be different and the = receiver should detect that. However in the OIDC Logout case, by = design, the =E2=80=9Ciss=E2=80=9D value would be the same. The = =E2=80=9Caud=E2=80=9D would also likely be the same unless the spec = indicates that an alias =E2=80=9Caud=E2=80=9D be used even though the = audience may be the same entity in both cases. > =20 > B. Exclusive-Use of Sub: =E2=80=9Csub=E2=80=9D is interpreted to by = traditional definition and is reserved for OAuth tokens and OIDC Connect = usage only. In order to avoid confusing, all profiling event specs = should NOT use =E2=80=9Csub=E2=80=9D in the top level except for OIDC. > =20 > This has the disadvantage that OIDC requires special handling in terms = of a general use event library, but on the other hand a Logout Event = might be handled directly by existing ID Token code. > =20 > This still has the disadvantage that an SET could be confused for an = ID Token. > =20 > C. No-Top-Level Data: In order to more aggressively avoid confusion of = SETs as ID Tokens, make it mandatory that SETs may not contain a = =E2=80=9Csub=E2=80=9D value at the top level. The OIDC Logout Event, = for example, would then include a =E2=80=9Csub=E2=80=9D value in the = payload area. This should cause existing relying parties to fail = correctly. =20 > =20 > This would provide a maximal difference form a IDToken or access = token. > =20 > This would have the advantage that envelopes contain no data, and that = every SET has a payload where the data is found. It requires more = parsing in some cases, but it is at least consistent. While we don=E2=80=99= t expect general processors like in SOAP for distribution (much of it is = point to point and very contextually driven), I personally expect to = see: > * Development of general purpose libraries and tools that are used = enhance protocols and systems=20 > * Audit and threat analysis systems will be looking at some events = historically. These will tend to merge multiple event feeds. > =20 > Mike Jones also suggested using the =E2=80=9Ccty=E2=80=9D (content = type) header attribute from JWT. I think most code today has this set = to ignore or fixed as =E2=80=9CJWT=E2=80=9D. I wonder what current = implements would feel if we introduced a =E2=80=9Ccty=E2=80=9D value of = =E2=80=9CSET=E2=80=9D? Would that help? > =20 > I think it is very important to be able to clearly distinguish = different types of JWT tokens. For example, not being able to cross post = a Security Event Token as an Id Token.=20 > =20 > Reading RFC 7519 I don't think cty fits the bill, but I could be = wrong. cty is a header parameter used by the crypto algorithm and the = default value is JWT. We need to distinguish sub-types of JWT, and it = should be a claim inside the JWT. > =20 > With the above issue in mind, I think option A is the cleanest = solution. > =20 > =20 > =20 > Thanks for your comments. > =20 > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =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 = --Apple-Mail=_9EB8E239-4327-4F59-A91C-7C496506DB4D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The possible rational for a JWT type claim is not for = multiplexing multiple types in the same channel but to prevent having = one protocol get the AS to sign a JWT that could be mis interpreted by = another protocol in a different channel.   These sorts of attacks = have happened to other things in the past.

It is true that the lack of a nonce now = and token binding in the future would stop a Connect client from = accepting a events token.   

The audience could also be different = and that would also stop them from being accepted. (I am not = recommending that but it is possible)

I think we have ways to deal with it = for connect id_tokens.   My concern going forward is that there = will be a lot of other protocols using JWT so it may be useful for SET = and others to have a jwt_type claim that could be used to prevent cross = channel attacks.   It is also possible for other things to = mistakenly process id_tokens if audiences are reused.

It may stop some = horrible mistake down the road, that potentially has nothing to do with = Connect. 

In some ways the simple thing is for clients to use district = audiences across protocols, but that would add some complexity to logout = as we all ready have a logical audience for the event.

John B.







On Aug 24, 2016, at 5:49 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

I=E2=80=99m not advocating =E2=80=9Ctyp=E2=80=9D= or =E2=80=9Ccty=E2=80=9D for any particular use case.  I was just = bringing them into the discussion because people were talking about type = fields and some might not be aware of the type fields that already part = of the standards.
 
A general-purpose JWT = type claim seems only to be useful to me in use cases in which multiple = kinds of unrelated JWTs are valid in the same context (the SOAP = pattern).  Again, there may be valid such use cases, but they = don=E2=80=99t come up in events use cases, in which events listeners = should only be listening for specific families of events and not = arbitrary JWTs.
 
To the particular point = about whether an event JWT can be confused with an ID Token, two = complementary preventions seem pertinent:
=C2=B7       Require that any OP that issues events (such = as logout tokens) *also* reject any purported ID = Tokens that contain an =E2=80=9Cevents=E2=80=9D claim.  This new = rule needs to only be put in place at the time the OP starts issuing = JWTs that are not ID Tokens.  The problem can=E2=80=99t occur = before that.
=C2=B7       Require that non-ID Tokens not contain a = =E2=80=9Cnonce=E2=80=9D, as is already the case for logout tokens.
 
Either of these would do the job.  Doing both is defense = in depth.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;       -- Mike
 
From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf = Of John Bradley
Sent: Wednesday, August 24, 2016 = 1:32 PM
To: Marius Scurtescu <mscurtescu@google.com>
Cc: id-event@ietf.org; Phil = Hunt <phil.hunt@oracle.com>
Subject: Re: [Id-event] Discussion = on use of "sub" and confusion as ID Token
 
The idea for cty was to allow a JWS to encapsulate things = like a binary GIF as an example.   I think using it for = Distinguishing subtypes of JWT would be a stretch.
 
I am most comfortable with A.   I = think that adding a JWT type claim at the top level may also be useful = going forward to avoid misinterpretation.
 
John B.
On = Aug 24, 2016, at 4:51 PM, Marius Scurtescu <mscurtescu@google.com> = wrote:
 
On Wed, Aug 24, 2016 at 11:07 AM, Phil Hunt <phil.hunt@oracle.com> wrote:
 
The authors have been = having a discussion with regards to using the =E2=80=9Csub=E2=80=9D = claim in the top level. I think it is important to try and get this = discussion back to the main group. My apologies for the long note. I = wanted to get all the pros and cons on the table (hint:  please add = if I missed any)...
 
A= question remains should =E2=80=9Csub=E2=80=9D be usable at the top = level.  The downside of this approach is that a SET could = potentially be presented as an access or iD token and might initially be = confused because existing code does not know it needs to look for an = =E2=80=9Cevents=E2=80=9D attribute.  The SET and ID Token for all = intensive purposes are the same since a SET just has something extra = (the events claim).
 
There is also the question that if OIDC Logout uses it in the = top level, may other events use it? RFC7519 defines =E2=80=9Csub=E2=80=9D = as a String or URI value. For example, in SCIM events, the =E2=80=9Csub=E2= =80=9D value could be a SCIM Resource URI that indicates the resource = whose state has changed.  In OAuth it could be defined as the token = identifier of the token that has been revoked.  A SET about = blacklisting an IP address might put the IP address in sub.
 
So there are three = options (Option A seems to be favoured so far):  
 
A.  Sub at Top = Level:  =E2=80=9Csub=E2=80=9D= generally used to reference the Security Subject the SET is talking = about.  It uses a more general english language intent of subject = rather than the traditional use as seen in SAML or OpenID Connect.  = Regardless it is still compliant with RFC7519 (a String or URI).
 
This would tend to lead = to a style of SETs where the envelope carries the validation = information, the type of event, and the subject of the event. Additional = data goes in the payload. An advantage of this style, is that for many = events, the only thing needed is the event type and the subject.  = No payloads would be needed.
 
For events that don=E2=80=99t want payload, it is probably ok = for profiling event standards to define more claims at the top level. = They MUST be registered in the JWT registry. Profiling events can avoid = registration by just putting their attributes/claims in the payload area = as described in the spec.  However, this would be inconsistent with = those that use payloads with unregistered claims.  I point out that = we switched from registered event URNs to URIs to avoid = registration.  Hence the move to payload objects to eliminate = registration for attributes/claims.  
 
This still has the = negatives of being confusable as an ID Token by existing code. There has = been a discussion that =E2=80=9Ciss=E2=80=9D and/or =E2=80=9Caud=E2=80=9D = should actually be different and the receiver should detect that.  = However in the OIDC Logout case, by design, the =E2=80=9Ciss=E2=80=9D = value would be the same.  The =E2=80=9Caud=E2=80=9D would also = likely be the same unless the spec indicates that an alias =E2=80=9Caud=E2= =80=9D be used even though the audience may be the same entity in both = cases.
 
B. Exclusive-Use of = Sub: =E2=80=9Csub=E2=80=9D is = interpreted to by traditional definition and is reserved for OAuth = tokens and OIDC Connect usage only.  In order to  avoid = confusing, all profiling event specs should NOT use =E2=80=9Csub=E2=80=9D = in the top level except for OIDC.
 
This has the = disadvantage that OIDC requires special handling in terms of a general = use event library, but on the other hand a Logout Event might be handled = directly by existing ID Token code.
 
This still has the = disadvantage that an SET could be confused for an ID Token.
 
C. No-Top-Level = Data: In order to more = aggressively avoid confusion of SETs as ID Tokens, make it mandatory = that SETs may not contain a =E2=80=9Csub=E2=80=9D value at the top = level.  The OIDC Logout Event, for example, would then include a = =E2=80=9Csub=E2=80=9D value in the payload area. This should cause = existing relying parties to fail correctly.  
 
This would provide a = maximal difference form a IDToken or access token.
 
This would have the = advantage that envelopes contain no data, and that every SET has a = payload where the data is found. It requires more parsing in some cases, = but it is at least consistent. While we don=E2=80=99t expect general = processors like in SOAP for distribution (much of it is point to point = and very contextually driven), I personally expect to see:
  *  Development of = general purpose libraries and tools that are used enhance protocols and = systems 
  *  Audit and threat = analysis systems will be looking at some events historically. These will = tend to merge multiple event feeds.
 
Mike Jones also = suggested using the =E2=80=9Ccty=E2=80=9D (content type) header = attribute from JWT.  I think most code today has this set to ignore = or fixed as =E2=80=9CJWT=E2=80=9D.  I wonder what current = implements would feel if we introduced a =E2=80=9Ccty=E2=80=9D value of = =E2=80=9CSET=E2=80=9D?  Would that help?
 
I= think it is very important to be able to clearly distinguish different = types of JWT tokens. For example, not being able to cross post a = Security Event Token as an Id Token. 
 
Reading RFC 7519 I = don't think cty fits the bill, but I could be wrong. cty is a header = parameter used by the crypto algorithm and the default value is JWT. We = need to distinguish sub-types of JWT, and it should be a claim inside = the JWT.
 
With the above issue in = mind, I think option A is the cleanest solution.
 
 
 
Thanks for your = comments.
 
 
Phil
 
@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=_9EB8E239-4327-4F59-A91C-7C496506DB4D-- From nobody Wed Aug 24 14:41:59 2016 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 310AE12D1DE for ; Wed, 24 Aug 2016 14:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.548, 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 FHnsx718stVd for ; Wed, 24 Aug 2016 14:41:55 -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 08BF912D0F5 for ; Wed, 24 Aug 2016 14:41:54 -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 u7OLfqh0027671 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 24 Aug 2016 21:41:52 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u7OLfqgn015617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 24 Aug 2016 21:41:52 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 u7OLfptJ021164; Wed, 24 Aug 2016 21:41:51 GMT Received: from [10.0.1.5] (/24.86.208.48) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 24 Aug 2016 14:41:50 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_1F48670A-481C-4670-B8DA-235ED22A0B31" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Phil Hunt In-Reply-To: Date: Wed, 24 Aug 2016 14:41:48 -0700 Message-Id: <99F73572-FF0E-4F88-9E61-C69601CC4C23@oracle.com> References: <3D5305B0-0365-4B07-9D35-81F0B7B04FF2@oracle.com> <382F27DF-A35A-43F3-8C2E-CE3D8ABC4ADB@ve7jtb.com> To: Mike Jones X-Mailer: Apple Mail (2.3124) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: John Bradley , "id-event@ietf.org" , Marius Scurtescu Subject: Re: [Id-event] Discussion on use of "sub" and confusion as ID Token X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 24 Aug 2016 21:41:58 -0000 --Apple-Mail=_1F48670A-481C-4670-B8DA-235ED22A0B31 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Ok. Can we agree that a strong security consideration would be the = appropriate remedy? The text (not finished yet) might cover the following: Audiences that receive both JWTs (e.g. as access tokens) and SETs for = security events should take care to ensure that a SET passed in a = channel where it could be confused as an access token MUST take care to = evaluate: * The presence/absence of =E2=80=9Cevents=E2=80=9D claim * That the =E2=80=9Caud=E2=80=9D value is correct. And where possible = the SET =E2=80=9Caud=E2=80=9D and the access token =E2=80=9Caud=E2=80=9D = are in fact different even if it is the same service entity. * That access tokens and SETs SHOULD NOT be received over the same = channel and at minimum SHOULD be separate endpoints. e.g. access tokens = via the authorization header of a resource service, versus SETs received = over HTTP POST at a specific web URI associated with the subscription. * Check for the presence of a =E2=80=9Cnonce=E2=80=9D in the case of an = OpenID Connect id_token. Phil @independentid www.independentid.com = phil.hunt@oracle.com = > On Aug 24, 2016, at 2:31 PM, Mike Jones = wrote: >=20 > A spec could create a top-level JWT type claim, but I=E2=80=99d assert = that it=E2=80=99s out of scope for the Events spec. It would probably = need to be its own spec and say basically =E2=80=9Cuse it if you=E2=80=99r= e in use cases in which it=E2=80=99s useful to distinguish between = things=E2=80=9D. > =C2=A0 <> > From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of John = Bradley > Sent: Wednesday, August 24, 2016 2:24 PM > To: Phil Hunt > Cc: id-event@ietf.org; Marius Scurtescu > Subject: Re: [Id-event] Discussion on use of "sub" and confusion as ID = Token > =20 > I was saying that cty was wrong for this. =20 > =20 > If you look at the definition of typ in JWS = https://tools.ietf.org/html/rfc7515#page-13 = you can see that it is = really intended to be the media type of the complete JWS/JWE and is = omitted or set to JWT if it is a compact JWT. Setting it to SET = seems wrong as it is still a JWT. I was recommending considering a JWT = top level claim in the JWT registry. > =20 > John B. > =20 > =20 > On Aug 24, 2016, at 5:59 PM, Phil Hunt > wrote: > =20 > John, > =20 > Did you mean adding a =E2=80=9Cjwt_type=E2=80=9D attribute (that = becomes a registered JWT claim) OR adding a new type value for the JWT = header =E2=80=9Ctyp=E2=80=9D? Note for everyone=E2=80=99s convenience = from 7519: > =20 > The "typ" (type) Header Parameter defined by [JWS = ] and [JWE = ] is used > by JWT applications to declare the media type [IANA.MediaTypes = ] of > this complete JWT. This is intended for use by the JWT application > when values that are not JWTs could also be present in an = application > data structure that can contain a JWT object; the application can = use > this value to disambiguate among the different kinds of objects = that > might be present. It will typically not be used by applications = when > it is already known that the object is a JWT. This parameter is > ignored by JWT implementations; any processing of this parameter is > performed by the JWT application. If present, it is RECOMMENDED = that > its value be "JWT" to indicate that this object is a JWT. While > media type names are not case sensitive, it is RECOMMENDED that = "JWT" > always be spelled using uppercase characters for compatibility with > legacy implementations. Use of this Header Parameter is OPTIONAL. > =20 > =20 > What is concerning is the line that says:=20 > It will typically not be used by applications when > it is already known that the object is a JWT. This parameter is > ignored by JWT implementations; any processing of this parameter is > performed by the JWT application. If present, it is RECOMMENDED = that > its value be "JWT" to indicate that this object is a JWT. > =20 > If it is typically ignored, then having it =E2=80=9Ctyp=E2=80=9D be = =E2=80=9CSET=E2=80=9D may not help much initially. But at least it is = more definitive. > =20 > If the group is comfortable, I am ok with making =E2=80=9Ctyp=E2=80=9D = be =E2=80=9CSET=E2=80=9D. It is one more distinguishing item. =20 > =20 > Regardless, I will also put a cautionary note in the security = considerations that if issuing SETs to audiences that also receive JWTs, = that appropriate care be taken not to confuse if somehow a hacker is = able to present the SET as if it were a JWT to gain access (e.g. in an = authorization header). Normally this should not be possible as I would = assume SETs are passed via something like an HTTP POST back-channel. > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > =20 > =20 >=20 > =20 > On Aug 24, 2016, at 1:31 PM, John Bradley > wrote: > =20 > The idea for cty was to allow a JWS to encapsulate things like a = binary GIF as an example. I think using it for Distinguishing subtypes = of JWT would be a stretch. > =20 > I am most comfortable with A. I think that adding a JWT type claim = at the top level may also be useful going forward to avoid = misinterpretation. > =20 > John B. > On Aug 24, 2016, at 4:51 PM, Marius Scurtescu > wrote: > =20 > On Wed, Aug 24, 2016 at 11:07 AM, Phil Hunt > wrote: > =20 > The authors have been having a discussion with regards to using the = =E2=80=9Csub=E2=80=9D claim in the top level. I think it is important to = try and get this discussion back to the main group. My apologies for the = long note. I wanted to get all the pros and cons on the table (hint: = please add if I missed any)... > =20 > A question remains should =E2=80=9Csub=E2=80=9D be usable at the top = level. The downside of this approach is that a SET could potentially be = presented as an access or iD token and might initially be confused = because existing code does not know it needs to look for an =E2=80=9Cevent= s=E2=80=9D attribute. The SET and ID Token for all intensive purposes = are the same since a SET just has something extra (the events claim). > =20 > There is also the question that if OIDC Logout uses it in the top = level, may other events use it? RFC7519 defines =E2=80=9Csub=E2=80=9D as = a String or URI value. For example, in SCIM events, the =E2=80=9Csub=E2=80= =9D value could be a SCIM Resource URI that indicates the resource whose = state has changed. In OAuth it could be defined as the token identifier = of the token that has been revoked. A SET about blacklisting an IP = address might put the IP address in sub. > =20 > So there are three options (Option A seems to be favoured so far): =20 > =20 > A. Sub at Top Level: =E2=80=9Csub=E2=80=9D generally used to = reference the Security Subject the SET is talking about. It uses a more = general english language intent of subject rather than the traditional = use as seen in SAML or OpenID Connect. Regardless it is still compliant = with RFC7519 (a String or URI). > =20 > This would tend to lead to a style of SETs where the envelope carries = the validation information, the type of event, and the subject of the = event. Additional data goes in the payload. An advantage of this style, = is that for many events, the only thing needed is the event type and the = subject. No payloads would be needed. > =20 > For events that don=E2=80=99t want payload, it is probably ok for = profiling event standards to define more claims at the top level. They = MUST be registered in the JWT registry. Profiling events can avoid = registration by just putting their attributes/claims in the payload area = as described in the spec. However, this would be inconsistent with = those that use payloads with unregistered claims. I point out that we = switched from registered event URNs to URIs to avoid registration. = Hence the move to payload objects to eliminate registration for = attributes/claims. =20 > =20 > This still has the negatives of being confusable as an ID Token by = existing code. There has been a discussion that =E2=80=9Ciss=E2=80=9D = and/or =E2=80=9Caud=E2=80=9D should actually be different and the = receiver should detect that. However in the OIDC Logout case, by = design, the =E2=80=9Ciss=E2=80=9D value would be the same. The = =E2=80=9Caud=E2=80=9D would also likely be the same unless the spec = indicates that an alias =E2=80=9Caud=E2=80=9D be used even though the = audience may be the same entity in both cases. > =20 > B. Exclusive-Use of Sub: =E2=80=9Csub=E2=80=9D is interpreted to by = traditional definition and is reserved for OAuth tokens and OIDC Connect = usage only. In order to avoid confusing, all profiling event specs = should NOT use =E2=80=9Csub=E2=80=9D in the top level except for OIDC. > =20 > This has the disadvantage that OIDC requires special handling in terms = of a general use event library, but on the other hand a Logout Event = might be handled directly by existing ID Token code. > =20 > This still has the disadvantage that an SET could be confused for an = ID Token. > =20 > C. No-Top-Level Data: In order to more aggressively avoid confusion of = SETs as ID Tokens, make it mandatory that SETs may not contain a = =E2=80=9Csub=E2=80=9D value at the top level. The OIDC Logout Event, = for example, would then include a =E2=80=9Csub=E2=80=9D value in the = payload area. This should cause existing relying parties to fail = correctly. =20 > =20 > This would provide a maximal difference form a IDToken or access = token. > =20 > This would have the advantage that envelopes contain no data, and that = every SET has a payload where the data is found. It requires more = parsing in some cases, but it is at least consistent. While we don=E2=80=99= t expect general processors like in SOAP for distribution (much of it is = point to point and very contextually driven), I personally expect to = see: > * Development of general purpose libraries and tools that are used = enhance protocols and systems=20 > * Audit and threat analysis systems will be looking at some events = historically. These will tend to merge multiple event feeds. > =20 > Mike Jones also suggested using the =E2=80=9Ccty=E2=80=9D (content = type) header attribute from JWT. I think most code today has this set = to ignore or fixed as =E2=80=9CJWT=E2=80=9D. I wonder what current = implements would feel if we introduced a =E2=80=9Ccty=E2=80=9D value of = =E2=80=9CSET=E2=80=9D? Would that help? > =20 > I think it is very important to be able to clearly distinguish = different types of JWT tokens. For example, not being able to cross post = a Security Event Token as an Id Token.=20 > =20 > Reading RFC 7519 I don't think cty fits the bill, but I could be = wrong. cty is a header parameter used by the crypto algorithm and the = default value is JWT. We need to distinguish sub-types of JWT, and it = should be a claim inside the JWT. > =20 > With the above issue in mind, I think option A is the cleanest = solution. > =20 > =20 > =20 > Thanks for your comments. > =20 > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =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 > _______________________________________________ > 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=_1F48670A-481C-4670-B8DA-235ED22A0B31 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Ok.  Can we agree that a strong security consideration = would be the appropriate remedy?

The text (not finished yet) might cover the = following:

Audiences that receive both JWTs (e.g. as access tokens) and = SETs for security events should take care to ensure that a SET passed in = a channel where it could be confused as an access token MUST take care = to evaluate:
* The presence/absence of =E2=80=9Cevent= s=E2=80=9D claim
* That the =E2=80=9Caud=E2=80=9D = value is correct.  And where possible the SET =E2=80=9Caud=E2=80=9D = and the access token =E2=80=9Caud=E2=80=9D are in fact different even if = it is the same service entity.
* That access tokens = and SETs SHOULD NOT be received over the same channel and at minimum = SHOULD be separate endpoints. e.g. access tokens via the authorization = header of a resource service, versus SETs received over HTTP POST at a = specific web URI associated with the subscription.
* = Check for the presence of a =E2=80=9Cnonce=E2=80=9D in the case of an = OpenID Connect id_token.




On Aug 24, 2016, at 2:31 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

A spec could create a top-level JWT type = claim, but I=E2=80=99d assert that it=E2=80=99s out of scope for the = Events spec.  It would probably need to be its own spec and say = basically =E2=80=9Cuse it if you=E2=80=99re in use cases in which it=E2=80= =99s useful to distinguish between things=E2=80=9D.
 
From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf = Of John Bradley
Sent: Wednesday, August 24, 2016 = 2:24 PM
To: Phil Hunt <phil.hunt@oracle.com>
Cc: id-event@ietf.org; = Marius Scurtescu <mscurtescu@google.com>
Subject: Re: [Id-event] Discussion = on use of "sub" and confusion as ID Token
 
I was saying that cty was wrong for this.  
 
If you look at the definition of typ in = JWS https://tools.ietf.org/html/rfc7515#page-13  you can = see that it is really intended to be the media type of the complete = JWS/JWE and is omitted or set to JWT if it is a compact JWT.   =   Setting it to SET seems wrong as it is still a JWT.   I was = recommending considering a JWT top level claim in the JWT registry.
 
John B.
 
 
On = Aug 24, 2016, at 5:59 PM, Phil Hunt <phil.hunt@oracle.com> = wrote:
 
John,
 
Did you mean adding a =E2=80=9Cjwt_type=E2=80= =9D attribute (that becomes a registered JWT claim) OR adding a new type = value for the JWT header =E2=80=9Ctyp=E2=80=9D?  Note for = everyone=E2=80=99s convenience from 7519:
 
The "typ" (type) =
Header Parameter defined by [JWS] and [JWE] is used
   by =
JWT applications to declare the media type [IANA.MediaTypes] of
   this =
complete JWT.  This is intended for use by the JWT application
   when values that are not JWTs could also be =
present in an application
   data structure that =
can contain a JWT object; the application can use
   this value to disambiguate among the different =
kinds of objects that
   might be =
present.  It will typically not be used by applications when
   it is already known that the object is a =
JWT.  This parameter is
   =
ignored by JWT implementations; any processing of this parameter is
   performed by the JWT application.  If =
present, it is RECOMMENDED that
   its =
value be "JWT" to indicate that this object is a JWT.  While
   media type names are not case sensitive, it is =
RECOMMENDED that "JWT"
   always be spelled =
using uppercase characters for compatibility with
   legacy implementations.  Use of this Header =
Parameter is OPTIONAL.
 
 
What is concerning is the line that says: 
It will typically not be used by =
applications when
   it is already known =
that the object is a JWT.  This =
parameter is
   ignored by JWT implementations; any =
processing of this parameter is
   =
performed by the JWT application.  If present, it is RECOMMENDED =
that
   its value be "JWT" to indicate that this object =
is a JWT.
 
If it is typically = ignored, then having it =E2=80=9Ctyp=E2=80=9D be =E2=80=9CSET=E2=80=9D = may not help much initially. But at least it is more definitive.
 
If the group is comfortable, I am ok with = making =E2=80=9Ctyp=E2=80=9D be =E2=80=9CSET=E2=80=9D.  It is one = more distinguishing item.  
 
Regardless, I will also put a cautionary note in the = security considerations that if issuing SETs to audiences that also = receive JWTs, that appropriate care be taken not to confuse if somehow a = hacker is able to present the SET as if it were a JWT to gain access = (e.g. in an authorization header).  Normally this should not be = possible as I would assume SETs are passed via something like an HTTP = POST back-channel.
 
Phil
 
@independentid
www.independentid.com
 
 

 

 
On = Aug 24, 2016, at 1:31 PM, John Bradley <ve7jtb@ve7jtb.com> = wrote:
 
The idea for cty was = to allow a JWS to encapsulate things like a binary GIF as an example. =   I think using it for Distinguishing subtypes of JWT would be a = stretch.
 
I am most comfortable = with A.   I think that adding a JWT type claim at the top level may = also be useful going forward to avoid misinterpretation.
 
John B.
On = Aug 24, 2016, at 4:51 PM, Marius Scurtescu <mscurtescu@google.com> = wrote:
 
On Wed, Aug 24, 2016 at 11:07 AM, Phil Hunt <phil.hunt@oracle.com> wrote:
 
The authors have been = having a discussion with regards to using the =E2=80=9Csub=E2=80=9D = claim in the top level. I think it is important to try and get this = discussion back to the main group. My apologies for the long note. I = wanted to get all the pros and cons on the table (hint:  please add = if I missed any)...
 
A= question remains should =E2=80=9Csub=E2=80=9D be usable at the top = level.  The downside of this approach is that a SET could = potentially be presented as an access or iD token and might initially be = confused because existing code does not know it needs to look for an = =E2=80=9Cevents=E2=80=9D attribute.  The SET and ID Token for all = intensive purposes are the same since a SET just has something extra = (the events claim).
 
There is also the question that if OIDC Logout uses it in the = top level, may other events use it? RFC7519 defines =E2=80=9Csub=E2=80=9D = as a String or URI value. For example, in SCIM events, the =E2=80=9Csub=E2= =80=9D value could be a SCIM Resource URI that indicates the resource = whose state has changed.  In OAuth it could be defined as the token = identifier of the token that has been revoked.  A SET about = blacklisting an IP address might put the IP address in sub.
 
So there are three = options (Option A seems to be favoured so far):  
 
A.  Sub at Top = Level:  =E2=80=9Csub=E2=80=9D= generally used to reference the Security Subject the SET is talking = about.  It uses a more general english language intent of subject = rather than the traditional use as seen in SAML or OpenID Connect.  = Regardless it is still compliant with RFC7519 (a String or URI).
 
This would tend to lead = to a style of SETs where the envelope carries the validation = information, the type of event, and the subject of the event. Additional = data goes in the payload. An advantage of this style, is that for many = events, the only thing needed is the event type and the subject.  = No payloads would be needed.
 
For events that don=E2=80=99t want payload, it is probably ok = for profiling event standards to define more claims at the top level. = They MUST be registered in the JWT registry. Profiling events can avoid = registration by just putting their attributes/claims in the payload area = as described in the spec.  However, this would be inconsistent with = those that use payloads with unregistered claims.  I point out that = we switched from registered event URNs to URIs to avoid = registration.  Hence the move to payload objects to eliminate = registration for attributes/claims.  
 
This still has the = negatives of being confusable as an ID Token by existing code. There has = been a discussion that =E2=80=9Ciss=E2=80=9D and/or =E2=80=9Caud=E2=80=9D = should actually be different and the receiver should detect that.  = However in the OIDC Logout case, by design, the =E2=80=9Ciss=E2=80=9D = value would be the same.  The =E2=80=9Caud=E2=80=9D would also = likely be the same unless the spec indicates that an alias =E2=80=9Caud=E2= =80=9D be used even though the audience may be the same entity in both = cases.
 
B. Exclusive-Use of = Sub: =E2=80=9Csub=E2=80=9D is = interpreted to by traditional definition and is reserved for OAuth = tokens and OIDC Connect usage only.  In order to  avoid = confusing, all profiling event specs should NOT use =E2=80=9Csub=E2=80=9D = in the top level except for OIDC.
 
This has the = disadvantage that OIDC requires special handling in terms of a general = use event library, but on the other hand a Logout Event might be handled = directly by existing ID Token code.
 
This still has the = disadvantage that an SET could be confused for an ID Token.
 
C. No-Top-Level = Data: In order to more = aggressively avoid confusion of SETs as ID Tokens, make it mandatory = that SETs may not contain a =E2=80=9Csub=E2=80=9D value at the top = level.  The OIDC Logout Event, for example, would then include a = =E2=80=9Csub=E2=80=9D value in the payload area. This should cause = existing relying parties to fail correctly.  
 
This would provide a = maximal difference form a IDToken or access token.
 
This would have the = advantage that envelopes contain no data, and that every SET has a = payload where the data is found. It requires more parsing in some cases, = but it is at least consistent. While we don=E2=80=99t expect general = processors like in SOAP for distribution (much of it is point to point = and very contextually driven), I personally expect to see:
  *  Development of = general purpose libraries and tools that are used enhance protocols and = systems 
  *  Audit and threat = analysis systems will be looking at some events historically. These will = tend to merge multiple event feeds.
 
Mike Jones also = suggested using the =E2=80=9Ccty=E2=80=9D (content type) header = attribute from JWT.  I think most code today has this set to ignore = or fixed as =E2=80=9CJWT=E2=80=9D.  I wonder what current = implements would feel if we introduced a =E2=80=9Ccty=E2=80=9D value of = =E2=80=9CSET=E2=80=9D?  Would that help?
 
I= think it is very important to be able to clearly distinguish different = types of JWT tokens. For example, not being able to cross post a = Security Event Token as an Id Token. 
 
Reading RFC 7519 I = don't think cty fits the bill, but I could be wrong. cty is a header = parameter used by the crypto algorithm and the default value is JWT. We = need to distinguish sub-types of JWT, and it should be a claim inside = the JWT.
 
With the above issue in = mind, I think option A is the cleanest solution.
 
 
 
Thanks for your = comments.
 
 
Phil
 
@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
 
_______________________________________________
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=_1F48670A-481C-4670-B8DA-235ED22A0B31-- From nobody Wed Aug 24 14:45:02 2016 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 2CDD412D5F6 for ; Wed, 24 Aug 2016 14:45:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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] 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 k1P-pfYb2BX9 for ; Wed, 24 Aug 2016 14:44:57 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::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 45E6F12D73C for ; Wed, 24 Aug 2016 14:44:57 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id t7so28932842qkh.1 for ; Wed, 24 Aug 2016 14:44:57 -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=UR3CxNHTYRMvVIuyPddUmZ2v8wNlKZfgrwqcn0s26Oo=; b=agQjUjpGSEGTQagvXd6/mDnkIluM7JaHFxUSDQ12qquxrVeW+hu7MdAFWP3zq5jf1c tpJCly7+JuRi1t/QsNzOik1vipTahs5C8gPDbUCKoZHinZFVzATELM8CmPdCKBj7veS8 GDrAc8j8ePkO5YnbW3ZWg8aTh73Q1XDXnkuHlrMqSAP0vXjMQR5lCQitlXlxx0VZJWWe Ofauegx0SsZyN35Hd9GNh94WQhJpKG5BSOowpboVkM0s10aAcoXn6BHUiS+FUp+yNwl0 QVnGVB+hyb86zDTLF8//620nz6RDNv/WTsaN75889UNKtSUf56zfdrFXpgM+QfTAbHFk vDaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UR3CxNHTYRMvVIuyPddUmZ2v8wNlKZfgrwqcn0s26Oo=; b=SF7d/kZ1m770QpeL/1/JYzfg/feKyBPtv+waynHH3UAGN62C8Tq13ypuPqnNRy6k8g p/NYHuDQRrpxYB5nH041TJ8Sweq663sjcZxG7ssdid68MNm0LW1NHppKqFLRZWXSSA/t 65HFFg8WrflHZgIMcA2mMu7ISHVuX3AYpYWnKsVzIzisP0Br+eYEMR9bHZP3TBzNDKL7 EWgbfMUgb5sgUa8QH3C/U7CcGzudZwZd8azR1VxyfO7BOaXsUpMu5I/lIC4tgUN3kZfA 6NKAjXqipbq2zpXlv6rwiTXbeD2XGJ8bIt4zi0My0yoSeQvr9I3ONfl+CQNXxTogMQFK mnlg== X-Gm-Message-State: AE9vXwO1TbBlK8krjrA1yWwJABXqnSbcjPtKrqSUH4vgrJ4TQEJy4qqt+v1Zea3VXgG3n1h+28xbHg1nyW4UeCEa X-Received: by 10.55.69.79 with SMTP id s76mr5991859qka.13.1472075096354; Wed, 24 Aug 2016 14:44:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.105.3 with HTTP; Wed, 24 Aug 2016 14:44:53 -0700 (PDT) X-Originating-IP: [181.201.108.96] In-Reply-To: <3D5305B0-0365-4B07-9D35-81F0B7B04FF2@oracle.com> References: <3D5305B0-0365-4B07-9D35-81F0B7B04FF2@oracle.com> From: John Bradley Date: Wed, 24 Aug 2016 18:44:53 -0300 Message-ID: To: Phil Hunt Content-Type: multipart/alternative; boundary=001a114aa7ac339386053ad831a9 Archived-At: Cc: id-event@ietf.org, Marius Scurtescu Subject: Re: [Id-event] Discussion on use of "sub" and confusion as ID Token X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 24 Aug 2016 21:45:01 -0000 --001a114aa7ac339386053ad831a9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I was saying that cty was wrong for this. If you look at the definition of typ in JWS https://tools.ietf.org/ html/rfc7515#page-13 you can see that it is really intended to be the media type of the complete JWS/JWE and is omitted or set to JWT if it is a compact JWT. Setting it to SET seems wrong as it is still a JWT. I was recommending cosidering a JWT On Aug 24, 2016, at 5:59 PM, Phil Hunt wrote: John, Did you mean adding a =E2=80=9Cjwt_type=E2=80=9D attribute (that becomes a = registered JWT claim) OR adding a new type value for the JWT header =E2=80=9Ctyp=E2=80=9D?= Note for everyone=E2=80=99s convenience from 7519: The "typ" (type) Header Parameter defined by [JWS ] and [JWE ] is used by JWT applications to declare the media type [IANA.MediaTypes ] of this complete JWT. This is intended for use by the JWT application when values that are not JWTs could also be present in an application data structure that can contain a JWT object; the application can use this value to disambiguate among the different kinds of objects that might be present. It will typically not be used by applications when it is already known that the object is a JWT. This parameter is ignored by JWT implementations; any processing of this parameter is performed by the JWT application. If present, it is RECOMMENDED that its value be "JWT" to indicate that this object is a JWT. While media type names are not case sensitive, it is RECOMMENDED that "JWT" always be spelled using uppercase characters for compatibility with legacy implementations. Use of this Header Parameter is OPTIONAL. What is concerning is the line that says: It will typically not be used by applications when it is already known that the object is a JWT. *This parameter is ignored by JWT implementations*; any processing of this parameter is performed by the JWT application. If present, it is RECOMMENDED that its value be "JWT" to indicate that this object is a JWT. If it is typically ignored, then having it =E2=80=9Ctyp=E2=80=9D be =E2=80= =9CSET=E2=80=9D may not help much initially. But at least it is more definitive. If the group is comfortable, I am ok with making =E2=80=9Ctyp=E2=80=9D be = =E2=80=9CSET=E2=80=9D. It is one more distinguishing item. Regardless, I will also put a cautionary note in the security considerations that if issuing SETs to audiences that also receive JWTs, that appropriate care be taken not to confuse if somehow a hacker is able to present the SET as if it were a JWT to gain access (e.g. in an authorization header). Normally this should not be possible as I would assume SETs are passed via something like an HTTP POST back-channel. Phil @independentid www.independentid.com phil.hunt@oracle.com On Aug 24, 2016, at 1:31 PM, John Bradley wrote: The idea for cty was to allow a JWS to encapsulate things like a binary GIF as an example. I think using it for Distinguishing subtypes of JWT would be a stretch. I am most comfortable with A. I think that adding a JWT type claim at the top level may also be useful going forward to avoid misinterpretation. John B. On Aug 24, 2016, at 4:51 PM, Marius Scurtescu wrote= : On Wed, Aug 24, 2016 at 11:07 AM, Phil Hunt wrote: > > The authors have been having a discussion with regards to using the =E2= =80=9Csub=E2=80=9D > claim in the top level. I think it is important to try and get this > discussion back to the main group. My apologies for the long note. I want= ed > to get all the pros and cons on the table (hint: please add if I missed > any)... > > A question remains should =E2=80=9Csub=E2=80=9D be usable at the top leve= l. The downside > of this approach is that a SET could potentially be presented as an acces= s > or iD token and might initially be confused because existing code does no= t > know it needs to look for an =E2=80=9Cevents=E2=80=9D attribute. The SET= and ID Token for > all intensive purposes are the same since a SET just has something extra > (the events claim). > > There is also the question that if OIDC Logout uses it in the top level, > may other events use it? RFC7519 defines =E2=80=9Csub=E2=80=9D as a Strin= g or URI value. > For example, in SCIM events, the =E2=80=9Csub=E2=80=9D value could be a S= CIM Resource URI > that indicates the resource whose state has changed. In OAuth it could b= e > defined as the token identifier of the token that has been revoked. A SE= T > about blacklisting an IP address might put the IP address in sub. > > So there are three options (Option A seems to be favoured so far): > > *A. Sub at Top Level:* =E2=80=9Csub=E2=80=9D generally used to referenc= e the Security > Subject the SET is talking about. It uses a more general english languag= e > intent of subject rather than the traditional use as seen in SAML or Open= ID > Connect. Regardless it is still compliant with RFC7519 (a String or URI)= . > > This would tend to lead to a style of SETs where the envelope carries the > validation information, the type of event, and the subject of the event. > Additional data goes in the payload. An advantage of this style, is that > for many events, the only thing needed is the event type and the subject. > No payloads would be needed. > > For events that don=E2=80=99t want payload, it is probably ok for profili= ng event > standards to define more claims at the top level. They MUST be registered > in the JWT registry. Profiling events can avoid registration by just > putting their attributes/claims in the payload area as described in the > spec. However, this would be inconsistent with those that use payloads > with unregistered claims. I point out that we switched from registered > event URNs to URIs to avoid registration. Hence the move to payload > objects to eliminate registration for attributes/claims. > > This still has the negatives of being confusable as an ID Token by > existing code. There has been a discussion that =E2=80=9Ciss=E2=80=9D and= /or =E2=80=9Caud=E2=80=9D should > actually be different and the receiver should detect that. However in th= e > OIDC Logout case, by design, the =E2=80=9Ciss=E2=80=9D value would be the= same. The =E2=80=9Caud=E2=80=9D > would also likely be the same unless the spec indicates that an alias =E2= =80=9Caud=E2=80=9D > be used even though the audience may be the same entity in both cases. > > *B. Exclusive-Use of Sub:* =E2=80=9Csub=E2=80=9D is interpreted to by tra= ditional > definition and is reserved for OAuth tokens and OIDC Connect usage only. > In order to avoid confusing, all profiling event specs should NOT use > =E2=80=9Csub=E2=80=9D in the top level except for OIDC. > > This has the disadvantage that OIDC requires special handling in terms of > a general use event library, but on the other hand a Logout Event might b= e > handled directly by existing ID Token code. > > This still has the disadvantage that an SET could be confused for an ID > Token. > > *C. No-Top-Level Data:* In order to more aggressively avoid confusion of > SETs as ID Tokens, make it mandatory that SETs may not contain a =E2=80= =9Csub=E2=80=9D > value at the top level. The OIDC Logout Event, for example, would then > include a =E2=80=9Csub=E2=80=9D value in the payload area. This should ca= use existing > relying parties to fail correctly. > > This would provide a maximal difference form a IDToken or access token. > > This would have the advantage that envelopes contain no data, and that > every SET has a payload where the data is found. It requires more parsing > in some cases, but it is at least consistent. While we don=E2=80=99t expe= ct general > processors like in SOAP for distribution (much of it is point to point an= d > very contextually driven), I personally expect to see: > * Development of general purpose libraries and tools that are used > enhance protocols and systems > * Audit and threat analysis systems will be looking at some events > historically. These will tend to merge multiple event feeds. > > Mike Jones also suggested using the *=E2=80=9Ccty=E2=80=9D* (content type= ) header > attribute from JWT. I think most code today has this set to ignore or > fixed as =E2=80=9CJWT=E2=80=9D. I wonder what current implements would f= eel if we > introduced a =E2=80=9Ccty=E2=80=9D value of =E2=80=9CSET=E2=80=9D? Would= that help? > I think it is very important to be able to clearly distinguish different types of JWT tokens. For example, not being able to cross post a Security Event Token as an Id Token. Reading RFC 7519 I don't think cty fits the bill, but I could be wrong. cty is a header parameter used by the crypto algorithm and the default value is JWT. We need to distinguish sub-types of JWT, and it should be a claim inside the JWT. With the above issue in mind, I think option A is the cleanest solution. > Thanks for your comments. > > > Phil > > @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 _______________________________________________ Id-event mailing list Id-event@ietf.org https://www.ietf.org/mailman/listinfo/id-event --001a114aa7ac339386053ad831a9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I was say= ing that cty was wrong for this. =C2=A0

If you look at t= he definition of typ in JWS=C2=A0https://tools.ietf.org/html/rfc7515#pa= ge-13=C2=A0 you can see that it is really intended to be the media type= of the complete JWS/JWE and is omitted or set to JWT if it is a compact JW= T. =C2=A0 =C2=A0 Setting it to SET seems wrong as it is still a JWT. =C2=A0= I was recommending cosidering a JWT=C2=A0


On Aug 24, 2016, at = 5:59 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

John,

Did you mean adding a =E2=80=9Cjw= t_type=E2=80=9D attribute (that becomes a registered JWT claim) OR adding a= new type value for the JWT header =E2=80=9Ctyp=E2=80=9D?=C2=A0 Note for ev= eryone=E2=80=99s convenience from 7519:

The "typ" (t=
ype) Header Parameter defined by [JWS] and [JWE] =
is used
   by JWT applications to declare the media type [IANA.MediaType=
s] of
   this complete JWT.  This is intended for use by the JWT application
   when values that are not JWTs could also be present in an application
   data structure that can contain a JWT object; the application can use
   this value to disambiguate among the different kinds of objects that
   might be present.  It will typically not be used by applications when
   it is already known that the object is a JWT.  This parameter is
   ignored by JWT implementations; any processing of this parameter is
   performed by the JWT application.  If present, it is RECOMMENDED that
   its value be "JWT" to indicate that this object is a JWT.  Whi=
le
   media type names are not case sensitive, it is RECOMMENDED that "JW=
T"
   always be spelled using uppercase characters for compatibility with
   legacy implementations.  Use of this Header Parameter is OPTIONAL.
=


What is concerning is the line tha= t says:=C2=A0
It will typically not be used by applications when
   it is already known that the object is a JWT.  This parameter is
   ignored by JWT implementations; any processing of this parameter=
 is
   performed by the JWT application.  If present, it is RECOMMENDED that
   its value be "JWT" to indicate that this object is a JWT.

If it is typically ignored, then having it =E2=80=9Cty=
p=E2=80=9D be =E2=80=9CSET=E2=80=9D may not help much initially. But at lea=
st it is more definitive.

If the group is comforta=
ble, I am ok with making =E2=80=9Ctyp=E2=80=9D be =E2=80=9CSET=E2=80=9D.=C2=
=A0 It is one more distinguishing item. =C2=A0

Reg=
ardless, I will also put a cautionary note in the security considerations t=
hat if issuing SETs to audiences that also receive JWTs, that appropriate c=
are be taken not to confuse if somehow a hacker is able to present the SET =
as if it were a JWT to gain access (e.g. in an authorization header).=C2=A0=
 Normally this should not be possible as I would assume SETs are passed via=
 something like an HTTP POST back-channel.



<=
span style=3D"border-collapse:separate;line-height:normal;border-spacing:0p=
x">








On Aug 24, 2016, at 1:31 PM, John B=
radley <ve7jtb@ve=
7jtb.com> wrote:

T=
he idea for cty was to allow a JWS to encapsulate things like a binary GIF =
as an example. =C2=A0 I think using it for Distinguishing subtypes of JWT w=
ould be a stretch.

I am most comfortable with A. =C2=A0 =
I think that adding a JWT type claim at the top level may also be useful go=
ing forward to avoid misinterpretation.

John B.
On Aug 24, 2016, at 4:51 PM, Marius Sc=
urtescu <mscu=
rtescu@google.com> wrote:

On Wed, Aug 24, 2016 at 11:07 AM, Phil Hunt=C2=A0=
<phil.hunt@oracle.com>=C2=A0wrote:
<=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pa=
dding-left:1ex">

The=
 authors have been having a discussion with regards to using the =E2=80=9Cs=
ub=E2=80=9D claim in the top level. I think it is important to try and get =
this discussion back to the main group. My apologies for the long note. I w=
anted to get all the pros and cons on the table (hint: =C2=A0please add if =
I missed any)...

A question remains should =E2=80=
=9Csub=E2=80=9D be usable at the top level.=C2=A0 The downside of this appr=
oach is that a SET could potentially be presented as an access or iD token =
and might initially be confused because existing code does not know it need=
s to look for an =E2=80=9Cevents=E2=80=9D attribute.=C2=A0 The SET and ID T=
oken for all intensive purposes are the same since a SET just has something=
 extra (the events claim).

There is also the quest=
ion that if OIDC Logout uses it in the top level, may other events use it? =
RFC7519 defines =E2=80=9Csub=E2=80=9D as a String or URI value. For example=
, in SCIM events, the =E2=80=9Csub=E2=80=9D value could be a SCIM Resource =
URI that indicates the resource whose state has changed.=C2=A0 In OAuth it =
could be defined as the token identifier of the token that has been revoked=
.=C2=A0 A SET about blacklisting an IP address might put the IP address in =
sub.

So there are three options (Option A seems to=
 be favoured so far): =C2=A0

A.=C2=A0 Sub at To=
p Level:=C2=A0=C2=A0=E2=80=9Csub=E2=80=9D generally used t=
o reference the Security Subject the SET is talking about.=C2=A0 It uses a =
more general english language intent of subject rather than the traditional=
 use as seen in SAML or OpenID Connect.=C2=A0 Regardless it is still compli=
ant with RFC7519 (a String or URI).

This would ten=
d to lead to a style of SETs where the envelope carries the validation info=
rmation, the type of event, and the subject of the event. Additional data g=
oes in the payload. An advantage of this style, is that for many events, th=
e only thing needed is the event type and the subject.=C2=A0 No payloads wo=
uld be needed.

For events that don=E2=80=99t =
want payload, it is probably ok for profiling event standards to define mor=
e claims at the top level. They MUST be registered in the JWT registry. Pro=
filing events can avoid registration by just putting their attributes/claim=
s in the payload area as described in the spec.=C2=A0 However, this would b=
e inconsistent with those that use payloads with unregistered claims.=C2=A0=
 I point out that we switched from registered event URNs to URIs to avoid r=
egistration.=C2=A0 Hence the move to payload objects to eliminate registrat=
ion for attributes/claims. =C2=A0

This still=
 has the negatives of being confusable as an ID Token by existing code. The=
re has been a discussion that =E2=80=9Ciss=E2=80=9D and/or =E2=80=9Caud=E2=
=80=9D should actually be different and the receiver should detect that.=C2=
=A0 However in the OIDC Logout case, by design, the =E2=80=9Ciss=E2=80=9D v=
alue would be the same.=C2=A0 The =E2=80=9Caud=E2=80=9D would also likely b=
e the same unless the spec indicates that an alias =E2=80=9Caud=E2=80=9D be=
 used even though the audience may be the same entity in both cases.
<=
div>
B. Exclusive-Use of Sub:=C2=A0=E2=80=
=9Csub=E2=80=9D is interpreted to by traditional definition and is reserved=
 for OAuth tokens and OIDC Connect usage only.=C2=A0 In order to =C2=A0avoi=
d confusing, all profiling event specs should NOT use =E2=80=9Csub=E2=80=9D=
 in the top level except for OIDC.

This has the di=
sadvantage that OIDC requires special handling in terms of a general use ev=
ent library, but on the other hand a Logout Event might be handled directly=
 by existing ID Token code.

This still has the dis=
advantage that an SET could be confused for an ID Token.

C. No-Top-Level Data:=C2=A0In order to more aggr=
essively avoid confusion of SETs as ID Tokens, make it mandatory that SETs =
may not contain a =E2=80=9Csub=E2=80=9D value at the top level.=C2=A0 The O=
IDC Logout Event, for example, would then include a =E2=80=9Csub=E2=80=9D v=
alue in the payload area. This should cause existing relying parties to fai=
l correctly. =C2=A0

This would provide a maximal d=
ifference form a IDToken or access token.

This wou=
ld have the advantage that envelopes contain no data, and that every SET ha=
s a payload where the data is found. It requires more parsing in some cases=
, but it is at least consistent. While we don=E2=80=99t expect general proc=
essors like in SOAP for distribution (much of it is point to point and very=
 contextually driven), I personally expect to see:
=C2=A0=
=C2=A0* =C2=A0Development of general purpose libraries and tools tha=
t are used enhance protocols and systems=C2=A0
=C2=A0=C2=A0=
* =C2=A0Audit and threat analysis systems will be looking at some ev=
ents historically. These will tend to merge multiple event feeds.

Mike Jones also suggested using the=C2=A0=
=E2=80=9Ccty=E2=80=9D=C2=A0(content type) header attribute=
 from JWT.=C2=A0 I think most code today has this set to ignore or fixed as=
 =E2=80=9CJWT=E2=80=9D.=C2=A0 I wonder what current implements would feel i=
f we introduced a =E2=80=9Ccty=E2=80=9D value of =E2=80=9CSET=E2=80=9D?=C2=
=A0 Would that help?

I think it=
 is very important to be able to clearly distinguish different types of JWT=
 tokens. For example, not being able to cross post a Security Event Token a=
s an Id Token.=C2=A0

Reading=C2=A0RFC 7519 I don&#=
39;t think cty fits the bill, but I could be wrong. cty is a header paramet=
er used by the crypto algorithm and the default value is JWT. We need to di=
stinguish sub-types of JWT, and it should be a claim inside the JWT.
<=
div>
With the above issue in mind, I think option A is the cl=
eanest solution.



Thanks for your comments.
=


<=
br>

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


<=
span style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-w=
eight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-tr=
ansform:none;white-space:normal;word-spacing:0px;float:none;display:inline!=
important">_______________________________________________
Id-event mailing li=
st
Id-event@ietf.org
https://www.ietf.org/mail=
man/listinfo/id-event

____= ___________________________________________
Id-event mailing listId-event@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/id-event
<= /blockquote>


= --001a114aa7ac339386053ad831a9-- From nobody Wed Aug 24 14:46:59 2016 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 099B512D60D for ; Wed, 24 Aug 2016 14:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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] 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 zTO_q3kSkPnW for ; Wed, 24 Aug 2016 14:46:54 -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 245AF12B00E for ; Wed, 24 Aug 2016 14:46:54 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id 52so14356115qtq.3 for ; Wed, 24 Aug 2016 14:46:54 -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=0/uHS2kDjVglhBE0oFZswtoEtit6ydb+ORO0Yn/0yRA=; b=k5dZy98dgLLYZV02mMDVSOUulxQAboENuiJgUWD+e20KNd0GEhwmnG+3nvkIr7OEkG VLC8n8UMoO7/eVyJZGNfBb+KvqYm6L0tHCj+PhFBEi3pVdgLwC1kiZXLxmxKZRfJaUF9 WjAoTy06h1kscaNBRsXDVtymRMFkDSaYToS2sUNixBk8ngXRJEbjmHhkOvboAHUaHVbp vL33HGUcuA6XHh0NSCeFrNxjHOvcnBMfLP/pQ+mX94GF4z+0Okcac/H0s3PF3FZnqjOg 9jgC8CUl8X/6Y6QPW1ExEcOsOmPUd01ILNYwMqD0TFCX9XFZZTLl0SFeHR/uLSaXEBIH OOlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0/uHS2kDjVglhBE0oFZswtoEtit6ydb+ORO0Yn/0yRA=; b=R9oyQmUc470/Qsc0D75zg9rSGHV7pPIKOuOuH81UhrQT4TY6u8r/BRHyd9nMPTtrw0 Kj0dFypq9oJNijxLx7XTnwv5C+NNpPpNij1sJbvHyLFWDCQDvRdE3Mrd9K560VGJt7cq wBWw5ZgTqXgBLTDlZg7iQDk/YpCG7nJwN73Z9zBEbWLvVDiHT+wyP1SS2HATuaylu0P6 O1O6qPti1n2zD4t0u/zDzRubbZHIROO0s8ncm2m6CGqqO7fD8mJZgdTeH7jPI+7kWnDm gdm1Zg6gOwsQqzTaHbD2u7Arirysg8lTUk/5TGiZIunkdoiTbRBZGrmzivOMuXGeUTS0 lBKA== X-Gm-Message-State: AE9vXwNMJwHU5CuhvbHOfAfXv3D8KCOGDB+vv+2BLgS+KCq0m4zS6NkPNqz0lULmGafWJZZRRl+4eTE256oM/DvP X-Received: by 10.200.33.200 with SMTP id 8mr6136969qtz.137.1472075213163; Wed, 24 Aug 2016 14:46:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.105.3 with HTTP; Wed, 24 Aug 2016 14:46:51 -0700 (PDT) X-Originating-IP: [181.201.108.96] In-Reply-To: References: <3D5305B0-0365-4B07-9D35-81F0B7B04FF2@oracle.com> <382F27DF-A35A-43F3-8C2E-CE3D8ABC4ADB@ve7jtb.com> From: John Bradley Date: Wed, 24 Aug 2016 18:46:51 -0300 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=001a11410c8e29e8c5053ad838ea Archived-At: Cc: Marius Scurtescu , "id-event@ietf.org" , Phil Hunt Subject: Re: [Id-event] Discussion on use of "sub" and confusion as ID Token X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 24 Aug 2016 21:46:58 -0000 --001a11410c8e29e8c5053ad838ea Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes, on one of the calls we talked about it being a separate spec to register the claim and then events could use it. On Wed, Aug 24, 2016 at 6:31 PM, Mike Jones wrote: > A spec could create a top-level JWT type claim, but I=E2=80=99d assert th= at it=E2=80=99s > out of scope for the Events spec. It would probably need to be its own > spec and say basically =E2=80=9Cuse it if you=E2=80=99re in use cases in = which it=E2=80=99s useful > to distinguish between things=E2=80=9D. > > > > *From:* Id-event [mailto:id-event-bounces@ietf.org] *On Behalf Of *John > Bradley > *Sent:* Wednesday, August 24, 2016 2:24 PM > *To:* Phil Hunt > *Cc:* id-event@ietf.org; Marius Scurtescu > *Subject:* Re: [Id-event] Discussion on use of "sub" and confusion as ID > Token > > > > I was saying that cty was wrong for this. > > > > If you look at the definition of typ in JWS https://tools.ietf.org/ > html/rfc7515#page-13 you can see that it is really intended to be the > media type of the complete JWS/JWE and is omitted or set to JWT if it is = a > compact JWT. Setting it to SET seems wrong as it is still a JWT. I > was recommending considering a JWT top level claim in the JWT registry. > > > > John B. > > > > > > On Aug 24, 2016, at 5:59 PM, Phil Hunt wrote: > > > > John, > > > > Did you mean adding a =E2=80=9Cjwt_type=E2=80=9D attribute (that becomes = a registered JWT > claim) OR adding a new type value for the JWT header =E2=80=9Ctyp=E2=80= =9D? Note for > everyone=E2=80=99s convenience from 7519: > > > > The "typ" (type) Header Parameter defined by [JWS ] and [JWE ] is used > > by JWT applications to declare the media type [IANA.MediaTypes ] of > > this complete JWT. This is intended for use by the JWT application > > when values that are not JWTs could also be present in an application > > data structure that can contain a JWT object; the application can use > > this value to disambiguate among the different kinds of objects that > > might be present. It will typically not be used by applications when > > it is already known that the object is a JWT. This parameter is > > ignored by JWT implementations; any processing of this parameter is > > performed by the JWT application. If present, it is RECOMMENDED that > > its value be "JWT" to indicate that this object is a JWT. While > > media type names are not case sensitive, it is RECOMMENDED that "JWT" > > always be spelled using uppercase characters for compatibility with > > legacy implementations. Use of this Header Parameter is OPTIONAL. > > > > > > What is concerning is the line that says: > > It will typically not be used by applications when > > it is already known that the object is a JWT. *This parameter is* > > * ignored by JWT implementations*; any processing of this parameter is > > performed by the JWT application. If present, it is RECOMMENDED that > > its value be "JWT" to indicate that this object is a JWT. > > > > If it is typically ignored, then having it =E2=80=9Ctyp=E2=80=9D be =E2= =80=9CSET=E2=80=9D may not help > much initially. But at least it is more definitive. > > > > If the group is comfortable, I am ok with making =E2=80=9Ctyp=E2=80=9D be= =E2=80=9CSET=E2=80=9D. It is > one more distinguishing item. > > > > Regardless, I will also put a cautionary note in the security > considerations that if issuing SETs to audiences that also receive JWTs, > that appropriate care be taken not to confuse if somehow a hacker is able > to present the SET as if it were a JWT to gain access (e.g. in an > authorization header). Normally this should not be possible as I would > assume SETs are passed via something like an HTTP POST back-channel. > > > > Phil > > > > @independentid > > www.independentid.com > > phil.hunt@oracle.com > > > > > > > > > > On Aug 24, 2016, at 1:31 PM, John Bradley wrote: > > > > The idea for cty was to allow a JWS to encapsulate things like a binary > GIF as an example. I think using it for Distinguishing subtypes of JWT > would be a stretch. > > > > I am most comfortable with A. I think that adding a JWT type claim at > the top level may also be useful going forward to avoid misinterpretation= . > > > > John B. > > On Aug 24, 2016, at 4:51 PM, Marius Scurtescu > wrote: > > > > On Wed, Aug 24, 2016 at 11:07 AM, Phil Hunt wrote: > > > > The authors have been having a discussion with regards to using the =E2= =80=9Csub=E2=80=9D > claim in the top level. I think it is important to try and get this > discussion back to the main group. My apologies for the long note. I want= ed > to get all the pros and cons on the table (hint: please add if I missed > any)... > > > > A question remains should =E2=80=9Csub=E2=80=9D be usable at the top leve= l. The downside > of this approach is that a SET could potentially be presented as an acces= s > or iD token and might initially be confused because existing code does no= t > know it needs to look for an =E2=80=9Cevents=E2=80=9D attribute. The SET= and ID Token for > all intensive purposes are the same since a SET just has something extra > (the events claim). > > > > There is also the question that if OIDC Logout uses it in the top level, > may other events use it? RFC7519 defines =E2=80=9Csub=E2=80=9D as a Strin= g or URI value. > For example, in SCIM events, the =E2=80=9Csub=E2=80=9D value could be a S= CIM Resource URI > that indicates the resource whose state has changed. In OAuth it could b= e > defined as the token identifier of the token that has been revoked. A SE= T > about blacklisting an IP address might put the IP address in sub. > > > > So there are three options (Option A seems to be favoured so far): > > > > *A. Sub at Top Level:* =E2=80=9Csub=E2=80=9D generally used to referenc= e the Security > Subject the SET is talking about. It uses a more general english languag= e > intent of subject rather than the traditional use as seen in SAML or Open= ID > Connect. Regardless it is still compliant with RFC7519 (a String or URI)= . > > > > This would tend to lead to a style of SETs where the envelope carries the > validation information, the type of event, and the subject of the event. > Additional data goes in the payload. An advantage of this style, is that > for many events, the only thing needed is the event type and the subject. > No payloads would be needed. > > > > For events that don=E2=80=99t want payload, it is probably ok for profili= ng event > standards to define more claims at the top level. They MUST be registered > in the JWT registry. Profiling events can avoid registration by just > putting their attributes/claims in the payload area as described in the > spec. However, this would be inconsistent with those that use payloads > with unregistered claims. I point out that we switched from registered > event URNs to URIs to avoid registration. Hence the move to payload > objects to eliminate registration for attributes/claims. > > > > This still has the negatives of being confusable as an ID Token by > existing code. There has been a discussion that =E2=80=9Ciss=E2=80=9D and= /or =E2=80=9Caud=E2=80=9D should > actually be different and the receiver should detect that. However in th= e > OIDC Logout case, by design, the =E2=80=9Ciss=E2=80=9D value would be the= same. The =E2=80=9Caud=E2=80=9D > would also likely be the same unless the spec indicates that an alias =E2= =80=9Caud=E2=80=9D > be used even though the audience may be the same entity in both cases. > > > > *B. Exclusive-Use of Sub:* =E2=80=9Csub=E2=80=9D is interpreted to by tra= ditional > definition and is reserved for OAuth tokens and OIDC Connect usage only. > In order to avoid confusing, all profiling event specs should NOT use > =E2=80=9Csub=E2=80=9D in the top level except for OIDC. > > > > This has the disadvantage that OIDC requires special handling in terms of > a general use event library, but on the other hand a Logout Event might b= e > handled directly by existing ID Token code. > > > > This still has the disadvantage that an SET could be confused for an ID > Token. > > > > *C. No-Top-Level Data:* In order to more aggressively avoid confusion of > SETs as ID Tokens, make it mandatory that SETs may not contain a =E2=80= =9Csub=E2=80=9D > value at the top level. The OIDC Logout Event, for example, would then > include a =E2=80=9Csub=E2=80=9D value in the payload area. This should ca= use existing > relying parties to fail correctly. > > > > This would provide a maximal difference form a IDToken or access token. > > > > This would have the advantage that envelopes contain no data, and that > every SET has a payload where the data is found. It requires more parsing > in some cases, but it is at least consistent. While we don=E2=80=99t expe= ct general > processors like in SOAP for distribution (much of it is point to point an= d > very contextually driven), I personally expect to see: > > * Development of general purpose libraries and tools that are used > enhance protocols and systems > > * Audit and threat analysis systems will be looking at some events > historically. These will tend to merge multiple event feeds. > > > > Mike Jones also suggested using the *=E2=80=9Ccty=E2=80=9D* (content type= ) header > attribute from JWT. I think most code today has this set to ignore or > fixed as =E2=80=9CJWT=E2=80=9D. I wonder what current implements would f= eel if we > introduced a =E2=80=9Ccty=E2=80=9D value of =E2=80=9CSET=E2=80=9D? Would= that help? > > > > I think it is very important to be able to clearly distinguish different > types of JWT tokens. For example, not being able to cross post a Security > Event Token as an Id Token. > > > > Reading RFC 7519 I don't think cty fits the bill, but I could be wrong. > cty is a header parameter used by the crypto algorithm and the default > value is JWT. We need to distinguish sub-types of JWT, and it should be a > claim inside the JWT. > > > > With the above issue in mind, I think option A is the cleanest solution. > > > > > > > > Thanks for your comments. > > > > > > Phil > > > > @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 > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > > > --001a11410c8e29e8c5053ad838ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes, =C2=A0on one of the calls we talked about it being a = separate spec to register the claim and then events could use it.

On Wed, Aug 24, 2016 = at 6:31 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

A spec could create a top-level JWT t= ype claim, but I=E2=80=99d assert that it=E2=80=99s out of scope for the Ev= ents spec.=C2=A0 It would probably need to be its own spec and say basically =E2=80=9Cuse it if you=E2=80=99re in use cases in which it=E2=80= =99s useful to distinguish between things=E2=80=9D.

=C2=A0

From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of John Bradley
Sent: Wednesday, August 24, 2016 2:24 PM
To: Phil Hunt <phil.hunt@oracle.com>
Cc: id-event@= ietf.org; Marius Scurtescu <mscurtescu@google.com>
Subject: Re: [Id-event] Discussion on use of "sub" and con= fusion as ID Token

=C2=A0

I was saying that cty was wrong for this. =C2=A0<= /u>

=C2=A0

If you look at the definition of typ in JWS=C2=A0http= s://tools.ietf.org/html/rfc7515#page-13=C2=A0 you can see that it = is really intended to be the media type of the complete JWS/JWE and is omitted or set to JWT if it is a compact JWT. =C2=A0 =C2=A0 Setting it to = SET seems wrong as it is still a JWT. =C2=A0 I was recommending considering= a JWT top level claim in the JWT registry.

=C2=A0

John B.

=C2=A0

=C2=A0

On Aug 24, 2016, at 5:59 PM, Phil Hunt <phil.hunt@oracle.com= > wrote:

=C2=A0

John,

=C2=A0

Did you mean adding a =E2=80=9Cjwt_type=E2=80=9D att= ribute (that becomes a registered JWT claim) OR adding a new type value for= the JWT header =E2=80=9Ctyp=E2=80=9D?=C2=A0 Note for everyone=E2=80=99s co= nvenience from 7519:

=C2=A0

The "typ" (type) Header Parameter defined by [JWS] and [JWE] is used
=C2=A0=C2=A0 by JWT applications to declare the media type [IANA.MediaTypes] of
=C2=A0=C2=A0 this complete JWT.=C2=A0 This is intended for use by the =
JWT application
=C2=A0=C2=A0 when values that are not JWTs could also be present in an=
 application
=C2=A0=C2=A0 data structure that can contain a JWT object; the applica=
tion can use
=C2=A0=C2=A0 this value to disambiguate among the different kinds of o=
bjects that
=C2=A0=C2=A0 might be present.=C2=A0 It will typically not be used by =
applications when
=C2=A0=C2=A0 it is already known that the object is a JWT.=C2=A0 This =
parameter is
=C2=A0=C2=A0 ignored by JWT implementations; any processing of this pa=
rameter is
=C2=A0=C2=A0 performed by the JWT application.=C2=A0 If present, it is=
 RECOMMENDED that
=C2=A0=C2=A0 its value be "JWT" to indicate that this object=
 is a JWT.=C2=A0 While
=C2=A0=C2=A0 media type names are not case sensitive, it is RECOMMENDE=
D that "JWT"
=C2=A0=C2=A0 always be spelled using uppercase characters for compatib=
ility with
=C2=A0=C2=A0 legacy implementations.=C2=A0 Use of this Header Paramete=
r is OPTIONAL.

=C2=A0

=C2=A0

What is concerning is the line that says:=C2=A0

It will typically not be used by applications when
=C2=A0=C2=A0 it is already known that the object is a JWT.=C2=A0 This parameter is
=C2=A0=C2=A0 ignored by JWT implementations; any process=
ing of this parameter is
=C2=A0=C2=A0 performed by the JWT application.=C2=A0 If present, it is=
 RECOMMENDED that
=C2=A0=C2=A0 its value be "JWT" to indicate that this object=
 is a JWT.

=C2=A0

If it is typically ignored, then having it =E2=80=9C= typ=E2=80=9D be =E2=80=9CSET=E2=80=9D may not help much initially. But at l= east it is more definitive.

=C2=A0

If the group is comfortable, I am ok with making =E2= =80=9Ctyp=E2=80=9D be =E2=80=9CSET=E2=80=9D.=C2=A0 It is one more distingui= shing item. =C2=A0

=C2=A0

Regardless, I will also put a cautionary note in the= security considerations that if issuing SETs to audiences that also receiv= e JWTs, that appropriate care be taken not to confuse if somehow a hacker i= s able to present the SET as if it were a JWT to gain access (e.g. in an authorization header).=C2=A0 Normall= y this should not be possible as I would assume SETs are passed via somethi= ng like an HTTP POST back-channel.

=C2=A0

Phil

=C2=A0

@independentid

phil.hunt@oracle.com

=C2=A0

=C2=A0

=C2=A0<= /p>

=C2=A0

On Aug 24, 2016, at 1:31 PM, John Bradley <ve7jtb@ve7jtb.com> = wrote:

=C2=A0

The idea for cty was to allow a JWS to encapsulate t= hings like a binary GIF as an example. =C2=A0 I think using it for Distingu= ishing subtypes of JWT would be a stretch.

=C2=A0

I am most comfortable with A. =C2=A0 I think that ad= ding a JWT type claim at the top level may also be useful going forward to = avoid misinterpretation.

=C2=A0

John B.

On Aug 24, 2016, at 4:51 PM, Marius Scurtescu <mscurtescu@google.= com> wrote:

=C2=A0

On Wed, Aug 24, 2016 at 11:07 AM, Phil Hunt= =C2=A0<= phil.hunt@oracle.com>=C2=A0wrote:

=C2=A0

The authors have been having a discussion with reg= ards to using the =E2=80=9Csub=E2=80=9D claim in the top level. I think it = is important to try and get this discussion back to the main group. My apologies for the long note. I wanted to get all the pros and cons on t= he table (hint: =C2=A0please add if I missed any)...

=C2=A0

A question remains should =E2=80=9Csub=E2=80=9D be= usable at the top level.=C2=A0 The downside of this approach is that a SET= could potentially be presented as an access or iD token and might initially be confused because existing code does not know it needs to look= for an =E2=80=9Cevents=E2=80=9D attribute.=C2=A0 The SET and ID Token for = all intensive purposes are the same since a SET just has something extra (t= he events claim).

=C2=A0

There is also the question that if OIDC Logout use= s it in the top level, may other events use it? RFC7519 defines =E2=80=9Csu= b=E2=80=9D as a String or URI value. For example, in SCIM events, the =E2=80=9Csub=E2=80=9D value could be a SCIM Resource URI that indicate= s the resource whose state has changed.=C2=A0 In OAuth it could be defined = as the token identifier of the token that has been revoked.=C2=A0 A SET abo= ut blacklisting an IP address might put the IP address in sub.

=C2=A0

So there are three options (Option A seems to be f= avoured so far): =C2=A0

=C2=A0

A.=C2=A0 Sub at Top Level:= =C2=A0=C2=A0=E2=80=9Csub=E2=80=9D generally used to reference the Security Subject the SET is talking about.= =C2=A0 It uses a more general english language intent of subject rather tha= n the traditional use as seen in SAML or OpenID Connect.=C2=A0 Regardless i= t is still compliant with RFC7519 (a String or URI).

=C2=A0

This would tend to lead to a style of SETs where t= he envelope carries the validation information, the type of event, and the = subject of the event. Additional data goes in the payload. An advantage of this style, is that for many events, the only= thing needed is the event type and the subject.=C2=A0 No payloads would be= needed.

=C2=A0

For events that don=E2=80=99t want payload, it is = probably ok for profiling event standards to define more claims at the top = level. They MUST be registered in the JWT registry. Profiling events can avoid registration by just putting their attributes/claims in t= he payload area as described in the spec.=C2=A0 However, this would be inco= nsistent with those that use payloads with unregistered claims.=C2=A0 I poi= nt out that we switched from registered event URNs to URIs to avoid registration.=C2=A0 Hence the move to payload object= s to eliminate registration for attributes/claims. =C2=A0

=C2=A0

This still has the negatives of being confusable a= s an ID Token by existing code. There has been a discussion that =E2=80=9Ci= ss=E2=80=9D and/or =E2=80=9Caud=E2=80=9D should actually be different and t= he receiver should detect that.=C2=A0 However in the OIDC Logout case, by des= ign, the =E2=80=9Ciss=E2=80=9D value would be the same.=C2=A0 The =E2=80=9C= aud=E2=80=9D would also likely be the same unless the spec indicates that a= n alias =E2=80=9Caud=E2=80=9D be used even though the audience may be the s= ame entity in both cases.

=C2=A0

B. Exclusive-Use of Sub:=C2= =A0=E2=80=9Csub=E2=80=9D is interpreted to by traditional definition and is reserved for OAuth toke= ns and OIDC Connect usage only.=C2=A0 In order to =C2=A0avoid confusing, al= l profiling event specs should NOT use =E2=80=9Csub=E2=80=9D in the top lev= el except for OIDC.

=C2=A0

This has the disadvantage that OIDC requires speci= al handling in terms of a general use event library, but on the other hand = a Logout Event might be handled directly by existing ID Token code.

=C2=A0

This still has the disadvantage that an SET could = be confused for an ID Token.

=C2=A0

C. No-Top-Level Data:=C2=A0<= /span>In order to more aggressively avoid confusion of SETs as ID Tokens, make it m= andatory that SETs may not contain a =E2=80=9Csub=E2=80=9D value at the top= level.=C2=A0 The OIDC Logout Event, for example, would then include a =E2= =80=9Csub=E2=80=9D value in the payload area. This should cause existing relying parties to fail correctly. =C2=A0

=C2=A0

This would provide a maximal difference form a IDT= oken or access token.

=C2=A0

This would have the advantage that envelopes conta= in no data, and that every SET has a payload where the data is found. It re= quires more parsing in some cases, but it is at least consistent. While we don=E2=80=99t expect general processors like in= SOAP for distribution (much of it is point to point and very contextually = driven), I personally expect to see:

=C2=A0=C2=A0* =C2=A0Development of ge= neral purpose libraries and tools that are used enhance protocols and syste= ms=C2=A0

=C2=A0=C2=A0* =C2=A0Audit and threat = analysis systems will be looking at some events historically. These will te= nd to merge multiple event feeds.

=C2=A0

Mike Jones also suggested using the=C2=A0=E2=80=9Ccty=E2=80=9D=C2=A0(content type) header at= tribute from JWT.=C2=A0 I think most code today has this set to ignore or fixed as =E2= =80=9CJWT=E2=80=9D.=C2=A0 I wonder what current implements would feel if we= introduced a =E2=80=9Ccty=E2=80=9D value of =E2=80=9CSET=E2=80=9D?=C2=A0 W= ould that help?

=C2=A0

I think it is very important to be able to clearly= distinguish different types of JWT tokens. For example, not being able to = cross post a Security Event Token as an Id Token.=C2=A0

=C2=A0

Reading=C2=A0RFC 7519 I don't think cty fits t= he bill, but I could be wrong. cty is a header parameter used by the crypto= algorithm and the default value is JWT. We need to distinguish sub-types of JWT, and it should be a claim inside the JWT.

=C2=A0

With the above issue in mind, I think option A is = the cleanest solution.

=C2=A0

=C2=A0

=C2=A0

Thanks for your comments.

=C2=A0

=C2=A0

Phil

=C2=A0

@independentid

phil.hunt@oracle.com

=C2=A0

=C2=A0

=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

=C2=A0


--001a11410c8e29e8c5053ad838ea-- From nobody Wed Aug 24 14:50:36 2016 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 2A22512D1C8 for ; Wed, 24 Aug 2016 14:50:34 -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 1qF3INYGcBJu for ; Wed, 24 Aug 2016 14:50:30 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0128.outbound.protection.outlook.com [104.47.38.128]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E788E12D76E for ; Wed, 24 Aug 2016 14:50: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=58pfjQLu6D2bivo97ehisp+BQxwfQ1Yx6DbNzctHI0U=; b=OESA4CBFdloKAjUxbK8BLg3brQ4hzfgAxIkgcaMiJ3JnA9HJZLi44SOe6pHxrqJvZ4qdXdfB8xwaFWMzdiSCPIVWDZn1LaPi5pRUYjQxgVWntCpQ8DuZEmDTvG1ZqJNaCxGtJLydxpIL52KLiMpnQzPk9+30CuyM2lO/0S1II4U= Received: from SN1PR0301MB1645.namprd03.prod.outlook.com (10.162.130.139) by SN1PR0301MB1645.namprd03.prod.outlook.com (10.162.130.139) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.13; Wed, 24 Aug 2016 21:50:28 +0000 Received: from SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) by SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) with mapi id 15.01.0587.013; Wed, 24 Aug 2016 21:50:28 +0000 From: Mike Jones To: John Bradley Thread-Topic: [Id-event] Discussion on use of "sub" and confusion as ID Token Thread-Index: AQHR/jJ6Kzu5WyrJDU6lijc1KOHPZaBYhVKAgAALW4CAAAfQgIAABtOAgAABn1CAAAS3gIAAAHaQ Date: Wed, 24 Aug 2016 21:50:27 +0000 Message-ID: References: <3D5305B0-0365-4B07-9D35-81F0B7B04FF2@oracle.com> <382F27DF-A35A-43F3-8C2E-CE3D8ABC4ADB@ve7jtb.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [64.134.242.226] x-ms-office365-filtering-correlation-id: b8c4a464-6937-4f17-9df4-08d3cc68a96d x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1645; 6:Jx95fHXYL5SlZg6hQ0bl+vhfi0e9qVSL3gwSi7M5hnG66keFvl8uM9Tx3pxS8h8TpK3klFjZ1CYeVLb6oWVBbtuhDA6B8jgkEdC8BrEuodYWuhxLnzBOzxEppZ4170NcGJIt3lGyFyilwkKBlDhbPJBHUD2mTlgIigv4Syh5nKm+Bpv3r4dHFvWpMjMB52RE4SZyA2TLO2r1+D+uY5b9/qD5+FwYLaqo8f2JnfzRKGF4esqCY779/yYn/iYxmtVkwr60H8sQ/p1wrbHN/YHSwvSrla5KSTbWkd/KKeWd5YGMuY48kPGSkI3xDnhAEx05x2yr+QZaPB51erH/GPWLSg==; 5:gU1ee2CiAL99KJlQJse6BNkrI+HS+YEBZQL+1/oPUbe0kOWQJ55FU++AXf1kIzra/+k1Lwu4ml7IrAk835gdL9HTR9sAcJ27yu4FxPbBoeuqkXADZIVFqNlU4kKV4jC6XvqkawbPyxBqcB88iiMx4g==; 24:B7rwEf/WJY/rWLoijUHFnNMN65DcgNtwbJxgdbxRnhWB4ODdvJq6xVUbjjwnRvlDnsWAPuT72FwlMtxT5AzgSuwpygtlK5mWkBcrEq4CVcU=; 7:B/cy9z0bbl6srgBgjDGa6abEZS9YfDTRxvkdcqRkZHGjGR9ooKcGx/nNoktX8DQNanNvLPDyh/7au3ljeQC1OkZ9LNDUHZuffKwtISS/O+0weDjNYo55e3xXVams3Dzlt6l/KHzKE6EWD56F3doh3pM9T482qcSV6JkJ5uoBVIOpXbOFwVifI9t+G2DipHYz0e01uMFwkvakfVQfFjZsOqF+KJEUcI/4nx2gK5+XkMrvZPLl6tUsCLcRsRdOCcbB x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1645; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(192374486261705)(211936372134217)(21748063052155)(21532816269658)(146099531331640)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:SN1PR0301MB1645; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1645; x-forefront-prvs: 0044C17179 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(24454002)(199003)(51444003)(377454003)(189002)(106116001)(6116002)(3846002)(93886004)(102836003)(16236675004)(33656002)(76576001)(76176999)(54356999)(86362001)(50986999)(99286002)(101416001)(66066001)(68736007)(86612001)(87936001)(19617315012)(74316002)(586003)(3280700002)(105586002)(3660700001)(19625215002)(122556002)(7696003)(7846002)(7906003)(15975445007)(8676002)(11100500001)(5660300001)(92566002)(2900100001)(8936002)(7736002)(106356001)(110136002)(5002640100001)(790700001)(19580395003)(77096005)(2950100001)(81156014)(10090500001)(19609705001)(189998001)(97736004)(2906002)(10400500002)(9686002)(4326007)(19300405004)(19580405001)(8990500004)(5005710100001)(81166006)(10290500002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0301MB1645; H:SN1PR0301MB1645.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB164555B61381414BA03FCA26F5EA0SN1PR0301MB1645_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Aug 2016 21:50:27.8318 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1645 Archived-At: Cc: Marius Scurtescu , "id-event@ietf.org" , Phil Hunt Subject: Re: [Id-event] Discussion on use of "sub" and confusion as ID Token X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 24 Aug 2016 21:50:35 -0000 --_000_SN1PR0301MB164555B61381414BA03FCA26F5EA0SN1PR0301MB1645_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB3b3VsZCBzdHJvbmdseSBvcHBvc2UgZXZlbnRzIHJlcXVpcmluZyB1c2Ugb2YgaXQsIGJlY2F1 c2UgaXTigJlzIG5vdCBuZWNlc3NhcnkgZm9yIGFuIGV2ZW50IHN0cmVhbS4gIEl0IHdvdWxkIGJl IHVubmVjZXNzYXJ5IGJhZ2dhZ2UuDQoNCkkgYWdyZWUgd2l0aCBQaGlsIHRoYXQgc3Ryb25nIHNl Y3VyaXR5IGNvbnNpZGVyYXRpb25zIGlzIGFzIGZhciBhcyB3ZSBzaG91bGQgZ28gaW4gdGhlIEV2 ZW50IFRva2VuIHNwZWMuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IEpvaG4gQnJhZGxleSBbbWFpbHRvOnZl N2p0YkB2ZTdqdGIuY29tXQ0KU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMjQsIDIwMTYgMjo0NyBQ TQ0KVG86IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4NCkNjOiBQaGls IEh1bnQgPHBoaWwuaHVudEBvcmFjbGUuY29tPjsgaWQtZXZlbnRAaWV0Zi5vcmc7IE1hcml1cyBT Y3VydGVzY3UgPG1zY3VydGVzY3VAZ29vZ2xlLmNvbT4NClN1YmplY3Q6IFJlOiBbSWQtZXZlbnRd IERpc2N1c3Npb24gb24gdXNlIG9mICJzdWIiIGFuZCBjb25mdXNpb24gYXMgSUQgVG9rZW4NCg0K WWVzLCAgb24gb25lIG9mIHRoZSBjYWxscyB3ZSB0YWxrZWQgYWJvdXQgaXQgYmVpbmcgYSBzZXBh cmF0ZSBzcGVjIHRvIHJlZ2lzdGVyIHRoZSBjbGFpbSBhbmQgdGhlbiBldmVudHMgY291bGQgdXNl IGl0Lg0KDQpPbiBXZWQsIEF1ZyAyNCwgMjAxNiBhdCA2OjMxIFBNLCBNaWtlIEpvbmVzIDxNaWNo YWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNv bT4+IHdyb3RlOg0KQSBzcGVjIGNvdWxkIGNyZWF0ZSBhIHRvcC1sZXZlbCBKV1QgdHlwZSBjbGFp bSwgYnV0IEnigJlkIGFzc2VydCB0aGF0IGl04oCZcyBvdXQgb2Ygc2NvcGUgZm9yIHRoZSBFdmVu dHMgc3BlYy4gIEl0IHdvdWxkIHByb2JhYmx5IG5lZWQgdG8gYmUgaXRzIG93biBzcGVjIGFuZCBz YXkgYmFzaWNhbGx5IOKAnHVzZSBpdCBpZiB5b3XigJlyZSBpbiB1c2UgY2FzZXMgaW4gd2hpY2gg aXTigJlzIHVzZWZ1bCB0byBkaXN0aW5ndWlzaCBiZXR3ZWVuIHRoaW5nc+KAnS4NCg0KRnJvbTog SWQtZXZlbnQgW21haWx0bzppZC1ldmVudC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzppZC1ldmVu dC1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIEpvaG4gQnJhZGxleQ0KU2VudDogV2Vk bmVzZGF5LCBBdWd1c3QgMjQsIDIwMTYgMjoyNCBQTQ0KVG86IFBoaWwgSHVudCA8cGhpbC5odW50 QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj4NCkNjOiBpZC1ldmVudEBp ZXRmLm9yZzxtYWlsdG86aWQtZXZlbnRAaWV0Zi5vcmc+OyBNYXJpdXMgU2N1cnRlc2N1IDxtc2N1 cnRlc2N1QGdvb2dsZS5jb208bWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbT4+DQpTdWJqZWN0 OiBSZTogW0lkLWV2ZW50XSBEaXNjdXNzaW9uIG9uIHVzZSBvZiAic3ViIiBhbmQgY29uZnVzaW9u IGFzIElEIFRva2VuDQoNCkkgd2FzIHNheWluZyB0aGF0IGN0eSB3YXMgd3JvbmcgZm9yIHRoaXMu DQoNCklmIHlvdSBsb29rIGF0IHRoZSBkZWZpbml0aW9uIG9mIHR5cCBpbiBKV1MgaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL3JmYzc1MTUjcGFnZS0xMyAgeW91IGNhbiBzZWUgdGhhdCBpdCBp cyByZWFsbHkgaW50ZW5kZWQgdG8gYmUgdGhlIG1lZGlhIHR5cGUgb2YgdGhlIGNvbXBsZXRlIEpX Uy9KV0UgYW5kIGlzIG9taXR0ZWQgb3Igc2V0IHRvIEpXVCBpZiBpdCBpcyBhIGNvbXBhY3QgSldU LiAgICAgU2V0dGluZyBpdCB0byBTRVQgc2VlbXMgd3JvbmcgYXMgaXQgaXMgc3RpbGwgYSBKV1Qu ICAgSSB3YXMgcmVjb21tZW5kaW5nIGNvbnNpZGVyaW5nIGEgSldUIHRvcCBsZXZlbCBjbGFpbSBp biB0aGUgSldUIHJlZ2lzdHJ5Lg0KDQpKb2huIEIuDQoNCg0KT24gQXVnIDI0LCAyMDE2LCBhdCA1 OjU5IFBNLCBQaGlsIEh1bnQgPHBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRA b3JhY2xlLmNvbT4+IHdyb3RlOg0KDQpKb2huLA0KDQpEaWQgeW91IG1lYW4gYWRkaW5nIGEg4oCc and0X3R5cGXigJ0gYXR0cmlidXRlICh0aGF0IGJlY29tZXMgYSByZWdpc3RlcmVkIEpXVCBjbGFp bSkgT1IgYWRkaW5nIGEgbmV3IHR5cGUgdmFsdWUgZm9yIHRoZSBKV1QgaGVhZGVyIOKAnHR5cOKA nT8gIE5vdGUgZm9yIGV2ZXJ5b25l4oCZcyBjb252ZW5pZW5jZSBmcm9tIDc1MTk6DQoNCg0KVGhl ICJ0eXAiICh0eXBlKSBIZWFkZXIgUGFyYW1ldGVyIGRlZmluZWQgYnkgW0pXUzxodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvcmZjNzUxOSNyZWYtSldTPl0gYW5kIFtKV0U8aHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL3JmYzc1MTkjcmVmLUpXRT5dIGlzIHVzZWQNCg0KICAgYnkgSldUIGFw cGxpY2F0aW9ucyB0byBkZWNsYXJlIHRoZSBtZWRpYSB0eXBlIFtJQU5BLk1lZGlhVHlwZXM8aHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc1MTkjcmVmLUlBTkEuTWVkaWFUeXBlcz5dIG9m DQoNCiAgIHRoaXMgY29tcGxldGUgSldULiAgVGhpcyBpcyBpbnRlbmRlZCBmb3IgdXNlIGJ5IHRo ZSBKV1QgYXBwbGljYXRpb24NCg0KICAgd2hlbiB2YWx1ZXMgdGhhdCBhcmUgbm90IEpXVHMgY291 bGQgYWxzbyBiZSBwcmVzZW50IGluIGFuIGFwcGxpY2F0aW9uDQoNCiAgIGRhdGEgc3RydWN0dXJl IHRoYXQgY2FuIGNvbnRhaW4gYSBKV1Qgb2JqZWN0OyB0aGUgYXBwbGljYXRpb24gY2FuIHVzZQ0K DQogICB0aGlzIHZhbHVlIHRvIGRpc2FtYmlndWF0ZSBhbW9uZyB0aGUgZGlmZmVyZW50IGtpbmRz IG9mIG9iamVjdHMgdGhhdA0KDQogICBtaWdodCBiZSBwcmVzZW50LiAgSXQgd2lsbCB0eXBpY2Fs bHkgbm90IGJlIHVzZWQgYnkgYXBwbGljYXRpb25zIHdoZW4NCg0KICAgaXQgaXMgYWxyZWFkeSBr bm93biB0aGF0IHRoZSBvYmplY3QgaXMgYSBKV1QuICBUaGlzIHBhcmFtZXRlciBpcw0KDQogICBp Z25vcmVkIGJ5IEpXVCBpbXBsZW1lbnRhdGlvbnM7IGFueSBwcm9jZXNzaW5nIG9mIHRoaXMgcGFy YW1ldGVyIGlzDQoNCiAgIHBlcmZvcm1lZCBieSB0aGUgSldUIGFwcGxpY2F0aW9uLiAgSWYgcHJl c2VudCwgaXQgaXMgUkVDT01NRU5ERUQgdGhhdA0KDQogICBpdHMgdmFsdWUgYmUgIkpXVCIgdG8g aW5kaWNhdGUgdGhhdCB0aGlzIG9iamVjdCBpcyBhIEpXVC4gIFdoaWxlDQoNCiAgIG1lZGlhIHR5 cGUgbmFtZXMgYXJlIG5vdCBjYXNlIHNlbnNpdGl2ZSwgaXQgaXMgUkVDT01NRU5ERUQgdGhhdCAi SldUIg0KDQogICBhbHdheXMgYmUgc3BlbGxlZCB1c2luZyB1cHBlcmNhc2UgY2hhcmFjdGVycyBm b3IgY29tcGF0aWJpbGl0eSB3aXRoDQoNCiAgIGxlZ2FjeSBpbXBsZW1lbnRhdGlvbnMuICBVc2Ug b2YgdGhpcyBIZWFkZXIgUGFyYW1ldGVyIGlzIE9QVElPTkFMLg0KDQoNCldoYXQgaXMgY29uY2Vy bmluZyBpcyB0aGUgbGluZSB0aGF0IHNheXM6DQoNCkl0IHdpbGwgdHlwaWNhbGx5IG5vdCBiZSB1 c2VkIGJ5IGFwcGxpY2F0aW9ucyB3aGVuDQoNCiAgIGl0IGlzIGFscmVhZHkga25vd24gdGhhdCB0 aGUgb2JqZWN0IGlzIGEgSldULiAgVGhpcyBwYXJhbWV0ZXIgaXMNCg0KICAgaWdub3JlZCBieSBK V1QgaW1wbGVtZW50YXRpb25zOyBhbnkgcHJvY2Vzc2luZyBvZiB0aGlzIHBhcmFtZXRlciBpcw0K DQogICBwZXJmb3JtZWQgYnkgdGhlIEpXVCBhcHBsaWNhdGlvbi4gIElmIHByZXNlbnQsIGl0IGlz IFJFQ09NTUVOREVEIHRoYXQNCg0KICAgaXRzIHZhbHVlIGJlICJKV1QiIHRvIGluZGljYXRlIHRo YXQgdGhpcyBvYmplY3QgaXMgYSBKV1QuDQoNCklmIGl0IGlzIHR5cGljYWxseSBpZ25vcmVkLCB0 aGVuIGhhdmluZyBpdCDigJx0eXDigJ0gYmUg4oCcU0VU4oCdIG1heSBub3QgaGVscCBtdWNoIGlu aXRpYWxseS4gQnV0IGF0IGxlYXN0IGl0IGlzIG1vcmUgZGVmaW5pdGl2ZS4NCg0KSWYgdGhlIGdy b3VwIGlzIGNvbWZvcnRhYmxlLCBJIGFtIG9rIHdpdGggbWFraW5nIOKAnHR5cOKAnSBiZSDigJxT RVTigJ0uICBJdCBpcyBvbmUgbW9yZSBkaXN0aW5ndWlzaGluZyBpdGVtLg0KDQpSZWdhcmRsZXNz LCBJIHdpbGwgYWxzbyBwdXQgYSBjYXV0aW9uYXJ5IG5vdGUgaW4gdGhlIHNlY3VyaXR5IGNvbnNp ZGVyYXRpb25zIHRoYXQgaWYgaXNzdWluZyBTRVRzIHRvIGF1ZGllbmNlcyB0aGF0IGFsc28gcmVj ZWl2ZSBKV1RzLCB0aGF0IGFwcHJvcHJpYXRlIGNhcmUgYmUgdGFrZW4gbm90IHRvIGNvbmZ1c2Ug aWYgc29tZWhvdyBhIGhhY2tlciBpcyBhYmxlIHRvIHByZXNlbnQgdGhlIFNFVCBhcyBpZiBpdCB3 ZXJlIGEgSldUIHRvIGdhaW4gYWNjZXNzIChlLmcuIGluIGFuIGF1dGhvcml6YXRpb24gaGVhZGVy KS4gIE5vcm1hbGx5IHRoaXMgc2hvdWxkIG5vdCBiZSBwb3NzaWJsZSBhcyBJIHdvdWxkIGFzc3Vt ZSBTRVRzIGFyZSBwYXNzZWQgdmlhIHNvbWV0aGluZyBsaWtlIGFuIEhUVFAgUE9TVCBiYWNrLWNo YW5uZWwuDQoNClBoaWwNCg0KQGluZGVwZW5kZW50aWQNCnd3dy5pbmRlcGVuZGVudGlkLmNvbTxo dHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tLz4NCnBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0 bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4NCg0KDQoNCg0KT24gQXVnIDI0LCAyMDE2LCBhdCAxOjMx IFBNLCBKb2huIEJyYWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPG1haWx0bzp2ZTdqdGJAdmU3anRi LmNvbT4+IHdyb3RlOg0KDQpUaGUgaWRlYSBmb3IgY3R5IHdhcyB0byBhbGxvdyBhIEpXUyB0byBl bmNhcHN1bGF0ZSB0aGluZ3MgbGlrZSBhIGJpbmFyeSBHSUYgYXMgYW4gZXhhbXBsZS4gICBJIHRo aW5rIHVzaW5nIGl0IGZvciBEaXN0aW5ndWlzaGluZyBzdWJ0eXBlcyBvZiBKV1Qgd291bGQgYmUg YSBzdHJldGNoLg0KDQpJIGFtIG1vc3QgY29tZm9ydGFibGUgd2l0aCBBLiAgIEkgdGhpbmsgdGhh dCBhZGRpbmcgYSBKV1QgdHlwZSBjbGFpbSBhdCB0aGUgdG9wIGxldmVsIG1heSBhbHNvIGJlIHVz ZWZ1bCBnb2luZyBmb3J3YXJkIHRvIGF2b2lkIG1pc2ludGVycHJldGF0aW9uLg0KDQpKb2huIEIu DQpPbiBBdWcgMjQsIDIwMTYsIGF0IDQ6NTEgUE0sIE1hcml1cyBTY3VydGVzY3UgPG1zY3VydGVz Y3VAZ29vZ2xlLmNvbTxtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tPj4gd3JvdGU6DQoNCk9u IFdlZCwgQXVnIDI0LCAyMDE2IGF0IDExOjA3IEFNLCBQaGlsIEh1bnQgPHBoaWwuaHVudEBvcmFj bGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+IHdyb3RlOg0KDQpUaGUgYXV0aG9y cyBoYXZlIGJlZW4gaGF2aW5nIGEgZGlzY3Vzc2lvbiB3aXRoIHJlZ2FyZHMgdG8gdXNpbmcgdGhl IOKAnHN1YuKAnSBjbGFpbSBpbiB0aGUgdG9wIGxldmVsLiBJIHRoaW5rIGl0IGlzIGltcG9ydGFu dCB0byB0cnkgYW5kIGdldCB0aGlzIGRpc2N1c3Npb24gYmFjayB0byB0aGUgbWFpbiBncm91cC4g TXkgYXBvbG9naWVzIGZvciB0aGUgbG9uZyBub3RlLiBJIHdhbnRlZCB0byBnZXQgYWxsIHRoZSBw cm9zIGFuZCBjb25zIG9uIHRoZSB0YWJsZSAoaGludDogIHBsZWFzZSBhZGQgaWYgSSBtaXNzZWQg YW55KS4uLg0KDQpBIHF1ZXN0aW9uIHJlbWFpbnMgc2hvdWxkIOKAnHN1YuKAnSBiZSB1c2FibGUg YXQgdGhlIHRvcCBsZXZlbC4gIFRoZSBkb3duc2lkZSBvZiB0aGlzIGFwcHJvYWNoIGlzIHRoYXQg YSBTRVQgY291bGQgcG90ZW50aWFsbHkgYmUgcHJlc2VudGVkIGFzIGFuIGFjY2VzcyBvciBpRCB0 b2tlbiBhbmQgbWlnaHQgaW5pdGlhbGx5IGJlIGNvbmZ1c2VkIGJlY2F1c2UgZXhpc3RpbmcgY29k ZSBkb2VzIG5vdCBrbm93IGl0IG5lZWRzIHRvIGxvb2sgZm9yIGFuIOKAnGV2ZW50c+KAnSBhdHRy aWJ1dGUuICBUaGUgU0VUIGFuZCBJRCBUb2tlbiBmb3IgYWxsIGludGVuc2l2ZSBwdXJwb3NlcyBh cmUgdGhlIHNhbWUgc2luY2UgYSBTRVQganVzdCBoYXMgc29tZXRoaW5nIGV4dHJhICh0aGUgZXZl bnRzIGNsYWltKS4NCg0KVGhlcmUgaXMgYWxzbyB0aGUgcXVlc3Rpb24gdGhhdCBpZiBPSURDIExv Z291dCB1c2VzIGl0IGluIHRoZSB0b3AgbGV2ZWwsIG1heSBvdGhlciBldmVudHMgdXNlIGl0PyBS RkM3NTE5IGRlZmluZXMg4oCcc3Vi4oCdIGFzIGEgU3RyaW5nIG9yIFVSSSB2YWx1ZS4gRm9yIGV4 YW1wbGUsIGluIFNDSU0gZXZlbnRzLCB0aGUg4oCcc3Vi4oCdIHZhbHVlIGNvdWxkIGJlIGEgU0NJ TSBSZXNvdXJjZSBVUkkgdGhhdCBpbmRpY2F0ZXMgdGhlIHJlc291cmNlIHdob3NlIHN0YXRlIGhh cyBjaGFuZ2VkLiAgSW4gT0F1dGggaXQgY291bGQgYmUgZGVmaW5lZCBhcyB0aGUgdG9rZW4gaWRl bnRpZmllciBvZiB0aGUgdG9rZW4gdGhhdCBoYXMgYmVlbiByZXZva2VkLiAgQSBTRVQgYWJvdXQg YmxhY2tsaXN0aW5nIGFuIElQIGFkZHJlc3MgbWlnaHQgcHV0IHRoZSBJUCBhZGRyZXNzIGluIHN1 Yi4NCg0KU28gdGhlcmUgYXJlIHRocmVlIG9wdGlvbnMgKE9wdGlvbiBBIHNlZW1zIHRvIGJlIGZh dm91cmVkIHNvIGZhcik6DQoNCkEuICBTdWIgYXQgVG9wIExldmVsOiAg4oCcc3Vi4oCdIGdlbmVy YWxseSB1c2VkIHRvIHJlZmVyZW5jZSB0aGUgU2VjdXJpdHkgU3ViamVjdCB0aGUgU0VUIGlzIHRh bGtpbmcgYWJvdXQuICBJdCB1c2VzIGEgbW9yZSBnZW5lcmFsIGVuZ2xpc2ggbGFuZ3VhZ2UgaW50 ZW50IG9mIHN1YmplY3QgcmF0aGVyIHRoYW4gdGhlIHRyYWRpdGlvbmFsIHVzZSBhcyBzZWVuIGlu IFNBTUwgb3IgT3BlbklEIENvbm5lY3QuICBSZWdhcmRsZXNzIGl0IGlzIHN0aWxsIGNvbXBsaWFu dCB3aXRoIFJGQzc1MTkgKGEgU3RyaW5nIG9yIFVSSSkuDQoNClRoaXMgd291bGQgdGVuZCB0byBs ZWFkIHRvIGEgc3R5bGUgb2YgU0VUcyB3aGVyZSB0aGUgZW52ZWxvcGUgY2FycmllcyB0aGUgdmFs aWRhdGlvbiBpbmZvcm1hdGlvbiwgdGhlIHR5cGUgb2YgZXZlbnQsIGFuZCB0aGUgc3ViamVjdCBv ZiB0aGUgZXZlbnQuIEFkZGl0aW9uYWwgZGF0YSBnb2VzIGluIHRoZSBwYXlsb2FkLiBBbiBhZHZh bnRhZ2Ugb2YgdGhpcyBzdHlsZSwgaXMgdGhhdCBmb3IgbWFueSBldmVudHMsIHRoZSBvbmx5IHRo aW5nIG5lZWRlZCBpcyB0aGUgZXZlbnQgdHlwZSBhbmQgdGhlIHN1YmplY3QuICBObyBwYXlsb2Fk cyB3b3VsZCBiZSBuZWVkZWQuDQoNCkZvciBldmVudHMgdGhhdCBkb27igJl0IHdhbnQgcGF5bG9h ZCwgaXQgaXMgcHJvYmFibHkgb2sgZm9yIHByb2ZpbGluZyBldmVudCBzdGFuZGFyZHMgdG8gZGVm aW5lIG1vcmUgY2xhaW1zIGF0IHRoZSB0b3AgbGV2ZWwuIFRoZXkgTVVTVCBiZSByZWdpc3RlcmVk IGluIHRoZSBKV1QgcmVnaXN0cnkuIFByb2ZpbGluZyBldmVudHMgY2FuIGF2b2lkIHJlZ2lzdHJh dGlvbiBieSBqdXN0IHB1dHRpbmcgdGhlaXIgYXR0cmlidXRlcy9jbGFpbXMgaW4gdGhlIHBheWxv YWQgYXJlYSBhcyBkZXNjcmliZWQgaW4gdGhlIHNwZWMuICBIb3dldmVyLCB0aGlzIHdvdWxkIGJl IGluY29uc2lzdGVudCB3aXRoIHRob3NlIHRoYXQgdXNlIHBheWxvYWRzIHdpdGggdW5yZWdpc3Rl cmVkIGNsYWltcy4gIEkgcG9pbnQgb3V0IHRoYXQgd2Ugc3dpdGNoZWQgZnJvbSByZWdpc3RlcmVk IGV2ZW50IFVSTnMgdG8gVVJJcyB0byBhdm9pZCByZWdpc3RyYXRpb24uICBIZW5jZSB0aGUgbW92 ZSB0byBwYXlsb2FkIG9iamVjdHMgdG8gZWxpbWluYXRlIHJlZ2lzdHJhdGlvbiBmb3IgYXR0cmli dXRlcy9jbGFpbXMuDQoNClRoaXMgc3RpbGwgaGFzIHRoZSBuZWdhdGl2ZXMgb2YgYmVpbmcgY29u ZnVzYWJsZSBhcyBhbiBJRCBUb2tlbiBieSBleGlzdGluZyBjb2RlLiBUaGVyZSBoYXMgYmVlbiBh IGRpc2N1c3Npb24gdGhhdCDigJxpc3PigJ0gYW5kL29yIOKAnGF1ZOKAnSBzaG91bGQgYWN0dWFs bHkgYmUgZGlmZmVyZW50IGFuZCB0aGUgcmVjZWl2ZXIgc2hvdWxkIGRldGVjdCB0aGF0LiAgSG93 ZXZlciBpbiB0aGUgT0lEQyBMb2dvdXQgY2FzZSwgYnkgZGVzaWduLCB0aGUg4oCcaXNz4oCdIHZh bHVlIHdvdWxkIGJlIHRoZSBzYW1lLiAgVGhlIOKAnGF1ZOKAnSB3b3VsZCBhbHNvIGxpa2VseSBi ZSB0aGUgc2FtZSB1bmxlc3MgdGhlIHNwZWMgaW5kaWNhdGVzIHRoYXQgYW4gYWxpYXMg4oCcYXVk 4oCdIGJlIHVzZWQgZXZlbiB0aG91Z2ggdGhlIGF1ZGllbmNlIG1heSBiZSB0aGUgc2FtZSBlbnRp dHkgaW4gYm90aCBjYXNlcy4NCg0KQi4gRXhjbHVzaXZlLVVzZSBvZiBTdWI6IOKAnHN1YuKAnSBp cyBpbnRlcnByZXRlZCB0byBieSB0cmFkaXRpb25hbCBkZWZpbml0aW9uIGFuZCBpcyByZXNlcnZl ZCBmb3IgT0F1dGggdG9rZW5zIGFuZCBPSURDIENvbm5lY3QgdXNhZ2Ugb25seS4gIEluIG9yZGVy IHRvICBhdm9pZCBjb25mdXNpbmcsIGFsbCBwcm9maWxpbmcgZXZlbnQgc3BlY3Mgc2hvdWxkIE5P VCB1c2Ug4oCcc3Vi4oCdIGluIHRoZSB0b3AgbGV2ZWwgZXhjZXB0IGZvciBPSURDLg0KDQpUaGlz IGhhcyB0aGUgZGlzYWR2YW50YWdlIHRoYXQgT0lEQyByZXF1aXJlcyBzcGVjaWFsIGhhbmRsaW5n IGluIHRlcm1zIG9mIGEgZ2VuZXJhbCB1c2UgZXZlbnQgbGlicmFyeSwgYnV0IG9uIHRoZSBvdGhl ciBoYW5kIGEgTG9nb3V0IEV2ZW50IG1pZ2h0IGJlIGhhbmRsZWQgZGlyZWN0bHkgYnkgZXhpc3Rp bmcgSUQgVG9rZW4gY29kZS4NCg0KVGhpcyBzdGlsbCBoYXMgdGhlIGRpc2FkdmFudGFnZSB0aGF0 IGFuIFNFVCBjb3VsZCBiZSBjb25mdXNlZCBmb3IgYW4gSUQgVG9rZW4uDQoNCkMuIE5vLVRvcC1M ZXZlbCBEYXRhOiBJbiBvcmRlciB0byBtb3JlIGFnZ3Jlc3NpdmVseSBhdm9pZCBjb25mdXNpb24g b2YgU0VUcyBhcyBJRCBUb2tlbnMsIG1ha2UgaXQgbWFuZGF0b3J5IHRoYXQgU0VUcyBtYXkgbm90 IGNvbnRhaW4gYSDigJxzdWLigJ0gdmFsdWUgYXQgdGhlIHRvcCBsZXZlbC4gIFRoZSBPSURDIExv Z291dCBFdmVudCwgZm9yIGV4YW1wbGUsIHdvdWxkIHRoZW4gaW5jbHVkZSBhIOKAnHN1YuKAnSB2 YWx1ZSBpbiB0aGUgcGF5bG9hZCBhcmVhLiBUaGlzIHNob3VsZCBjYXVzZSBleGlzdGluZyByZWx5 aW5nIHBhcnRpZXMgdG8gZmFpbCBjb3JyZWN0bHkuDQoNClRoaXMgd291bGQgcHJvdmlkZSBhIG1h eGltYWwgZGlmZmVyZW5jZSBmb3JtIGEgSURUb2tlbiBvciBhY2Nlc3MgdG9rZW4uDQoNClRoaXMg d291bGQgaGF2ZSB0aGUgYWR2YW50YWdlIHRoYXQgZW52ZWxvcGVzIGNvbnRhaW4gbm8gZGF0YSwg YW5kIHRoYXQgZXZlcnkgU0VUIGhhcyBhIHBheWxvYWQgd2hlcmUgdGhlIGRhdGEgaXMgZm91bmQu IEl0IHJlcXVpcmVzIG1vcmUgcGFyc2luZyBpbiBzb21lIGNhc2VzLCBidXQgaXQgaXMgYXQgbGVh c3QgY29uc2lzdGVudC4gV2hpbGUgd2UgZG9u4oCZdCBleHBlY3QgZ2VuZXJhbCBwcm9jZXNzb3Jz IGxpa2UgaW4gU09BUCBmb3IgZGlzdHJpYnV0aW9uIChtdWNoIG9mIGl0IGlzIHBvaW50IHRvIHBv aW50IGFuZCB2ZXJ5IGNvbnRleHR1YWxseSBkcml2ZW4pLCBJIHBlcnNvbmFsbHkgZXhwZWN0IHRv IHNlZToNCiAgKiAgRGV2ZWxvcG1lbnQgb2YgZ2VuZXJhbCBwdXJwb3NlIGxpYnJhcmllcyBhbmQg dG9vbHMgdGhhdCBhcmUgdXNlZCBlbmhhbmNlIHByb3RvY29scyBhbmQgc3lzdGVtcw0KICAqICBB dWRpdCBhbmQgdGhyZWF0IGFuYWx5c2lzIHN5c3RlbXMgd2lsbCBiZSBsb29raW5nIGF0IHNvbWUg ZXZlbnRzIGhpc3RvcmljYWxseS4gVGhlc2Ugd2lsbCB0ZW5kIHRvIG1lcmdlIG11bHRpcGxlIGV2 ZW50IGZlZWRzLg0KDQpNaWtlIEpvbmVzIGFsc28gc3VnZ2VzdGVkIHVzaW5nIHRoZSDigJxjdHni gJ0gKGNvbnRlbnQgdHlwZSkgaGVhZGVyIGF0dHJpYnV0ZSBmcm9tIEpXVC4gIEkgdGhpbmsgbW9z dCBjb2RlIHRvZGF5IGhhcyB0aGlzIHNldCB0byBpZ25vcmUgb3IgZml4ZWQgYXMg4oCcSldU4oCd LiAgSSB3b25kZXIgd2hhdCBjdXJyZW50IGltcGxlbWVudHMgd291bGQgZmVlbCBpZiB3ZSBpbnRy b2R1Y2VkIGEg4oCcY3R54oCdIHZhbHVlIG9mIOKAnFNFVOKAnT8gIFdvdWxkIHRoYXQgaGVscD8N Cg0KSSB0aGluayBpdCBpcyB2ZXJ5IGltcG9ydGFudCB0byBiZSBhYmxlIHRvIGNsZWFybHkgZGlz dGluZ3Vpc2ggZGlmZmVyZW50IHR5cGVzIG9mIEpXVCB0b2tlbnMuIEZvciBleGFtcGxlLCBub3Qg YmVpbmcgYWJsZSB0byBjcm9zcyBwb3N0IGEgU2VjdXJpdHkgRXZlbnQgVG9rZW4gYXMgYW4gSWQg VG9rZW4uDQoNClJlYWRpbmcgUkZDIDc1MTkgSSBkb24ndCB0aGluayBjdHkgZml0cyB0aGUgYmls bCwgYnV0IEkgY291bGQgYmUgd3JvbmcuIGN0eSBpcyBhIGhlYWRlciBwYXJhbWV0ZXIgdXNlZCBi eSB0aGUgY3J5cHRvIGFsZ29yaXRobSBhbmQgdGhlIGRlZmF1bHQgdmFsdWUgaXMgSldULiBXZSBu ZWVkIHRvIGRpc3Rpbmd1aXNoIHN1Yi10eXBlcyBvZiBKV1QsIGFuZCBpdCBzaG91bGQgYmUgYSBj bGFpbSBpbnNpZGUgdGhlIEpXVC4NCg0KV2l0aCB0aGUgYWJvdmUgaXNzdWUgaW4gbWluZCwgSSB0 aGluayBvcHRpb24gQSBpcyB0aGUgY2xlYW5lc3Qgc29sdXRpb24uDQoNCg0KDQpUaGFua3MgZm9y IHlvdXIgY29tbWVudHMuDQoNCg0KUGhpbA0KDQpAaW5kZXBlbmRlbnRpZA0Kd3d3LmluZGVwZW5k ZW50aWQuY29tPGh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20vPg0KcGhpbC5odW50QG9yYWNs ZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPg0KDQoNCg0KDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJZC1ldmVudCBtYWlsaW5nIGxp c3QNCklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZz4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklkLWV2ZW50IG1haWxpbmcgbGlzdA0K SWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudA0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSWQtZXZlbnQgbWFpbGluZyBsaXN0DQpJZC1l dmVudEBpZXRmLm9yZzxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50DQoNCg0KDQo= --_000_SN1PR0301MB164555B61381414BA03FCA26F5EA0SN1PR0301MB1645_ 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 Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHls ZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmln aHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlm O30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJl Zm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1h aWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h cmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+SSB3b3VsZCBzdHJvbmds eSBvcHBvc2UgZXZlbnRzIHJlcXVpcmluZyB1c2Ugb2YgaXQsIGJlY2F1c2UgaXTigJlzIG5vdCBu ZWNlc3NhcnkgZm9yIGFuIGV2ZW50IHN0cmVhbS4mbmJzcDsgSXQgd291bGQgYmUgdW5uZWNlc3Nh cnkgYmFnZ2FnZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPkkg YWdyZWUgd2l0aCBQaGlsIHRoYXQgc3Ryb25nIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGlzIGFz IGZhciBhcyB3ZSBzaG91bGQgZ28gaW4gdGhlIEV2ZW50IFRva2VuIHNwZWMuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMw MDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8c3BhbiBzdHlsZT0i bXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PC9zcGFuPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4g Sm9obiBCcmFkbGV5IFttYWlsdG86dmU3anRiQHZlN2p0Yi5jb21dDQo8YnI+DQo8Yj5TZW50Ojwv Yj4gV2VkbmVzZGF5LCBBdWd1c3QgMjQsIDIwMTYgMjo0NyBQTTxicj4NCjxiPlRvOjwvYj4gTWlr ZSBKb25lcyAmbHQ7TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tJmd0Ozxicj4NCjxiPkNjOjwv Yj4gUGhpbCBIdW50ICZsdDtwaGlsLmh1bnRAb3JhY2xlLmNvbSZndDs7IGlkLWV2ZW50QGlldGYu b3JnOyBNYXJpdXMgU2N1cnRlc2N1ICZsdDttc2N1cnRlc2N1QGdvb2dsZS5jb20mZ3Q7PGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBbSWQtZXZlbnRdIERpc2N1c3Npb24gb24gdXNlIG9mICZxdW90 O3N1YiZxdW90OyBhbmQgY29uZnVzaW9uIGFzIElEIFRva2VuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+WWVzLCAmbmJzcDtvbiBvbmUgb2YgdGhlIGNhbGxzIHdlIHRhbGtl ZCBhYm91dCBpdCBiZWluZyBhIHNlcGFyYXRlIHNwZWMgdG8gcmVnaXN0ZXIgdGhlIGNsYWltIGFu ZCB0aGVuIGV2ZW50cyBjb3VsZCB1c2UgaXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEF1ZyAyNCwgMjAxNiBhdCA2OjMxIFBNLCBNaWtlIEpv bmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIiB0YXJn ZXQ9Il9ibGFuayI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5BIHNwZWMgY291bGQgY3JlYXRl IGEgdG9wLWxldmVsIEpXVCB0eXBlIGNsYWltLCBidXQgSeKAmWQgYXNzZXJ0IHRoYXQgaXTigJlz IG91dCBvZiBzY29wZSBmb3IgdGhlIEV2ZW50cw0KIHNwZWMuJm5ic3A7IEl0IHdvdWxkIHByb2Jh Ymx5IG5lZWQgdG8gYmUgaXRzIG93biBzcGVjIGFuZCBzYXkgYmFzaWNhbGx5IOKAnHVzZSBpdCBp ZiB5b3XigJlyZSBpbiB1c2UgY2FzZXMgaW4gd2hpY2ggaXTigJlzIHVzZWZ1bCB0byBkaXN0aW5n dWlzaCBiZXR3ZWVuIHRoaW5nc+KAnS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxhIG5hbWU9Im1fNjAzMjU2NzE5OTIxMjc5MjI1Nl9fTWFpbEVuZENvbXBv c2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PC9hPjxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4gSWQtZXZlbnQgW21haWx0bzo8YSBocmVmPSJtYWlsdG86aWQtZXZlbnQtYm91bmNl c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmc8L2E+ XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Kb2huIEJyYWRsZXk8YnI+DQo8Yj5TZW50OjwvYj4gV2Vk bmVzZGF5LCBBdWd1c3QgMjQsIDIwMTYgMjoyNCBQTTxicj4NCjxiPlRvOjwvYj4gUGhpbCBIdW50 ICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5r Ij5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJt YWlsdG86aWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pZC1ldmVudEBpZXRmLm9y ZzwvYT47IE1hcml1cyBTY3VydGVzY3UgJmx0OzxhIGhyZWY9Im1haWx0bzptc2N1cnRlc2N1QGdv b2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5tc2N1cnRlc2N1QGdvb2dsZS5jb208L2E+Jmd0Ozxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0lkLWV2ZW50XSBEaXNjdXNzaW9uIG9uIHVzZSBvZiAm cXVvdDtzdWImcXVvdDsgYW5kIGNvbmZ1c2lvbiBhcyBJRCBUb2tlbjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIHdhcyBzYXlpbmcgdGhhdCBjdHkg d2FzIHdyb25nIGZvciB0aGlzLiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPklmIHlvdSBsb29rIGF0IHRoZSBkZWZp bml0aW9uIG9mIHR5cCBpbiBKV1MmbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvcmZjNzUxNSNwYWdlLTEzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL3JmYzc1MTUjcGFnZS0xMzwvYT4mbmJzcDsgeW91IGNhbiBzZWUgdGhhdA0KIGl0 IGlzIHJlYWxseSBpbnRlbmRlZCB0byBiZSB0aGUgbWVkaWEgdHlwZSBvZiB0aGUgY29tcGxldGUg SldTL0pXRSBhbmQgaXMgb21pdHRlZCBvciBzZXQgdG8gSldUIGlmIGl0IGlzIGEgY29tcGFjdCBK V1QuICZuYnNwOyAmbmJzcDsgU2V0dGluZyBpdCB0byBTRVQgc2VlbXMgd3JvbmcgYXMgaXQgaXMg c3RpbGwgYSBKV1QuICZuYnNwOyBJIHdhcyByZWNvbW1lbmRpbmcgY29uc2lkZXJpbmcgYSBKV1Qg dG9wIGxldmVsIGNsYWltIGluIHRoZSBKV1QgcmVnaXN0cnkuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Kb2huIEIuPG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBBdWcgMjQsIDIw MTYsIGF0IDU6NTkgUE0sIFBoaWwgSHVudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBv cmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5K b2huLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkRp ZCB5b3UgbWVhbiBhZGRpbmcgYSDigJxqd3RfdHlwZeKAnSBhdHRyaWJ1dGUgKHRoYXQgYmVjb21l cyBhIHJlZ2lzdGVyZWQgSldUIGNsYWltKSBPUiBhZGRpbmcgYSBuZXcgdHlwZSB2YWx1ZSBmb3Ig dGhlIEpXVCBoZWFkZXIg4oCcdHlw4oCdPyZuYnNwOyBOb3RlIGZvciBldmVyeW9uZeKAmXMgY29u dmVuaWVuY2UgZnJvbSA3NTE5OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw cmU+VGhlICZxdW90O3R5cCZxdW90OyAodHlwZSkgSGVhZGVyIFBhcmFtZXRlciBkZWZpbmVkIGJ5 IFs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzUxOSNyZWYtSldTIiB0 YXJnZXQ9Il9ibGFuayIgdGl0bGU9IiZxdW90O0pTT04gV2ViIFNpZ25hdHVyZSAoSldTKSZxdW90 OyI+SldTPC9hPl0gYW5kIFs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj NzUxOSNyZWYtSldFIiB0YXJnZXQ9Il9ibGFuayIgdGl0bGU9IiZxdW90O0pTT04gV2ViIEVuY3J5 cHRpb24gKEpXRSkmcXVvdDsiPkpXRTwvYT5dIGlzIHVzZWQ8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT4mbmJzcDsmbmJzcDsgYnkgSldUIGFwcGxpY2F0aW9ucyB0byBkZWNsYXJlIHRoZSBtZWRpYSB0 eXBlIFs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzUxOSNyZWYtSUFO QS5NZWRpYVR5cGVzIiB0YXJnZXQ9Il9ibGFuayI+SUFOQS5NZWRpYVR5cGVzPC9hPl0gb2Y8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgdGhpcyBjb21wbGV0ZSBKV1QuJm5ic3A7 IFRoaXMgaXMgaW50ZW5kZWQgZm9yIHVzZSBieSB0aGUgSldUIGFwcGxpY2F0aW9uPG86cD48L286 cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHdoZW4gdmFsdWVzIHRoYXQgYXJlIG5vdCBKV1Rz IGNvdWxkIGFsc28gYmUgcHJlc2VudCBpbiBhbiBhcHBsaWNhdGlvbjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPiZuYnNwOyZuYnNwOyBkYXRhIHN0cnVjdHVyZSB0aGF0IGNhbiBjb250YWluIGEgSldU IG9iamVjdDsgdGhlIGFwcGxpY2F0aW9uIGNhbiB1c2U8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m bmJzcDsmbmJzcDsgdGhpcyB2YWx1ZSB0byBkaXNhbWJpZ3VhdGUgYW1vbmcgdGhlIGRpZmZlcmVu dCBraW5kcyBvZiBvYmplY3RzIHRoYXQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJz cDsgbWlnaHQgYmUgcHJlc2VudC4mbmJzcDsgSXQgd2lsbCB0eXBpY2FsbHkgbm90IGJlIHVzZWQg YnkgYXBwbGljYXRpb25zIHdoZW48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsg aXQgaXMgYWxyZWFkeSBrbm93biB0aGF0IHRoZSBvYmplY3QgaXMgYSBKV1QuJm5ic3A7IFRoaXMg cGFyYW1ldGVyIGlzPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGlnbm9yZWQg YnkgSldUIGltcGxlbWVudGF0aW9uczsgYW55IHByb2Nlc3Npbmcgb2YgdGhpcyBwYXJhbWV0ZXIg aXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgcGVyZm9ybWVkIGJ5IHRoZSBK V1QgYXBwbGljYXRpb24uJm5ic3A7IElmIHByZXNlbnQsIGl0IGlzIFJFQ09NTUVOREVEIHRoYXQ8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgaXRzIHZhbHVlIGJlICZxdW90O0pX VCZxdW90OyB0byBpbmRpY2F0ZSB0aGF0IHRoaXMgb2JqZWN0IGlzIGEgSldULiZuYnNwOyBXaGls ZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBtZWRpYSB0eXBlIG5hbWVzIGFy ZSBub3QgY2FzZSBzZW5zaXRpdmUsIGl0IGlzIFJFQ09NTUVOREVEIHRoYXQgJnF1b3Q7SldUJnF1 b3Q7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGFsd2F5cyBiZSBzcGVsbGVk IHVzaW5nIHVwcGVyY2FzZSBjaGFyYWN0ZXJzIGZvciBjb21wYXRpYmlsaXR5IHdpdGg8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgbGVnYWN5IGltcGxlbWVudGF0aW9ucy4mbmJz cDsgVXNlIG9mIHRoaXMgSGVhZGVyIFBhcmFtZXRlciBpcyBPUFRJT05BTC48bzpwPjwvbzpwPjwv cHJlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPldoYXQg aXMgY29uY2VybmluZyBpcyB0aGUgbGluZSB0aGF0IHNheXM6Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cHJlPkl0IHdpbGwgdHlwaWNhbGx5IG5vdCBiZSB1c2VkIGJ5IGFw cGxpY2F0aW9ucyB3aGVuPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGl0IGlz IGFscmVhZHkga25vd24gdGhhdCB0aGUgb2JqZWN0IGlzIGEgSldULiZuYnNwOyA8Yj48dT5UaGlz IHBhcmFtZXRlciBpczwvdT48L2I+PG86cD48L286cD48L3ByZT4NCjxwcmU+PGI+PHU+Jm5ic3A7 Jm5ic3A7IGlnbm9yZWQgYnkgSldUIGltcGxlbWVudGF0aW9uczwvdT48L2I+OyBhbnkgcHJvY2Vz c2luZyBvZiB0aGlzIHBhcmFtZXRlciBpczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZu YnNwOyBwZXJmb3JtZWQgYnkgdGhlIEpXVCBhcHBsaWNhdGlvbi4mbmJzcDsgSWYgcHJlc2VudCwg aXQgaXMgUkVDT01NRU5ERUQgdGhhdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNw OyBpdHMgdmFsdWUgYmUgJnF1b3Q7SldUJnF1b3Q7IHRvIGluZGljYXRlIHRoYXQgdGhpcyBvYmpl Y3QgaXMgYSBKV1QuPG86cD48L286cD48L3ByZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5JZiBpdCBpcyB0eXBpY2FsbHkgaWdub3JlZCwgdGhlbiBoYXZpbmcgaXQg4oCcdHlw 4oCdIGJlIOKAnFNFVOKAnSBtYXkgbm90IGhlbHAgbXVjaCBpbml0aWFsbHkuIEJ1dCBhdCBsZWFz dCBpdCBpcyBtb3JlIGRlZmluaXRpdmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JZiB0aGUgZ3JvdXAgaXMgY29tZm9ydGFibGUsIEkg YW0gb2sgd2l0aCBtYWtpbmcg4oCcdHlw4oCdIGJlIOKAnFNFVOKAnS4mbmJzcDsgSXQgaXMgb25l IG1vcmUgZGlzdGluZ3Vpc2hpbmcgaXRlbS4gJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5SZWdhcmRsZXNzLCBJIHdpbGwgYWxz byBwdXQgYSBjYXV0aW9uYXJ5IG5vdGUgaW4gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHRo YXQgaWYgaXNzdWluZyBTRVRzIHRvIGF1ZGllbmNlcyB0aGF0IGFsc28gcmVjZWl2ZSBKV1RzLCB0 aGF0IGFwcHJvcHJpYXRlIGNhcmUgYmUgdGFrZW4gbm90IHRvIGNvbmZ1c2UNCiBpZiBzb21laG93 IGEgaGFja2VyIGlzIGFibGUgdG8gcHJlc2VudCB0aGUgU0VUIGFzIGlmIGl0IHdlcmUgYSBKV1Qg dG8gZ2FpbiBhY2Nlc3MgKGUuZy4gaW4gYW4gYXV0aG9yaXphdGlvbiBoZWFkZXIpLiZuYnNwOyBO b3JtYWxseSB0aGlzIHNob3VsZCBub3QgYmUgcG9zc2libGUgYXMgSSB3b3VsZCBhc3N1bWUgU0VU cyBhcmUgcGFzc2VkIHZpYSBzb21ldGhpbmcgbGlrZSBhbiBIVFRQIFBPU1QgYmFjay1jaGFubmVs LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlBoaWw8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PkBpbmRlcGVuZGVudGlkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxhIGhyZWY9Imh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20vIiB0YXJn ZXQ9Il9ibGFuayI+d3d3LmluZGVwZW5kZW50aWQuY29tPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxhIGhy ZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBoaWwuaHVu dEBvcmFjbGUuY29tPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRv bToxMi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+T24gQXVnIDI0LCAyMDE2LCBhdCAxOjMxIFBNLCBKb2huIEJyYWRsZXkgJmx0 OzxhIGhyZWY9Im1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZlN2p0 YkB2ZTdqdGIuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIGlkZWEgZm9yIGN0eSB3YXMgdG8gYWxsb3cgYSBKV1Mg dG8gZW5jYXBzdWxhdGUgdGhpbmdzIGxpa2UgYSBiaW5hcnkgR0lGIGFzIGFuIGV4YW1wbGUuICZu YnNwOyBJIHRoaW5rIHVzaW5nIGl0IGZvciBEaXN0aW5ndWlzaGluZyBzdWJ0eXBlcyBvZiBKV1Qg d291bGQgYmUgYSBzdHJldGNoLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPkkgYW0gbW9zdCBjb21mb3J0YWJsZSB3aXRoIEEuICZuYnNwOyBJIHRoaW5r IHRoYXQgYWRkaW5nIGEgSldUIHR5cGUgY2xhaW0gYXQgdGhlIHRvcCBsZXZlbCBtYXkgYWxzbyBi ZSB1c2VmdWwgZ29pbmcgZm9yd2FyZCB0byBhdm9pZCBtaXNpbnRlcnByZXRhdGlvbi48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkpvaG4g Qi48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i Pk9uIEF1ZyAyNCwgMjAxNiwgYXQgNDo1MSBQTSwgTWFyaXVzIFNjdXJ0ZXNjdSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1zY3VydGVz Y3VAZ29vZ2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+T24g V2VkLCBBdWcgMjQsIDIwMTYgYXQgMTE6MDcgQU0sIFBoaWwgSHVudCZuYnNwOyZsdDs8YSBocmVm PSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5waGlsLmh1bnRA b3JhY2xlLmNvbTwvYT4mZ3Q7Jm5ic3A7d3JvdGU6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj5UaGUgYXV0aG9ycyBoYXZlIGJlZW4gaGF2aW5nIGEgZGlzY3Vzc2lv biB3aXRoIHJlZ2FyZHMgdG8gdXNpbmcgdGhlIOKAnHN1YuKAnSBjbGFpbSBpbiB0aGUgdG9wIGxl dmVsLiBJIHRoaW5rIGl0IGlzDQogaW1wb3J0YW50IHRvIHRyeSBhbmQgZ2V0IHRoaXMgZGlzY3Vz c2lvbiBiYWNrIHRvIHRoZSBtYWluIGdyb3VwLiBNeSBhcG9sb2dpZXMgZm9yIHRoZSBsb25nIG5v dGUuIEkgd2FudGVkIHRvIGdldCBhbGwgdGhlIHByb3MgYW5kIGNvbnMgb24gdGhlIHRhYmxlICho aW50OiAmbmJzcDtwbGVhc2UgYWRkIGlmIEkgbWlzc2VkIGFueSkuLi48L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+QSBxdWVzdGlvbiByZW1haW5zIHNo b3VsZCDigJxzdWLigJ0gYmUgdXNhYmxlIGF0IHRoZSB0b3AgbGV2ZWwuJm5ic3A7IFRoZSBkb3du c2lkZSBvZiB0aGlzIGFwcHJvYWNoIGlzIHRoYXQgYSBTRVQgY291bGQgcG90ZW50aWFsbHkNCiBi ZSBwcmVzZW50ZWQgYXMgYW4gYWNjZXNzIG9yIGlEIHRva2VuIGFuZCBtaWdodCBpbml0aWFsbHkg YmUgY29uZnVzZWQgYmVjYXVzZSBleGlzdGluZyBjb2RlIGRvZXMgbm90IGtub3cgaXQgbmVlZHMg dG8gbG9vayBmb3IgYW4g4oCcZXZlbnRz4oCdIGF0dHJpYnV0ZS4mbmJzcDsgVGhlIFNFVCBhbmQg SUQgVG9rZW4gZm9yIGFsbCBpbnRlbnNpdmUgcHVycG9zZXMgYXJlIHRoZSBzYW1lIHNpbmNlIGEg U0VUIGp1c3QgaGFzIHNvbWV0aGluZyBleHRyYSAodGhlIGV2ZW50cw0KIGNsYWltKS48L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VGhlcmUgaXMgYWxz byB0aGUgcXVlc3Rpb24gdGhhdCBpZiBPSURDIExvZ291dCB1c2VzIGl0IGluIHRoZSB0b3AgbGV2 ZWwsIG1heSBvdGhlciBldmVudHMgdXNlIGl0PyBSRkM3NTE5IGRlZmluZXMNCiDigJxzdWLigJ0g YXMgYSBTdHJpbmcgb3IgVVJJIHZhbHVlLiBGb3IgZXhhbXBsZSwgaW4gU0NJTSBldmVudHMsIHRo ZSDigJxzdWLigJ0gdmFsdWUgY291bGQgYmUgYSBTQ0lNIFJlc291cmNlIFVSSSB0aGF0IGluZGlj YXRlcyB0aGUgcmVzb3VyY2Ugd2hvc2Ugc3RhdGUgaGFzIGNoYW5nZWQuJm5ic3A7IEluIE9BdXRo IGl0IGNvdWxkIGJlIGRlZmluZWQgYXMgdGhlIHRva2VuIGlkZW50aWZpZXIgb2YgdGhlIHRva2Vu IHRoYXQgaGFzIGJlZW4gcmV2b2tlZC4mbmJzcDsgQSBTRVQNCiBhYm91dCBibGFja2xpc3Rpbmcg YW4gSVAgYWRkcmVzcyBtaWdodCBwdXQgdGhlIElQIGFkZHJlc3MgaW4gc3ViLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5TbyB0aGVyZSBhcmUgdGhy ZWUgb3B0aW9ucyAoT3B0aW9uIEEgc2VlbXMgdG8gYmUgZmF2b3VyZWQgc28gZmFyKTogJm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkEu Jm5ic3A7IFN1YiBhdCBUb3AgTGV2ZWw6PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJz cDsmbmJzcDvigJxzdWLigJ0gZ2VuZXJhbGx5DQogdXNlZCB0byByZWZlcmVuY2UgdGhlIFNlY3Vy aXR5IFN1YmplY3QgdGhlIFNFVCBpcyB0YWxraW5nIGFib3V0LiZuYnNwOyBJdCB1c2VzIGEgbW9y ZSBnZW5lcmFsIGVuZ2xpc2ggbGFuZ3VhZ2UgaW50ZW50IG9mIHN1YmplY3QgcmF0aGVyIHRoYW4g dGhlIHRyYWRpdGlvbmFsIHVzZSBhcyBzZWVuIGluIFNBTUwgb3IgT3BlbklEIENvbm5lY3QuJm5i c3A7IFJlZ2FyZGxlc3MgaXQgaXMgc3RpbGwgY29tcGxpYW50IHdpdGggUkZDNzUxOSAoYSBTdHJp bmcgb3IgVVJJKS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZiI+VGhpcyB3b3VsZCB0ZW5kIHRvIGxlYWQgdG8gYSBzdHlsZSBvZiBTRVRzIHdoZXJlIHRo ZSBlbnZlbG9wZSBjYXJyaWVzIHRoZSB2YWxpZGF0aW9uIGluZm9ybWF0aW9uLCB0aGUgdHlwZSBv ZiBldmVudCwNCiBhbmQgdGhlIHN1YmplY3Qgb2YgdGhlIGV2ZW50LiBBZGRpdGlvbmFsIGRhdGEg Z29lcyBpbiB0aGUgcGF5bG9hZC4gQW4gYWR2YW50YWdlIG9mIHRoaXMgc3R5bGUsIGlzIHRoYXQg Zm9yIG1hbnkgZXZlbnRzLCB0aGUgb25seSB0aGluZyBuZWVkZWQgaXMgdGhlIGV2ZW50IHR5cGUg YW5kIHRoZSBzdWJqZWN0LiZuYnNwOyBObyBwYXlsb2FkcyB3b3VsZCBiZSBuZWVkZWQuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5Gb3Ig ZXZlbnRzIHRoYXQgZG9u4oCZdCB3YW50IHBheWxvYWQsIGl0IGlzIHByb2JhYmx5IG9rIGZvciBw cm9maWxpbmcgZXZlbnQgc3RhbmRhcmRzIHRvIGRlZmluZSBtb3JlIGNsYWltcyBhdCB0aGUNCiB0 b3AgbGV2ZWwuIFRoZXkgTVVTVCBiZSByZWdpc3RlcmVkIGluIHRoZSBKV1QgcmVnaXN0cnkuIFBy b2ZpbGluZyBldmVudHMgY2FuIGF2b2lkIHJlZ2lzdHJhdGlvbiBieSBqdXN0IHB1dHRpbmcgdGhl aXIgYXR0cmlidXRlcy9jbGFpbXMgaW4gdGhlIHBheWxvYWQgYXJlYSBhcyBkZXNjcmliZWQgaW4g dGhlIHNwZWMuJm5ic3A7IEhvd2V2ZXIsIHRoaXMgd291bGQgYmUgaW5jb25zaXN0ZW50IHdpdGgg dGhvc2UgdGhhdCB1c2UgcGF5bG9hZHMgd2l0aCB1bnJlZ2lzdGVyZWQNCiBjbGFpbXMuJm5ic3A7 IEkgcG9pbnQgb3V0IHRoYXQgd2Ugc3dpdGNoZWQgZnJvbSByZWdpc3RlcmVkIGV2ZW50IFVSTnMg dG8gVVJJcyB0byBhdm9pZCByZWdpc3RyYXRpb24uJm5ic3A7IEhlbmNlIHRoZSBtb3ZlIHRvIHBh eWxvYWQgb2JqZWN0cyB0byBlbGltaW5hdGUgcmVnaXN0cmF0aW9uIGZvciBhdHRyaWJ1dGVzL2Ns YWltcy4gJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+VGhpcyBzdGlsbCBoYXMgdGhlIG5lZ2F0aXZlcyBvZiBiZWluZyBjb25m dXNhYmxlIGFzIGFuIElEIFRva2VuIGJ5IGV4aXN0aW5nIGNvZGUuIFRoZXJlIGhhcyBiZWVuIGEg ZGlzY3Vzc2lvbiB0aGF0DQog4oCcaXNz4oCdIGFuZC9vciDigJxhdWTigJ0gc2hvdWxkIGFjdHVh bGx5IGJlIGRpZmZlcmVudCBhbmQgdGhlIHJlY2VpdmVyIHNob3VsZCBkZXRlY3QgdGhhdC4mbmJz cDsgSG93ZXZlciBpbiB0aGUgT0lEQyBMb2dvdXQgY2FzZSwgYnkgZGVzaWduLCB0aGUg4oCcaXNz 4oCdIHZhbHVlIHdvdWxkIGJlIHRoZSBzYW1lLiZuYnNwOyBUaGUg4oCcYXVk4oCdIHdvdWxkIGFs c28gbGlrZWx5IGJlIHRoZSBzYW1lIHVubGVzcyB0aGUgc3BlYyBpbmRpY2F0ZXMgdGhhdCBhbiBh bGlhcyDigJxhdWTigJ0gYmUgdXNlZA0KIGV2ZW4gdGhvdWdoIHRoZSBhdWRpZW5jZSBtYXkgYmUg dGhlIHNhbWUgZW50aXR5IGluIGJvdGggY2FzZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkIuIEV4Y2x1c2l2ZS1Vc2Ugb2YgU3ViOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A74oCcc3Vi4oCdIGlzDQogaW50ZXJwcmV0ZWQg dG8gYnkgdHJhZGl0aW9uYWwgZGVmaW5pdGlvbiBhbmQgaXMgcmVzZXJ2ZWQgZm9yIE9BdXRoIHRv a2VucyBhbmQgT0lEQyBDb25uZWN0IHVzYWdlIG9ubHkuJm5ic3A7IEluIG9yZGVyIHRvICZuYnNw O2F2b2lkIGNvbmZ1c2luZywgYWxsIHByb2ZpbGluZyBldmVudCBzcGVjcyBzaG91bGQgTk9UIHVz ZSDigJxzdWLigJ0gaW4gdGhlIHRvcCBsZXZlbCBleGNlcHQgZm9yIE9JREMuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlRoaXMgaGFzIHRoZSBkaXNh ZHZhbnRhZ2UgdGhhdCBPSURDIHJlcXVpcmVzIHNwZWNpYWwgaGFuZGxpbmcgaW4gdGVybXMgb2Yg YSBnZW5lcmFsIHVzZSBldmVudCBsaWJyYXJ5LCBidXQgb24gdGhlDQogb3RoZXIgaGFuZCBhIExv Z291dCBFdmVudCBtaWdodCBiZSBoYW5kbGVkIGRpcmVjdGx5IGJ5IGV4aXN0aW5nIElEIFRva2Vu IGNvZGUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi PlRoaXMgc3RpbGwgaGFzIHRoZSBkaXNhZHZhbnRhZ2UgdGhhdCBhbiBTRVQgY291bGQgYmUgY29u ZnVzZWQgZm9yIGFuIElEIFRva2VuLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmIj5DLiBOby1Ub3AtTGV2ZWwgRGF0YTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPiZuYnNwO0luIG9yZGVyIHRvDQogbW9yZSBhZ2dyZXNzaXZlbHkgYXZvaWQg Y29uZnVzaW9uIG9mIFNFVHMgYXMgSUQgVG9rZW5zLCBtYWtlIGl0IG1hbmRhdG9yeSB0aGF0IFNF VHMgbWF5IG5vdCBjb250YWluIGEg4oCcc3Vi4oCdIHZhbHVlIGF0IHRoZSB0b3AgbGV2ZWwuJm5i c3A7IFRoZSBPSURDIExvZ291dCBFdmVudCwgZm9yIGV4YW1wbGUsIHdvdWxkIHRoZW4gaW5jbHVk ZSBhIOKAnHN1YuKAnSB2YWx1ZSBpbiB0aGUgcGF5bG9hZCBhcmVhLiBUaGlzIHNob3VsZCBjYXVz ZSBleGlzdGluZyByZWx5aW5nDQogcGFydGllcyB0byBmYWlsIGNvcnJlY3RseS4gJm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlRoaXMgd291 bGQgcHJvdmlkZSBhIG1heGltYWwgZGlmZmVyZW5jZSBmb3JtIGEgSURUb2tlbiBvciBhY2Nlc3Mg dG9rZW4uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi PlRoaXMgd291bGQgaGF2ZSB0aGUgYWR2YW50YWdlIHRoYXQgZW52ZWxvcGVzIGNvbnRhaW4gbm8g ZGF0YSwgYW5kIHRoYXQgZXZlcnkgU0VUIGhhcyBhIHBheWxvYWQgd2hlcmUgdGhlIGRhdGEgaXMN CiBmb3VuZC4gSXQgcmVxdWlyZXMgbW9yZSBwYXJzaW5nIGluIHNvbWUgY2FzZXMsIGJ1dCBpdCBp cyBhdCBsZWFzdCBjb25zaXN0ZW50LiBXaGlsZSB3ZSBkb27igJl0IGV4cGVjdCBnZW5lcmFsIHBy b2Nlc3NvcnMgbGlrZSBpbiBTT0FQIGZvciBkaXN0cmlidXRpb24gKG11Y2ggb2YgaXQgaXMgcG9p bnQgdG8gcG9pbnQgYW5kIHZlcnkgY29udGV4dHVhbGx5IGRyaXZlbiksIEkgcGVyc29uYWxseSBl eHBlY3QgdG8gc2VlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7KiAmbmJzcDtE ZXZlbG9wbWVudCBvZiBnZW5lcmFsIHB1cnBvc2UgbGlicmFyaWVzIGFuZCB0b29scyB0aGF0IGFy ZSB1c2VkIGVuaGFuY2UgcHJvdG9jb2xzIGFuZCBzeXN0ZW1zJm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj4mbmJzcDsmbmJzcDsqICZuYnNwO0F1ZGl0IGFuZCB0aHJlYXQgYW5hbHlzaXMgc3lz dGVtcyB3aWxsIGJlIGxvb2tpbmcgYXQgc29tZSBldmVudHMgaGlzdG9yaWNhbGx5LiBUaGVzZSB3 aWxsIHRlbmQgdG8gbWVyZ2UgbXVsdGlwbGUNCiBldmVudCBmZWVkcy48L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+TWlrZSBKb25lcyBhbHNvIHN1Z2dl c3RlZCB1c2luZyB0aGUmbmJzcDs8Yj7igJxjdHnigJ08L2I+Jm5ic3A7KGNvbnRlbnQgdHlwZSkg aGVhZGVyIGF0dHJpYnV0ZSBmcm9tIEpXVC4mbmJzcDsgSSB0aGluayBtb3N0IGNvZGUgdG9kYXkN CiBoYXMgdGhpcyBzZXQgdG8gaWdub3JlIG9yIGZpeGVkIGFzIOKAnEpXVOKAnS4mbmJzcDsgSSB3 b25kZXIgd2hhdCBjdXJyZW50IGltcGxlbWVudHMgd291bGQgZmVlbCBpZiB3ZSBpbnRyb2R1Y2Vk IGEg4oCcY3R54oCdIHZhbHVlIG9mIOKAnFNFVOKAnT8mbmJzcDsgV291bGQgdGhhdCBoZWxwPzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWYiPkkgdGhpbmsgaXQgaXMgdmVyeSBpbXBvcnRhbnQgdG8gYmUgYWJsZSB0 byBjbGVhcmx5IGRpc3Rpbmd1aXNoIGRpZmZlcmVudCB0eXBlcyBvZiBKV1QgdG9rZW5zLiBGb3Ig ZXhhbXBsZSwgbm90IGJlaW5nDQogYWJsZSB0byBjcm9zcyBwb3N0IGEgU2VjdXJpdHkgRXZlbnQg VG9rZW4gYXMgYW4gSWQgVG9rZW4uJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlJlYWRpbmcmbmJzcDtSRkMgNzUxOSBJIGRvbid0IHRoaW5r IGN0eSBmaXRzIHRoZSBiaWxsLCBidXQgSSBjb3VsZCBiZSB3cm9uZy4gY3R5IGlzIGEgaGVhZGVy IHBhcmFtZXRlciB1c2VkIGJ5IHRoZSBjcnlwdG8NCiBhbGdvcml0aG0gYW5kIHRoZSBkZWZhdWx0 IHZhbHVlIGlzIEpXVC4gV2UgbmVlZCB0byBkaXN0aW5ndWlzaCBzdWItdHlwZXMgb2YgSldULCBh bmQgaXQgc2hvdWxkIGJlIGEgY2xhaW0gaW5zaWRlIHRoZSBKV1QuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPldpdGggdGhlIGFib3ZlIGlzc3VlIGlu IG1pbmQsIEkgdGhpbmsgb3B0aW9uIEEgaXMgdGhlIGNsZWFuZXN0IHNvbHV0aW9uLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5UaGFua3MgZm9yIHlvdXIgY29t bWVudHMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZiI+UGhpbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmIj5AaW5kZXBlbmRlbnRpZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ PGEgaHJlZj0iaHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNvbS8iIHRhcmdldD0iX2JsYW5rIj53 d3cuaW5kZXBlbmRlbnRpZC5jb208L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPjxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0 b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCklkLWV2ZW50IG1haWxpbmcgbGlzdDxicj4N CjxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPklkLWV2 ZW50QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vaWQtZXZlbnQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50PC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCklkLWV2ZW50IG1haWxpbmcgbGlzdDxicj4N Cjwvc3Bhbj48YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmIj5JZC1ldmVudEBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vaWQtZXZlbnQiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50PC9zcGFuPjwvYT48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQpJZC1ldmVudCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86 SWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5JZC1ldmVudEBpZXRmLm9yZzwvYT48 YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2 ZW50IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9pZC1ldmVudDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_SN1PR0301MB164555B61381414BA03FCA26F5EA0SN1PR0301MB1645_-- From nobody Wed Aug 24 14:55:43 2016 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 D964912D5F6 for ; Wed, 24 Aug 2016 14:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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_H2=-0.001, 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 JLzHWN68T1XY for ; Wed, 24 Aug 2016 14:55:38 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0096.outbound.protection.outlook.com [104.47.32.96]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7D2F12B00E for ; Wed, 24 Aug 2016 14:55: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=iMVX8er+MLqBuyA17BcN16ZCga5C4n07ehlytBmkmS0=; b=Rm4EUVG7aUV1dUdKtgbOV6Ms5e+N5IZOtRt1q1xfrcW22kG2XDOXKCDuKu+y9cKUny5v1d4iqLt6FDhHJKOMigqCXOtX08PVoqgvGAkV4uiTjNJQGVjRx75TxvBjqPNTqJala5z0zP3DGoQoVhDFa9oMk9mXEmgkO2z9gIUSxQo= Received: from SN1PR0301MB1645.namprd03.prod.outlook.com (10.162.130.139) by SN1PR0301MB1647.namprd03.prod.outlook.com (10.162.130.141) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.13; Wed, 24 Aug 2016 21:55:34 +0000 Received: from SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) by SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) with mapi id 15.01.0587.013; Wed, 24 Aug 2016 21:55:35 +0000 From: Mike Jones To: Mike Jones , John Bradley Thread-Topic: [Id-event] Discussion on use of "sub" and confusion as ID Token Thread-Index: AQHR/jJ6Kzu5WyrJDU6lijc1KOHPZaBYhVKAgAALW4CAAAfQgIAABtOAgAABn1CAAAS3gIAAAHaQgAABN2A= Date: Wed, 24 Aug 2016 21:55:35 +0000 Message-ID: References: <3D5305B0-0365-4B07-9D35-81F0B7B04FF2@oracle.com> <382F27DF-A35A-43F3-8C2E-CE3D8ABC4ADB@ve7jtb.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [64.134.242.226] x-ms-office365-filtering-correlation-id: 2efae5db-9bd6-491f-151a-08d3cc6960dc x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1647; 6:OETZJu4ZBOJg7NYr17/pihHx1Vg3oi0nipwNh+XwSNZ6r0dc81M8+51Z85zxUbxEdvdnoAxjYoZHFEBIx7mzZnXwbVgAfqotMcXfxDGh7gtbYsxKSH3Gw29D8w6t1bDhMpEf1g3Cqq85I+lyzXnu8pRoUi5+hC1VP3EdfWa+MKmWQb1FdLJlwWU3aXfjqagrH2TLsWc50BXZE5kKYupZZqaQSDzNU2EEIADaJ6wxShVUsCOIQNaEMG5Ve+sLbzrurj3UPSvjpBetqP30R/lkRFHfPCQkZbFMwRfNM0JwgoDcFlaulCqZC9z/tInQPYxkleQoytvS8imV4tOsB9zHPw==; 5:2xbwRNO2U0qj3vE2xxuSoCo8ZorGvS/CZL+GH1a8Dhq3DhN+zsg+f0Jzy9vJhS5qfBBASjxZEv0hGI+ir/olE7Qe2XrUAAJVsHCu6+ROnGb+iAGHSadbir4p2I1WOnzeOzmEtG9gkKa2NCWIB4dQnQ==; 24:IchvqeZRref+r+WuiXTwtay2gGR5C+JmD1iu1OTllGuE7v/9PK7ScuQi3MvRR3wv1ti4zhDiBUlCdfTAfi42SbVk+0ScighiahnVMBzgFoQ=; 7:HV/X3KPZeaVhnrgmskeJYvRmuLxci5NOUreJeC4Vowok15dIxzlhq49fGxkOm2AnWdx5FbcKIea9u3FaifELL0Jn+xtAYhFSVUsDQRDuhJnlbb/lNKLGJBhJ/jLBEKx1X+0QGrZom75YO+wkgf6n/ry4HSaUJ0e9WVq7WrNVQZ+UXhSPEd3aVC1m2S13VaTnXygd/VQUHn6ONMDeq0bXu/2FzicLy/luIycd64JXLrTIq3K4Zl9giX2XeeXNOAXn x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1647; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(192374486261705)(211936372134217)(21748063052155)(21532816269658)(146099531331640)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:SN1PR0301MB1647; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1647; x-forefront-prvs: 0044C17179 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(51444003)(377454003)(189002)(24454002)(19625215002)(9686002)(87936001)(54356999)(76176999)(15975445007)(5660300001)(19617315012)(50986999)(5002640100001)(33656002)(101416001)(10090500001)(189998001)(2561002)(5001770100001)(77096005)(102836003)(19580405001)(2906002)(2421001)(2950100001)(19580395003)(2900100001)(7906003)(10400500002)(7696003)(74316002)(586003)(86362001)(3846002)(4326007)(8990500004)(86612001)(790700001)(6116002)(10290500002)(92566002)(5005710100001)(19300405004)(97736004)(7736002)(7846002)(66066001)(3280700002)(93886004)(3660700001)(19609705001)(68736007)(122556002)(76576001)(105586002)(1511001)(106116001)(99286002)(8676002)(16236675004)(81156014)(8936002)(81166006)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0301MB1647; H:SN1PR0301MB1645.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB16452624ECBC114DB86B3DCFF5EA0SN1PR0301MB1645_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Aug 2016 21:55:35.7129 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1647 Archived-At: Cc: Phil Hunt , "id-event@ietf.org" , Marius Scurtescu Subject: Re: [Id-event] Discussion on use of "sub" and confusion as ID Token X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 24 Aug 2016 21:55:42 -0000 --_000_SN1PR0301MB16452624ECBC114DB86B3DCFF5EA0SN1PR0301MB1645_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmWxsIGFkZCBvbmUgb3RoZXIgdGhvdWdodCB3aGljaCBpcyBiZWhpbmQgd2hhdCBJIHdyb3Rl IGJlbG93LiAgQSBnb29kIHNwZWMgc29sdmVzIG9uZSB0aGluZyBhbmQgc29sdmVzIGl0IHdlbGwu ICBUaGUgdGhpbmcgZm9yIHRoZSBldmVudHMgc3BlYyB0byBzb2x2ZSBpcyBkZWZpbmluZyBhIHN0 YW5kYXJkIHdheSB0byByZXByZXNlbnQgYW4gZXZlbnQgaW4gYSBKV1QuICBJdCBzaG91bGQgc3Rv cCB0aGVyZS4NCg0KRGlzdGluZ3Vpc2hpbmcgYmV0d2VlbiBhbGwgSldUcyBpcyBhIGRpZmZlcmVu dCBwcm9ibGVtLCB3aGljaCBpcyB3aHkgKGlmIGFueSBvZiB1cyBldmVyIGRlY2lkZSB0byBzb2x2 ZSBpdCkgaXQgc2hvdWxkIGJlIGluIGEgZGlmZmVyZW50LCB1bnJlbGF0ZWQgc3BlYy4gIEJ1dCBh Z2FpbiwgSeKAmW0gbGVlcnkgb2YgdGhpcyBpbiB0aGUgZmlyc3QgcGxhY2UsIGJlY2F1c2UgdGhl IHByaW1hcnkgdXNlIG9mIGl0IGlzIHRvIGVuYWJsZSBTT0FQLXN0eWxlIG1lc3NhZ2UgZGlzcGF0 Y2hpbmcuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAtLSBNaWtlDQoNCkZyb206IElkLWV2ZW50IFttYWlsdG86aWQtZXZlbnQtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1pa2UgSm9uZXMNClNlbnQ6IFdlZG5lc2RheSwgQXVn dXN0IDI0LCAyMDE2IDI6NTAgUE0NClRvOiBKb2huIEJyYWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29t Pg0KQ2M6IE1hcml1cyBTY3VydGVzY3UgPG1zY3VydGVzY3VAZ29vZ2xlLmNvbT47IGlkLWV2ZW50 QGlldGYub3JnOyBQaGlsIEh1bnQgPHBoaWwuaHVudEBvcmFjbGUuY29tPg0KU3ViamVjdDogUmU6 IFtJZC1ldmVudF0gRGlzY3Vzc2lvbiBvbiB1c2Ugb2YgInN1YiIgYW5kIGNvbmZ1c2lvbiBhcyBJ RCBUb2tlbg0KDQpJIHdvdWxkIHN0cm9uZ2x5IG9wcG9zZSBldmVudHMgcmVxdWlyaW5nIHVzZSBv ZiBpdCwgYmVjYXVzZSBpdOKAmXMgbm90IG5lY2Vzc2FyeSBmb3IgYW4gZXZlbnQgc3RyZWFtLiAg SXQgd291bGQgYmUgdW5uZWNlc3NhcnkgYmFnZ2FnZS4NCg0KSSBhZ3JlZSB3aXRoIFBoaWwgdGhh dCBzdHJvbmcgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgaXMgYXMgZmFyIGFzIHdlIHNob3VsZCBn byBpbiB0aGUgRXZlbnQgVG9rZW4gc3BlYy4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogSm9obiBCcmFkbGV5 IFttYWlsdG86dmU3anRiQHZlN2p0Yi5jb21dDQpTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAyNCwg MjAxNiAyOjQ3IFBNDQpUbzogTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29t PG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+Pg0KQ2M6IFBoaWwgSHVudCA8cGhp bC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj47IGlkLWV2ZW50 QGlldGYub3JnPG1haWx0bzppZC1ldmVudEBpZXRmLm9yZz47IE1hcml1cyBTY3VydGVzY3UgPG1z Y3VydGVzY3VAZ29vZ2xlLmNvbTxtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tPj4NClN1Ympl Y3Q6IFJlOiBbSWQtZXZlbnRdIERpc2N1c3Npb24gb24gdXNlIG9mICJzdWIiIGFuZCBjb25mdXNp b24gYXMgSUQgVG9rZW4NCg0KWWVzLCAgb24gb25lIG9mIHRoZSBjYWxscyB3ZSB0YWxrZWQgYWJv dXQgaXQgYmVpbmcgYSBzZXBhcmF0ZSBzcGVjIHRvIHJlZ2lzdGVyIHRoZSBjbGFpbSBhbmQgdGhl biBldmVudHMgY291bGQgdXNlIGl0Lg0KDQpPbiBXZWQsIEF1ZyAyNCwgMjAxNiBhdCA2OjMxIFBN LCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwu Sm9uZXNAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KQSBzcGVjIGNvdWxkIGNyZWF0ZSBhIHRvcC1s ZXZlbCBKV1QgdHlwZSBjbGFpbSwgYnV0IEnigJlkIGFzc2VydCB0aGF0IGl04oCZcyBvdXQgb2Yg c2NvcGUgZm9yIHRoZSBFdmVudHMgc3BlYy4gIEl0IHdvdWxkIHByb2JhYmx5IG5lZWQgdG8gYmUg aXRzIG93biBzcGVjIGFuZCBzYXkgYmFzaWNhbGx5IOKAnHVzZSBpdCBpZiB5b3XigJlyZSBpbiB1 c2UgY2FzZXMgaW4gd2hpY2ggaXTigJlzIHVzZWZ1bCB0byBkaXN0aW5ndWlzaCBiZXR3ZWVuIHRo aW5nc+KAnS4NCg0KRnJvbTogSWQtZXZlbnQgW21haWx0bzppZC1ldmVudC1ib3VuY2VzQGlldGYu b3JnPG1haWx0bzppZC1ldmVudC1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIEpvaG4g QnJhZGxleQ0KU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMjQsIDIwMTYgMjoyNCBQTQ0KVG86IFBo aWwgSHVudCA8cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29t Pj4NCkNjOiBpZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86aWQtZXZlbnRAaWV0Zi5vcmc+OyBNYXJp dXMgU2N1cnRlc2N1IDxtc2N1cnRlc2N1QGdvb2dsZS5jb208bWFpbHRvOm1zY3VydGVzY3VAZ29v Z2xlLmNvbT4+DQpTdWJqZWN0OiBSZTogW0lkLWV2ZW50XSBEaXNjdXNzaW9uIG9uIHVzZSBvZiAi c3ViIiBhbmQgY29uZnVzaW9uIGFzIElEIFRva2VuDQoNCkkgd2FzIHNheWluZyB0aGF0IGN0eSB3 YXMgd3JvbmcgZm9yIHRoaXMuDQoNCklmIHlvdSBsb29rIGF0IHRoZSBkZWZpbml0aW9uIG9mIHR5 cCBpbiBKV1MgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc1MTUjcGFnZS0xMyAgeW91 IGNhbiBzZWUgdGhhdCBpdCBpcyByZWFsbHkgaW50ZW5kZWQgdG8gYmUgdGhlIG1lZGlhIHR5cGUg b2YgdGhlIGNvbXBsZXRlIEpXUy9KV0UgYW5kIGlzIG9taXR0ZWQgb3Igc2V0IHRvIEpXVCBpZiBp dCBpcyBhIGNvbXBhY3QgSldULiAgICAgU2V0dGluZyBpdCB0byBTRVQgc2VlbXMgd3JvbmcgYXMg aXQgaXMgc3RpbGwgYSBKV1QuICAgSSB3YXMgcmVjb21tZW5kaW5nIGNvbnNpZGVyaW5nIGEgSldU IHRvcCBsZXZlbCBjbGFpbSBpbiB0aGUgSldUIHJlZ2lzdHJ5Lg0KDQpKb2huIEIuDQoNCg0KT24g QXVnIDI0LCAyMDE2LCBhdCA1OjU5IFBNLCBQaGlsIEh1bnQgPHBoaWwuaHVudEBvcmFjbGUuY29t PG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+IHdyb3RlOg0KDQpKb2huLA0KDQpEaWQgeW91 IG1lYW4gYWRkaW5nIGEg4oCcand0X3R5cGXigJ0gYXR0cmlidXRlICh0aGF0IGJlY29tZXMgYSBy ZWdpc3RlcmVkIEpXVCBjbGFpbSkgT1IgYWRkaW5nIGEgbmV3IHR5cGUgdmFsdWUgZm9yIHRoZSBK V1QgaGVhZGVyIOKAnHR5cOKAnT8gIE5vdGUgZm9yIGV2ZXJ5b25l4oCZcyBjb252ZW5pZW5jZSBm cm9tIDc1MTk6DQoNCg0KVGhlICJ0eXAiICh0eXBlKSBIZWFkZXIgUGFyYW1ldGVyIGRlZmluZWQg YnkgW0pXUzxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzUxOSNyZWYtSldTPl0gYW5k IFtKV0U8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc1MTkjcmVmLUpXRT5dIGlzIHVz ZWQNCg0KICAgYnkgSldUIGFwcGxpY2F0aW9ucyB0byBkZWNsYXJlIHRoZSBtZWRpYSB0eXBlIFtJ QU5BLk1lZGlhVHlwZXM8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc1MTkjcmVmLUlB TkEuTWVkaWFUeXBlcz5dIG9mDQoNCiAgIHRoaXMgY29tcGxldGUgSldULiAgVGhpcyBpcyBpbnRl bmRlZCBmb3IgdXNlIGJ5IHRoZSBKV1QgYXBwbGljYXRpb24NCg0KICAgd2hlbiB2YWx1ZXMgdGhh dCBhcmUgbm90IEpXVHMgY291bGQgYWxzbyBiZSBwcmVzZW50IGluIGFuIGFwcGxpY2F0aW9uDQoN CiAgIGRhdGEgc3RydWN0dXJlIHRoYXQgY2FuIGNvbnRhaW4gYSBKV1Qgb2JqZWN0OyB0aGUgYXBw bGljYXRpb24gY2FuIHVzZQ0KDQogICB0aGlzIHZhbHVlIHRvIGRpc2FtYmlndWF0ZSBhbW9uZyB0 aGUgZGlmZmVyZW50IGtpbmRzIG9mIG9iamVjdHMgdGhhdA0KDQogICBtaWdodCBiZSBwcmVzZW50 LiAgSXQgd2lsbCB0eXBpY2FsbHkgbm90IGJlIHVzZWQgYnkgYXBwbGljYXRpb25zIHdoZW4NCg0K ICAgaXQgaXMgYWxyZWFkeSBrbm93biB0aGF0IHRoZSBvYmplY3QgaXMgYSBKV1QuICBUaGlzIHBh cmFtZXRlciBpcw0KDQogICBpZ25vcmVkIGJ5IEpXVCBpbXBsZW1lbnRhdGlvbnM7IGFueSBwcm9j ZXNzaW5nIG9mIHRoaXMgcGFyYW1ldGVyIGlzDQoNCiAgIHBlcmZvcm1lZCBieSB0aGUgSldUIGFw cGxpY2F0aW9uLiAgSWYgcHJlc2VudCwgaXQgaXMgUkVDT01NRU5ERUQgdGhhdA0KDQogICBpdHMg dmFsdWUgYmUgIkpXVCIgdG8gaW5kaWNhdGUgdGhhdCB0aGlzIG9iamVjdCBpcyBhIEpXVC4gIFdo aWxlDQoNCiAgIG1lZGlhIHR5cGUgbmFtZXMgYXJlIG5vdCBjYXNlIHNlbnNpdGl2ZSwgaXQgaXMg UkVDT01NRU5ERUQgdGhhdCAiSldUIg0KDQogICBhbHdheXMgYmUgc3BlbGxlZCB1c2luZyB1cHBl cmNhc2UgY2hhcmFjdGVycyBmb3IgY29tcGF0aWJpbGl0eSB3aXRoDQoNCiAgIGxlZ2FjeSBpbXBs ZW1lbnRhdGlvbnMuICBVc2Ugb2YgdGhpcyBIZWFkZXIgUGFyYW1ldGVyIGlzIE9QVElPTkFMLg0K DQoNCldoYXQgaXMgY29uY2VybmluZyBpcyB0aGUgbGluZSB0aGF0IHNheXM6DQoNCkl0IHdpbGwg dHlwaWNhbGx5IG5vdCBiZSB1c2VkIGJ5IGFwcGxpY2F0aW9ucyB3aGVuDQoNCiAgIGl0IGlzIGFs cmVhZHkga25vd24gdGhhdCB0aGUgb2JqZWN0IGlzIGEgSldULiAgVGhpcyBwYXJhbWV0ZXIgaXMN Cg0KICAgaWdub3JlZCBieSBKV1QgaW1wbGVtZW50YXRpb25zOyBhbnkgcHJvY2Vzc2luZyBvZiB0 aGlzIHBhcmFtZXRlciBpcw0KDQogICBwZXJmb3JtZWQgYnkgdGhlIEpXVCBhcHBsaWNhdGlvbi4g IElmIHByZXNlbnQsIGl0IGlzIFJFQ09NTUVOREVEIHRoYXQNCg0KICAgaXRzIHZhbHVlIGJlICJK V1QiIHRvIGluZGljYXRlIHRoYXQgdGhpcyBvYmplY3QgaXMgYSBKV1QuDQoNCklmIGl0IGlzIHR5 cGljYWxseSBpZ25vcmVkLCB0aGVuIGhhdmluZyBpdCDigJx0eXDigJ0gYmUg4oCcU0VU4oCdIG1h eSBub3QgaGVscCBtdWNoIGluaXRpYWxseS4gQnV0IGF0IGxlYXN0IGl0IGlzIG1vcmUgZGVmaW5p dGl2ZS4NCg0KSWYgdGhlIGdyb3VwIGlzIGNvbWZvcnRhYmxlLCBJIGFtIG9rIHdpdGggbWFraW5n IOKAnHR5cOKAnSBiZSDigJxTRVTigJ0uICBJdCBpcyBvbmUgbW9yZSBkaXN0aW5ndWlzaGluZyBp dGVtLg0KDQpSZWdhcmRsZXNzLCBJIHdpbGwgYWxzbyBwdXQgYSBjYXV0aW9uYXJ5IG5vdGUgaW4g dGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHRoYXQgaWYgaXNzdWluZyBTRVRzIHRvIGF1ZGll bmNlcyB0aGF0IGFsc28gcmVjZWl2ZSBKV1RzLCB0aGF0IGFwcHJvcHJpYXRlIGNhcmUgYmUgdGFr ZW4gbm90IHRvIGNvbmZ1c2UgaWYgc29tZWhvdyBhIGhhY2tlciBpcyBhYmxlIHRvIHByZXNlbnQg dGhlIFNFVCBhcyBpZiBpdCB3ZXJlIGEgSldUIHRvIGdhaW4gYWNjZXNzIChlLmcuIGluIGFuIGF1 dGhvcml6YXRpb24gaGVhZGVyKS4gIE5vcm1hbGx5IHRoaXMgc2hvdWxkIG5vdCBiZSBwb3NzaWJs ZSBhcyBJIHdvdWxkIGFzc3VtZSBTRVRzIGFyZSBwYXNzZWQgdmlhIHNvbWV0aGluZyBsaWtlIGFu IEhUVFAgUE9TVCBiYWNrLWNoYW5uZWwuDQoNClBoaWwNCg0KQGluZGVwZW5kZW50aWQNCnd3dy5p bmRlcGVuZGVudGlkLmNvbTxodHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tLz4NCnBoaWwuaHVu dEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4NCg0KDQoNCg0KT24gQXVn IDI0LCAyMDE2LCBhdCAxOjMxIFBNLCBKb2huIEJyYWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPG1h aWx0bzp2ZTdqdGJAdmU3anRiLmNvbT4+IHdyb3RlOg0KDQpUaGUgaWRlYSBmb3IgY3R5IHdhcyB0 byBhbGxvdyBhIEpXUyB0byBlbmNhcHN1bGF0ZSB0aGluZ3MgbGlrZSBhIGJpbmFyeSBHSUYgYXMg YW4gZXhhbXBsZS4gICBJIHRoaW5rIHVzaW5nIGl0IGZvciBEaXN0aW5ndWlzaGluZyBzdWJ0eXBl cyBvZiBKV1Qgd291bGQgYmUgYSBzdHJldGNoLg0KDQpJIGFtIG1vc3QgY29tZm9ydGFibGUgd2l0 aCBBLiAgIEkgdGhpbmsgdGhhdCBhZGRpbmcgYSBKV1QgdHlwZSBjbGFpbSBhdCB0aGUgdG9wIGxl dmVsIG1heSBhbHNvIGJlIHVzZWZ1bCBnb2luZyBmb3J3YXJkIHRvIGF2b2lkIG1pc2ludGVycHJl dGF0aW9uLg0KDQpKb2huIEIuDQpPbiBBdWcgMjQsIDIwMTYsIGF0IDQ6NTEgUE0sIE1hcml1cyBT Y3VydGVzY3UgPG1zY3VydGVzY3VAZ29vZ2xlLmNvbTxtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUu Y29tPj4gd3JvdGU6DQoNCk9uIFdlZCwgQXVnIDI0LCAyMDE2IGF0IDExOjA3IEFNLCBQaGlsIEh1 bnQgPHBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+IHdy b3RlOg0KDQpUaGUgYXV0aG9ycyBoYXZlIGJlZW4gaGF2aW5nIGEgZGlzY3Vzc2lvbiB3aXRoIHJl Z2FyZHMgdG8gdXNpbmcgdGhlIOKAnHN1YuKAnSBjbGFpbSBpbiB0aGUgdG9wIGxldmVsLiBJIHRo aW5rIGl0IGlzIGltcG9ydGFudCB0byB0cnkgYW5kIGdldCB0aGlzIGRpc2N1c3Npb24gYmFjayB0 byB0aGUgbWFpbiBncm91cC4gTXkgYXBvbG9naWVzIGZvciB0aGUgbG9uZyBub3RlLiBJIHdhbnRl ZCB0byBnZXQgYWxsIHRoZSBwcm9zIGFuZCBjb25zIG9uIHRoZSB0YWJsZSAoaGludDogIHBsZWFz ZSBhZGQgaWYgSSBtaXNzZWQgYW55KS4uLg0KDQpBIHF1ZXN0aW9uIHJlbWFpbnMgc2hvdWxkIOKA nHN1YuKAnSBiZSB1c2FibGUgYXQgdGhlIHRvcCBsZXZlbC4gIFRoZSBkb3duc2lkZSBvZiB0aGlz IGFwcHJvYWNoIGlzIHRoYXQgYSBTRVQgY291bGQgcG90ZW50aWFsbHkgYmUgcHJlc2VudGVkIGFz IGFuIGFjY2VzcyBvciBpRCB0b2tlbiBhbmQgbWlnaHQgaW5pdGlhbGx5IGJlIGNvbmZ1c2VkIGJl Y2F1c2UgZXhpc3RpbmcgY29kZSBkb2VzIG5vdCBrbm93IGl0IG5lZWRzIHRvIGxvb2sgZm9yIGFu IOKAnGV2ZW50c+KAnSBhdHRyaWJ1dGUuICBUaGUgU0VUIGFuZCBJRCBUb2tlbiBmb3IgYWxsIGlu dGVuc2l2ZSBwdXJwb3NlcyBhcmUgdGhlIHNhbWUgc2luY2UgYSBTRVQganVzdCBoYXMgc29tZXRo aW5nIGV4dHJhICh0aGUgZXZlbnRzIGNsYWltKS4NCg0KVGhlcmUgaXMgYWxzbyB0aGUgcXVlc3Rp b24gdGhhdCBpZiBPSURDIExvZ291dCB1c2VzIGl0IGluIHRoZSB0b3AgbGV2ZWwsIG1heSBvdGhl ciBldmVudHMgdXNlIGl0PyBSRkM3NTE5IGRlZmluZXMg4oCcc3Vi4oCdIGFzIGEgU3RyaW5nIG9y IFVSSSB2YWx1ZS4gRm9yIGV4YW1wbGUsIGluIFNDSU0gZXZlbnRzLCB0aGUg4oCcc3Vi4oCdIHZh bHVlIGNvdWxkIGJlIGEgU0NJTSBSZXNvdXJjZSBVUkkgdGhhdCBpbmRpY2F0ZXMgdGhlIHJlc291 cmNlIHdob3NlIHN0YXRlIGhhcyBjaGFuZ2VkLiAgSW4gT0F1dGggaXQgY291bGQgYmUgZGVmaW5l ZCBhcyB0aGUgdG9rZW4gaWRlbnRpZmllciBvZiB0aGUgdG9rZW4gdGhhdCBoYXMgYmVlbiByZXZv a2VkLiAgQSBTRVQgYWJvdXQgYmxhY2tsaXN0aW5nIGFuIElQIGFkZHJlc3MgbWlnaHQgcHV0IHRo ZSBJUCBhZGRyZXNzIGluIHN1Yi4NCg0KU28gdGhlcmUgYXJlIHRocmVlIG9wdGlvbnMgKE9wdGlv biBBIHNlZW1zIHRvIGJlIGZhdm91cmVkIHNvIGZhcik6DQoNCkEuICBTdWIgYXQgVG9wIExldmVs OiAg4oCcc3Vi4oCdIGdlbmVyYWxseSB1c2VkIHRvIHJlZmVyZW5jZSB0aGUgU2VjdXJpdHkgU3Vi amVjdCB0aGUgU0VUIGlzIHRhbGtpbmcgYWJvdXQuICBJdCB1c2VzIGEgbW9yZSBnZW5lcmFsIGVu Z2xpc2ggbGFuZ3VhZ2UgaW50ZW50IG9mIHN1YmplY3QgcmF0aGVyIHRoYW4gdGhlIHRyYWRpdGlv bmFsIHVzZSBhcyBzZWVuIGluIFNBTUwgb3IgT3BlbklEIENvbm5lY3QuICBSZWdhcmRsZXNzIGl0 IGlzIHN0aWxsIGNvbXBsaWFudCB3aXRoIFJGQzc1MTkgKGEgU3RyaW5nIG9yIFVSSSkuDQoNClRo aXMgd291bGQgdGVuZCB0byBsZWFkIHRvIGEgc3R5bGUgb2YgU0VUcyB3aGVyZSB0aGUgZW52ZWxv cGUgY2FycmllcyB0aGUgdmFsaWRhdGlvbiBpbmZvcm1hdGlvbiwgdGhlIHR5cGUgb2YgZXZlbnQs IGFuZCB0aGUgc3ViamVjdCBvZiB0aGUgZXZlbnQuIEFkZGl0aW9uYWwgZGF0YSBnb2VzIGluIHRo ZSBwYXlsb2FkLiBBbiBhZHZhbnRhZ2Ugb2YgdGhpcyBzdHlsZSwgaXMgdGhhdCBmb3IgbWFueSBl dmVudHMsIHRoZSBvbmx5IHRoaW5nIG5lZWRlZCBpcyB0aGUgZXZlbnQgdHlwZSBhbmQgdGhlIHN1 YmplY3QuICBObyBwYXlsb2FkcyB3b3VsZCBiZSBuZWVkZWQuDQoNCkZvciBldmVudHMgdGhhdCBk b27igJl0IHdhbnQgcGF5bG9hZCwgaXQgaXMgcHJvYmFibHkgb2sgZm9yIHByb2ZpbGluZyBldmVu dCBzdGFuZGFyZHMgdG8gZGVmaW5lIG1vcmUgY2xhaW1zIGF0IHRoZSB0b3AgbGV2ZWwuIFRoZXkg TVVTVCBiZSByZWdpc3RlcmVkIGluIHRoZSBKV1QgcmVnaXN0cnkuIFByb2ZpbGluZyBldmVudHMg Y2FuIGF2b2lkIHJlZ2lzdHJhdGlvbiBieSBqdXN0IHB1dHRpbmcgdGhlaXIgYXR0cmlidXRlcy9j bGFpbXMgaW4gdGhlIHBheWxvYWQgYXJlYSBhcyBkZXNjcmliZWQgaW4gdGhlIHNwZWMuICBIb3dl dmVyLCB0aGlzIHdvdWxkIGJlIGluY29uc2lzdGVudCB3aXRoIHRob3NlIHRoYXQgdXNlIHBheWxv YWRzIHdpdGggdW5yZWdpc3RlcmVkIGNsYWltcy4gIEkgcG9pbnQgb3V0IHRoYXQgd2Ugc3dpdGNo ZWQgZnJvbSByZWdpc3RlcmVkIGV2ZW50IFVSTnMgdG8gVVJJcyB0byBhdm9pZCByZWdpc3RyYXRp b24uICBIZW5jZSB0aGUgbW92ZSB0byBwYXlsb2FkIG9iamVjdHMgdG8gZWxpbWluYXRlIHJlZ2lz dHJhdGlvbiBmb3IgYXR0cmlidXRlcy9jbGFpbXMuDQoNClRoaXMgc3RpbGwgaGFzIHRoZSBuZWdh dGl2ZXMgb2YgYmVpbmcgY29uZnVzYWJsZSBhcyBhbiBJRCBUb2tlbiBieSBleGlzdGluZyBjb2Rl LiBUaGVyZSBoYXMgYmVlbiBhIGRpc2N1c3Npb24gdGhhdCDigJxpc3PigJ0gYW5kL29yIOKAnGF1 ZOKAnSBzaG91bGQgYWN0dWFsbHkgYmUgZGlmZmVyZW50IGFuZCB0aGUgcmVjZWl2ZXIgc2hvdWxk IGRldGVjdCB0aGF0LiAgSG93ZXZlciBpbiB0aGUgT0lEQyBMb2dvdXQgY2FzZSwgYnkgZGVzaWdu LCB0aGUg4oCcaXNz4oCdIHZhbHVlIHdvdWxkIGJlIHRoZSBzYW1lLiAgVGhlIOKAnGF1ZOKAnSB3 b3VsZCBhbHNvIGxpa2VseSBiZSB0aGUgc2FtZSB1bmxlc3MgdGhlIHNwZWMgaW5kaWNhdGVzIHRo YXQgYW4gYWxpYXMg4oCcYXVk4oCdIGJlIHVzZWQgZXZlbiB0aG91Z2ggdGhlIGF1ZGllbmNlIG1h eSBiZSB0aGUgc2FtZSBlbnRpdHkgaW4gYm90aCBjYXNlcy4NCg0KQi4gRXhjbHVzaXZlLVVzZSBv ZiBTdWI6IOKAnHN1YuKAnSBpcyBpbnRlcnByZXRlZCB0byBieSB0cmFkaXRpb25hbCBkZWZpbml0 aW9uIGFuZCBpcyByZXNlcnZlZCBmb3IgT0F1dGggdG9rZW5zIGFuZCBPSURDIENvbm5lY3QgdXNh Z2Ugb25seS4gIEluIG9yZGVyIHRvICBhdm9pZCBjb25mdXNpbmcsIGFsbCBwcm9maWxpbmcgZXZl bnQgc3BlY3Mgc2hvdWxkIE5PVCB1c2Ug4oCcc3Vi4oCdIGluIHRoZSB0b3AgbGV2ZWwgZXhjZXB0 IGZvciBPSURDLg0KDQpUaGlzIGhhcyB0aGUgZGlzYWR2YW50YWdlIHRoYXQgT0lEQyByZXF1aXJl cyBzcGVjaWFsIGhhbmRsaW5nIGluIHRlcm1zIG9mIGEgZ2VuZXJhbCB1c2UgZXZlbnQgbGlicmFy eSwgYnV0IG9uIHRoZSBvdGhlciBoYW5kIGEgTG9nb3V0IEV2ZW50IG1pZ2h0IGJlIGhhbmRsZWQg ZGlyZWN0bHkgYnkgZXhpc3RpbmcgSUQgVG9rZW4gY29kZS4NCg0KVGhpcyBzdGlsbCBoYXMgdGhl IGRpc2FkdmFudGFnZSB0aGF0IGFuIFNFVCBjb3VsZCBiZSBjb25mdXNlZCBmb3IgYW4gSUQgVG9r ZW4uDQoNCkMuIE5vLVRvcC1MZXZlbCBEYXRhOiBJbiBvcmRlciB0byBtb3JlIGFnZ3Jlc3NpdmVs eSBhdm9pZCBjb25mdXNpb24gb2YgU0VUcyBhcyBJRCBUb2tlbnMsIG1ha2UgaXQgbWFuZGF0b3J5 IHRoYXQgU0VUcyBtYXkgbm90IGNvbnRhaW4gYSDigJxzdWLigJ0gdmFsdWUgYXQgdGhlIHRvcCBs ZXZlbC4gIFRoZSBPSURDIExvZ291dCBFdmVudCwgZm9yIGV4YW1wbGUsIHdvdWxkIHRoZW4gaW5j bHVkZSBhIOKAnHN1YuKAnSB2YWx1ZSBpbiB0aGUgcGF5bG9hZCBhcmVhLiBUaGlzIHNob3VsZCBj YXVzZSBleGlzdGluZyByZWx5aW5nIHBhcnRpZXMgdG8gZmFpbCBjb3JyZWN0bHkuDQoNClRoaXMg d291bGQgcHJvdmlkZSBhIG1heGltYWwgZGlmZmVyZW5jZSBmb3JtIGEgSURUb2tlbiBvciBhY2Nl c3MgdG9rZW4uDQoNClRoaXMgd291bGQgaGF2ZSB0aGUgYWR2YW50YWdlIHRoYXQgZW52ZWxvcGVz IGNvbnRhaW4gbm8gZGF0YSwgYW5kIHRoYXQgZXZlcnkgU0VUIGhhcyBhIHBheWxvYWQgd2hlcmUg dGhlIGRhdGEgaXMgZm91bmQuIEl0IHJlcXVpcmVzIG1vcmUgcGFyc2luZyBpbiBzb21lIGNhc2Vz LCBidXQgaXQgaXMgYXQgbGVhc3QgY29uc2lzdGVudC4gV2hpbGUgd2UgZG9u4oCZdCBleHBlY3Qg Z2VuZXJhbCBwcm9jZXNzb3JzIGxpa2UgaW4gU09BUCBmb3IgZGlzdHJpYnV0aW9uIChtdWNoIG9m IGl0IGlzIHBvaW50IHRvIHBvaW50IGFuZCB2ZXJ5IGNvbnRleHR1YWxseSBkcml2ZW4pLCBJIHBl cnNvbmFsbHkgZXhwZWN0IHRvIHNlZToNCiAgKiAgRGV2ZWxvcG1lbnQgb2YgZ2VuZXJhbCBwdXJw b3NlIGxpYnJhcmllcyBhbmQgdG9vbHMgdGhhdCBhcmUgdXNlZCBlbmhhbmNlIHByb3RvY29scyBh bmQgc3lzdGVtcw0KICAqICBBdWRpdCBhbmQgdGhyZWF0IGFuYWx5c2lzIHN5c3RlbXMgd2lsbCBi ZSBsb29raW5nIGF0IHNvbWUgZXZlbnRzIGhpc3RvcmljYWxseS4gVGhlc2Ugd2lsbCB0ZW5kIHRv IG1lcmdlIG11bHRpcGxlIGV2ZW50IGZlZWRzLg0KDQpNaWtlIEpvbmVzIGFsc28gc3VnZ2VzdGVk IHVzaW5nIHRoZSDigJxjdHnigJ0gKGNvbnRlbnQgdHlwZSkgaGVhZGVyIGF0dHJpYnV0ZSBmcm9t IEpXVC4gIEkgdGhpbmsgbW9zdCBjb2RlIHRvZGF5IGhhcyB0aGlzIHNldCB0byBpZ25vcmUgb3Ig Zml4ZWQgYXMg4oCcSldU4oCdLiAgSSB3b25kZXIgd2hhdCBjdXJyZW50IGltcGxlbWVudHMgd291 bGQgZmVlbCBpZiB3ZSBpbnRyb2R1Y2VkIGEg4oCcY3R54oCdIHZhbHVlIG9mIOKAnFNFVOKAnT8g IFdvdWxkIHRoYXQgaGVscD8NCg0KSSB0aGluayBpdCBpcyB2ZXJ5IGltcG9ydGFudCB0byBiZSBh YmxlIHRvIGNsZWFybHkgZGlzdGluZ3Vpc2ggZGlmZmVyZW50IHR5cGVzIG9mIEpXVCB0b2tlbnMu IEZvciBleGFtcGxlLCBub3QgYmVpbmcgYWJsZSB0byBjcm9zcyBwb3N0IGEgU2VjdXJpdHkgRXZl bnQgVG9rZW4gYXMgYW4gSWQgVG9rZW4uDQoNClJlYWRpbmcgUkZDIDc1MTkgSSBkb24ndCB0aGlu ayBjdHkgZml0cyB0aGUgYmlsbCwgYnV0IEkgY291bGQgYmUgd3JvbmcuIGN0eSBpcyBhIGhlYWRl ciBwYXJhbWV0ZXIgdXNlZCBieSB0aGUgY3J5cHRvIGFsZ29yaXRobSBhbmQgdGhlIGRlZmF1bHQg dmFsdWUgaXMgSldULiBXZSBuZWVkIHRvIGRpc3Rpbmd1aXNoIHN1Yi10eXBlcyBvZiBKV1QsIGFu ZCBpdCBzaG91bGQgYmUgYSBjbGFpbSBpbnNpZGUgdGhlIEpXVC4NCg0KV2l0aCB0aGUgYWJvdmUg aXNzdWUgaW4gbWluZCwgSSB0aGluayBvcHRpb24gQSBpcyB0aGUgY2xlYW5lc3Qgc29sdXRpb24u DQoNCg0KDQpUaGFua3MgZm9yIHlvdXIgY29tbWVudHMuDQoNCg0KUGhpbA0KDQpAaW5kZXBlbmRl bnRpZA0Kd3d3LmluZGVwZW5kZW50aWQuY29tPGh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20v Pg0KcGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPg0KDQoN Cg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJ ZC1ldmVudCBtYWlsaW5nIGxpc3QNCklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBp ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklkLWV2 ZW50IG1haWxpbmcgbGlzdA0KSWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGlldGYu b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudA0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSWQtZXZlbnQg bWFpbGluZyBsaXN0DQpJZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50DQoNCg0KDQo= --_000_SN1PR0301MB16452624ECBC114DB86B3DCFF5EA0SN1PR0301MB1645_ 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 Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZv cm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpwLm1zb25vcm1h bDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25v cm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6 MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1h aWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7DQoJY29sb3I6IzAwMjA2MDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMwMDIwNjAiPknigJlsbCBhZGQgb25lIG90aGVyIHRob3VnaHQgd2hpY2ggaXMgYmVoaW5k IHdoYXQgSSB3cm90ZSBiZWxvdy4mbmJzcDsgQSBnb29kIHNwZWMgc29sdmVzIG9uZSB0aGluZyBh bmQgc29sdmVzIGl0IHdlbGwuJm5ic3A7IFRoZSB0aGluZyBmb3IgdGhlIGV2ZW50cyBzcGVjIHRv IHNvbHZlIGlzIGRlZmluaW5nDQogYSBzdGFuZGFyZCB3YXkgdG8gcmVwcmVzZW50IGFuIGV2ZW50 IGluIGEgSldULiZuYnNwOyBJdCBzaG91bGQgc3RvcCB0aGVyZS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPkRpc3Rpbmd1aXNoaW5nIGJldHdlZW4gYWxsIEpXVHMg aXMgYSBkaWZmZXJlbnQgcHJvYmxlbSwgd2hpY2ggaXMgd2h5IChpZiBhbnkgb2YgdXMgZXZlciBk ZWNpZGUgdG8gc29sdmUgaXQpIGl0IHNob3VsZCBiZSBpbiBhIGRpZmZlcmVudCwgdW5yZWxhdGVk IHNwZWMuJm5ic3A7IEJ1dA0KIGFnYWluLCBJ4oCZbSBsZWVyeSBvZiB0aGlzIGluIHRoZSBmaXJz dCBwbGFjZSwgYmVjYXVzZSB0aGUgcHJpbWFyeSB1c2Ugb2YgaXQgaXMgdG8gZW5hYmxlIFNPQVAt c3R5bGUgbWVzc2FnZSBkaXNwYXRjaGluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBN aWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0i X01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxF bmRDb21wb3NlIj48L3NwYW4+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4gSWQtZXZlbnQgW21haWx0bzppZC1ldmVudC1ib3VuY2VzQGlldGYub3Jn XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5NaWtlIEpvbmVzPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5l c2RheSwgQXVndXN0IDI0LCAyMDE2IDI6NTAgUE08YnI+DQo8Yj5Ubzo8L2I+IEpvaG4gQnJhZGxl eSAmbHQ7dmU3anRiQHZlN2p0Yi5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBNYXJpdXMgU2N1cnRl c2N1ICZsdDttc2N1cnRlc2N1QGdvb2dsZS5jb20mZ3Q7OyBpZC1ldmVudEBpZXRmLm9yZzsgUGhp bCBIdW50ICZsdDtwaGlsLmh1bnRAb3JhY2xlLmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IFtJZC1ldmVudF0gRGlzY3Vzc2lvbiBvbiB1c2Ugb2YgJnF1b3Q7c3ViJnF1b3Q7IGFuZCBj b25mdXNpb24gYXMgSUQgVG9rZW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+SSB3b3VsZCBzdHJvbmds eSBvcHBvc2UgZXZlbnRzIHJlcXVpcmluZyB1c2Ugb2YgaXQsIGJlY2F1c2UgaXTigJlzIG5vdCBu ZWNlc3NhcnkgZm9yIGFuIGV2ZW50IHN0cmVhbS4mbmJzcDsgSXQgd291bGQgYmUgdW5uZWNlc3Nh cnkgYmFnZ2FnZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPkkg YWdyZWUgd2l0aCBQaGlsIHRoYXQgc3Ryb25nIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGlzIGFz IGZhciBhcyB3ZSBzaG91bGQgZ28gaW4gdGhlIEV2ZW50IFRva2VuIHNwZWMuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMw MDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBKb2huIEJyYWRsZXkgWzxhIGhyZWY9Im1h aWx0bzp2ZTdqdGJAdmU3anRiLmNvbSI+bWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tPC9hPl0NCjxi cj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEF1Z3VzdCAyNCwgMjAxNiAyOjQ3IFBNPGJyPg0K PGI+VG86PC9iPiBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0Bt aWNyb3NvZnQuY29tIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0Ozxicj4NCjxi PkNjOjwvYj4gUGhpbCBIdW50ICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5j b20iPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86aWQtZXZl bnRAaWV0Zi5vcmciPmlkLWV2ZW50QGlldGYub3JnPC9hPjsgTWFyaXVzIFNjdXJ0ZXNjdSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbSI+bXNjdXJ0ZXNjdUBnb29nbGUu Y29tPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtJZC1ldmVudF0gRGlzY3Vzc2lv biBvbiB1c2Ugb2YgJnF1b3Q7c3ViJnF1b3Q7IGFuZCBjb25mdXNpb24gYXMgSUQgVG9rZW48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXMsICZuYnNwO29uIG9uZSBvZiB0 aGUgY2FsbHMgd2UgdGFsa2VkIGFib3V0IGl0IGJlaW5nIGEgc2VwYXJhdGUgc3BlYyB0byByZWdp c3RlciB0aGUgY2xhaW0gYW5kIHRoZW4gZXZlbnRzIGNvdWxkIHVzZSBpdC48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgQXVnIDI0LCAyMDE2IGF0 IDY6MzEgUE0sIE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1p Y3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGlu O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5BIHNwZWMgY291bGQgY3JlYXRlIGEg dG9wLWxldmVsIEpXVCB0eXBlIGNsYWltLCBidXQgSeKAmWQgYXNzZXJ0IHRoYXQgaXTigJlzIG91 dCBvZiBzY29wZSBmb3IgdGhlIEV2ZW50cw0KIHNwZWMuJm5ic3A7IEl0IHdvdWxkIHByb2JhYmx5 IG5lZWQgdG8gYmUgaXRzIG93biBzcGVjIGFuZCBzYXkgYmFzaWNhbGx5IOKAnHVzZSBpdCBpZiB5 b3XigJlyZSBpbiB1c2UgY2FzZXMgaW4gd2hpY2ggaXTigJlzIHVzZWZ1bCB0byBkaXN0aW5ndWlz aCBiZXR3ZWVuIHRoaW5nc+KAnS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxhIG5hbWU9Im1fNjAzMjU2NzE5OTIxMjc5MjI1Nl9fTWFpbEVuZENvbXBvc2Ui PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PC9hPjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4gSWQtZXZlbnQgW21haWx0bzo8YSBocmVmPSJtYWlsdG86aWQtZXZlbnQtYm91bmNlc0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0K PGI+T24gQmVoYWxmIE9mIDwvYj5Kb2huIEJyYWRsZXk8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVz ZGF5LCBBdWd1c3QgMjQsIDIwMTYgMjoyNCBQTTxicj4NCjxiPlRvOjwvYj4gUGhpbCBIdW50ICZs dDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5w aGlsLmh1bnRAb3JhY2xlLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWls dG86aWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pZC1ldmVudEBpZXRmLm9yZzwv YT47IE1hcml1cyBTY3VydGVzY3UgJmx0OzxhIGhyZWY9Im1haWx0bzptc2N1cnRlc2N1QGdvb2ds ZS5jb20iIHRhcmdldD0iX2JsYW5rIj5tc2N1cnRlc2N1QGdvb2dsZS5jb208L2E+Jmd0Ozxicj4N CjxiPlN1YmplY3Q6PC9iPiBSZTogW0lkLWV2ZW50XSBEaXNjdXNzaW9uIG9uIHVzZSBvZiAmcXVv dDtzdWImcXVvdDsgYW5kIGNvbmZ1c2lvbiBhcyBJRCBUb2tlbjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIHdhcyBzYXlpbmcgdGhhdCBjdHkgd2Fz IHdyb25nIGZvciB0aGlzLiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPklmIHlvdSBsb29rIGF0IHRoZSBkZWZpbml0 aW9uIG9mIHR5cCBpbiBKV1MmbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvcmZjNzUxNSNwYWdlLTEzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL3JmYzc1MTUjcGFnZS0xMzwvYT4mbmJzcDsgeW91IGNhbiBzZWUgdGhhdA0KIGl0IGlz IHJlYWxseSBpbnRlbmRlZCB0byBiZSB0aGUgbWVkaWEgdHlwZSBvZiB0aGUgY29tcGxldGUgSldT L0pXRSBhbmQgaXMgb21pdHRlZCBvciBzZXQgdG8gSldUIGlmIGl0IGlzIGEgY29tcGFjdCBKV1Qu ICZuYnNwOyAmbmJzcDsgU2V0dGluZyBpdCB0byBTRVQgc2VlbXMgd3JvbmcgYXMgaXQgaXMgc3Rp bGwgYSBKV1QuICZuYnNwOyBJIHdhcyByZWNvbW1lbmRpbmcgY29uc2lkZXJpbmcgYSBKV1QgdG9w IGxldmVsIGNsYWltIGluIHRoZSBKV1QgcmVnaXN0cnkuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Kb2huIEIuPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBBdWcgMjQsIDIwMTYs IGF0IDU6NTkgUE0sIFBoaWwgSHVudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFj bGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Kb2hu LDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkRpZCB5 b3UgbWVhbiBhZGRpbmcgYSDigJxqd3RfdHlwZeKAnSBhdHRyaWJ1dGUgKHRoYXQgYmVjb21lcyBh IHJlZ2lzdGVyZWQgSldUIGNsYWltKSBPUiBhZGRpbmcgYSBuZXcgdHlwZSB2YWx1ZSBmb3IgdGhl IEpXVCBoZWFkZXIg4oCcdHlw4oCdPyZuYnNwOyBOb3RlIGZvciBldmVyeW9uZeKAmXMgY29udmVu aWVuY2UgZnJvbSA3NTE5OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmU+ VGhlICZxdW90O3R5cCZxdW90OyAodHlwZSkgSGVhZGVyIFBhcmFtZXRlciBkZWZpbmVkIGJ5IFs8 YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzUxOSNyZWYtSldTIiB0YXJn ZXQ9Il9ibGFuayIgdGl0bGU9IiZxdW90O0pTT04gV2ViIFNpZ25hdHVyZSAoSldTKSZxdW90OyI+ SldTPC9hPl0gYW5kIFs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzUx OSNyZWYtSldFIiB0YXJnZXQ9Il9ibGFuayIgdGl0bGU9IiZxdW90O0pTT04gV2ViIEVuY3J5cHRp b24gKEpXRSkmcXVvdDsiPkpXRTwvYT5dIGlzIHVzZWQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m bmJzcDsmbmJzcDsgYnkgSldUIGFwcGxpY2F0aW9ucyB0byBkZWNsYXJlIHRoZSBtZWRpYSB0eXBl IFs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzUxOSNyZWYtSUFOQS5N ZWRpYVR5cGVzIiB0YXJnZXQ9Il9ibGFuayI+SUFOQS5NZWRpYVR5cGVzPC9hPl0gb2Y8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgdGhpcyBjb21wbGV0ZSBKV1QuJm5ic3A7IFRo aXMgaXMgaW50ZW5kZWQgZm9yIHVzZSBieSB0aGUgSldUIGFwcGxpY2F0aW9uPG86cD48L286cD48 L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHdoZW4gdmFsdWVzIHRoYXQgYXJlIG5vdCBKV1RzIGNv dWxkIGFsc28gYmUgcHJlc2VudCBpbiBhbiBhcHBsaWNhdGlvbjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPiZuYnNwOyZuYnNwOyBkYXRhIHN0cnVjdHVyZSB0aGF0IGNhbiBjb250YWluIGEgSldUIG9i amVjdDsgdGhlIGFwcGxpY2F0aW9uIGNhbiB1c2U8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJz cDsmbmJzcDsgdGhpcyB2YWx1ZSB0byBkaXNhbWJpZ3VhdGUgYW1vbmcgdGhlIGRpZmZlcmVudCBr aW5kcyBvZiBvYmplY3RzIHRoYXQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsg bWlnaHQgYmUgcHJlc2VudC4mbmJzcDsgSXQgd2lsbCB0eXBpY2FsbHkgbm90IGJlIHVzZWQgYnkg YXBwbGljYXRpb25zIHdoZW48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgaXQg aXMgYWxyZWFkeSBrbm93biB0aGF0IHRoZSBvYmplY3QgaXMgYSBKV1QuJm5ic3A7IFRoaXMgcGFy YW1ldGVyIGlzPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGlnbm9yZWQgYnkg SldUIGltcGxlbWVudGF0aW9uczsgYW55IHByb2Nlc3Npbmcgb2YgdGhpcyBwYXJhbWV0ZXIgaXM8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgcGVyZm9ybWVkIGJ5IHRoZSBKV1Qg YXBwbGljYXRpb24uJm5ic3A7IElmIHByZXNlbnQsIGl0IGlzIFJFQ09NTUVOREVEIHRoYXQ8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgaXRzIHZhbHVlIGJlICZxdW90O0pXVCZx dW90OyB0byBpbmRpY2F0ZSB0aGF0IHRoaXMgb2JqZWN0IGlzIGEgSldULiZuYnNwOyBXaGlsZTxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBtZWRpYSB0eXBlIG5hbWVzIGFyZSBu b3QgY2FzZSBzZW5zaXRpdmUsIGl0IGlzIFJFQ09NTUVOREVEIHRoYXQgJnF1b3Q7SldUJnF1b3Q7 PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGFsd2F5cyBiZSBzcGVsbGVkIHVz aW5nIHVwcGVyY2FzZSBjaGFyYWN0ZXJzIGZvciBjb21wYXRpYmlsaXR5IHdpdGg8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgbGVnYWN5IGltcGxlbWVudGF0aW9ucy4mbmJzcDsg VXNlIG9mIHRoaXMgSGVhZGVyIFBhcmFtZXRlciBpcyBPUFRJT05BTC48bzpwPjwvbzpwPjwvcHJl Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPldoYXQgaXMg Y29uY2VybmluZyBpcyB0aGUgbGluZSB0aGF0IHNheXM6Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cHJlPkl0IHdpbGwgdHlwaWNhbGx5IG5vdCBiZSB1c2VkIGJ5IGFwcGxp Y2F0aW9ucyB3aGVuPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGl0IGlzIGFs cmVhZHkga25vd24gdGhhdCB0aGUgb2JqZWN0IGlzIGEgSldULiZuYnNwOyA8Yj48dT5UaGlzIHBh cmFtZXRlciBpczwvdT48L2I+PG86cD48L286cD48L3ByZT4NCjxwcmU+PGI+PHU+Jm5ic3A7Jm5i c3A7IGlnbm9yZWQgYnkgSldUIGltcGxlbWVudGF0aW9uczwvdT48L2I+OyBhbnkgcHJvY2Vzc2lu ZyBvZiB0aGlzIHBhcmFtZXRlciBpczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNw OyBwZXJmb3JtZWQgYnkgdGhlIEpXVCBhcHBsaWNhdGlvbi4mbmJzcDsgSWYgcHJlc2VudCwgaXQg aXMgUkVDT01NRU5ERUQgdGhhdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBp dHMgdmFsdWUgYmUgJnF1b3Q7SldUJnF1b3Q7IHRvIGluZGljYXRlIHRoYXQgdGhpcyBvYmplY3Qg aXMgYSBKV1QuPG86cD48L286cD48L3ByZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5JZiBpdCBpcyB0eXBpY2FsbHkgaWdub3JlZCwgdGhlbiBoYXZpbmcgaXQg4oCcdHlw4oCd IGJlIOKAnFNFVOKAnSBtYXkgbm90IGhlbHAgbXVjaCBpbml0aWFsbHkuIEJ1dCBhdCBsZWFzdCBp dCBpcyBtb3JlIGRlZmluaXRpdmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5JZiB0aGUgZ3JvdXAgaXMgY29tZm9ydGFibGUsIEkgYW0g b2sgd2l0aCBtYWtpbmcg4oCcdHlw4oCdIGJlIOKAnFNFVOKAnS4mbmJzcDsgSXQgaXMgb25lIG1v cmUgZGlzdGluZ3Vpc2hpbmcgaXRlbS4gJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5SZWdhcmRsZXNzLCBJIHdpbGwgYWxzbyBw dXQgYSBjYXV0aW9uYXJ5IG5vdGUgaW4gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHRoYXQg aWYgaXNzdWluZyBTRVRzIHRvIGF1ZGllbmNlcyB0aGF0IGFsc28gcmVjZWl2ZSBKV1RzLCB0aGF0 IGFwcHJvcHJpYXRlIGNhcmUgYmUgdGFrZW4gbm90IHRvIGNvbmZ1c2UNCiBpZiBzb21laG93IGEg aGFja2VyIGlzIGFibGUgdG8gcHJlc2VudCB0aGUgU0VUIGFzIGlmIGl0IHdlcmUgYSBKV1QgdG8g Z2FpbiBhY2Nlc3MgKGUuZy4gaW4gYW4gYXV0aG9yaXphdGlvbiBoZWFkZXIpLiZuYnNwOyBOb3Jt YWxseSB0aGlzIHNob3VsZCBub3QgYmUgcG9zc2libGUgYXMgSSB3b3VsZCBhc3N1bWUgU0VUcyBh cmUgcGFzc2VkIHZpYSBzb21ldGhpbmcgbGlrZSBhbiBIVFRQIFBPU1QgYmFjay1jaGFubmVsLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlBoaWw8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkBp bmRlcGVuZGVudGlkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxhIGhyZWY9Imh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20vIiB0YXJnZXQ9 Il9ibGFuayI+d3d3LmluZGVwZW5kZW50aWQuY29tPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxhIGhyZWY9 Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBoaWwuaHVudEBv cmFjbGUuY29tPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbTox Mi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+T24gQXVnIDI0LCAyMDE2LCBhdCAxOjMxIFBNLCBKb2huIEJyYWRsZXkgJmx0Ozxh IGhyZWY9Im1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZlN2p0YkB2 ZTdqdGIuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+VGhlIGlkZWEgZm9yIGN0eSB3YXMgdG8gYWxsb3cgYSBKV1MgdG8g ZW5jYXBzdWxhdGUgdGhpbmdzIGxpa2UgYSBiaW5hcnkgR0lGIGFzIGFuIGV4YW1wbGUuICZuYnNw OyBJIHRoaW5rIHVzaW5nIGl0IGZvciBEaXN0aW5ndWlzaGluZyBzdWJ0eXBlcyBvZiBKV1Qgd291 bGQgYmUgYSBzdHJldGNoLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPkkgYW0gbW9zdCBjb21mb3J0YWJsZSB3aXRoIEEuICZuYnNwOyBJIHRoaW5rIHRo YXQgYWRkaW5nIGEgSldUIHR5cGUgY2xhaW0gYXQgdGhlIHRvcCBsZXZlbCBtYXkgYWxzbyBiZSB1 c2VmdWwgZ29pbmcgZm9yd2FyZCB0byBhdm9pZCBtaXNpbnRlcnByZXRhdGlvbi48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkpvaG4gQi48 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9u IEF1ZyAyNCwgMjAxNiwgYXQgNDo1MSBQTSwgTWFyaXVzIFNjdXJ0ZXNjdSAmbHQ7PGEgaHJlZj0i bWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1zY3VydGVzY3VA Z29vZ2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+T24gV2Vk LCBBdWcgMjQsIDIwMTYgYXQgMTE6MDcgQU0sIFBoaWwgSHVudCZuYnNwOyZsdDs8YSBocmVmPSJt YWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5waGlsLmh1bnRAb3Jh Y2xlLmNvbTwvYT4mZ3Q7Jm5ic3A7d3JvdGU6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj5UaGUgYXV0aG9ycyBoYXZlIGJlZW4gaGF2aW5nIGEgZGlzY3Vzc2lvbiB3 aXRoIHJlZ2FyZHMgdG8gdXNpbmcgdGhlIOKAnHN1YuKAnSBjbGFpbSBpbiB0aGUgdG9wIGxldmVs LiBJIHRoaW5rIGl0IGlzDQogaW1wb3J0YW50IHRvIHRyeSBhbmQgZ2V0IHRoaXMgZGlzY3Vzc2lv biBiYWNrIHRvIHRoZSBtYWluIGdyb3VwLiBNeSBhcG9sb2dpZXMgZm9yIHRoZSBsb25nIG5vdGUu IEkgd2FudGVkIHRvIGdldCBhbGwgdGhlIHByb3MgYW5kIGNvbnMgb24gdGhlIHRhYmxlIChoaW50 OiAmbmJzcDtwbGVhc2UgYWRkIGlmIEkgbWlzc2VkIGFueSkuLi48L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+QSBxdWVzdGlvbiByZW1haW5zIHNob3Vs ZCDigJxzdWLigJ0gYmUgdXNhYmxlIGF0IHRoZSB0b3AgbGV2ZWwuJm5ic3A7IFRoZSBkb3duc2lk ZSBvZiB0aGlzIGFwcHJvYWNoIGlzIHRoYXQgYSBTRVQgY291bGQgcG90ZW50aWFsbHkNCiBiZSBw cmVzZW50ZWQgYXMgYW4gYWNjZXNzIG9yIGlEIHRva2VuIGFuZCBtaWdodCBpbml0aWFsbHkgYmUg Y29uZnVzZWQgYmVjYXVzZSBleGlzdGluZyBjb2RlIGRvZXMgbm90IGtub3cgaXQgbmVlZHMgdG8g bG9vayBmb3IgYW4g4oCcZXZlbnRz4oCdIGF0dHJpYnV0ZS4mbmJzcDsgVGhlIFNFVCBhbmQgSUQg VG9rZW4gZm9yIGFsbCBpbnRlbnNpdmUgcHVycG9zZXMgYXJlIHRoZSBzYW1lIHNpbmNlIGEgU0VU IGp1c3QgaGFzIHNvbWV0aGluZyBleHRyYSAodGhlIGV2ZW50cw0KIGNsYWltKS48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VGhlcmUgaXMgYWxzbyB0 aGUgcXVlc3Rpb24gdGhhdCBpZiBPSURDIExvZ291dCB1c2VzIGl0IGluIHRoZSB0b3AgbGV2ZWws IG1heSBvdGhlciBldmVudHMgdXNlIGl0PyBSRkM3NTE5IGRlZmluZXMNCiDigJxzdWLigJ0gYXMg YSBTdHJpbmcgb3IgVVJJIHZhbHVlLiBGb3IgZXhhbXBsZSwgaW4gU0NJTSBldmVudHMsIHRoZSDi gJxzdWLigJ0gdmFsdWUgY291bGQgYmUgYSBTQ0lNIFJlc291cmNlIFVSSSB0aGF0IGluZGljYXRl cyB0aGUgcmVzb3VyY2Ugd2hvc2Ugc3RhdGUgaGFzIGNoYW5nZWQuJm5ic3A7IEluIE9BdXRoIGl0 IGNvdWxkIGJlIGRlZmluZWQgYXMgdGhlIHRva2VuIGlkZW50aWZpZXIgb2YgdGhlIHRva2VuIHRo YXQgaGFzIGJlZW4gcmV2b2tlZC4mbmJzcDsgQSBTRVQNCiBhYm91dCBibGFja2xpc3RpbmcgYW4g SVAgYWRkcmVzcyBtaWdodCBwdXQgdGhlIElQIGFkZHJlc3MgaW4gc3ViLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5TbyB0aGVyZSBhcmUgdGhyZWUg b3B0aW9ucyAoT3B0aW9uIEEgc2VlbXMgdG8gYmUgZmF2b3VyZWQgc28gZmFyKTogJm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkEuJm5i c3A7IFN1YiBhdCBUb3AgTGV2ZWw6PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsm bmJzcDvigJxzdWLigJ0gZ2VuZXJhbGx5DQogdXNlZCB0byByZWZlcmVuY2UgdGhlIFNlY3VyaXR5 IFN1YmplY3QgdGhlIFNFVCBpcyB0YWxraW5nIGFib3V0LiZuYnNwOyBJdCB1c2VzIGEgbW9yZSBn ZW5lcmFsIGVuZ2xpc2ggbGFuZ3VhZ2UgaW50ZW50IG9mIHN1YmplY3QgcmF0aGVyIHRoYW4gdGhl IHRyYWRpdGlvbmFsIHVzZSBhcyBzZWVuIGluIFNBTUwgb3IgT3BlbklEIENvbm5lY3QuJm5ic3A7 IFJlZ2FyZGxlc3MgaXQgaXMgc3RpbGwgY29tcGxpYW50IHdpdGggUkZDNzUxOSAoYSBTdHJpbmcg b3IgVVJJKS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp ZiI+VGhpcyB3b3VsZCB0ZW5kIHRvIGxlYWQgdG8gYSBzdHlsZSBvZiBTRVRzIHdoZXJlIHRoZSBl bnZlbG9wZSBjYXJyaWVzIHRoZSB2YWxpZGF0aW9uIGluZm9ybWF0aW9uLCB0aGUgdHlwZSBvZiBl dmVudCwNCiBhbmQgdGhlIHN1YmplY3Qgb2YgdGhlIGV2ZW50LiBBZGRpdGlvbmFsIGRhdGEgZ29l cyBpbiB0aGUgcGF5bG9hZC4gQW4gYWR2YW50YWdlIG9mIHRoaXMgc3R5bGUsIGlzIHRoYXQgZm9y IG1hbnkgZXZlbnRzLCB0aGUgb25seSB0aGluZyBuZWVkZWQgaXMgdGhlIGV2ZW50IHR5cGUgYW5k IHRoZSBzdWJqZWN0LiZuYnNwOyBObyBwYXlsb2FkcyB3b3VsZCBiZSBuZWVkZWQuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5Gb3IgZXZl bnRzIHRoYXQgZG9u4oCZdCB3YW50IHBheWxvYWQsIGl0IGlzIHByb2JhYmx5IG9rIGZvciBwcm9m aWxpbmcgZXZlbnQgc3RhbmRhcmRzIHRvIGRlZmluZSBtb3JlIGNsYWltcyBhdCB0aGUNCiB0b3Ag bGV2ZWwuIFRoZXkgTVVTVCBiZSByZWdpc3RlcmVkIGluIHRoZSBKV1QgcmVnaXN0cnkuIFByb2Zp bGluZyBldmVudHMgY2FuIGF2b2lkIHJlZ2lzdHJhdGlvbiBieSBqdXN0IHB1dHRpbmcgdGhlaXIg YXR0cmlidXRlcy9jbGFpbXMgaW4gdGhlIHBheWxvYWQgYXJlYSBhcyBkZXNjcmliZWQgaW4gdGhl IHNwZWMuJm5ic3A7IEhvd2V2ZXIsIHRoaXMgd291bGQgYmUgaW5jb25zaXN0ZW50IHdpdGggdGhv c2UgdGhhdCB1c2UgcGF5bG9hZHMgd2l0aCB1bnJlZ2lzdGVyZWQNCiBjbGFpbXMuJm5ic3A7IEkg cG9pbnQgb3V0IHRoYXQgd2Ugc3dpdGNoZWQgZnJvbSByZWdpc3RlcmVkIGV2ZW50IFVSTnMgdG8g VVJJcyB0byBhdm9pZCByZWdpc3RyYXRpb24uJm5ic3A7IEhlbmNlIHRoZSBtb3ZlIHRvIHBheWxv YWQgb2JqZWN0cyB0byBlbGltaW5hdGUgcmVnaXN0cmF0aW9uIGZvciBhdHRyaWJ1dGVzL2NsYWlt cy4gJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+VGhpcyBzdGlsbCBoYXMgdGhlIG5lZ2F0aXZlcyBvZiBiZWluZyBjb25mdXNh YmxlIGFzIGFuIElEIFRva2VuIGJ5IGV4aXN0aW5nIGNvZGUuIFRoZXJlIGhhcyBiZWVuIGEgZGlz Y3Vzc2lvbiB0aGF0DQog4oCcaXNz4oCdIGFuZC9vciDigJxhdWTigJ0gc2hvdWxkIGFjdHVhbGx5 IGJlIGRpZmZlcmVudCBhbmQgdGhlIHJlY2VpdmVyIHNob3VsZCBkZXRlY3QgdGhhdC4mbmJzcDsg SG93ZXZlciBpbiB0aGUgT0lEQyBMb2dvdXQgY2FzZSwgYnkgZGVzaWduLCB0aGUg4oCcaXNz4oCd IHZhbHVlIHdvdWxkIGJlIHRoZSBzYW1lLiZuYnNwOyBUaGUg4oCcYXVk4oCdIHdvdWxkIGFsc28g bGlrZWx5IGJlIHRoZSBzYW1lIHVubGVzcyB0aGUgc3BlYyBpbmRpY2F0ZXMgdGhhdCBhbiBhbGlh cyDigJxhdWTigJ0gYmUgdXNlZA0KIGV2ZW4gdGhvdWdoIHRoZSBhdWRpZW5jZSBtYXkgYmUgdGhl IHNhbWUgZW50aXR5IGluIGJvdGggY2FzZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkIuIEV4Y2x1c2l2ZS1Vc2Ugb2YgU3ViOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A74oCcc3Vi4oCdIGlzDQogaW50ZXJwcmV0ZWQgdG8g YnkgdHJhZGl0aW9uYWwgZGVmaW5pdGlvbiBhbmQgaXMgcmVzZXJ2ZWQgZm9yIE9BdXRoIHRva2Vu cyBhbmQgT0lEQyBDb25uZWN0IHVzYWdlIG9ubHkuJm5ic3A7IEluIG9yZGVyIHRvICZuYnNwO2F2 b2lkIGNvbmZ1c2luZywgYWxsIHByb2ZpbGluZyBldmVudCBzcGVjcyBzaG91bGQgTk9UIHVzZSDi gJxzdWLigJ0gaW4gdGhlIHRvcCBsZXZlbCBleGNlcHQgZm9yIE9JREMuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlRoaXMgaGFzIHRoZSBkaXNhZHZh bnRhZ2UgdGhhdCBPSURDIHJlcXVpcmVzIHNwZWNpYWwgaGFuZGxpbmcgaW4gdGVybXMgb2YgYSBn ZW5lcmFsIHVzZSBldmVudCBsaWJyYXJ5LCBidXQgb24gdGhlDQogb3RoZXIgaGFuZCBhIExvZ291 dCBFdmVudCBtaWdodCBiZSBoYW5kbGVkIGRpcmVjdGx5IGJ5IGV4aXN0aW5nIElEIFRva2VuIGNv ZGUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlRo aXMgc3RpbGwgaGFzIHRoZSBkaXNhZHZhbnRhZ2UgdGhhdCBhbiBTRVQgY291bGQgYmUgY29uZnVz ZWQgZm9yIGFuIElEIFRva2VuLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj5DLiBOby1Ub3AtTGV2ZWwgRGF0YTo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPiZuYnNwO0luIG9yZGVyIHRvDQogbW9yZSBhZ2dyZXNzaXZlbHkgYXZvaWQgY29u ZnVzaW9uIG9mIFNFVHMgYXMgSUQgVG9rZW5zLCBtYWtlIGl0IG1hbmRhdG9yeSB0aGF0IFNFVHMg bWF5IG5vdCBjb250YWluIGEg4oCcc3Vi4oCdIHZhbHVlIGF0IHRoZSB0b3AgbGV2ZWwuJm5ic3A7 IFRoZSBPSURDIExvZ291dCBFdmVudCwgZm9yIGV4YW1wbGUsIHdvdWxkIHRoZW4gaW5jbHVkZSBh IOKAnHN1YuKAnSB2YWx1ZSBpbiB0aGUgcGF5bG9hZCBhcmVhLiBUaGlzIHNob3VsZCBjYXVzZSBl eGlzdGluZyByZWx5aW5nDQogcGFydGllcyB0byBmYWlsIGNvcnJlY3RseS4gJm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlRoaXMgd291bGQg cHJvdmlkZSBhIG1heGltYWwgZGlmZmVyZW5jZSBmb3JtIGEgSURUb2tlbiBvciBhY2Nlc3MgdG9r ZW4uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlRo aXMgd291bGQgaGF2ZSB0aGUgYWR2YW50YWdlIHRoYXQgZW52ZWxvcGVzIGNvbnRhaW4gbm8gZGF0 YSwgYW5kIHRoYXQgZXZlcnkgU0VUIGhhcyBhIHBheWxvYWQgd2hlcmUgdGhlIGRhdGEgaXMNCiBm b3VuZC4gSXQgcmVxdWlyZXMgbW9yZSBwYXJzaW5nIGluIHNvbWUgY2FzZXMsIGJ1dCBpdCBpcyBh dCBsZWFzdCBjb25zaXN0ZW50LiBXaGlsZSB3ZSBkb27igJl0IGV4cGVjdCBnZW5lcmFsIHByb2Nl c3NvcnMgbGlrZSBpbiBTT0FQIGZvciBkaXN0cmlidXRpb24gKG11Y2ggb2YgaXQgaXMgcG9pbnQg dG8gcG9pbnQgYW5kIHZlcnkgY29udGV4dHVhbGx5IGRyaXZlbiksIEkgcGVyc29uYWxseSBleHBl Y3QgdG8gc2VlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7KiAmbmJzcDtEZXZl bG9wbWVudCBvZiBnZW5lcmFsIHB1cnBvc2UgbGlicmFyaWVzIGFuZCB0b29scyB0aGF0IGFyZSB1 c2VkIGVuaGFuY2UgcHJvdG9jb2xzIGFuZCBzeXN0ZW1zJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj4mbmJzcDsmbmJzcDsqICZuYnNwO0F1ZGl0IGFuZCB0aHJlYXQgYW5hbHlzaXMgc3lzdGVt cyB3aWxsIGJlIGxvb2tpbmcgYXQgc29tZSBldmVudHMgaGlzdG9yaWNhbGx5LiBUaGVzZSB3aWxs IHRlbmQgdG8gbWVyZ2UgbXVsdGlwbGUNCiBldmVudCBmZWVkcy48L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+TWlrZSBKb25lcyBhbHNvIHN1Z2dlc3Rl ZCB1c2luZyB0aGUmbmJzcDs8Yj7igJxjdHnigJ08L2I+Jm5ic3A7KGNvbnRlbnQgdHlwZSkgaGVh ZGVyIGF0dHJpYnV0ZSBmcm9tIEpXVC4mbmJzcDsgSSB0aGluayBtb3N0IGNvZGUgdG9kYXkNCiBo YXMgdGhpcyBzZXQgdG8gaWdub3JlIG9yIGZpeGVkIGFzIOKAnEpXVOKAnS4mbmJzcDsgSSB3b25k ZXIgd2hhdCBjdXJyZW50IGltcGxlbWVudHMgd291bGQgZmVlbCBpZiB3ZSBpbnRyb2R1Y2VkIGEg 4oCcY3R54oCdIHZhbHVlIG9mIOKAnFNFVOKAnT8mbmJzcDsgV291bGQgdGhhdCBoZWxwPzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPkkgdGhpbmsgaXQgaXMgdmVyeSBpbXBvcnRhbnQgdG8gYmUgYWJsZSB0byBj bGVhcmx5IGRpc3Rpbmd1aXNoIGRpZmZlcmVudCB0eXBlcyBvZiBKV1QgdG9rZW5zLiBGb3IgZXhh bXBsZSwgbm90IGJlaW5nDQogYWJsZSB0byBjcm9zcyBwb3N0IGEgU2VjdXJpdHkgRXZlbnQgVG9r ZW4gYXMgYW4gSWQgVG9rZW4uJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWYiPlJlYWRpbmcmbmJzcDtSRkMgNzUxOSBJIGRvbid0IHRoaW5rIGN0 eSBmaXRzIHRoZSBiaWxsLCBidXQgSSBjb3VsZCBiZSB3cm9uZy4gY3R5IGlzIGEgaGVhZGVyIHBh cmFtZXRlciB1c2VkIGJ5IHRoZSBjcnlwdG8NCiBhbGdvcml0aG0gYW5kIHRoZSBkZWZhdWx0IHZh bHVlIGlzIEpXVC4gV2UgbmVlZCB0byBkaXN0aW5ndWlzaCBzdWItdHlwZXMgb2YgSldULCBhbmQg aXQgc2hvdWxkIGJlIGEgY2xhaW0gaW5zaWRlIHRoZSBKV1QuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPldpdGggdGhlIGFib3ZlIGlzc3VlIGluIG1p bmQsIEkgdGhpbmsgb3B0aW9uIEEgaXMgdGhlIGNsZWFuZXN0IHNvbHV0aW9uLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5UaGFua3MgZm9yIHlvdXIgY29tbWVu dHMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+UGhpbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj5AaW5kZXBlbmRlbnRpZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGEg aHJlZj0iaHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNvbS8iIHRhcmdldD0iX2JsYW5rIj53d3cu aW5kZXBlbmRlbnRpZC5jb208L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWYiPjxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFy Z2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206 MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCklkLWV2ZW50IG1haWxpbmcgbGlzdDxicj4NCjxh IGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPklkLWV2ZW50 QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vaWQtZXZlbnQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50PC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCklkLWV2ZW50IG1haWxpbmcgbGlzdDxicj4NCjwv c3Bhbj48YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj5JZC1ldmVudEBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZiI+PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vaWQtZXZlbnQiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50PC9zcGFuPjwvYT48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQpJZC1ldmVudCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86SWQt ZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5JZC1ldmVudEBpZXRmLm9yZzwvYT48YnI+ DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50 IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9p ZC1ldmVudDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_SN1PR0301MB16452624ECBC114DB86B3DCFF5EA0SN1PR0301MB1645_-- From nobody Wed Aug 24 14:56:27 2016 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 75BC112D60D for ; Wed, 24 Aug 2016 14:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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] 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 lJVsV5klKTAH for ; Wed, 24 Aug 2016 14:56:23 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::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 6826212D78C for ; Wed, 24 Aug 2016 14:56:23 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id z190so29205441qkc.0 for ; Wed, 24 Aug 2016 14:56:23 -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=6ieJFUGKyoSGfOBdWV0TFfo1AfVlq4HZ8EInF8Dh5z8=; b=LcvjLmqdlDQO1MR8UfusiWn3kkR9ZYJ6HAjRLrPiViF0P5iiVWT21QXV/2sEfp4OAb tsnC1AszDuoV3gPV8u/6iOTmm1br2iFMJsH9lQxKtUp2y7U4SVLMdg4mBfDAbnH4LMxu QXIAh3QVZEHd60SwV8cZUkwqaMu+MlG63AQRfPh8w+NlriOW338NqHXAr4Yr2CC7Aad9 dY32NTOwKEoPiCRSPxAZMarSGo2/N+Sgx8V0E3CYsHCF9O9B4Hbz+zMEBcRPLzJunx/7 TMVs6rRSxmlfRHmowrdZbUoPShD5yZnNBsXyGxEbpgV7FVybZqMWyVovZvXkjU1KWG0M IzHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6ieJFUGKyoSGfOBdWV0TFfo1AfVlq4HZ8EInF8Dh5z8=; b=XmNyKbFP5DbrV/J9j4ABgPkmBjB3T3SVwQjQsLhFd7xF/luqfhQdCk3VFF0HiCerxY A80S96BfGX/InfQsyDKpg4vEUm3HyaTSYdatTjXh2Y6TNAI92cOTjf6xPinj7ueURYj6 aq+BEUG59V8nY9DJcd8ZMip6N6R8C9jWBjb9hxmXvwmE9ePgBhITnevYWlsTr3iosXzq dnSKac6k6eMZTAUi5SPYqpMK4R72sAEO8YyByIXvu7IgpxvdRsnQ4Mncw4jovDpkzEyt fJEfhy2cWnAjVt/xGs4qV4L4ODX1btZiaN75rLKRXkCaIc5IfmNriH1FuB6Fu1DIyrTG n+QA== X-Gm-Message-State: AE9vXwMXkbwEd6IIBW2gWO9so6Uv7PzMU17cwQPQ9jMw23CINm0KwM5kUBctpS9DBfJj44pVsvEtwykQZiNT6BBh X-Received: by 10.55.53.138 with SMTP id c132mr6142706qka.79.1472075782391; Wed, 24 Aug 2016 14:56:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.105.3 with HTTP; Wed, 24 Aug 2016 14:56:20 -0700 (PDT) X-Originating-IP: [181.201.108.96] In-Reply-To: <99F73572-FF0E-4F88-9E61-C69601CC4C23@oracle.com> References: <3D5305B0-0365-4B07-9D35-81F0B7B04FF2@oracle.com> <382F27DF-A35A-43F3-8C2E-CE3D8ABC4ADB@ve7jtb.com> <99F73572-FF0E-4F88-9E61-C69601CC4C23@oracle.com> From: John Bradley Date: Wed, 24 Aug 2016 18:56:20 -0300 Message-ID: To: Phil Hunt Content-Type: multipart/alternative; boundary=001a11476ad417c902053ad85a99 Archived-At: Cc: Mike Jones , "id-event@ietf.org" , Marius Scurtescu Subject: Re: [Id-event] Discussion on use of "sub" and confusion as ID Token X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 24 Aug 2016 21:56:26 -0000 --001a11476ad417c902053ad85a99 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The problem is a bad guy getting a SET JWT and replaying it against any other channel that takes JWT such as access tokens. All protocols that receive JWT need to ensure that they are valid. one way to do that is to have different logical audiences for different protocols. The fact that JWT ignore claims that are not understood gives us great flexibility but also opens the possibility of cross protocol attacks. This will be a general problem for anything using JWT bearer tokens as it can be for protocols using SAML bearer. Even with proof of possession a malicious client could perhaps generate a cross channel privilege escalation. I think this is potential general problem. On Wed, Aug 24, 2016 at 6:41 PM, Phil Hunt wrote: > Ok. Can we agree that a strong security consideration would be the > appropriate remedy? > > The text (not finished yet) might cover the following: > > Audiences that receive both JWTs (e.g. as access tokens) and SETs for > security events should take care to ensure that a SET passed in a channel > where it could be confused as an access token MUST take care to evaluate: > * The presence/absence of =E2=80=9Cevents=E2=80=9D claim > * That the =E2=80=9Caud=E2=80=9D value is correct. And where possible th= e SET =E2=80=9Caud=E2=80=9D and > the access token =E2=80=9Caud=E2=80=9D are in fact different even if it i= s the same service > entity. > * That access tokens and SETs SHOULD NOT be received over the same channe= l > and at minimum SHOULD be separate endpoints. e.g. access tokens via the > authorization header of a resource service, versus SETs received over HTT= P > POST at a specific web URI associated with the subscription. > * Check for the presence of a =E2=80=9Cnonce=E2=80=9D in the case of an O= penID Connect > id_token. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > On Aug 24, 2016, at 2:31 PM, Mike Jones > wrote: > > A spec could create a top-level JWT type claim, but I=E2=80=99d assert th= at it=E2=80=99s > out of scope for the Events spec. It would probably need to be its own > spec and say basically =E2=80=9Cuse it if you=E2=80=99re in use cases in = which it=E2=80=99s useful > to distinguish between things=E2=80=9D. > > *From:* Id-event [mailto:id-event-bounces@ietf.org > ] *On Behalf Of *John Bradley > *Sent:* Wednesday, August 24, 2016 2:24 PM > *To:* Phil Hunt > *Cc:* id-event@ietf.org; Marius Scurtescu > *Subject:* Re: [Id-event] Discussion on use of "sub" and confusion as ID > Token > > I was saying that cty was wrong for this. > > If you look at the definition of typ in JWS https://tools.ietf.org/ > html/rfc7515#page-13 you can see that it is really intended to be the > media type of the complete JWS/JWE and is omitted or set to JWT if it is = a > compact JWT. Setting it to SET seems wrong as it is still a JWT. I > was recommending considering a JWT top level claim in the JWT registry. > > John B. > > > > On Aug 24, 2016, at 5:59 PM, Phil Hunt wrote: > > John, > > Did you mean adding a =E2=80=9Cjwt_type=E2=80=9D attribute (that becomes = a registered JWT > claim) OR adding a new type value for the JWT header =E2=80=9Ctyp=E2=80= =9D? Note for > everyone=E2=80=99s convenience from 7519: > > > The "typ" (type) Header Parameter defined by [JWS ] and [JWE ] is used > > by JWT applications to declare the media type [IANA.MediaTypes ] of > > this complete JWT. This is intended for use by the JWT application > > when values that are not JWTs could also be present in an application > > data structure that can contain a JWT object; the application can use > > this value to disambiguate among the different kinds of objects that > > might be present. It will typically not be used by applications when > > it is already known that the object is a JWT. This parameter is > > ignored by JWT implementations; any processing of this parameter is > > performed by the JWT application. If present, it is RECOMMENDED that > > its value be "JWT" to indicate that this object is a JWT. While > > media type names are not case sensitive, it is RECOMMENDED that "JWT" > > always be spelled using uppercase characters for compatibility with > > legacy implementations. Use of this Header Parameter is OPTIONAL. > > > > What is concerning is the line that says: > > It will typically not be used by applications when > > it is already known that the object is a JWT. *This parameter is* > > * ignored by JWT implementations*; any processing of this parameter is > > performed by the JWT application. If present, it is RECOMMENDED that > > its value be "JWT" to indicate that this object is a JWT. > > > If it is typically ignored, then having it =E2=80=9Ctyp=E2=80=9D be =E2= =80=9CSET=E2=80=9D may not help > much initially. But at least it is more definitive. > > If the group is comfortable, I am ok with making =E2=80=9Ctyp=E2=80=9D be= =E2=80=9CSET=E2=80=9D. It is > one more distinguishing item. > > Regardless, I will also put a cautionary note in the security > considerations that if issuing SETs to audiences that also receive JWTs, > that appropriate care be taken not to confuse if somehow a hacker is able > to present the SET as if it were a JWT to gain access (e.g. in an > authorization header). Normally this should not be possible as I would > assume SETs are passed via something like an HTTP POST back-channel. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > > On Aug 24, 2016, at 1:31 PM, John Bradley wrote: > > The idea for cty was to allow a JWS to encapsulate things like a binary > GIF as an example. I think using it for Distinguishing subtypes of JWT > would be a stretch. > > I am most comfortable with A. I think that adding a JWT type claim at > the top level may also be useful going forward to avoid misinterpretation= . > > John B. > > On Aug 24, 2016, at 4:51 PM, Marius Scurtescu > wrote: > > On Wed, Aug 24, 2016 at 11:07 AM, Phil Hunt wrote: > > > The authors have been having a discussion with regards to using the =E2= =80=9Csub=E2=80=9D > claim in the top level. I think it is important to try and get this > discussion back to the main group. My apologies for the long note. I want= ed > to get all the pros and cons on the table (hint: please add if I missed > any)... > > A question remains should =E2=80=9Csub=E2=80=9D be usable at the top leve= l. The downside > of this approach is that a SET could potentially be presented as an acces= s > or iD token and might initially be confused because existing code does no= t > know it needs to look for an =E2=80=9Cevents=E2=80=9D attribute. The SET= and ID Token for > all intensive purposes are the same since a SET just has something extra > (the events claim). > > There is also the question that if OIDC Logout uses it in the top level, > may other events use it? RFC7519 defines =E2=80=9Csub=E2=80=9D as a Strin= g or URI value. > For example, in SCIM events, the =E2=80=9Csub=E2=80=9D value could be a S= CIM Resource URI > that indicates the resource whose state has changed. In OAuth it could b= e > defined as the token identifier of the token that has been revoked. A SE= T > about blacklisting an IP address might put the IP address in sub. > > So there are three options (Option A seems to be favoured so far): > > *A. Sub at Top Level:* =E2=80=9Csub=E2=80=9D generally used to referenc= e the Security > Subject the SET is talking about. It uses a more general english languag= e > intent of subject rather than the traditional use as seen in SAML or Open= ID > Connect. Regardless it is still compliant with RFC7519 (a String or URI)= . > > This would tend to lead to a style of SETs where the envelope carries the > validation information, the type of event, and the subject of the event. > Additional data goes in the payload. An advantage of this style, is that > for many events, the only thing needed is the event type and the subject. > No payloads would be needed. > > For events that don=E2=80=99t want payload, it is probably ok for profili= ng event > standards to define more claims at the top level. They MUST be registered > in the JWT registry. Profiling events can avoid registration by just > putting their attributes/claims in the payload area as described in the > spec. However, this would be inconsistent with those that use payloads > with unregistered claims. I point out that we switched from registered > event URNs to URIs to avoid registration. Hence the move to payload > objects to eliminate registration for attributes/claims. > > This still has the negatives of being confusable as an ID Token by > existing code. There has been a discussion that =E2=80=9Ciss=E2=80=9D and= /or =E2=80=9Caud=E2=80=9D should > actually be different and the receiver should detect that. However in th= e > OIDC Logout case, by design, the =E2=80=9Ciss=E2=80=9D value would be the= same. The =E2=80=9Caud=E2=80=9D > would also likely be the same unless the spec indicates that an alias =E2= =80=9Caud=E2=80=9D > be used even though the audience may be the same entity in both cases. > > *B. Exclusive-Use of Sub:* =E2=80=9Csub=E2=80=9D is interpreted to by tra= ditional > definition and is reserved for OAuth tokens and OIDC Connect usage only. > In order to avoid confusing, all profiling event specs should NOT use > =E2=80=9Csub=E2=80=9D in the top level except for OIDC. > > This has the disadvantage that OIDC requires special handling in terms of > a general use event library, but on the other hand a Logout Event might b= e > handled directly by existing ID Token code. > > This still has the disadvantage that an SET could be confused for an ID > Token. > > *C. No-Top-Level Data:* In order to more aggressively avoid confusion of > SETs as ID Tokens, make it mandatory that SETs may not contain a =E2=80= =9Csub=E2=80=9D > value at the top level. The OIDC Logout Event, for example, would then > include a =E2=80=9Csub=E2=80=9D value in the payload area. This should ca= use existing > relying parties to fail correctly. > > This would provide a maximal difference form a IDToken or access token. > > This would have the advantage that envelopes contain no data, and that > every SET has a payload where the data is found. It requires more parsing > in some cases, but it is at least consistent. While we don=E2=80=99t expe= ct general > processors like in SOAP for distribution (much of it is point to point an= d > very contextually driven), I personally expect to see: > * Development of general purpose libraries and tools that are used > enhance protocols and systems > * Audit and threat analysis systems will be looking at some events > historically. These will tend to merge multiple event feeds. > > Mike Jones also suggested using the *=E2=80=9Ccty=E2=80=9D* (content type= ) header > attribute from JWT. I think most code today has this set to ignore or > fixed as =E2=80=9CJWT=E2=80=9D. I wonder what current implements would f= eel if we > introduced a =E2=80=9Ccty=E2=80=9D value of =E2=80=9CSET=E2=80=9D? Would= that help? > > > I think it is very important to be able to clearly distinguish different > types of JWT tokens. For example, not being able to cross post a Security > Event Token as an Id Token. > > Reading RFC 7519 I don't think cty fits the bill, but I could be wrong. > cty is a header parameter used by the crypto algorithm and the default > value is JWT. We need to distinguish sub-types of JWT, and it should be a > claim inside the JWT. > > With the above issue in mind, I think option A is the cleanest solution. > > > > > Thanks for your comments. > > > Phil > > @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 > > > _______________________________________________ > 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 > > > --001a11476ad417c902053ad85a99 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The problem is a bad guy getting a SET JWT and replaying i= t against any other channel that takes JWT such as access tokens.=C2=A0
All protocols that receive JWT need to ensure that they are= valid. =C2=A0one way to do that is to have different logical audiences for= different protocols.

The fact that JWT ignore cla= ims that are not understood gives us great flexibility but also opens the p= ossibility of cross protocol attacks.

This will be= a general problem for anything using JWT bearer tokens as it can be for pr= otocols using SAML bearer.=C2=A0 Even with proof of possession a malicious = client could perhaps generate a cross channel privilege escalation.

I think this is potential general problem.

On Wed, Aug 24, 2016= at 6:41 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
Ok.=C2=A0= Can we agree that a strong security consideration would be the appropriate= remedy?

The text (not finished yet) might cover the fol= lowing:

Audiences that receive both JWTs (e.g. as = access tokens) and SETs for security events should take care to ensure that= a SET passed in a channel where it could be confused as an access token MU= ST take care to evaluate:
* The presence/absence of =E2=80=9Ceven= ts=E2=80=9D claim
* That the =E2=80=9Caud=E2=80=9D value is corre= ct.=C2=A0 And where possible the SET =E2=80=9Caud=E2=80=9D and the access t= oken =E2=80=9Caud=E2=80=9D are in fact different even if it is the same ser= vice entity.
* That access tokens and SETs SHOULD NOT be received= over the same channel and at minimum SHOULD be separate endpoints. e.g. ac= cess tokens via the authorization header of a resource service, versus SETs= received over HTTP POST at a specific web URI associated with the subscrip= tion.
* Check for the presence of a =E2=80=9Cnonce=E2=80=9D in th= e case of an OpenID Connect id_token.


On Aug 24, 2016, at 2:31 PM, Mike J= ones <M= ichael.Jones@microsoft.com> wrote:

A spec could cr= eate a top-level JWT type claim, but I=E2=80=99d assert that it=E2=80=99s o= ut of scope for the Events spec.=C2=A0 It would probably need to be its own= spec and say basically =E2=80=9Cuse it if you=E2=80=99re in use cases in w= hich it=E2=80=99s useful to distinguish between things=E2=80=9D.<= /u>
=
From:=C2=A0Id-event [mailto:id-event-bounces@ietf.org]=C2=A0On Behalf= Of=C2=A0John Bradley
Sent:=C2=A0We= dnesday, August 24, 2016 2:24 PM
To:=C2=A0Phil Hunt = <phil.hunt@ora= cle.com>
Cc:=C2=A0id-event@ietf.org; Marius Scurtescu <mscurtescu@google.c= om>
Subject:=C2=A0Re: [Id-event] Discussion o= n use of "sub" and confusion as ID Token
=C2=A0
I was saying that cty was wrong for this. =C2=A0=
=C2=A0
If you look at the definition of typ in JWS=C2=A0https://tools.ietf.org/html/r= fc7515#page-13=C2=A0 you can see that it is really intended to be the m= edia type of the complete JWS/JWE and is omitted or set to JWT if it is a c= ompact JWT. =C2=A0 =C2=A0 Setting it to SET seems wrong as it is still a JW= T. =C2=A0 I was recommending considering a JWT top level claim in the JWT r= egistry.
=C2=A0=
John B.
<= div>
=C2=A0
=C2=A0
On Aug 24, 2016, at 5:5= 9 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
The "typ" (type) Header Paramet=
er defined by [JWS] and [JWE] is used
=C2=A0=C2=A0 by JWT application=
s to declare the media type [IANA.MediaTypes] of
=C2=
=A0=C2=A0 this complete JWT.=C2=A0 This is intended for use by the JWT appl=
ication
=C2=A0=C2=A0 when values that are n=
ot JWTs could also be present in an application
=C2=A0=C2=A0 data structure that can contain a JWT object; the applica=
tion can use
=C2=A0=C2=A0 this value to dis=
ambiguate among the different kinds of objects that
=C2=A0=C2=A0 might be present.=C2=A0 It will typically not be used= by applications when
=C2=A0=C2=A0 it is al=
ready known that the object is a JWT.=C2=A0 This parameter is=

=C2=A0=C2=A0 ignored by JWT implementations; any process=
ing of this parameter is
=C2=A0=C2=A0 perfo=
rmed by the JWT application.=C2=A0 If present, it is RECOMMENDED that
=C2=A0=C2=A0 its value be "JWT" to ind=
icate that this object is a JWT.=C2=A0 While
=C2=A0=C2=A0 media type names are not case sensitive, it is RECOMMENDED =
that "JWT"
=C2=A0=C2=A0 always be=
 spelled using uppercase characters for compatibility with
=C2=A0=C2=A0 legacy implementations.=C2=A0 Use of this Head=
er Parameter is OPTIONAL.
=C2=A0
=C2= =A0
What is concerning is the= line that says:=C2=A0
It will t=
ypically not be used by applications when
=
=C2=A0=C2=A0 it is already known that the object is a JWT.=C2=A0 This=
 parameter is
=C2=A0=C2=A0 ig=
nored by JWT implementations; any processing of this parameter is
=C2=A0=C2=A0 performed by the JWT applicatio=
n.=C2=A0 If present, it is RECOMMENDED that
=C2=A0=C2=A0 its value be "JWT" to indicate that this object i=
s a JWT.
=C2=A0
If it is typically ignored, then h= aving it =E2=80=9Ctyp=E2=80=9D be =E2=80=9CSET=E2=80=9D may not help much i= nitially. But at least it is more definitive.
=C2=A0
If the group is comfortable, I am ok with making =E2=80=9Ctyp=E2= =80=9D be =E2=80=9CSET=E2=80=9D.=C2=A0 It is one more distinguishing item. = =C2=A0
=C2=A0
Regardless, I will also put a = cautionary note in the security considerations that if issuing SETs to audi= ences that also receive JWTs, that appropriate care be taken not to confuse= if somehow a hacker is able to present the SET as if it were a JWT to gain= access (e.g. in an authorization header).=C2=A0 Normally this should not b= e possible as I would assume SETs are passed via something like an HTTP POS= T back-channel.
=C2=A0
Phil
= =C2=A0
@independentid<= /u>
=C2=A0<= u>
=C2=A0

=C2=A0

=C2=A0
On Aug 24, 2016, = at 1:31 PM, John Bradley <ve7jtb@ve7jtb.com= > wrote:
=C2= =A0
The idea for cty was to al= low a JWS to encapsulate things like a binary GIF as an example. =C2=A0 I t= hink using it for Distinguishing subtypes of JWT would be a stretch.=
=C2=A0
I am most comfortable with A. =C2=A0 I think that= adding a JWT type claim at the top level may also be useful going forward = to avoid misinterpretation.
=C2=A0
John B.
On Aug 24, 2016, at 4:51 PM, Marius Scurtesc= u <mscurtescu@google.com> wrote:=
=C2=A0
=
This would tend to lead to a style of SETs where the envelope c= arries the validation information, the type of event, and the subject of th= e event. Additional data goes in the payload. An advantage of this style, i= s that for many events, the only thing needed is the event type and the sub= ject.=C2=A0 No payloads would be needed.
=C2=A0
=
Reading=C2=A0RFC 7519 I don't think cty fits the bill, = but I could be wrong. cty is a header parameter used by the crypto algorith= m and the default value is JWT. We need to distinguish sub-types of JWT, an= d it should be a claim inside the JWT.
=C2=A0
<= div style=3D"margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times = New Roman',serif">_______________________________________________
Id-event = mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/= id-event
=C2=A0
_= ______________________________________________
Id-event mailing lis= t
Id-event@ietf.org
https://www.ietf.org/mailman/listin= fo/id-event
=C2=A0
=C2=A0
_______________________________________________
Id-event mailing list<= br style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-wei= ght:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-tran= sform:none;white-space:normal;word-spacing:0px">Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event

--001a11476ad417c902053ad85a99-- From nobody Wed Aug 24 15:05:17 2016 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 E420612D756 for ; Wed, 24 Aug 2016 15:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.548, 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 qTBMjsTUlcCV for ; Wed, 24 Aug 2016 15:05:13 -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 6C39B12D675 for ; Wed, 24 Aug 2016 15:05:13 -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 u7OM5Akn021112 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 24 Aug 2016 22:05:11 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u7OM59UO015554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 24 Aug 2016 22:05:10 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u7OM53fl027456; Wed, 24 Aug 2016 22:05:09 GMT Received: from [10.0.1.5] (/24.86.208.48) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 24 Aug 2016 15:04:57 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_AB600C82-B010-4596-97AD-681594149431" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Phil Hunt In-Reply-To: Date: Wed, 24 Aug 2016 15:04:55 -0700 Message-Id: <29300667-D812-47F5-8923-A67D606F3228@oracle.com> References: <3D5305B0-0365-4B07-9D35-81F0B7B04FF2@oracle.com> <382F27DF-A35A-43F3-8C2E-CE3D8ABC4ADB@ve7jtb.com> <99F73572-FF0E-4F88-9E61-C69601CC4C23@oracle.com> To: John Bradley X-Mailer: Apple Mail (2.3124) X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: Mike Jones , "id-event@ietf.org" , Marius Scurtescu Subject: Re: [Id-event] Discussion on use of "sub" and confusion as ID Token X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 24 Aug 2016 22:05:16 -0000 --Apple-Mail=_AB600C82-B010-4596-97AD-681594149431 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 +1 This has been my concern. I think Mike is right that the correction of adding a type does not = belong in SET - but mainly because, you would not expect an implementer = of JWTs for the purpose of access tokens would think to look for a = security consideration in an event token spec. Phil @independentid www.independentid.com = phil.hunt@oracle.com = > On Aug 24, 2016, at 2:56 PM, John Bradley wrote: >=20 > The problem is a bad guy getting a SET JWT and replaying it against = any other channel that takes JWT such as access tokens.=20 >=20 > All protocols that receive JWT need to ensure that they are valid. = one way to do that is to have different logical audiences for different = protocols. >=20 > The fact that JWT ignore claims that are not understood gives us great = flexibility but also opens the possibility of cross protocol attacks. >=20 > This will be a general problem for anything using JWT bearer tokens as = it can be for protocols using SAML bearer. Even with proof of = possession a malicious client could perhaps generate a cross channel = privilege escalation. >=20 > I think this is potential general problem. >=20 > On Wed, Aug 24, 2016 at 6:41 PM, Phil Hunt > wrote: > Ok. Can we agree that a strong security consideration would be the = appropriate remedy? >=20 > The text (not finished yet) might cover the following: >=20 > Audiences that receive both JWTs (e.g. as access tokens) and SETs for = security events should take care to ensure that a SET passed in a = channel where it could be confused as an access token MUST take care to = evaluate: > * The presence/absence of =E2=80=9Cevents=E2=80=9D claim > * That the =E2=80=9Caud=E2=80=9D value is correct. And where possible = the SET =E2=80=9Caud=E2=80=9D and the access token =E2=80=9Caud=E2=80=9D = are in fact different even if it is the same service entity. > * That access tokens and SETs SHOULD NOT be received over the same = channel and at minimum SHOULD be separate endpoints. e.g. access tokens = via the authorization header of a resource service, versus SETs received = over HTTP POST at a specific web URI associated with the subscription. > * Check for the presence of a =E2=80=9Cnonce=E2=80=9D in the case of = an OpenID Connect id_token. >=20 > Phil >=20 > @independentid > www.independentid.com = phil.hunt@oracle.com = >=20 >=20 >=20 >=20 >=20 >> On Aug 24, 2016, at 2:31 PM, Mike Jones > wrote: >>=20 >> A spec could create a top-level JWT type claim, but I=E2=80=99d = assert that it=E2=80=99s out of scope for the Events spec. It would = probably need to be its own spec and say basically =E2=80=9Cuse it if = you=E2=80=99re in use cases in which it=E2=80=99s useful to distinguish = between things=E2=80=9D. >> =C2=A0 <> >> From: Id-event [mailto:id-event-bounces@ietf.org = ] On Behalf Of John Bradley >> Sent: Wednesday, August 24, 2016 2:24 PM >> To: Phil Hunt > >> Cc: id-event@ietf.org ; Marius Scurtescu = > >> Subject: Re: [Id-event] Discussion on use of "sub" and confusion as = ID Token >> =20 >> I was saying that cty was wrong for this. =20 >> =20 >> If you look at the definition of typ in JWS = https://tools.ietf.org/html/rfc7515#page-13 = you can see that it is = really intended to be the media type of the complete JWS/JWE and is = omitted or set to JWT if it is a compact JWT. Setting it to SET = seems wrong as it is still a JWT. I was recommending considering a JWT = top level claim in the JWT registry. >> =20 >> John B. >> =20 >> =20 >> On Aug 24, 2016, at 5:59 PM, Phil Hunt > wrote: >> =20 >> John, >> =20 >> Did you mean adding a =E2=80=9Cjwt_type=E2=80=9D attribute (that = becomes a registered JWT claim) OR adding a new type value for the JWT = header =E2=80=9Ctyp=E2=80=9D? Note for everyone=E2=80=99s convenience = from 7519: >> =20 >> The "typ" (type) Header Parameter defined by [JWS = ] and [JWE = ] is used >> by JWT applications to declare the media type [IANA.MediaTypes = ] of >> this complete JWT. This is intended for use by the JWT = application >> when values that are not JWTs could also be present in an = application >> data structure that can contain a JWT object; the application can = use >> this value to disambiguate among the different kinds of objects = that >> might be present. It will typically not be used by applications = when >> it is already known that the object is a JWT. This parameter is >> ignored by JWT implementations; any processing of this parameter = is >> performed by the JWT application. If present, it is RECOMMENDED = that >> its value be "JWT" to indicate that this object is a JWT. While >> media type names are not case sensitive, it is RECOMMENDED that = "JWT" >> always be spelled using uppercase characters for compatibility = with >> legacy implementations. Use of this Header Parameter is OPTIONAL. >> =20 >> =20 >> What is concerning is the line that says:=20 >> It will typically not be used by applications when >> it is already known that the object is a JWT. This parameter is >> ignored by JWT implementations; any processing of this parameter = is >> performed by the JWT application. If present, it is RECOMMENDED = that >> its value be "JWT" to indicate that this object is a JWT. >> =20 >> If it is typically ignored, then having it =E2=80=9Ctyp=E2=80=9D be = =E2=80=9CSET=E2=80=9D may not help much initially. But at least it is = more definitive. >> =20 >> If the group is comfortable, I am ok with making =E2=80=9Ctyp=E2=80=9D = be =E2=80=9CSET=E2=80=9D. It is one more distinguishing item. =20 >> =20 >> Regardless, I will also put a cautionary note in the security = considerations that if issuing SETs to audiences that also receive JWTs, = that appropriate care be taken not to confuse if somehow a hacker is = able to present the SET as if it were a JWT to gain access (e.g. in an = authorization header). Normally this should not be possible as I would = assume SETs are passed via something like an HTTP POST back-channel. >> =20 >> Phil >> =20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> =20 >> =20 >> =20 >>=20 >> =20 >> On Aug 24, 2016, at 1:31 PM, John Bradley > wrote: >> =20 >> The idea for cty was to allow a JWS to encapsulate things like a = binary GIF as an example. I think using it for Distinguishing subtypes = of JWT would be a stretch. >> =20 >> I am most comfortable with A. I think that adding a JWT type claim = at the top level may also be useful going forward to avoid = misinterpretation. >> =20 >> John B. >> On Aug 24, 2016, at 4:51 PM, Marius Scurtescu > wrote: >> =20 >> On Wed, Aug 24, 2016 at 11:07 AM, Phil Hunt > wrote: >> =20 >> The authors have been having a discussion with regards to using the = =E2=80=9Csub=E2=80=9D claim in the top level. I think it is important to = try and get this discussion back to the main group. My apologies for the = long note. I wanted to get all the pros and cons on the table (hint: = please add if I missed any)... >> =20 >> A question remains should =E2=80=9Csub=E2=80=9D be usable at the top = level. The downside of this approach is that a SET could potentially be = presented as an access or iD token and might initially be confused = because existing code does not know it needs to look for an =E2=80=9Cevent= s=E2=80=9D attribute. The SET and ID Token for all intensive purposes = are the same since a SET just has something extra (the events claim). >> =20 >> There is also the question that if OIDC Logout uses it in the top = level, may other events use it? RFC7519 defines =E2=80=9Csub=E2=80=9D as = a String or URI value. For example, in SCIM events, the =E2=80=9Csub=E2=80= =9D value could be a SCIM Resource URI that indicates the resource whose = state has changed. In OAuth it could be defined as the token identifier = of the token that has been revoked. A SET about blacklisting an IP = address might put the IP address in sub. >> =20 >> So there are three options (Option A seems to be favoured so far): =20= >> =20 >> A. Sub at Top Level: =E2=80=9Csub=E2=80=9D generally used to = reference the Security Subject the SET is talking about. It uses a more = general english language intent of subject rather than the traditional = use as seen in SAML or OpenID Connect. Regardless it is still compliant = with RFC7519 (a String or URI). >> =20 >> This would tend to lead to a style of SETs where the envelope carries = the validation information, the type of event, and the subject of the = event. Additional data goes in the payload. An advantage of this style, = is that for many events, the only thing needed is the event type and the = subject. No payloads would be needed. >> =20 >> For events that don=E2=80=99t want payload, it is probably ok for = profiling event standards to define more claims at the top level. They = MUST be registered in the JWT registry. Profiling events can avoid = registration by just putting their attributes/claims in the payload area = as described in the spec. However, this would be inconsistent with = those that use payloads with unregistered claims. I point out that we = switched from registered event URNs to URIs to avoid registration. = Hence the move to payload objects to eliminate registration for = attributes/claims. =20 >> =20 >> This still has the negatives of being confusable as an ID Token by = existing code. There has been a discussion that =E2=80=9Ciss=E2=80=9D = and/or =E2=80=9Caud=E2=80=9D should actually be different and the = receiver should detect that. However in the OIDC Logout case, by = design, the =E2=80=9Ciss=E2=80=9D value would be the same. The = =E2=80=9Caud=E2=80=9D would also likely be the same unless the spec = indicates that an alias =E2=80=9Caud=E2=80=9D be used even though the = audience may be the same entity in both cases. >> =20 >> B. Exclusive-Use of Sub: =E2=80=9Csub=E2=80=9D is interpreted to by = traditional definition and is reserved for OAuth tokens and OIDC Connect = usage only. In order to avoid confusing, all profiling event specs = should NOT use =E2=80=9Csub=E2=80=9D in the top level except for OIDC. >> =20 >> This has the disadvantage that OIDC requires special handling in = terms of a general use event library, but on the other hand a Logout = Event might be handled directly by existing ID Token code. >> =20 >> This still has the disadvantage that an SET could be confused for an = ID Token. >> =20 >> C. No-Top-Level Data: In order to more aggressively avoid confusion = of SETs as ID Tokens, make it mandatory that SETs may not contain a = =E2=80=9Csub=E2=80=9D value at the top level. The OIDC Logout Event, = for example, would then include a =E2=80=9Csub=E2=80=9D value in the = payload area. This should cause existing relying parties to fail = correctly. =20 >> =20 >> This would provide a maximal difference form a IDToken or access = token. >> =20 >> This would have the advantage that envelopes contain no data, and = that every SET has a payload where the data is found. It requires more = parsing in some cases, but it is at least consistent. While we don=E2=80=99= t expect general processors like in SOAP for distribution (much of it is = point to point and very contextually driven), I personally expect to = see: >> * Development of general purpose libraries and tools that are used = enhance protocols and systems=20 >> * Audit and threat analysis systems will be looking at some events = historically. These will tend to merge multiple event feeds. >> =20 >> Mike Jones also suggested using the =E2=80=9Ccty=E2=80=9D (content = type) header attribute from JWT. I think most code today has this set = to ignore or fixed as =E2=80=9CJWT=E2=80=9D. I wonder what current = implements would feel if we introduced a =E2=80=9Ccty=E2=80=9D value of = =E2=80=9CSET=E2=80=9D? Would that help? >> =20 >> I think it is very important to be able to clearly distinguish = different types of JWT tokens. For example, not being able to cross post = a Security Event Token as an Id Token.=20 >> =20 >> Reading RFC 7519 I don't think cty fits the bill, but I could be = wrong. cty is a header parameter used by the crypto algorithm and the = default value is JWT. We need to distinguish sub-types of JWT, and it = should be a claim inside the JWT. >> =20 >> With the above issue in mind, I think option A is the cleanest = solution. >> =20 >> =20 >> =20 >> Thanks for your comments. >> =20 >> =20 >> Phil >> =20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> =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 >> _______________________________________________ >> 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 --Apple-Mail=_AB600C82-B010-4596-97AD-681594149431 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 +1  This has been my concern.

I think Mike is right that the = correction of adding a type does not belong in SET - but mainly because, = you would not expect an implementer of JWTs for the purpose of access = tokens would think to look for a security consideration in an event = token spec.




On Aug 24, 2016, at 2:56 PM, John Bradley <ve7jtb@ve7jtb.com> = wrote:

The problem is a bad guy getting a SET JWT and = replaying it against any other channel that takes JWT such as access = tokens. 

All = protocols that receive JWT need to ensure that they are valid.  one = way to do that is to have different logical audiences for different = protocols.

The = fact that JWT ignore claims that are not understood gives us great = flexibility but also opens the possibility of cross protocol = attacks.

This = will be a general problem for anything using JWT bearer tokens as it can = be for protocols using SAML bearer.  Even with proof of possession = a malicious client could perhaps generate a cross channel privilege = escalation.

I = think this is potential general problem.

On Wed, = Aug 24, 2016 at 6:41 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
Ok.  Can we agree that a = strong security consideration would be the appropriate remedy?

The text (not finished = yet) might cover the following:

Audiences that receive both JWTs (e.g. = as access tokens) and SETs for security events should take care to = ensure that a SET passed in a channel where it could be confused as an = access token MUST take care to evaluate:
* The = presence/absence of =E2=80=9Cevents=E2=80=9D claim
* = That the =E2=80=9Caud=E2=80=9D value is correct.  And where = possible the SET =E2=80=9Caud=E2=80=9D and the access token =E2=80=9Caud=E2= =80=9D are in fact different even if it is the same service = entity.
* That access tokens and SETs SHOULD NOT be = received over the same channel and at minimum SHOULD be separate = endpoints. e.g. access tokens via the authorization header of a resource = service, versus SETs received over HTTP POST at a specific web URI = associated with the subscription.
* Check for the = presence of a =E2=80=9Cnonce=E2=80=9D in the case of an OpenID Connect = id_token.

Phil

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




=

On Aug 24, 2016, at 2:31 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

A spec could create a top-level JWT type claim, but I=E2=80=99= d assert that it=E2=80=99s out of scope for the Events spec.  It = would probably need to be its own spec and say basically =E2=80=9Cuse it = if you=E2=80=99re in use cases in which it=E2=80=99s useful to = distinguish between things=E2=80=9D.
 
From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of John Bradley
Sent: Wednesday, August 24, = 2016 2:24 PM
To: Phil Hunt <phil.hunt@oracle.com>
Cc: id-event@ietf.org; Marius Scurtescu <mscurtescu@google.com>
Subject: Re: [Id-event] = Discussion on use of "sub" and confusion as ID Token
 
I was saying that cty was wrong for this.  
 
If= you look at the definition of typ in JWS https://tools.ietf.org/html/rfc7515#page-13  you can see that it is really = intended to be the media type of the complete JWS/JWE and is omitted or = set to JWT if it is a compact JWT.     Setting it to SET seems = wrong as it is still a JWT.   I was recommending considering a JWT = top level claim in the JWT registry.
 
John B.
 
 
On Aug 24, 2016, at 5:59 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
 
John,
 
Did you mean adding a =E2=80=9Cjwt_type=E2=80=9D = attribute (that becomes a registered JWT claim) OR adding a new type = value for the JWT header =E2=80=9Ctyp=E2=80=9D?  Note for = everyone=E2=80=99s convenience from 7519:
 
The "typ" (type) Header Parameter defined by [JWS] and [JWE] is used
   by JWT applications to declare the media =
type [IANA.MediaTypes] of
  =
 this complete JWT.  This is intended for use by the JWT =
application
   when values that are not JWTs could also =
be present in an application
   data structure that can contain a JWT = object; the application can use
  =
 this value to disambiguate among the different kinds of objects that
  =
 might be present.  It will typically not be used by applications =
when
   it is already known that the object is a =
JWT.  This parameter is
   ignored by JWT implementations; any = processing of this parameter is
  =
 performed by the JWT application.  If present, it is RECOMMENDED =
that
   its value be "JWT" to indicate that this object =
is a JWT.  While
   media type names are not case sensitive, =
it is RECOMMENDED that "JWT"
   always be spelled using uppercase = characters for compatibility with
  =
 legacy implementations.  Use of this Header Parameter is =
OPTIONAL.
 
 
What is concerning is the line that says: 
It will typically not be used by applications when
  =
 it is already known that the object is a JWT.  This parameter is
   ignored by JWT =
implementations; any processing of this parameter is
  =
 performed by the JWT application.  If present, it is RECOMMENDED =
that
   its value be "JWT" to indicate that this object =
is a JWT.
 
If= it is typically ignored, then having it =E2=80=9Ctyp=E2=80=9D be = =E2=80=9CSET=E2=80=9D may not help much initially. But at least it is = more definitive.
 
If the group is comfortable, I am ok with = making =E2=80=9Ctyp=E2=80=9D be =E2=80=9CSET=E2=80=9D.  It is one = more distinguishing item.  
 
Regardless, I will also put a cautionary note = in the security considerations that if issuing SETs to audiences that = also receive JWTs, that appropriate care be taken not to confuse if = somehow a hacker is able to present the SET as if it were a JWT to gain = access (e.g. in an authorization header).  Normally this should not = be possible as I would assume SETs are passed via something like an HTTP = POST back-channel.
 
Phil
 
@independentid
www.independentid.com
 
 

 

 
On= Aug 24, 2016, at 1:31 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
 
The idea for cty was to allow a JWS to encapsulate things = like a binary GIF as an example.   I think using it for = Distinguishing subtypes of JWT would be a stretch.
 
I am most comfortable with A.   I think = that adding a JWT type claim at the top level may also be useful going = forward to avoid misinterpretation.
 
John B.
On Aug 24, 2016, at 4:51 PM, Marius Scurtescu = <mscurtescu@google.com> wrote:
 
On Wed, Aug 24, 2016 at 11:07 AM, Phil Hunt <phil.hunt@oracle.com> wrote:
 
The authors have been having a discussion with regards to = using the =E2=80=9Csub=E2=80=9D claim in the top level. I think it is = important to try and get this discussion back to the main group. My = apologies for the long note. I wanted to get all the pros and cons on = the table (hint:  please add if I missed any)...
 
A question remains should =E2=80=9Csub=E2=80=9D be usable at = the top level.  The downside of this approach is that a SET could = potentially be presented as an access or iD token and might initially be = confused because existing code does not know it needs to look for an = =E2=80=9Cevents=E2=80=9D attribute.  The SET and ID Token for all = intensive purposes are the same since a SET just has something extra = (the events claim).
 
There is also the question that if OIDC Logout uses it in the = top level, may other events use it? RFC7519 defines =E2=80=9Csub=E2=80=9D = as a String or URI value. For example, in SCIM events, the =E2=80=9Csub=E2= =80=9D value could be a SCIM Resource URI that indicates the resource = whose state has changed.  In OAuth it could be defined as the token = identifier of the token that has been revoked.  A SET about = blacklisting an IP address might put the IP address in sub.
 
So there are three options (Option A seems to be favoured so = far):  
 
A.  Sub at Top Level:  =E2=80=9Csub=E2=80=9D generally used to reference the = Security Subject the SET is talking about.  It uses a more general = english language intent of subject rather than the traditional use as = seen in SAML or OpenID Connect.  Regardless it is still compliant = with RFC7519 (a String or URI).
 
This would tend to lead to a style of SETs where the envelope = carries the validation information, the type of event, and the subject = of the event. Additional data goes in the payload. An advantage of this = style, is that for many events, the only thing needed is the event type = and the subject.  No payloads would be needed.
 
For = events that don=E2=80=99t want payload, it is probably ok for profiling = event standards to define more claims at the top level. They MUST be = registered in the JWT registry. Profiling events can avoid registration = by just putting their attributes/claims in the payload area as described = in the spec.  However, this would be inconsistent with those that = use payloads with unregistered claims.  I point out that we = switched from registered event URNs to URIs to avoid registration.  = Hence the move to payload objects to eliminate registration for = attributes/claims.  
 
This still has the negatives of being confusable as an ID = Token by existing code. There has been a discussion that =E2=80=9Ciss=E2=80= =9D and/or =E2=80=9Caud=E2=80=9D should actually be different and the = receiver should detect that.  However in the OIDC Logout case, by = design, the =E2=80=9Ciss=E2=80=9D value would be the same.  The = =E2=80=9Caud=E2=80=9D would also likely be the same unless the spec = indicates that an alias =E2=80=9Caud=E2=80=9D be used even though the = audience may be the same entity in both cases.
 
B. = Exclusive-Use of Sub: =E2=80=9Csub=E2=80=9D is interpreted to by traditional = definition and is reserved for OAuth tokens and OIDC Connect usage = only.  In order to  avoid confusing, all profiling event specs = should NOT use =E2=80=9Csub=E2=80=9D in the top level except for OIDC.
 
This has the disadvantage that OIDC requires special handling = in terms of a general use event library, but on the other hand a Logout = Event might be handled directly by existing ID Token code.
 
This still has the disadvantage that an SET could be confused = for an ID Token.
 
C. = No-Top-Level Data: In = order to more aggressively avoid confusion of SETs as ID Tokens, make it = mandatory that SETs may not contain a =E2=80=9Csub=E2=80=9D value at the = top level.  The OIDC Logout Event, for example, would then include = a =E2=80=9Csub=E2=80=9D value in the payload area. This should cause = existing relying parties to fail correctly.  
 
This would provide a maximal difference form a IDToken or = access token.
 
This would have the advantage that envelopes contain no data, = and that every SET has a payload where the data is found. It requires = more parsing in some cases, but it is at least consistent. While we = don=E2=80=99t expect general processors like in SOAP for distribution = (much of it is point to point and very contextually driven), I = personally expect to see:
  *  Development of = general purpose libraries and tools that are used enhance protocols and = systems 
  *  Audit and threat = analysis systems will be looking at some events historically. These will = tend to merge multiple event feeds.
 
Mike Jones also suggested using the =E2=80=9Ccty=E2=80=9D (content type) header attribute from JWT.  = I think most code today has this set to ignore or fixed as = =E2=80=9CJWT=E2=80=9D.  I wonder what current implements would feel = if we introduced a =E2=80=9Ccty=E2=80=9D value of =E2=80=9CSET=E2=80=9D?&n= bsp; Would that help?
 
I think it is very important to be able to clearly = distinguish different types of JWT tokens. For example, not being able = to cross post a Security Event Token as an Id Token. 
 
Reading RFC 7519 I don't think cty fits the bill, but I = could be wrong. cty is a header parameter used by the crypto algorithm = and the default value is JWT. We need to distinguish sub-types of JWT, = and it should be a claim inside the JWT.
 
With the above issue in mind, I think option A is the = cleanest solution.
 
 
 
Thanks for your comments.
 
 
Phil
 
@independentid
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
 
_______________________________________________
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=_AB600C82-B010-4596-97AD-681594149431-- From nobody Wed Aug 24 16:25:46 2016 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 8300E12D1E0 for ; Wed, 24 Aug 2016 16:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 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.548, 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 GAsg5J7uLF2G for ; Wed, 24 Aug 2016 16:25:41 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::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 87CC712D124 for ; Wed, 24 Aug 2016 16:25:40 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id i5so46508975wmg.0 for ; Wed, 24 Aug 2016 16:25:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=96XBzw9+pQu8w1tBGHFQnNpk/bxf50pIHIxeptRm2EE=; b=Z0Id13yFjun128kCztb3ukEYn5dkVCu8lNnsvczH2LvdsNCR1h93dncYj7Rze09w5x Kyh99mbZ6YK40ZPPbssBaULA9g76Px58FfY1Paw0SOTQHlchupz4AH75iieC6IlkU5+z 9Hz/We2/PYEJsm1tZzLgTheHirM+eavI+XSms8RhpboqIbxM6KSvPjtSVHkW81Eorhd3 RPM0kvF7cL2xohlMxwHW1o+69GO4G29Lke4RvTt/ORPTYsQutCpHrEccos2QcH/BgnFa UDhzIAPhTS5X1sRgPFSbVnG7ZN8fzR78oLt0win3ivYq5CtgY/cN7J2hn4GhCtAa13Ox KfpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=96XBzw9+pQu8w1tBGHFQnNpk/bxf50pIHIxeptRm2EE=; b=I04rSro02vgLAAMAf/NNM2sKSUakJpmgFCpT3yDvY9ZVYUff6wxWoaZRGocRMK/fYe 415XarjQi4EgI3ikHWOxnNIA0OqQkSUPSIsa+wtUmOuSUsEgHwvzAfJLiJbxSyzVv0SL Ovhyvob8lUgMD8wRa+jHzB4mrIiWotjNnaL5ICbqIRrbetlOMKE4nON1/os7nK6qs6h6 4P0EY/sFEdycNRgRKxo0Kv2WkgI9I2fmMQg7XL05PeE4G2D9lX38dSl6PSyXnjtOvCfv lOwaTSYSJVfVC+U83cBTF4I8ZuM7M9cKGhT+o+Q3C3o+zIWOX+iWWqetUKik4RI2N3Wc /VVg== X-Gm-Message-State: AEkoout1r+sSTxg41iqS3DEM/V/kOlbVBTTPGI3kRv0B8hFevMnA2J/394rSyT3rSGZRULJM62+/aMn0dqrcRqke X-Received: by 10.194.28.5 with SMTP id x5mr4524300wjg.11.1472081138723; Wed, 24 Aug 2016 16:25:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.167.78 with HTTP; Wed, 24 Aug 2016 16:25:17 -0700 (PDT) In-Reply-To: References: <3D5305B0-0365-4B07-9D35-81F0B7B04FF2@oracle.com> <382F27DF-A35A-43F3-8C2E-CE3D8ABC4ADB@ve7jtb.com> <99F73572-FF0E-4F88-9E61-C69601CC4C23@oracle.com> From: Marius Scurtescu Date: Wed, 24 Aug 2016 16:25:17 -0700 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=047d7b670b355adfab053ad999cf Archived-At: Cc: Mike Jones , "id-event@ietf.org" , Phil Hunt Subject: Re: [Id-event] Discussion on use of "sub" and confusion as ID Token X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 24 Aug 2016 23:25:45 -0000 --047d7b670b355adfab053ad999cf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Aug 24, 2016 at 2:56 PM, John Bradley wrote: > The problem is a bad guy getting a SET JWT and replaying it against any > other channel that takes JWT such as access tokens. > > All protocols that receive JWT need to ensure that they are valid. one > way to do that is to have different logical audiences for different > protocols. > > The fact that JWT ignore claims that are not understood gives us great > flexibility but also opens the possibility of cross protocol attacks. > > This will be a general problem for anything using JWT bearer tokens as it > can be for protocols using SAML bearer. Even with proof of possession a > malicious client could perhaps generate a cross channel privilege > escalation. > > I think this is potential general problem. > +1 > > On Wed, Aug 24, 2016 at 6:41 PM, Phil Hunt wrote: > >> Ok. Can we agree that a strong security consideration would be the >> appropriate remedy? >> >> The text (not finished yet) might cover the following: >> >> Audiences that receive both JWTs (e.g. as access tokens) and SETs for >> security events should take care to ensure that a SET passed in a channe= l >> where it could be confused as an access token MUST take care to evaluate= : >> * The presence/absence of =E2=80=9Cevents=E2=80=9D claim >> * That the =E2=80=9Caud=E2=80=9D value is correct. And where possible t= he SET =E2=80=9Caud=E2=80=9D and >> the access token =E2=80=9Caud=E2=80=9D are in fact different even if it = is the same service >> entity. >> * That access tokens and SETs SHOULD NOT be received over the same >> channel and at minimum SHOULD be separate endpoints. e.g. access tokens = via >> the authorization header of a resource service, versus SETs received ove= r >> HTTP POST at a specific web URI associated with the subscription. >> * Check for the presence of a =E2=80=9Cnonce=E2=80=9D in the case of an = OpenID Connect >> id_token. >> >> Phil >> >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> >> >> >> >> >> On Aug 24, 2016, at 2:31 PM, Mike Jones >> wrote: >> >> A spec could create a top-level JWT type claim, but I=E2=80=99d assert t= hat it=E2=80=99s >> out of scope for the Events spec. It would probably need to be its own >> spec and say basically =E2=80=9Cuse it if you=E2=80=99re in use cases in= which it=E2=80=99s useful >> to distinguish between things=E2=80=9D. >> >> *From:* Id-event [mailto:id-event-bounces@ietf.org >> ] *On Behalf Of *John Bradley >> *Sent:* Wednesday, August 24, 2016 2:24 PM >> *To:* Phil Hunt >> *Cc:* id-event@ietf.org; Marius Scurtescu >> *Subject:* Re: [Id-event] Discussion on use of "sub" and confusion as ID >> Token >> >> I was saying that cty was wrong for this. >> >> If you look at the definition of typ in JWS https://tools.ietf.org/htm >> l/rfc7515#page-13 you can see that it is really intended to be the >> media type of the complete JWS/JWE and is omitted or set to JWT if it is= a >> compact JWT. Setting it to SET seems wrong as it is still a JWT. I >> was recommending considering a JWT top level claim in the JWT registry. >> >> John B. >> >> >> >> On Aug 24, 2016, at 5:59 PM, Phil Hunt wrote: >> >> John, >> >> Did you mean adding a =E2=80=9Cjwt_type=E2=80=9D attribute (that becomes= a registered JWT >> claim) OR adding a new type value for the JWT header =E2=80=9Ctyp=E2=80= =9D? Note for >> everyone=E2=80=99s convenience from 7519: >> >> >> The "typ" (type) Header Parameter defined by [JWS ] and [JWE ] is used >> >> by JWT applications to declare the media type [IANA.MediaTypes ] of >> >> this complete JWT. This is intended for use by the JWT application >> >> when values that are not JWTs could also be present in an application >> >> data structure that can contain a JWT object; the application can use >> >> this value to disambiguate among the different kinds of objects that >> >> might be present. It will typically not be used by applications when >> >> it is already known that the object is a JWT. This parameter is >> >> ignored by JWT implementations; any processing of this parameter is >> >> performed by the JWT application. If present, it is RECOMMENDED that >> >> its value be "JWT" to indicate that this object is a JWT. While >> >> media type names are not case sensitive, it is RECOMMENDED that "JWT" >> >> always be spelled using uppercase characters for compatibility with >> >> legacy implementations. Use of this Header Parameter is OPTIONAL. >> >> >> >> What is concerning is the line that says: >> >> It will typically not be used by applications when >> >> it is already known that the object is a JWT. *This parameter is* >> >> * ignored by JWT implementations*; any processing of this parameter is >> >> performed by the JWT application. If present, it is RECOMMENDED that >> >> its value be "JWT" to indicate that this object is a JWT. >> >> >> If it is typically ignored, then having it =E2=80=9Ctyp=E2=80=9D be =E2= =80=9CSET=E2=80=9D may not help >> much initially. But at least it is more definitive. >> >> If the group is comfortable, I am ok with making =E2=80=9Ctyp=E2=80=9D b= e =E2=80=9CSET=E2=80=9D. It is >> one more distinguishing item. >> >> Regardless, I will also put a cautionary note in the security >> considerations that if issuing SETs to audiences that also receive JWTs, >> that appropriate care be taken not to confuse if somehow a hacker is abl= e >> to present the SET as if it were a JWT to gain access (e.g. in an >> authorization header). Normally this should not be possible as I would >> assume SETs are passed via something like an HTTP POST back-channel. >> >> Phil >> >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> >> >> >> >> >> >> On Aug 24, 2016, at 1:31 PM, John Bradley wrote: >> >> The idea for cty was to allow a JWS to encapsulate things like a binary >> GIF as an example. I think using it for Distinguishing subtypes of JWT >> would be a stretch. >> >> I am most comfortable with A. I think that adding a JWT type claim at >> the top level may also be useful going forward to avoid misinterpretatio= n. >> >> John B. >> >> On Aug 24, 2016, at 4:51 PM, Marius Scurtescu >> wrote: >> >> On Wed, Aug 24, 2016 at 11:07 AM, Phil Hunt wrote= : >> >> >> The authors have been having a discussion with regards to using the =E2= =80=9Csub=E2=80=9D >> claim in the top level. I think it is important to try and get this >> discussion back to the main group. My apologies for the long note. I wan= ted >> to get all the pros and cons on the table (hint: please add if I missed >> any)... >> >> A question remains should =E2=80=9Csub=E2=80=9D be usable at the top lev= el. The downside >> of this approach is that a SET could potentially be presented as an acce= ss >> or iD token and might initially be confused because existing code does n= ot >> know it needs to look for an =E2=80=9Cevents=E2=80=9D attribute. The SE= T and ID Token for >> all intensive purposes are the same since a SET just has something extra >> (the events claim). >> >> There is also the question that if OIDC Logout uses it in the top level, >> may other events use it? RFC7519 defines =E2=80=9Csub=E2=80=9D as a Stri= ng or URI value. >> For example, in SCIM events, the =E2=80=9Csub=E2=80=9D value could be a = SCIM Resource URI >> that indicates the resource whose state has changed. In OAuth it could = be >> defined as the token identifier of the token that has been revoked. A S= ET >> about blacklisting an IP address might put the IP address in sub. >> >> So there are three options (Option A seems to be favoured so far): >> >> *A. Sub at Top Level:* =E2=80=9Csub=E2=80=9D generally used to referen= ce the Security >> Subject the SET is talking about. It uses a more general english langua= ge >> intent of subject rather than the traditional use as seen in SAML or Ope= nID >> Connect. Regardless it is still compliant with RFC7519 (a String or URI= ). >> >> This would tend to lead to a style of SETs where the envelope carries th= e >> validation information, the type of event, and the subject of the event. >> Additional data goes in the payload. An advantage of this style, is that >> for many events, the only thing needed is the event type and the subject= . >> No payloads would be needed. >> >> For events that don=E2=80=99t want payload, it is probably ok for profil= ing event >> standards to define more claims at the top level. They MUST be registere= d >> in the JWT registry. Profiling events can avoid registration by just >> putting their attributes/claims in the payload area as described in the >> spec. However, this would be inconsistent with those that use payloads >> with unregistered claims. I point out that we switched from registered >> event URNs to URIs to avoid registration. Hence the move to payload >> objects to eliminate registration for attributes/claims. >> >> This still has the negatives of being confusable as an ID Token by >> existing code. There has been a discussion that =E2=80=9Ciss=E2=80=9D an= d/or =E2=80=9Caud=E2=80=9D should >> actually be different and the receiver should detect that. However in t= he >> OIDC Logout case, by design, the =E2=80=9Ciss=E2=80=9D value would be th= e same. The =E2=80=9Caud=E2=80=9D >> would also likely be the same unless the spec indicates that an alias = =E2=80=9Caud=E2=80=9D >> be used even though the audience may be the same entity in both cases. >> >> *B. Exclusive-Use of Sub:* =E2=80=9Csub=E2=80=9D is interpreted to by tr= aditional >> definition and is reserved for OAuth tokens and OIDC Connect usage only. >> In order to avoid confusing, all profiling event specs should NOT use >> =E2=80=9Csub=E2=80=9D in the top level except for OIDC. >> >> This has the disadvantage that OIDC requires special handling in terms o= f >> a general use event library, but on the other hand a Logout Event might = be >> handled directly by existing ID Token code. >> >> This still has the disadvantage that an SET could be confused for an ID >> Token. >> >> *C. No-Top-Level Data:* In order to more aggressively avoid confusion of >> SETs as ID Tokens, make it mandatory that SETs may not contain a =E2=80= =9Csub=E2=80=9D >> value at the top level. The OIDC Logout Event, for example, would then >> include a =E2=80=9Csub=E2=80=9D value in the payload area. This should c= ause existing >> relying parties to fail correctly. >> >> This would provide a maximal difference form a IDToken or access token. >> >> This would have the advantage that envelopes contain no data, and that >> every SET has a payload where the data is found. It requires more parsin= g >> in some cases, but it is at least consistent. While we don=E2=80=99t exp= ect general >> processors like in SOAP for distribution (much of it is point to point a= nd >> very contextually driven), I personally expect to see: >> * Development of general purpose libraries and tools that are used >> enhance protocols and systems >> * Audit and threat analysis systems will be looking at some events >> historically. These will tend to merge multiple event feeds. >> >> Mike Jones also suggested using the *=E2=80=9Ccty=E2=80=9D* (content typ= e) header >> attribute from JWT. I think most code today has this set to ignore or >> fixed as =E2=80=9CJWT=E2=80=9D. I wonder what current implements would = feel if we >> introduced a =E2=80=9Ccty=E2=80=9D value of =E2=80=9CSET=E2=80=9D? Woul= d that help? >> >> >> I think it is very important to be able to clearly distinguish different >> types of JWT tokens. For example, not being able to cross post a Securit= y >> Event Token as an Id Token. >> >> Reading RFC 7519 I don't think cty fits the bill, but I could be wrong. >> cty is a header parameter used by the crypto algorithm and the default >> value is JWT. We need to distinguish sub-types of JWT, and it should be = a >> claim inside the JWT. >> >> With the above issue in mind, I think option A is the cleanest solution. >> >> >> >> >> Thanks for your comments. >> >> >> Phil >> >> @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 >> >> >> _______________________________________________ >> 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 >> >> >> > --047d7b670b355adfab053ad999cf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Aug 24, 2016 at 2:56 PM, John Bradley <ve7jtb@ve7jtb.= com> wrote:
The problem is a bad guy getting a SET JWT and replaying it against any o= ther channel that takes JWT such as access tokens.=C2=A0

All protocols that receive JWT need to ensure that they are valid. =C2=A0o= ne way to do that is to have different logical audiences for different prot= ocols.

The fact that JWT ignore claims that are no= t understood gives us great flexibility but also opens the possibility of c= ross protocol attacks.

This will be a general prob= lem for anything using JWT bearer tokens as it can be for protocols using S= AML bearer.=C2=A0 Even with proof of possession a malicious client could pe= rhaps generate a cross channel privilege escalation.

I think this is potential general problem.
=
+1
=C2=A0

On Wed, Aug 24, 2016 at 6:41 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
Ok.=C2=A0 Can we agree that = a strong security consideration would be the appropriate remedy?

The text (not finished yet) might cover the following:
<= br>
Audiences that receive both JWTs (e.g. as access tokens) and = SETs for security events should take care to ensure that a SET passed in a = channel where it could be confused as an access token MUST take care to eva= luate:
* The presence/absence of =E2=80=9Cevents=E2=80=9D claim
* That the =E2=80=9Caud=E2=80=9D value is correct.=C2=A0 And where= possible the SET =E2=80=9Caud=E2=80=9D and the access token =E2=80=9Caud= =E2=80=9D are in fact different even if it is the same service entity.
* That access tokens and SETs SHOULD NOT be received over the same ch= annel and at minimum SHOULD be separate endpoints. e.g. access tokens via t= he authorization header of a resource service, versus SETs received over HT= TP POST at a specific web URI associated with the subscription.
*= Check for the presence of a =E2=80=9Cnonce=E2=80=9D in the case of an Open= ID Connect id_token.


On Aug 24, 2016, at 2:31 PM, Mike J= ones <Michael.Jones@microsoft.com> wrote:

A spec could create a top-level JWT type claim, but I=E2=80=99d assert th= at it=E2=80=99s out of scope for the Events spec.=C2=A0 It would probably n= eed to be its own spec and say basically =E2=80=9Cuse it if you=E2=80=99re = in use cases in which it=E2=80=99s useful to distinguish between things=E2= =80=9D.
From:=C2=A0Id-event [mailto:id-event-bounces@ietf.org]=C2=A0On Behalf = Of=C2=A0John Bradley
Sent:=C2=A0Wed= nesday, August 24, 2016 2:24 PM
To:=C2=A0Phil Hunt &= lt;phil.hunt@oracle.com>
Cc:=C2=A0id-event@ietf.= org; Marius Scurtescu <mscurtescu@google.com>
Subject:= =C2=A0Re: [Id-event] Discussion on use of "sub" = and confusion as ID Token
=C2=A0
I was saying = that cty was wrong for this. =C2=A0
=C2=A0
If you = look at the definition of typ in JWS=C2=A0https://tools.ietf.org/html/rfc7515#pa= ge-13=C2=A0 you can see that it is really intended to be the media type= of the complete JWS/JWE and is omitted or set to JWT if it is a compact JW= T. =C2=A0 =C2=A0 Setting it to SET seems wrong as it is still a JWT. =C2=A0= I was recommending considering a JWT top level claim in the JWT registry.<= u>
=C2=A0
John B.
=C2=A0
=C2=A0
On Aug 24, 2016, at 5:59 PM, Phil= Hunt <phil.hunt@oracle= .com> wrote:
= =C2=A0
John,
=C2=A0
Did you mean adding a =E2=80=9Cjwt_type=E2=80=9D attribute (= that becomes a registered JWT claim) OR adding a new type value for the JWT= header =E2=80=9Ctyp=E2=80=9D?=C2=A0 Note for everyone=E2=80=99s convenienc= e from 7519:
= =C2=A0
The "typ" (type) Heade=
r Parameter defined by [JWS] and [=
JWE] is used
<= pre style=3D"margin:0in 0in 0.0001pt;font-size:10pt;font-family:'Courie= r New'">=C2=A0=C2=A0 by JWT applications to declare the media type [I= ANA.MediaTypes] of
=C2=A0=C2=A0 this co=
mplete JWT.=C2=A0 This is intended for use by the JWT application=

=C2=A0=C2=A0 when values that are not JWTs could als=
o be present in an application
=C2=A0=C2=A0=
 data structure that can contain a JWT object; the application can use
=C2=A0=C2=A0 this value to disambiguate among t=
he different kinds of objects that
=C2=A0=
=C2=A0 might be present.=C2=A0 It will typically not be used by application=
s when
=C2=A0=C2=A0 it is already known tha=
t the object is a JWT.=C2=A0 This parameter is
=C2=A0=C2=A0 ignored by JWT implementations; any processing of this par=
ameter is
=C2=A0=C2=A0 performed by the JWT=
 application.=C2=A0 If present, it is RECOMMENDED that
<= pre style=3D"margin:0in 0in 0.0001pt;font-size:10pt;font-family:'Courie= r New'">=C2=A0=C2=A0 its value be "JWT" to indicate that this= object is a JWT.=C2=A0 While
=C2=A0=C2=A0 =
media type names are not case sensitive, it is RECOMMENDED that "JWT&q=
uot;
=C2=A0=C2=A0 always be spelled using u=
ppercase characters for compatibility with
=
=C2=A0=C2=A0 legacy implementations.=C2=A0 Use of this Header Parameter is =
OPTIONAL.
=C2=A0
=C2=A0
<= /div>
What is concerning is the line that says:= =C2=A0
It will typically not be =
used by applications when
=C2=A0=C2=A0 it i=
s already known that the object is a JWT.=C2=A0 This parameter is<=
/u>
=C2=A0=C2=A0 ignored by JWT impl=
ementations; any processing of this parameter is
=C2=A0=C2=A0 performed by the JWT application.=C2=A0 If prese=
nt, it is RECOMMENDED that
=C2=A0=C2=A0 its=
 value be "JWT" to indicate that this object is a JWT.<=
/u>
=C2=A0
<=
div style=3D"margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times =
New Roman',serif">If it is typically ignored, then having it =E2=80=9Ct=
yp=E2=80=9D be =E2=80=9CSET=E2=80=9D may not help much initially. But at le=
ast it is more definitive.
=C2=A0
If the gro= up is comfortable, I am ok with making =E2=80=9Ctyp=E2=80=9D be =E2=80=9CSE= T=E2=80=9D.=C2=A0 It is one more distinguishing item. =C2=A0<= /div>
=C2=A0
Regardless, I will also put a cautionary note in th= e security considerations that if issuing SETs to audiences that also recei= ve JWTs, that appropriate care be taken not to confuse if somehow a hacker = is able to present the SET as if it were a JWT to gain access (e.g. in an a= uthorization header).=C2=A0 Normally this should not be possible as I would= assume SETs are passed via something like an HTTP POST back-channel.
=C2=A0
<= /div>
Phil=
=C2=A0
@independentid
<= div style=3D"margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times = New Roman',serif">phil= .hunt@oracle.com
<= u>=C2=A0
=C2=A0

=C2=A0<= /p>

=C2=A0
On A= ug 24, 2016, at 1:31 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
=C2=A0
The idea for cty was to allow a JWS to encapsulate things like a binary = GIF as an example. =C2=A0 I think using it for Distinguishing subtypes of J= WT would be a stretch.
=C2=A0
I am most comfortabl= e with A. =C2=A0 I think that adding a JWT type claim at the top level may = also be useful going forward to avoid misinterpretation.
=C2=A0
John B.
On Aug 24, 2016= , at 4:51 PM, Marius Scurtescu <mscurtescu@google.com> wrote:
<= div style=3D"margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times = New Roman',serif">=C2=A0
On Wed, Aug 24, 2016 at 11:07 AM, Phil Hunt=C2=A0<phil.hunt@oracle.com>=C2=A0wrote:
=C2=A0
The authors have been having a discussion with regards to using the =E2= =80=9Csub=E2=80=9D claim in the top level. I think it is important to try a= nd get this discussion back to the main group. My apologies for the long no= te. I wanted to get all the pros and cons on the table (hint: =C2=A0please = add if I missed any)...
= =C2=A0
A question remains shou= ld =E2=80=9Csub=E2=80=9D be usable at the top level.=C2=A0 The downside of = this approach is that a SET could potentially be presented as an access or = iD token and might initially be confused because existing code does not kno= w it needs to look for an =E2=80=9Cevents=E2=80=9D attribute.=C2=A0 The SET= and ID Token for all intensive purposes are the same since a SET just has = something extra (the events claim).
=C2=A0
There is al= so the question that if OIDC Logout uses it in the top level, may other eve= nts use it? RFC7519 defines =E2=80=9Csub=E2=80=9D as a String or URI value.= For example, in SCIM events, the =E2=80=9Csub=E2=80=9D value could be a SC= IM Resource URI that indicates the resource whose state has changed.=C2=A0 = In OAuth it could be defined as the token identifier of the token that has = been revoked.=C2=A0 A SET about blacklisting an IP address might put the IP= address in sub.
=C2= =A0
So there are three options (Op= tion A seems to be favoured so far): =C2=A0
=C2=A0
= A.=C2=A0 Sub at Top Level:=C2=A0=C2=A0=E2=80=9Csub=E2=80=9D generall= y used to reference the Security Subject the SET is talking about.=C2=A0 It= uses a more general english language intent of subject rather than the tra= ditional use as seen in SAML or OpenID Connect.=C2=A0 Regardless it is stil= l compliant with RFC7519 (a String or URI).
=C2=A0
Thi= s would tend to lead to a style of SETs where the envelope carries the vali= dation information, the type of event, and the subject of the event. Additi= onal data goes in the payload. An advantage of this style, is that for many= events, the only thing needed is the event type and the subject.=C2=A0 No = payloads would be needed.
=C2=A0
For events tha= t don=E2=80=99t want payload, it is probably ok for profiling event standar= ds to define more claims at the top level. They MUST be registered in the J= WT registry. Profiling events can avoid registration by just putting their = attributes/claims in the payload area as described in the spec.=C2=A0 Howev= er, this would be inconsistent with those that use payloads with unregister= ed claims.=C2=A0 I point out that we switched from registered event URNs to= URIs to avoid registration.=C2=A0 Hence the move to payload objects to eli= minate registration for attributes/claims. =C2=A0
=C2=A0
This still has the negatives of being confusable as an ID Token by= existing code. There has been a discussion that =E2=80=9Ciss=E2=80=9D and/= or =E2=80=9Caud=E2=80=9D should actually be different and the receiver shou= ld detect that.=C2=A0 However in the OIDC Logout case, by design, the =E2= =80=9Ciss=E2=80=9D value would be the same.=C2=A0 The =E2=80=9Caud=E2=80=9D= would also likely be the same unless the spec indicates that an alias =E2= =80=9Caud=E2=80=9D be used even though the audience may be the same entity = in both cases.
= =C2= =A0
B. Exclusive-Use of Sub:=C2=A0=E2=80=9Csub=E2=80=9D is interpreted to by traditional definition= and is reserved for OAuth tokens and OIDC Connect usage only.=C2=A0 In ord= er to =C2=A0avoid confusing, all profiling event specs should NOT use =E2= =80=9Csub=E2=80=9D in the top level except for OIDC.
=C2=A0
This has the disadvantage that OIDC requires special handling in term= s of a general use event library, but on the other hand a Logout Event migh= t be handled directly by existing ID Token code.
=
=C2=A0
This still has the disadvantage that an SET could be confused for an ID T= oken.
=C2=A0<= /span>
C. No-Top-Level Data:= =C2=A0In o= rder to more aggressively avoid confusion of SETs as ID Tokens, make it man= datory that SETs may not contain a =E2=80=9Csub=E2=80=9D value at the top l= evel.=C2=A0 The OIDC Logout Event, for example, would then include a =E2=80= =9Csub=E2=80=9D value in the payload area. This should cause existing relyi= ng parties to fail correctly. =C2=A0
<= div style=3D"margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times = New Roman',serif">=C2=A0
This would= provide a maximal difference form a IDToken or access token.=
=C2=A0
<= div>
This would have the advantage that envelopes contain no data= , and that every SET has a payload where the data is found. It requires mor= e parsing in some cases, but it is at least consistent. While we don=E2=80= =99t expect general processors like in SOAP for distribution (much of it is= point to point and very contextually driven), I personally expect to see:<= u>
=C2=A0=C2=A0* = =C2=A0Development of general purpose libraries and tools that are used enha= nce protocols and systems=C2=A0
=C2=A0=C2=A0* =C2=A0Audit and threat analysis systems wil= l be looking at some events historically. These will tend to merge multiple= event feeds.
<= span style=3D"font-size:9pt;font-family:Helvetica,sans-serif">=C2=A0=
Mike Jones also suggested using t= he=C2=A0=E2=80=9Ccty=E2=80=9D=C2=A0(conten= t type) header attribute from JWT.=C2=A0 I think most code today has this s= et to ignore or fixed as =E2=80=9CJWT=E2=80=9D.=C2=A0 I wonder what current= implements would feel if we introduced a =E2=80=9Ccty=E2=80=9D value of = =E2=80=9CSET=E2=80=9D?=C2=A0 Would that help?
=C2=A0
I think it is very important to be able to clearly distin= guish different types of JWT tokens. For example, not being able to cross p= ost a Security Event Token as an Id Token.=C2=A0
=
=C2=A0
Reading=C2=A0RFC 7519 I don't think cty fits the bill, but I could be= wrong. cty is a header parameter used by the crypto algorithm and the defa= ult value is JWT. We need to distinguish sub-types of JWT, and it should be= a claim inside the JWT.
=C2=A0
With the above issue i= n mind, I think option A is the cleanest solution.
=C2=A0
=C2=A0
=
=C2=A0
Thanks for you= r comments.
=C2=A0<= /span>
=C2=A0
=C2=A0
=
=C2=A0

=C2=A0

=C2=A0<= /span>


______________________= _________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailma= n/listinfo/id-event

=C2=A0
___________= ____________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/l<= wbr>istinfo/id-event
=C2=A0
_______________________________________________
Id-event = mailing list
Id-event@ietf= .org
https://www.ietf.org/mailman/listinfo/id-event<= /div>
=C2=A0
=C2= =A0
_____________________________= __________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman= /listinfo/id-event
<= /div>

--047d7b670b355adfab053ad999cf-- From nobody Wed Aug 24 17:20:33 2016 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 997E412D0CD for ; Wed, 24 Aug 2016 17:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=unavailable 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 kLZsmZiWDgXi for ; Wed, 24 Aug 2016 17:20: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 2527212B061 for ; Wed, 24 Aug 2016 17:13:01 -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 u7P0D03D022752 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 25 Aug 2016 00:13:00 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u7P0CxO7031212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 25 Aug 2016 00:12:59 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u7P0CwrB006620; Thu, 25 Aug 2016 00:12:59 GMT Received: from [10.0.1.5] (/24.86.208.48) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 24 Aug 2016 17:12:58 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_CC0E5D80-1353-48A2-AD90-8D3F55F0B1EC" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Phil Hunt In-Reply-To: Date: Wed, 24 Aug 2016 17:12:57 -0700 Message-Id: References: To: Mike Jones X-Mailer: Apple Mail (2.3124) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: "id-event@ietf.org" Subject: Re: [Id-event] ID Event Token Simplification X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 25 Aug 2016 00:20:32 -0000 --Apple-Mail=_CC0E5D80-1353-48A2-AD90-8D3F55F0B1EC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Mike, Apologies, I just re-read and I missed something that might be a mistake = in your text. If you disagree we need to keep discussing. See inline. Phil @independentid www.independentid.com = phil.hunt@oracle.com = > On Aug 24, 2016, at 1:32 PM, Mike Jones = wrote: >=20 > A number of the ID Event Token contributors were discussing the ID = Event Token format yesterday and we came up with what seems like rough = consensus on a way to keep the ID Event Token spec simple enough that = it=E2=80=99s likely to be accepted by the security ADs and IESG as an = individual submission. The background on the agreement is this: > =20 > =C2=B7 JWTs containing events will contain only one or more = related events in a family of events, and not be a container of sets of = unrelated events. I believe the consensus is one and only one event plus extensions. An = extension might be from a different family entirely but related to the = primary event. For example, some might have context specific needs to = extend between partners. Or, some might want to add catergorization = information to the event (e.g. for multi-event threat analysis) such as = Cybox Threat categories. > =C2=B7 The primary event will be the first event in the = =E2=80=9Cevents=E2=80=9D list and the related events will be 2nd, 3rd, = etc. So the 2nd, 3rd etc are =E2=80=9Cextensions=E2=80=9D to the primary = event. They are not dual events. When we originally discussed =E2=80=9Cmulti-events=E2=80=9D the case was = when two different families had overlapping event definitions. So the = hypothetical scenarios was: Both SCIM and RISC might have an =E2=80=9Cacc= ount reset event=E2=80=9D. Should those be two separate events (for the = same actual event), OR should they be expressed together in a single = JWT? The consensus so far has been that such a scenario that has subscribers = for SCIM and RISC would generate two separate SETs. > =C2=B7 Claims pertaining to the family events should be = top-level claims. These should be registered in the JWT Claims Registry = unless they are private claim names or public claim names (as defined in = JWT sections 4.2 and 4.3). > =C2=B7 Claims pertaining only to an individual event should be = values within a claim using the same name as the event. These values = need only be defined within the event definition and need not be = registered as top-level claim names. > =C2=B7 It is up to each event family and individual event what = claims are included with the event family and event. > =20 > This works well because event listeners are listening for a defined = family of events and those only. Any events that the listeners = doesn=E2=80=99t recognize will be either ignored or generate errors, = depending upon the application context. Likewise, receiving a JWT = without an =E2=80=9Cevents=E2=80=9D claim at an events listener should = likely generate an error as well. > =20 > We are explicitly steering clear of the SOAP pattern, in which a = general-purpose message dispatcher was the listener. Developers have = voted with their feet in avoiding this pattern. We will be wise to do = the same. > =20 > The set of rules above is straightforward and doesn=E2=80=99t raise = any complicated questions. It should enable us to get the spec approved = soon. > =20 > I believe that Phil is working on changes for -04 along these lines. = Phil can follow up from here. > =20 > Thanks all, > -- Mike > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event = --Apple-Mail=_CC0E5D80-1353-48A2-AD90-8D3F55F0B1EC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Mike,

Apologies, I just re-read and I missed something that might = be a mistake in your text.  If you disagree we need to keep = discussing.

See = inline.




On Aug 24, 2016, at 1:32 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

A number of the ID Event = Token contributors were discussing the ID Event Token format yesterday = and we came up with what seems like rough consensus on a way to keep the = ID Event Token spec simple enough that it=E2=80=99s likely to be = accepted by the security ADs and IESG as an individual submission.  = The background on the agreement is this:
 
=C2=B7       JWTs = containing events will contain only one or more related events in a = family of events, and not be a container of sets of unrelated = events.
I believe the consensus is one and = only one event plus extensions.  An extension might be from a = different family entirely but related to the primary event.  For = example, some might have context specific needs to extend between = partners.  Or, some might want to add catergorization information = to the event (e.g. for multi-event threat analysis) such as Cybox Threat = categories.

=C2=B7       The = primary event will be the first event in the =E2=80=9Cevents=E2=80=9D = list and the related events will be 2nd, 3rd, etc.
So the 2nd, 3rd = etc are =E2=80=9Cextensions=E2=80=9D to the primary event.  They = are not dual events.

When we = originally discussed =E2=80=9Cmulti-events=E2=80=9D the case was when = two different families had overlapping event definitions. So the = hypothetical scenarios was:  Both SCIM and RISC might have an = =E2=80=9Caccount reset event=E2=80=9D.  Should those be two = separate events (for the same actual event), OR should they be expressed = together in a single JWT?

The = consensus so far has been that such a scenario that has subscribers for = SCIM and RISC would generate two separate SETs.

=C2=B7       Claims = pertaining to the family events should be top-level claims.  These = should be registered in the JWT Claims Registry unless they are private = claim names or public claim names (as defined in JWT sections 4.2 and = 4.3).
=C2=B7       Claims = pertaining only to an individual event should be values within a claim = using the same name as the event.  These values need only be = defined within the event definition and need not be registered as = top-level claim names.
=C2=B7       It is = up to each event family and individual event what claims are included = with the event family and event.
 
This works well because event listeners = are listening for a defined family of events and those only.  Any = events that the listeners doesn=E2=80=99t recognize will be either = ignored or generate errors, depending upon the application = context.  Likewise, receiving a JWT without an =E2=80=9Cevents=E2=80=9D= claim at an events listener should likely generate an error as = well.
 
We are = explicitly steering clear of the SOAP pattern, in which a = general-purpose message dispatcher was the listener.  Developers = have voted with their feet in avoiding this pattern.  We will be = wise to do the same.
 
The set of rules above is straightforward and doesn=E2=80=99t = raise any complicated questions.  It should enable us to get the = spec approved soon.
 
I believe that Phil is working on changes for -04 along these = lines.  Phil can follow up from here.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;       Thanks all,
          &nb= sp;            = ;            &= nbsp;           &nb= sp;       -- Mike
_______________________________________________
Id-event mailing = list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event

= --Apple-Mail=_CC0E5D80-1353-48A2-AD90-8D3F55F0B1EC-- From nobody Wed Aug 24 17:43:23 2016 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 CF2CF12D189 for ; Wed, 24 Aug 2016 17:43: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_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 QWmGyhW0fD58 for ; Wed, 24 Aug 2016 17:43:19 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0094.outbound.protection.outlook.com [104.47.40.94]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC4D212D5BC for ; Wed, 24 Aug 2016 17:43: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=1gyuCPYiBQ7uYB5/sQs/AyLvEnx8HFN4xQCEtWgEJr8=; b=TECi47JAXperv3a61YaSNI/fe9SEaZQdvxBlTU1l2PTjcJ8Ko+AcXbPClB/f75K1JnpFWWrOuEFXd1uivSWwhSuyF/SOGmB70nKnVkI5pLYe0a5VAAhZ1CGeu7x5K5vTl2xOri6i/549ML14LcW7hAVkhqVgBEbH/NxHZbLsRnE= Received: from SN1PR0301MB1645.namprd03.prod.outlook.com (10.162.130.139) by SN1PR0301MB1646.namprd03.prod.outlook.com (10.162.130.140) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.13; Thu, 25 Aug 2016 00:43:17 +0000 Received: from SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) by SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) with mapi id 15.01.0587.013; Thu, 25 Aug 2016 00:43:17 +0000 From: Mike Jones To: Phil Hunt Thread-Topic: [Id-event] ID Event Token Simplification Thread-Index: AdH+RIQI/K7I8J4VTqS0zwwP7EWChgAIOp+AAADlGAA= Date: Thu, 25 Aug 2016 00:43:16 +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: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [64.134.242.226] x-ms-office365-filtering-correlation-id: c62fd832-6905-4fda-d570-08d3cc80ce2b x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1646; 6:yjUOTSv5Y70WMP9YvLBcebZkULrgU2czbaePBnvD78Qg+7oCmS/tH7gLNIhTHVyRiPcx7ssBARfkviYYUSyqxH7ZKCmLF6fCS9WM+SYWIVXPokq969mvDjuHinA30D27q0Rlc96Gx4SskqlXIk75HO+b9c2+h19l9JZt255go3pC47TOACEwb6eTq2jozU3An3bVnPU8D+KHPoBuh8nN/Iwq4EIg/QypxVs6hjzin1iW/YJLq6z8Hq3XI7GZwFWFvczXZtUNt50smW/pStf6UAvG0JnaK6rNGv76u+kINrVHAFIsDyWUrbo7NyusozAR0v/on2xSutIhcqGRc99xqA==; 5:xl1xfy1vV6+s0k5vd3FjFCyS6jAHGbDGpkNbsj0tk1BO94QWlm420CAPJ1DUlMhLqx3gj7GfRbLf9XYpBjE+O9iMLP32k4fYAO7pO/lpkktNtT07DUBIp8ITx1Rn/fUTB3K64AFdLgmJOZmRpaNDfA==; 24:OlH5bjFqNut1ji9hvuvMOSY2P88FTpC8EU7iJmw43V/Ro9fTaMt05IC/Pt4wx3GCF2XzdNiMgHZT1ZoUzROkROA7MRmMFSxcLENTwxyT9b0=; 7:C2Xhqbbuc7am6NYw5M6c+mV1qLLGGzJQLm4JSKvLXcpYrz79bDbmvQ06kCGePCr3PxhPPb6X1VswNXZsnvpy8zz6VYlwavTIZYnSEQAqVZSO1uTMw4uAjfhHAPcEdZ7hN/llPoQHy6APFerN9u8luz320ycvKxWDEsVc76NqEf+bVvhmwLBHM+Lge23U2s5YDEgDNi+paLQoOKJ90QZ9tOJFjuJMhZR/UBglEyk+OFjtQSBzofCCEdFgcXx3O9LK x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1646; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(100405760836317)(21748063052155)(146099531331640); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:SN1PR0301MB1646; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1646; x-forefront-prvs: 0045236D47 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(199003)(377454003)(24454002)(52044002)(19609705001)(2950100001)(33656002)(122556002)(2900100001)(5660300001)(19580395003)(16236675004)(5002640100001)(87936001)(189998001)(101416001)(99286002)(15975445007)(19625215002)(76176999)(54356999)(105586002)(66066001)(7906003)(50986999)(74316002)(81156014)(7736002)(7846002)(19300405004)(8676002)(7696003)(4326007)(81166006)(19580405001)(86362001)(2906002)(11100500001)(77096005)(68736007)(1680700002)(92566002)(10290500002)(76576001)(9686002)(16601075003)(106356001)(102836003)(8936002)(10090500001)(8990500004)(790700001)(5005710100001)(10400500002)(6116002)(586003)(3846002)(3660700001)(3280700002)(86612001)(97736004)(110136002)(19617315012); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0301MB1646; H:SN1PR0301MB1645.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB1645CD8B79DA0811CEC2A330F5ED0SN1PR0301MB1645_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Aug 2016 00:43:17.4760 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1646 Archived-At: Cc: "id-event@ietf.org" Subject: Re: [Id-event] ID Event Token Simplification X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 25 Aug 2016 00:43:22 -0000 --_000_SN1PR0301MB1645CD8B79DA0811CEC2A330F5ED0SN1PR0301MB1645_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QSDigJxmYW1pbHnigJ0gaW4gbXkgbWluZCwgcmVhbGlzdGljYWxseSwgd2FzIGEgZ3JvdXAgb2Yg ZXZlbnRzIHRoYXQgaGF2ZSBjb21wYXRpYmxlIGNsYWltcyB1c2FnZSDigJMgcHJvYmFibHkgYSBy ZXN1bHQgb2YgdGhlbSBlaXRoZXIgYmVpbmcgZGVmaW5lZCB0b2dldGhlciwgb3IgcG9zc2libHkg YmVjYXVzZSB0aGV5IGFsbCBiZWxvbmcgdG8gdGhlIHNhbWUgZXZlbnRzIGZyYW1ld29yaywgdGhh dCBkZWZpbmVzIHRoZSBjbGFpbXMgdXNhZ2UgZm9yIHRoZSBmcmFtZXdvcmsuICAoRmVlbCBmcmVl IHRvIHVzZSB0ZXh0IGxpa2UgdGhlIGFib3ZlIGluIHRoZSBzcGVj4oCZcyBkZXNjcmlwdGlvbiBv ZiBldmVudCBmYW1pbGllcywgYnkgdGhlIHNheS4pDQoNCkkgZG9u4oCZdCBwZXJzb25hbGx5IHNl ZSBhbnkgZGlmZmVyZW5jZSBiZXR3ZWVuIGEgcHJpbWFyeSBldmVudCBhbmQgYW4gZXh0ZW5zaW9u IGV2ZW50LCBvdGhlciB0aGFuIG9uZSBpcyB0aGUgZmlyc3QgYXJyYXkgZWxlbWVudC4gIElmIHRo ZXJl4oCZcyBub3QgYW4gZW5mb3JjZWFibGUgc2VtYW50aWMgZGlmZmVyZW5jZSB0aGF0IG1hdHRl cnMsIEkgZG9u4oCZdCB0aGluayB0aGF0IHRoZSB0ZXh0IHNob3VsZCB0cnkgdG9vIGhhcmQgdG8g ZGlzdGluZ3Vpc2ggYmV0d2VlbiB0aGVtIGVpdGhlci4gIE1ha2luZyBhcnRpZmljaWFsIGRpc3Rp bmN0aW9ucyB3b3VsZCBsaWtlbHkgb25seSBtYWtlIHRoaW5ncyB1bm5lY2Vzc2FyaWx5IGJyaXR0 bGUsIGJlY2F1c2Ugd2UgY2Fu4oCZdCBhbnRpY2lwYXRlIHRoZSBuYXR1cmUgb2YgZXZlcnkgdXNl IGNhc2UuDQoNCkRvZXMgdGhhdCBtYWtlIHNlbnNlPyAgVGhhbmtzIGZvciBhc2tpbmcuDQoNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBN aWtlDQoNCkZyb206IFBoaWwgSHVudCBbbWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tXQ0KU2Vu dDogV2VkbmVzZGF5LCBBdWd1c3QgMjQsIDIwMTYgNToxMyBQTQ0KVG86IE1pa2UgSm9uZXMgPE1p Y2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4NCkNjOiBpZC1ldmVudEBpZXRmLm9yZw0KU3ViamVj dDogUmU6IFtJZC1ldmVudF0gSUQgRXZlbnQgVG9rZW4gU2ltcGxpZmljYXRpb24NCg0KTWlrZSwN Cg0KQXBvbG9naWVzLCBJIGp1c3QgcmUtcmVhZCBhbmQgSSBtaXNzZWQgc29tZXRoaW5nIHRoYXQg bWlnaHQgYmUgYSBtaXN0YWtlIGluIHlvdXIgdGV4dC4gIElmIHlvdSBkaXNhZ3JlZSB3ZSBuZWVk IHRvIGtlZXAgZGlzY3Vzc2luZy4NCg0KU2VlIGlubGluZS4NCg0KUGhpbA0KDQpAaW5kZXBlbmRl bnRpZA0Kd3d3LmluZGVwZW5kZW50aWQuY29tPGh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20+ DQpwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+DQoNCg0K DQoNCk9uIEF1ZyAyNCwgMjAxNiwgYXQgMTozMiBQTSwgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25l c0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PiB3cm90 ZToNCg0KQSBudW1iZXIgb2YgdGhlIElEIEV2ZW50IFRva2VuIGNvbnRyaWJ1dG9ycyB3ZXJlIGRp c2N1c3NpbmcgdGhlIElEIEV2ZW50IFRva2VuIGZvcm1hdCB5ZXN0ZXJkYXkgYW5kIHdlIGNhbWUg dXAgd2l0aCB3aGF0IHNlZW1zIGxpa2Ugcm91Z2ggY29uc2Vuc3VzIG9uIGEgd2F5IHRvIGtlZXAg dGhlIElEIEV2ZW50IFRva2VuIHNwZWMgc2ltcGxlIGVub3VnaCB0aGF0IGl04oCZcyBsaWtlbHkg dG8gYmUgYWNjZXB0ZWQgYnkgdGhlIHNlY3VyaXR5IEFEcyBhbmQgSUVTRyBhcyBhbiBpbmRpdmlk dWFsIHN1Ym1pc3Npb24uICBUaGUgYmFja2dyb3VuZCBvbiB0aGUgYWdyZWVtZW50IGlzIHRoaXM6 DQoNCuKAoiAgICAgICBKV1RzIGNvbnRhaW5pbmcgZXZlbnRzIHdpbGwgY29udGFpbiBvbmx5IG9u ZSBvciBtb3JlIHJlbGF0ZWQgZXZlbnRzIGluIGEgZmFtaWx5IG9mIGV2ZW50cywgYW5kIG5vdCBi ZSBhIGNvbnRhaW5lciBvZiBzZXRzIG9mIHVucmVsYXRlZCBldmVudHMuDQpJIGJlbGlldmUgdGhl IGNvbnNlbnN1cyBpcyBvbmUgYW5kIG9ubHkgb25lIGV2ZW50IHBsdXMgZXh0ZW5zaW9ucy4gIEFu IGV4dGVuc2lvbiBtaWdodCBiZSBmcm9tIGEgZGlmZmVyZW50IGZhbWlseSBlbnRpcmVseSBidXQg cmVsYXRlZCB0byB0aGUgcHJpbWFyeSBldmVudC4gIEZvciBleGFtcGxlLCBzb21lIG1pZ2h0IGhh dmUgY29udGV4dCBzcGVjaWZpYyBuZWVkcyB0byBleHRlbmQgYmV0d2VlbiBwYXJ0bmVycy4gIE9y LCBzb21lIG1pZ2h0IHdhbnQgdG8gYWRkIGNhdGVyZ29yaXphdGlvbiBpbmZvcm1hdGlvbiB0byB0 aGUgZXZlbnQgKGUuZy4gZm9yIG11bHRpLWV2ZW50IHRocmVhdCBhbmFseXNpcykgc3VjaCBhcyBD eWJveCBUaHJlYXQgY2F0ZWdvcmllcy4NCg0KDQrigKIgICAgICAgVGhlIHByaW1hcnkgZXZlbnQg d2lsbCBiZSB0aGUgZmlyc3QgZXZlbnQgaW4gdGhlIOKAnGV2ZW50c+KAnSBsaXN0IGFuZCB0aGUg cmVsYXRlZCBldmVudHMgd2lsbCBiZSAybmQsIDNyZCwgZXRjLg0KU28gdGhlIDJuZCwgM3JkIGV0 YyBhcmUg4oCcZXh0ZW5zaW9uc+KAnSB0byB0aGUgcHJpbWFyeSBldmVudC4gIFRoZXkgYXJlIG5v dCBkdWFsIGV2ZW50cy4NCg0KV2hlbiB3ZSBvcmlnaW5hbGx5IGRpc2N1c3NlZCDigJxtdWx0aS1l dmVudHPigJ0gdGhlIGNhc2Ugd2FzIHdoZW4gdHdvIGRpZmZlcmVudCBmYW1pbGllcyBoYWQgb3Zl cmxhcHBpbmcgZXZlbnQgZGVmaW5pdGlvbnMuIFNvIHRoZSBoeXBvdGhldGljYWwgc2NlbmFyaW9z IHdhczogIEJvdGggU0NJTSBhbmQgUklTQyBtaWdodCBoYXZlIGFuIOKAnGFjY291bnQgcmVzZXQg ZXZlbnTigJ0uICBTaG91bGQgdGhvc2UgYmUgdHdvIHNlcGFyYXRlIGV2ZW50cyAoZm9yIHRoZSBz YW1lIGFjdHVhbCBldmVudCksIE9SIHNob3VsZCB0aGV5IGJlIGV4cHJlc3NlZCB0b2dldGhlciBp biBhIHNpbmdsZSBKV1Q/DQoNClRoZSBjb25zZW5zdXMgc28gZmFyIGhhcyBiZWVuIHRoYXQgc3Vj aCBhIHNjZW5hcmlvIHRoYXQgaGFzIHN1YnNjcmliZXJzIGZvciBTQ0lNIGFuZCBSSVNDIHdvdWxk IGdlbmVyYXRlIHR3byBzZXBhcmF0ZSBTRVRzLg0KDQoNCuKAoiAgICAgICBDbGFpbXMgcGVydGFp bmluZyB0byB0aGUgZmFtaWx5IGV2ZW50cyBzaG91bGQgYmUgdG9wLWxldmVsIGNsYWltcy4gIFRo ZXNlIHNob3VsZCBiZSByZWdpc3RlcmVkIGluIHRoZSBKV1QgQ2xhaW1zIFJlZ2lzdHJ5IHVubGVz cyB0aGV5IGFyZSBwcml2YXRlIGNsYWltIG5hbWVzIG9yIHB1YmxpYyBjbGFpbSBuYW1lcyAoYXMg ZGVmaW5lZCBpbiBKV1Qgc2VjdGlvbnMgNC4yIGFuZCA0LjMpLg0K4oCiICAgICAgIENsYWltcyBw ZXJ0YWluaW5nIG9ubHkgdG8gYW4gaW5kaXZpZHVhbCBldmVudCBzaG91bGQgYmUgdmFsdWVzIHdp dGhpbiBhIGNsYWltIHVzaW5nIHRoZSBzYW1lIG5hbWUgYXMgdGhlIGV2ZW50LiAgVGhlc2UgdmFs dWVzIG5lZWQgb25seSBiZSBkZWZpbmVkIHdpdGhpbiB0aGUgZXZlbnQgZGVmaW5pdGlvbiBhbmQg bmVlZCBub3QgYmUgcmVnaXN0ZXJlZCBhcyB0b3AtbGV2ZWwgY2xhaW0gbmFtZXMuDQrigKIgICAg ICAgSXQgaXMgdXAgdG8gZWFjaCBldmVudCBmYW1pbHkgYW5kIGluZGl2aWR1YWwgZXZlbnQgd2hh dCBjbGFpbXMgYXJlIGluY2x1ZGVkIHdpdGggdGhlIGV2ZW50IGZhbWlseSBhbmQgZXZlbnQuDQoN ClRoaXMgd29ya3Mgd2VsbCBiZWNhdXNlIGV2ZW50IGxpc3RlbmVycyBhcmUgbGlzdGVuaW5nIGZv ciBhIGRlZmluZWQgZmFtaWx5IG9mIGV2ZW50cyBhbmQgdGhvc2Ugb25seS4gIEFueSBldmVudHMg dGhhdCB0aGUgbGlzdGVuZXJzIGRvZXNu4oCZdCByZWNvZ25pemUgd2lsbCBiZSBlaXRoZXIgaWdu b3JlZCBvciBnZW5lcmF0ZSBlcnJvcnMsIGRlcGVuZGluZyB1cG9uIHRoZSBhcHBsaWNhdGlvbiBj b250ZXh0LiAgTGlrZXdpc2UsIHJlY2VpdmluZyBhIEpXVCB3aXRob3V0IGFuIOKAnGV2ZW50c+KA nSBjbGFpbSBhdCBhbiBldmVudHMgbGlzdGVuZXIgc2hvdWxkIGxpa2VseSBnZW5lcmF0ZSBhbiBl cnJvciBhcyB3ZWxsLg0KDQpXZSBhcmUgZXhwbGljaXRseSBzdGVlcmluZyBjbGVhciBvZiB0aGUg U09BUCBwYXR0ZXJuLCBpbiB3aGljaCBhIGdlbmVyYWwtcHVycG9zZSBtZXNzYWdlIGRpc3BhdGNo ZXIgd2FzIHRoZSBsaXN0ZW5lci4gIERldmVsb3BlcnMgaGF2ZSB2b3RlZCB3aXRoIHRoZWlyIGZl ZXQgaW4gYXZvaWRpbmcgdGhpcyBwYXR0ZXJuLiAgV2Ugd2lsbCBiZSB3aXNlIHRvIGRvIHRoZSBz YW1lLg0KDQpUaGUgc2V0IG9mIHJ1bGVzIGFib3ZlIGlzIHN0cmFpZ2h0Zm9yd2FyZCBhbmQgZG9l c27igJl0IHJhaXNlIGFueSBjb21wbGljYXRlZCBxdWVzdGlvbnMuICBJdCBzaG91bGQgZW5hYmxl IHVzIHRvIGdldCB0aGUgc3BlYyBhcHByb3ZlZCBzb29uLg0KDQpJIGJlbGlldmUgdGhhdCBQaGls IGlzIHdvcmtpbmcgb24gY2hhbmdlcyBmb3IgLTA0IGFsb25nIHRoZXNlIGxpbmVzLiAgUGhpbCBj YW4gZm9sbG93IHVwIGZyb20gaGVyZS4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFRoYW5rcyBhbGwsDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklkLWV2ZW50IG1haWxpbmcgbGlz dA0KSWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudA0KDQo= --_000_SN1PR0301MB1645CD8B79DA0811CEC2A330F5ED0SN1PR0301MB1645_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1z b25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1l Om1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGlu Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNw YW4uYXBwbGUtc3R5bGUtc3Bhbg0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1zdHlsZS1zcGFuO30N CnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZl cnRlZC1zcGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMDAy MDYwO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGlu Ow0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+ PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4 dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxh eW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+QSDigJxmYW1p bHnigJ0gaW4gbXkgbWluZCwgcmVhbGlzdGljYWxseSwgd2FzIGEgZ3JvdXAgb2YgZXZlbnRzIHRo YXQgaGF2ZSBjb21wYXRpYmxlIGNsYWltcyB1c2FnZSDigJMgcHJvYmFibHkgYSByZXN1bHQgb2Yg dGhlbSBlaXRoZXIgYmVpbmcgZGVmaW5lZCB0b2dldGhlciwgb3IgcG9zc2libHkNCiBiZWNhdXNl IHRoZXkgYWxsIGJlbG9uZyB0byB0aGUgc2FtZSBldmVudHMgZnJhbWV3b3JrLCB0aGF0IGRlZmlu ZXMgdGhlIGNsYWltcyB1c2FnZSBmb3IgdGhlIGZyYW1ld29yay4mbmJzcDsgKEZlZWwgZnJlZSB0 byB1c2UgdGV4dCBsaWtlIHRoZSBhYm92ZSBpbiB0aGUgc3BlY+KAmXMgZGVzY3JpcHRpb24gb2Yg ZXZlbnQgZmFtaWxpZXMsIGJ5IHRoZSBzYXkuKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzAwMjA2MCI+SSBkb27igJl0IHBlcnNvbmFsbHkgc2VlIGFueSBkaWZmZXJlbmNlIGJl dHdlZW4gYSBwcmltYXJ5IGV2ZW50IGFuZCBhbiBleHRlbnNpb24gZXZlbnQsIG90aGVyIHRoYW4g b25lIGlzIHRoZSBmaXJzdCBhcnJheSBlbGVtZW50LiZuYnNwOyBJZiB0aGVyZeKAmXMgbm90IGFu IGVuZm9yY2VhYmxlDQogc2VtYW50aWMgZGlmZmVyZW5jZSB0aGF0IG1hdHRlcnMsIEkgZG9u4oCZ dCB0aGluayB0aGF0IHRoZSB0ZXh0IHNob3VsZCB0cnkgdG9vIGhhcmQgdG8gZGlzdGluZ3Vpc2gg YmV0d2VlbiB0aGVtIGVpdGhlci4mbmJzcDsgTWFraW5nIGFydGlmaWNpYWwgZGlzdGluY3Rpb25z IHdvdWxkIGxpa2VseSBvbmx5IG1ha2UgdGhpbmdzIHVubmVjZXNzYXJpbHkgYnJpdHRsZSwgYmVj YXVzZSB3ZSBjYW7igJl0IGFudGljaXBhdGUgdGhlIG5hdHVyZSBvZiBldmVyeSB1c2UgY2FzZS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPkRvZXMgdGhhdCBtYWtl IHNlbnNlPyZuYnNwOyBUaGFua3MgZm9yIGFza2luZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEg bmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6 X01haWxFbmRDb21wb3NlIj48L3NwYW4+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4gUGhpbCBIdW50IFttYWlsdG86cGhpbC5odW50QG9yYWNsZS5j b21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBBdWd1c3QgMjQsIDIwMTYgNToxMyBQ TTxicj4NCjxiPlRvOjwvYj4gTWlrZSBKb25lcyAmbHQ7TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQu Y29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gaWQtZXZlbnRAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IFtJZC1ldmVudF0gSUQgRXZlbnQgVG9rZW4gU2ltcGxpZmljYXRpb248bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NaWtlLDxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXBvbG9naWVzLCBJIGp1c3QgcmUt cmVhZCBhbmQgSSBtaXNzZWQgc29tZXRoaW5nIHRoYXQgbWlnaHQgYmUgYSBtaXN0YWtlIGluIHlv dXIgdGV4dC4gJm5ic3A7SWYgeW91IGRpc2FncmVlIHdlIG5lZWQgdG8ga2VlcCBkaXNjdXNzaW5n LjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2VlIGlubGlu ZS48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPlBoaWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+QGluZGVwZW5kZW50aWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjxhIGhyZWY9Imh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20iPnd3dy5pbmRlcGVu ZGVudGlkLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIj5waGlsLmh1bnRAb3JhY2xl LmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gQXVnIDI0LCAy MDE2LCBhdCAxOjMyIFBNLCBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5K b25lc0BtaWNyb3NvZnQuY29tIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+QSBudW1iZXIgb2YgdGhlIElEIEV2ZW50IFRva2VuIGNvbnRyaWJ1dG9ycyB3 ZXJlIGRpc2N1c3NpbmcgdGhlIElEIEV2ZW50IFRva2VuIGZvcm1hdCB5ZXN0ZXJkYXkgYW5kIHdl IGNhbWUgdXAgd2l0aCB3aGF0IHNlZW1zIGxpa2Ugcm91Z2ggY29uc2Vuc3VzIG9uIGEgd2F5IHRv IGtlZXAgdGhlIElEDQogRXZlbnQgVG9rZW4gc3BlYyBzaW1wbGUgZW5vdWdoIHRoYXQgaXTigJlz IGxpa2VseSB0byBiZSBhY2NlcHRlZCBieSB0aGUgc2VjdXJpdHkgQURzIGFuZCBJRVNHIGFzIGFu IGluZGl2aWR1YWwgc3VibWlzc2lvbi4mbmJzcDsgVGhlIGJhY2tncm91bmQgb24gdGhlIGFncmVl bWVudCBpcyB0aGlzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW4iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCI+wrc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPkpXVHMNCiBjb250YWluaW5nIGV2ZW50cyB3aWxsIGNvbnRhaW4gb25seSBvbmUgb3Ig bW9yZSByZWxhdGVkIGV2ZW50cyBpbiBhIGZhbWlseSBvZiBldmVudHMsIGFuZCBub3QgYmUgYSBj b250YWluZXIgb2Ygc2V0cyBvZiB1bnJlbGF0ZWQgZXZlbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J IGJlbGlldmUgdGhlIGNvbnNlbnN1cyBpcyBvbmUgYW5kIG9ubHkgb25lIGV2ZW50IHBsdXMgZXh0 ZW5zaW9ucy4gJm5ic3A7QW4gZXh0ZW5zaW9uIG1pZ2h0IGJlIGZyb20gYSBkaWZmZXJlbnQgZmFt aWx5IGVudGlyZWx5IGJ1dCByZWxhdGVkIHRvIHRoZSBwcmltYXJ5IGV2ZW50LiAmbmJzcDtGb3Ig ZXhhbXBsZSwgc29tZSBtaWdodCBoYXZlIGNvbnRleHQgc3BlY2lmaWMgbmVlZHMgdG8gZXh0ZW5k IGJldHdlZW4gcGFydG5lcnMuDQogJm5ic3A7T3IsIHNvbWUgbWlnaHQgd2FudCB0byBhZGQgY2F0 ZXJnb3JpemF0aW9uIGluZm9ybWF0aW9uIHRvIHRoZSBldmVudCAoZS5nLiBmb3IgbXVsdGktZXZl bnQgdGhyZWF0IGFuYWx5c2lzKSBzdWNoIGFzIEN5Ym94IFRocmVhdCBjYXRlZ29yaWVzLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJy Pg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW4iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCI+wrc8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZQ0KIHByaW1hcnkgZXZlbnQgd2lsbCBiZSB0aGUgZmly c3QgZXZlbnQgaW4gdGhlIOKAnGV2ZW50c+KAnSBsaXN0IGFuZCB0aGUgcmVsYXRlZCBldmVudHMg d2lsbCBiZSAyPHN1cD5uZDwvc3VwPiwgMzxzdXA+cmQ8L3N1cD4sIGV0Yy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+U28gdGhlIDJuZCwgM3JkIGV0YyBhcmUg4oCcZXh0ZW5zaW9uc+KAnSB0byB0aGUgcHJp bWFyeSBldmVudC4gJm5ic3A7VGhleSBhcmUgbm90IGR1YWwgZXZlbnRzLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGVuIHdlIG9yaWdpbmFs bHkgZGlzY3Vzc2VkIOKAnG11bHRpLWV2ZW50c+KAnSB0aGUgY2FzZSB3YXMgd2hlbiB0d28gZGlm ZmVyZW50IGZhbWlsaWVzIGhhZCBvdmVybGFwcGluZyBldmVudCBkZWZpbml0aW9ucy4gU28gdGhl IGh5cG90aGV0aWNhbCBzY2VuYXJpb3Mgd2FzOiAmbmJzcDtCb3RoIFNDSU0gYW5kIFJJU0MgbWln aHQgaGF2ZSBhbiDigJxhY2NvdW50IHJlc2V0IGV2ZW504oCdLiAmbmJzcDtTaG91bGQgdGhvc2Ug YmUgdHdvIHNlcGFyYXRlDQogZXZlbnRzIChmb3IgdGhlIHNhbWUgYWN0dWFsIGV2ZW50KSwgT1Ig c2hvdWxkIHRoZXkgYmUgZXhwcmVzc2VkIHRvZ2V0aGVyIGluIGEgc2luZ2xlIEpXVD88bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGNvbnNl bnN1cyBzbyBmYXIgaGFzIGJlZW4gdGhhdCBzdWNoIGEgc2NlbmFyaW8gdGhhdCBoYXMgc3Vic2Ny aWJlcnMgZm9yIFNDSU0gYW5kIFJJU0Mgd291bGQgZ2VuZXJhdGUgdHdvIHNlcGFyYXRlIFNFVHMu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+ DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbiI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sIj7Ctzwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Q2xhaW1zDQogcGVydGFpbmluZyB0byB0aGUgZmFt aWx5IGV2ZW50cyBzaG91bGQgYmUgdG9wLWxldmVsIGNsYWltcy4mbmJzcDsgVGhlc2Ugc2hvdWxk IGJlIHJlZ2lzdGVyZWQgaW4gdGhlIEpXVCBDbGFpbXMgUmVnaXN0cnkgdW5sZXNzIHRoZXkgYXJl IHByaXZhdGUgY2xhaW0gbmFtZXMgb3IgcHVibGljIGNsYWltIG5hbWVzIChhcyBkZWZpbmVkIGlu IEpXVCBzZWN0aW9ucyA0LjIgYW5kIDQuMykuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJ0ZXh0LWluZGVudDotLjI1aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OlN5bWJvbCI+wrc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkNsYWlt cw0KIHBlcnRhaW5pbmcgb25seSB0byBhbiBpbmRpdmlkdWFsIGV2ZW50IHNob3VsZCBiZSB2YWx1 ZXMgd2l0aGluIGEgY2xhaW0gdXNpbmcgdGhlIHNhbWUgbmFtZSBhcyB0aGUgZXZlbnQuJm5ic3A7 IFRoZXNlIHZhbHVlcyBuZWVkIG9ubHkgYmUgZGVmaW5lZCB3aXRoaW4gdGhlIGV2ZW50IGRlZmlu aXRpb24gYW5kIG5lZWQgbm90IGJlIHJlZ2lzdGVyZWQgYXMgdG9wLWxldmVsIGNsYWltIG5hbWVz LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpTeW1ib2wiPsK3PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JdA0KIGlzIHVwIHRvIGVhY2ggZXZlbnQgZmFtaWx5 IGFuZCBpbmRpdmlkdWFsIGV2ZW50IHdoYXQgY2xhaW1zIGFyZSBpbmNsdWRlZCB3aXRoIHRoZSBl dmVudCBmYW1pbHkgYW5kIGV2ZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5UaGlzIHdvcmtzIHdlbGwgYmVjYXVzZSBldmVudCBsaXN0ZW5lcnMgYXJlIGxp c3RlbmluZyBmb3IgYSBkZWZpbmVkIGZhbWlseSBvZiBldmVudHMgYW5kIHRob3NlIG9ubHkuJm5i c3A7IEFueSBldmVudHMgdGhhdCB0aGUgbGlzdGVuZXJzIGRvZXNu4oCZdCByZWNvZ25pemUgd2ls bCBiZSBlaXRoZXIgaWdub3JlZA0KIG9yIGdlbmVyYXRlIGVycm9ycywgZGVwZW5kaW5nIHVwb24g dGhlIGFwcGxpY2F0aW9uIGNvbnRleHQuJm5ic3A7IExpa2V3aXNlLCByZWNlaXZpbmcgYSBKV1Qg d2l0aG91dCBhbiDigJxldmVudHPigJ0gY2xhaW0gYXQgYW4gZXZlbnRzIGxpc3RlbmVyIHNob3Vs ZCBsaWtlbHkgZ2VuZXJhdGUgYW4gZXJyb3IgYXMgd2VsbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+V2UgYXJlIGV4cGxpY2l0bHkgc3RlZXJpbmcgY2xlYXIg b2YgdGhlIFNPQVAgcGF0dGVybiwgaW4gd2hpY2ggYSBnZW5lcmFsLXB1cnBvc2UgbWVzc2FnZSBk aXNwYXRjaGVyIHdhcyB0aGUgbGlzdGVuZXIuJm5ic3A7IERldmVsb3BlcnMgaGF2ZSB2b3RlZCB3 aXRoIHRoZWlyIGZlZXQgaW4gYXZvaWRpbmcgdGhpcw0KIHBhdHRlcm4uJm5ic3A7IFdlIHdpbGwg YmUgd2lzZSB0byBkbyB0aGUgc2FtZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+VGhlIHNldCBvZiBydWxlcyBhYm92ZSBpcyBzdHJhaWdodGZvcndhcmQgYW5k IGRvZXNu4oCZdCByYWlzZSBhbnkgY29tcGxpY2F0ZWQgcXVlc3Rpb25zLiZuYnNwOyBJdCBzaG91 bGQgZW5hYmxlIHVzIHRvIGdldCB0aGUgc3BlYyBhcHByb3ZlZCBzb29uLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JIGJlbGlldmUgdGhhdCBQaGlsIGlzIHdv cmtpbmcgb24gY2hhbmdlcyBmb3IgLTA0IGFsb25nIHRoZXNlIGxpbmVzLiZuYnNwOyBQaGlsIGNh biBmb2xsb3cgdXAgZnJvbSBoZXJlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhhbmtz IGFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCklkLWV2ZW50IG1haWxpbmcgbGlzdDxicj4NCjwvc3Bh bj48YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6Izk1NEY3MiI+SWQtZXZlbnRAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi Pjxicj4NCjwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2lkLWV2ZW50Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM5NTRGNzIiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ8L3NwYW4+PC9hPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_SN1PR0301MB1645CD8B79DA0811CEC2A330F5ED0SN1PR0301MB1645_-- From nobody Wed Aug 31 11:02:39 2016 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 C664712D615 for ; Wed, 31 Aug 2016 11:02:36 -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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=engageidentity-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 z1TSrZ3KQ7-f for ; Wed, 31 Aug 2016 11:02:35 -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 9E23012D612 for ; Wed, 31 Aug 2016 11:02:34 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id g62so42777582lfe.3 for ; Wed, 31 Aug 2016 11:02:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=engageidentity-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=O4/2rdjrL2IygEbJk0x92Q5p5DXisIGRW6QPmx4AOJc=; b=ONXTmvfsi/nO/zrGHATBHmsx/4u6GKRVvKT3M1moAaKElxo5RTc78w9SYGGHczH/Z0 GTPHufigeAt442Q5Ufqwv2NUhioIJUE77oaYPgwM1lpk6wk1WQEmb1wKXmVwvWmMOsXN no+LTsZI4603hv/CTv3/x666uD4BbQjGqgHRREUq5D5GZZ5LjgyC3Y0fFhU3lMcaYMEN 5t7sP2yyRIR+R4QlT3vyXww/nBhvSFy8YUBtFuNtnSvmc2Uxtd8YHIF9oml827/bFm6d 14pjoJ+o1TKA2La8UDE3eqBMRx70l6iI+EeCzNMaPnEGh3rj8kF5sThT553mOQNiIhZO uLSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=O4/2rdjrL2IygEbJk0x92Q5p5DXisIGRW6QPmx4AOJc=; b=M5z5s5/jaCRw88sfPR3HAte0kNJL0uE+DI+2M+/YudrIzZTdazZDwTLOh4M3lLOhon 6hvyjOJr4gt8Tu0rhsovPEKPVTnA/IKZYb8wAQsBm/rs2APUPihBOLDfI+nCz7kOc6Rp z3k0p8kMciGIMW3uosp8xxhJEJKR3Qm1YdGFog9AtLzSaIadrpT/0WB2gtfIIUckEKXa WKnELiWrG7PN0466EtbDxteNBuS7HBNDpBMCzhcMOgBN/QybtzsEViWa2TBbf9ZeONX+ Q4E0wbTXDZ8eNwt00XjlWSSsqFPooxTHMmNyyHmCQ4LYegY/A207paNykZ/4RN4uCIr9 ktuw== X-Gm-Message-State: AE9vXwOLONL7ckpI+yK3W8fHqZEoWI9k7YPS9SvcZtWKVBXQHhgsakEuaSbAUDQWaT3xM3FydlpyzlBXTQYisTre X-Received: by 10.25.1.133 with SMTP id 127mr4073352lfb.54.1472666552441; Wed, 31 Aug 2016 11:02:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.3.241 with HTTP; Wed, 31 Aug 2016 11:02:31 -0700 (PDT) From: Sarah Squire Date: Wed, 31 Aug 2016 11:02:31 -0700 Message-ID: To: id-event@ietf.org Content-Type: multipart/alternative; boundary=001a113b0220bb3ca9053b61e674 Archived-At: Subject: [Id-event] SET examples for a healthcare context X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 31 Aug 2016 18:02:37 -0000 --001a113b0220bb3ca9053b61e674 Content-Type: text/plain; charset=UTF-8 Hi all, I've been putting together some examples based on the idevent-token-03 draft. You can find them here: https://github.com/id-event/examples There are three examples of an idp-to-rp SET - consent, token revocation, and userinfo update. There are two examples of an rp-to-idp SET - parallel authentication and suspected fraud. This format seems workable for our use cases. Note that none of these include or require "sub" at the top level. Sarah Sarah Squire Engage Identity http://engageidentity.com --001a113b0220bb3ca9053b61e674 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

I've been putting together = some examples based on the idevent-token-03 draft. You can find them here:<= /div>


There are three examples of an idp-= to-rp SET - consent, token revocation, and userinfo update.

<= /div>
There are two examples of an rp-to-idp SET - parallel authenticat= ion and suspected fraud.

This format seems workabl= e for our use cases. Note that none of these include or require "sub&q= uot; at the top level.

Sarah

Sarah Squire
Engage Identity
--001a113b0220bb3ca9053b61e674-- From nobody Wed Aug 31 11:11:01 2016 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 E8C5F12D62A for ; Wed, 31 Aug 2016 11:10:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.548, 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 Etbl9WwlrZQt for ; Wed, 31 Aug 2016 11:10: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 3B97812D5FB for ; Wed, 31 Aug 2016 11:10:45 -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 u7VIAib5021999 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 31 Aug 2016 18:10:44 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u7VIAidJ010098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 31 Aug 2016 18:10:44 GMT Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u7VIAcBU015634 for ; Wed, 31 Aug 2016 18:10:43 GMT Received: from [10.0.1.5] (/24.86.208.48) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 31 Aug 2016 11:10:38 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_CB82BCF4-FA95-4157-9712-E31E2325CDDB" Message-Id: <2CD2401D-4FBD-4F39-8722-AB8D8333D856@oracle.com> Date: Wed, 31 Aug 2016 11:10:37 -0700 To: id-event@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Subject: [Id-event] Use of "exp" - recommend SHOULD NOT be used X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 31 Aug 2016 18:10:52 -0000 --Apple-Mail=_CB82BCF4-FA95-4157-9712-E31E2325CDDB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I had an offline email discussion with Mike Jones about =E2=80=9Cexp=E2=80= =9D. I thought I should share with the broader group. We discussed if =E2=80=9Cexp=E2=80=9D should have any meaning in a SET. = When you look at access tokens there are 3 things it is being used for: 1. Validation: is the token valid (not valid after exp) 2. Sessions: the token is not valid when the assertion expires A SET however is a statement of a fact at a point in time. =E2=80=9CToken= WAS revoked=E2=80=9D. One could say it is permanent and cannot expire = since the fact will not change. While we may not want to rule =E2=80=9Cex= p" out, it does feel like the use of it should be avoided. Any opinions here? Phil @independentid www.independentid.com = phil.hunt@oracle.com = --Apple-Mail=_CB82BCF4-FA95-4157-9712-E31E2325CDDB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I had an offline email discussion with Mike Jones about = =E2=80=9Cexp=E2=80=9D. I thought I should share with the broader = group.

We discussed = if =E2=80=9Cexp=E2=80=9D should have any meaning in a SET.  When = you look at access tokens there are 3 things it is being used = for:

1. = Validation: is the token valid (not valid after exp)
2. Sessions:  the token is not valid when the assertion = expires

A SET = however is a statement of a fact at a point in time.  =E2=80=9CToken = WAS revoked=E2=80=9D. One could say it is permanent and cannot expire = since the fact will not change.  While we may not want to rule = =E2=80=9Cexp" out, it does feel like the use of it should be = avoided.

Any = opinions here?




= --Apple-Mail=_CB82BCF4-FA95-4157-9712-E31E2325CDDB-- From nobody Wed Aug 31 11:20:30 2016 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 5B6F812D65F for ; Wed, 31 Aug 2016 11:20:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.548, 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 tK1fBzCRQAsH for ; Wed, 31 Aug 2016 11:20: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 9742912D645 for ; Wed, 31 Aug 2016 11:20:27 -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 u7VIKQO7023837 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 31 Aug 2016 18:20:26 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u7VIKQnj030299 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 31 Aug 2016 18:20:26 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u7VIKKF1020341 for ; Wed, 31 Aug 2016 18:20:25 GMT Received: from [10.0.1.5] (/24.86.208.48) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 31 Aug 2016 11:20:20 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_17C26285-F717-4098-9D3E-5F6D9A26EDAF" Message-Id: Date: Wed, 31 Aug 2016 11:20:19 -0700 To: id-event@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Subject: [Id-event] Editorial discussion: Attributes or Claims X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 31 Aug 2016 18:20:29 -0000 --Apple-Mail=_17C26285-F717-4098-9D3E-5F6D9A26EDAF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 For the next draft, I realized that draft 03 uses a mix of the terms = =E2=80=9Cattribute=E2=80=9D and =E2=80=9Cclaims=E2=80=9D. In part this = occured because the draft originally came out of SCIM and then we = switched to using JWTs. While the terms are used synonymously, it would probably be less = confusing to readers to use one term or the other and to properly define = its use. My feeling is that =E2=80=9Cattribute=E2=80=9D fits better as = we are saying a SET is a statement of fact from the perspective of the = issuer. The statement about attributes that are not in dispute (x was = changed). This is very different from an access token or an = authentication assertion where there is a degree of confidence in the = value. For draft 04, I have revised the draft to consistently use = =E2=80=9Cattributes=E2=80=9D while providing an explanation/definition. =20= I wanted to call your attention to this in advance and hopefully get = some discussion. I would like to make clear that we can switch to = =E2=80=9Cclaims=E2=80=9D if people feel strongly that consistency with = 7519 provided we can all agree to redefine the term =E2=80=9Cclaim=E2=80=9D= as being factual in a SET. I can see how people will view simplicity = and consistency in different ways here. In the end, I do not want to spend to much time on this as it doesn=E2=80=99= t change SETs normatively. This is just editorial cleanliness and we = should avoid too much bike shedding here. Phil @independentid www.independentid.com = phil.hunt@oracle.com = --Apple-Mail=_17C26285-F717-4098-9D3E-5F6D9A26EDAF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 For the next draft, I realized that draft 03 uses a mix of = the terms =E2=80=9Cattribute=E2=80=9D and =E2=80=9Cclaims=E2=80=9D. =  In part this occured because the draft originally came out of SCIM = and then we switched to using JWTs.

While the terms are used synonymously, = it would probably be less confusing to readers to use one term or the = other and to properly define its use. My feeling is that =E2=80=9Cattribut= e=E2=80=9D fits better as we are saying a SET is a statement of fact = from the perspective of the issuer.  The statement about attributes = that are not in dispute (x was changed).  This is very different = from an access token or an authentication assertion where there is a = degree of confidence in the value.

For draft 04, I have revised the draft = to consistently use =E2=80=9Cattributes=E2=80=9D while providing an = explanation/definition.  

I wanted to call your attention to this = in advance and hopefully get some discussion.  I would like to make = clear that we can switch to =E2=80=9Cclaims=E2=80=9D if people feel = strongly that consistency with 7519 provided we can all agree to = redefine the term =E2=80=9Cclaim=E2=80=9D as being factual in a SET. =  I can see how people will view simplicity and consistency in = different ways here.

In the end, I do not want to spend to much time on this as it = doesn=E2=80=99t change SETs normatively. This is just editorial = cleanliness and we should avoid too much bike shedding here.




= --Apple-Mail=_17C26285-F717-4098-9D3E-5F6D9A26EDAF-- From nobody Wed Aug 31 11:29:45 2016 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 F0B9912D67C for ; Wed, 31 Aug 2016 11:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.548, 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 J5igbRfsJ-Ew for ; Wed, 31 Aug 2016 11:29:39 -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 5715112D677 for ; Wed, 31 Aug 2016 11:29:38 -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 u7VITahD002987 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 31 Aug 2016 18:29:37 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u7VITaQf029837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 31 Aug 2016 18:29:36 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u7VITZw4015722; Wed, 31 Aug 2016 18:29:35 GMT Received: from [10.0.1.5] (/24.86.208.48) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 31 Aug 2016 11:29:35 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_60D51A91-A9BA-485F-BAF2-C918CBB77157" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Phil Hunt In-Reply-To: Date: Wed, 31 Aug 2016 11:29:34 -0700 Message-Id: References: To: Sarah Squire X-Mailer: Apple Mail (2.3124) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: id-event@ietf.org Subject: Re: [Id-event] SET examples for a healthcare context X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 31 Aug 2016 18:29:43 -0000 --Apple-Mail=_60D51A91-A9BA-485F-BAF2-C918CBB77157 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Sarah, Your examples highlight some issues around =E2=80=9Csub=E2=80=9D that = are still in a flux. For draft 04, the emerging consensus seems to be to = use =E2=80=9Csub=E2=80=9D to be used at the top level as it is already = defined as a JWT claim. Yet for some systems, the problem is that = =E2=80=9Csub=E2=80=9D is not a URI and without an =E2=80=9Ciss=E2=80=9D = is incomplete. This becomes problematic then if =E2=80=9Ciss=E2=80=9D = of the event is not the =E2=80=9Ciss=E2=80=9D of the =E2=80=9Csub=E2=80=9D= . Your examples actually show this - for example heart-parallel-auth.json For now, I=E2=80=99m just taking the editorial position that =E2=80=9Csub=E2= =80=9D in the envelope or =E2=80=9Csub=E2=80=9D in the payload is up to = the profiling specification to decide. That gives me some worry about = inconsistency between specs, but I think it may not be that big a deal = in practice since people will tend to worry about one family of events = at a time in the context of a single subscriber. Phil @independentid www.independentid.com = phil.hunt@oracle.com = > On Aug 31, 2016, at 11:02 AM, Sarah Squire = wrote: >=20 > Hi all, >=20 > I've been putting together some examples based on the idevent-token-03 = draft. You can find them here: >=20 > https://github.com/id-event/examples = >=20 > There are three examples of an idp-to-rp SET - consent, token = revocation, and userinfo update. >=20 > There are two examples of an rp-to-idp SET - parallel authentication = and suspected fraud. >=20 > This format seems workable for our use cases. Note that none of these = include or require "sub" at the top level. >=20 > Sarah >=20 > Sarah Squire > Engage Identity > http://engageidentity.com = ______________________________________________= _ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event --Apple-Mail=_60D51A91-A9BA-485F-BAF2-C918CBB77157 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Sarah,

Your= examples highlight some issues around =E2=80=9Csub=E2=80=9D that are = still in a flux. For draft 04, the emerging consensus seems to be to use = =E2=80=9Csub=E2=80=9D to be used at the top level as it is already = defined as a JWT claim.  Yet for some systems, the problem is that = =E2=80=9Csub=E2=80=9D is not a URI and without an =E2=80=9Ciss=E2=80=9D = is incomplete.  This becomes problematic then if =E2=80=9Ciss=E2=80=9D= of the event is not the =E2=80=9Ciss=E2=80=9D of the = =E2=80=9Csub=E2=80=9D.

Your examples actually show this - for example = heart-parallel-auth.json

For now, I=E2=80=99m just taking the editorial position that = =E2=80=9Csub=E2=80=9D in the envelope or =E2=80=9Csub=E2=80=9D in the = payload is up to the profiling specification to decide.  That gives = me some worry about inconsistency between specs, but I think it may not = be that big a deal in practice since people will tend to worry about one = family of events at a time in the context of a single = subscriber.




On Aug 31, 2016, at 11:02 AM, Sarah Squire <sarah@engageidentity.com> wrote:

Hi all,

I've been putting together some examples based on the = idevent-token-03 draft. You can find them here:

https://github.com/id-event/examples

There are three examples of an idp-to-rp SET - consent, token = revocation, and userinfo update.

There are two examples of an rp-to-idp = SET - parallel authentication and suspected fraud.

This format seems = workable for our use cases. Note that none of these include or require = "sub" at the top level.

Sarah

Sarah Squire
Engage Identity
http://engageidentity.com
_______________________________________________
Id-event = mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event

= --Apple-Mail=_60D51A91-A9BA-485F-BAF2-C918CBB77157-- From nobody Wed Aug 31 12:27:02 2016 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 DD31312D6B3 for ; Wed, 31 Aug 2016 12:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_NEUTRAL=0.779] autolearn=no 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 OR3Cv7zgleOk for ; Wed, 31 Aug 2016 12:26:59 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0111.outbound.protection.outlook.com [104.47.38.111]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8526612D095 for ; Wed, 31 Aug 2016 12:26:59 -0700 (PDT) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=nroy@internet2.edu; Received: from i2-denv-103.internet2.edu (2001:468:1f0c:1:d52f:fb7:225a:c22a) by SN2PR0801MB557.namprd08.prod.outlook.com (10.160.15.147) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.549.15; Wed, 31 Aug 2016 19:26:56 +0000 To: References: <2CD2401D-4FBD-4F39-8722-AB8D8333D856@oracle.com> From: Nick Roy Message-ID: Date: Wed, 31 Aug 2016 13:26:59 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <2CD2401D-4FBD-4F39-8722-AB8D8333D856@oracle.com> Content-Type: multipart/alternative; boundary="------------EBFF0ED106B0EDD9B739486C" X-Originating-IP: [2001:468:1f0c:1:d52f:fb7:225a:c22a] X-ClientProxiedBy: DM5PR20CA0020.namprd20.prod.outlook.com (10.173.136.158) To SN2PR0801MB557.namprd08.prod.outlook.com (10.160.15.147) X-MS-Office365-Filtering-Correlation-Id: 70d23953-9676-4029-9e51-08d3d1d4c5d4 X-Microsoft-Exchange-Diagnostics: 1; SN2PR0801MB557; 2:kwFAgw5aaIQTVOANviv0GEnIq2Pgq4qWOwIVIL7ngZVNWg/LBalVbzxePEg3IlN2+LZvJiqWW6Xh5/Hdh1YNqTdtdPbikfywtuLv00OYumbBzmt1GpxWZwSiMr5frlo808lfn4WLskEykdx5ctJLr63mBaN3aho1iyivP+5JMdVbPOa6t2TZqG1yg7JJvbhq; 3:HYq7jWYepgV9GogO3mBW/m1NkhtXTDdtLGF9VY6EJGhokxnfi+FWkSrzCltePHyF2p61hbe9mzdh6eF9TNpN2VNTap5vkG2njl4GJjQKWPJ/dghprcNGgZtFaeQgEAZd; 25:2NQpuL3oa/QnmGUoD2/GXU6BfiieSaGvCHJnvSnYXBS3kLRLcAMS2UftzNQt9x3b+66emQjFr89wrARLuSb6ps4vZILjCxjgh45OEo5ZjjkqhOWQt+GOezRCQtsinJgovQRwQhngLKCvYvys3dGMCmS5T4h9YfrvGe59fTPWx8NkQ9qzYMee49IewYfxcsl12UBmy1Ku69QcXUunJSSIPUBVmfdXXE7EAvDKwJnMvYtzbtBNxwAsvq+yjuCUsh/Zzcmzuq6UzbZ75FgPiW7Daull6b+QaRW5nPr3pdjY95OM9AVKtvwePCe89XRi6VDcfz/woMlRTNGHxHwV9g28qRcD05ucWMahBzwZFh6oMElRaC2XayQzXFK90oInhvg2dlJty7l09zRNEUYOX0pNJfyJiDGmPc4qG1b0+tsqab0= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN2PR0801MB557; X-Microsoft-Exchange-Diagnostics: 1; SN2PR0801MB557; 31:H879dmRj7p4DctAdReQUZSKKk0WPKj86rOcBn/yemcejfkBKNaLv6zEQHiyzUcpRrG98udoqL5TlUMtApnHRCO8xYOpVPmxEEcBBIQAHATYw7wu05EWgfLJWjRc5N6Ur+5ftQRwqOyxZD50FA4jGh62IZUJO+vtage9iRU1+VQ1F/Q0rpq77LMHuqWx1tUFgFFa5Lf9Qxg1rC3FsRq2xmArjQop010Or6cemU+soPDQ=; 20:4pyqzbSBqrmgWqH5e4UNxDchZrFsf1Cjj5NJYYRQIq2nUNkv/kYXsSVm1oUYYQqcM4n1k0E8YdMou+sYR6cfE7EikbcGF9RDWEQwNuykAFwMZ3FqEmm3ekeQIc26RBY7AVXGOkj/8S8vQeUzKhBd3ekeJgQEyZe1MEFG/Rs9R6U=; 4:547pxFj4d0iP9C4+3UsI8U0SGC8LzptsPBWJPHA4HkTaJ2AKhOEOFazOqK2BAQ/ANV6PmhF7fnivgPYilY9WC1tiSNTWc9HqS/6HqM3xeOd4XiG1SR0EKcbP0iJfjt8s3jW7SFLSH2VpWsk0qz0J8r75l9d0H7S5qoQ7aJ2QQwnosPkdAB9rq1TCixHgDV/wrKjl93UmNibzF98XIL0uDlvgOgmc+eYHPB5nghnrO0xtzutuTQnbHYDjxSbHxpMHIt6ukwpLlv35Da8I62CBikKLn2b+krkzQoZePWeSJo++Xg7pAvoyojF7v+vUDPq1JvJmNsGOCnHpnWeSRus4ZSZsyLL/wBiTt21st15ignLXNC+KqOfXjgKLWSLtK/mTUGq76W/vEWs5bOVQX2sbHyD/3P2yF/WThQCidFTn/1SrFII4oIqbbu8vB+fjers6 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(146099531331640); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:SN2PR0801MB557; BCL:0; PCL:0; RULEID:; SRVR:SN2PR0801MB557; X-Forefront-PRVS: 00514A2FE6 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(7916002)(189002)(377454003)(24454002)(199003)(84326002)(36756003)(83506001)(68736007)(65956001)(65806001)(2906002)(31696002)(64126003)(6116002)(8676002)(88552002)(81156014)(81166006)(586003)(86362001)(97736004)(90282001)(106356001)(2950100001)(512944002)(4001350100001)(107886002)(110136002)(16236675004)(5660300001)(65826007)(189998001)(77096005)(33646002)(89122001)(19617315012)(7736002)(7906003)(101416001)(53416004)(50986999)(69596002)(15975445007)(76176999)(7846002)(19580405001)(31686004)(54356999)(92566002)(16601075003)(450100001)(105586002)(2351001)(42186005)(75432002)(19580395003)(15974865002)(3826002)(217873001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR0801MB557; H:i2-denv-103.internet2.edu; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: internet2.edu does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN2PR0801MB557; 23:wyOzVXqWYavfTWK7Sasb7VmiQJAaG+IIE5AA9erD?= =?us-ascii?Q?nHRrVIP0UnBm2pogTJ0YYSnyO7K5lSOV6eIuTYsYDf0gii4uDgh1/rsr7X7k?= =?us-ascii?Q?LVL6yabPvGbwQAv1iBS0GS6rWQjFpqY9YO46XsB7jIRak3UjeS8Pbhsg1OMR?= =?us-ascii?Q?SxX5no3V7y7j97ZcPQ/+xp2dk5UA/eJhfkTDEg4gbiZkoTUUJ6y2Fj1AFe34?= =?us-ascii?Q?r5oVqEhjGBKBsO7Uh6DzR4NK0ClAW/1v3XLt3FLI0PmRz5bXazk8x5GDvPfu?= =?us-ascii?Q?kzijjFYMpCNHWdJu0uz+VoJ/2qSYmK3n6SHMdjhcPkgZiMS8vrds0y20sqf6?= =?us-ascii?Q?wYu3sYgyniyRF4JUf5LscRKZ/2HzwMHzQR7ehvRoRgzNFXykxGQvQuAfsbPs?= =?us-ascii?Q?R+t7MFnEbGGeAwLwxZT/84lVJAT808/zWJhw8jTGDkLyPhscBaT4vFesWf7i?= =?us-ascii?Q?AEH6G6+4laee831wgNhLI1k3mwNpk1pLwZNu+Nlg29yZX4FryvvlUSpRvJhn?= =?us-ascii?Q?VTRL0HOiu1DYKDKNjg1AXzt7UWJ/k4rO66djo5o+LBq383jYPAuDzGu1KhEd?= =?us-ascii?Q?QUx4/1HgtPNY1ENhoRg0flAm40z/2QerYG8gz6oAJdZZIW79aOS52MNt/PDg?= =?us-ascii?Q?5US0t1KpAaokb0yIEzY5tfyQF2UtWs5qA5D9a4g4JVAw/I+Kipw4rn36l0En?= =?us-ascii?Q?5AWko5RcdNm2FGT8u5STXupFjTYJa3IYc4nHnd7u3dGDve4cm7Ml6vQR/YHS?= =?us-ascii?Q?E4jVnJgriUVW3DsW505x8DfpXX6CSZV7yqj9odZfQ/OGkE8LRDpS2XslPJt2?= =?us-ascii?Q?VnKApXbAacNCtXDoytXIzTO0hVq0QhYmytQJubBFSxl8HySOoampnYMjNjPS?= =?us-ascii?Q?rlwV48Ksbiv51Vt7ReKxdSEbi2WeOVL4j4AddL9lsMKTy27iDbP+7sZFgYlI?= =?us-ascii?Q?9Pr8cS94w5pmueHNehwg4MZYgf3MNEPDadtgRusr/4k7sQsQw8McrmL+H+P6?= =?us-ascii?Q?ymPnkhJXfbUQx7VUWDYRDX6veRqpSKXkbqyJnBUtWFR/SFd46bwVH25fOAk/?= =?us-ascii?Q?ENfTDlw9UcAyY9JRWNNgarSLHJwwk4XjXiZf0k1ZIbPFj7I6SMe6BHRj/Jn+?= =?us-ascii?Q?QlqlNaZS0EaLhbJAmmPG74vCpW80XMVf+9H0JiqX4hpzwAgBtw9i0BBUoHSY?= =?us-ascii?Q?PWJy7ch2KUT+ZeJTGedDtKwTXA2U3jvX9rrowDQ3kc1tOXnC5SiXYe8yUD7Z?= =?us-ascii?Q?pVJeydxU0GhObJhQ3iniRBi7Yc4fQU089XH70WrsvjHmeJ1QbpskDBKPnwmM?= =?us-ascii?Q?azvj15p7tfdEAfcz9dyPD/W9Tl7ir3VRcrFXoV77Pdl3x+Q8CDnBV9YecEiL?= =?us-ascii?Q?atLhRVUnpRyd/i6NzdKH2zxAuYExuxJ7YGCVdC6TYW5KJsKF8ENgnbLp0qgB?= =?us-ascii?Q?hVRdbbEBQM3k4oXnWGHR1iUPKwL0yUfNLJNZYNqW6dQol/MdsR1pLbVU7B3h?= =?us-ascii?Q?aO/Bf2uB8F8aR/dJtmE83tiAwQzoqX8FGWY=3D?= X-Microsoft-Exchange-Diagnostics: 1; SN2PR0801MB557; 6:PC/zGzsJjhy0xrkNrsZFS9CB9d2ybBTjwoPuQaTApRWWQwMF2odGDrpuwttWwNS4cVK/C/R1jr8AnUrLJ1hnMdMuetyS+8ZeMTBE9CLpkiCv73NCCkwpozrlroDgx5f0R34VOME3PcaWQnDYeAj6G16bxzMGOxNU/1TFPNOPwsCac53pNEv9y6LK6JI4PM/9w+vwsWk0zeJdVEkaLbMUBghaUfn238Y3lLeZ0hHDigoO5ciqfv1GddiRH5EOrgmFrb8qCPHfyBL/IPXKKE3vFA3daWge3/ybn/688IOBPMQ=; 5:oneeUAKFzJD7//CciHv6s+Q2+Z6fcSnt8UeS5nXysEmR3768yk3OtGZjHR6BOWyzMHLlvtgO+O1eozkV7dpuLsLUbaod0wJDMZV23Pih3IFjVzhsTizEp0eF3/UADFOyGEhHfXxr+ISKEGateLbmMQ==; 24:n2hz4rW0sWksFpyHyXdemOJanETFWjUzdKOfdZwabSmx1ZkvB86M7ha2W6uAGJPVJu2aX0MLEQYfzrceoNYlU4XqyyjyPDcbH/bNOSMi1ag=; 7:7sZSuejFawVcRtxvDYJRYO9J71wCh7xKjfI7mu63AQPva3VNrsotOOXMkhPNbZfXz5ZPc/olbtE2nlh4nOOj9rYEa6ufchMRE9L9Qfe2R3ok7HFRfIsIo70U3V7Qk5E5MsVXySmLA8v1JANXNsmeHPC1dISJcGvdxWnKk9rLtSsTE+CdvqAgdqRCHRa3U2QSQZvRtvOSZjrI0Qgn5NpqiwuoFF4nlUTE2CSzAcdmp6USUQSZADhFsBYoD21dPnKJ SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: internet2.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Aug 2016 19:26:56.9347 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR0801MB557 Archived-At: Subject: Re: [Id-event] Use of "exp" - recommend SHOULD NOT be used X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 31 Aug 2016 19:27:02 -0000 --------------EBFF0ED106B0EDD9B739486C Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit +1 to your assessment of the situation Nick On 8/31/16 12:10 PM, Phil Hunt wrote: > I had an offline email discussion with Mike Jones about “exp”. I > thought I should share with the broader group. > > We discussed if “exp” should have any meaning in a SET. When you look > at access tokens there are 3 things it is being used for: > > 1. Validation: is the token valid (not valid after exp) > 2. Sessions: the token is not valid when the assertion expires > > A SET however is a statement of a fact at a point in time. “Token WAS > revoked”. One could say it is permanent and cannot expire since the > fact will not change. While we may not want to rule “exp" out, it > does feel like the use of it should be avoided. > > Any opinions here? > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event --------------EBFF0ED106B0EDD9B739486C Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit +1 to your assessment of the situation

Nick

On 8/31/16 12:10 PM, Phil Hunt wrote:
I had an offline email discussion with Mike Jones about “exp”. I thought I should share with the broader group.

We discussed if “exp” should have any meaning in a SET.  When you look at access tokens there are 3 things it is being used for:

1. Validation: is the token valid (not valid after exp)
2. Sessions:  the token is not valid when the assertion expires

A SET however is a statement of a fact at a point in time.  “Token WAS revoked”. One could say it is permanent and cannot expire since the fact will not change.  While we may not want to rule “exp" out, it does feel like the use of it should be avoided.

Any opinions here?



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

--------------EBFF0ED106B0EDD9B739486C-- From nobody Wed Aug 31 12:28:17 2016 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 EA81F12D75C for ; Wed, 31 Aug 2016 12:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_NEUTRAL=0.779] autolearn=no 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 6J4jmv7mPd7W for ; Wed, 31 Aug 2016 12:28:14 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0093.outbound.protection.outlook.com [104.47.32.93]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6487012D753 for ; Wed, 31 Aug 2016 12:28:14 -0700 (PDT) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=nroy@internet2.edu; Received: from i2-denv-103.internet2.edu (2001:468:1f0c:1:d52f:fb7:225a:c22a) by SN2PR0801MB558.namprd08.prod.outlook.com (10.160.15.148) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.549.15; Wed, 31 Aug 2016 19:28:11 +0000 To: References: From: Nick Roy Message-ID: Date: Wed, 31 Aug 2016 13:28:14 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------51F509566AF9615DD3A89837" X-Originating-IP: [2001:468:1f0c:1:d52f:fb7:225a:c22a] X-ClientProxiedBy: DM5PR20CA0012.namprd20.prod.outlook.com (10.173.136.150) To SN2PR0801MB558.namprd08.prod.outlook.com (10.160.15.148) X-MS-Office365-Filtering-Correlation-Id: 94bd0e0b-98e1-4ea8-be40-08d3d1d4f280 X-Microsoft-Exchange-Diagnostics: 1; SN2PR0801MB558; 2:2wYLLDeUu/Sh661uasHtle/R3nmSdiHvwZjbAL640T/dq1eccLY8k57JkuNF32Md4VFf0MEyIS6yYArXCTR2fKS4VbWo+amL8u44QJjT//gv/XJesk5zcZ0rml2QCSCshaxifYlFoBdsGL5heL8bqYMpDkGFZb2ECIVNva400wriPM3qMua6ftgS41FZG+tk; 3:f8XPMTHEcf7RRSUApfdQcgDy/TjyHjGwctG9O3fj2Axm/y1v022ZcJGKwGrxaw5e4G7cXTZz0oNB93avLZcD6z5jlM6leSH14oiLsSeWnXMQiyVCER92QLdH/CI4d/WY X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN2PR0801MB558; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN2PR0801MB558; 25:XAOkJQ6571EInNNVK08d4VK5LWabwcwarMPKy+BF?= =?us-ascii?Q?ej0jShWHA96A0aNOlKPsIxSMzZAAoRoeub2/hce3J1UIDe+VYRyZWzFxhaH5?= =?us-ascii?Q?VRdl8K45W1cuL6DfTQ/J13/ko/c/2fBdLGtWfO3IKCGhg9UeWSqNZVKMa2k/?= =?us-ascii?Q?/JLx6Hgdu0gy7rHbvxm6Ijlv9qc+EN3IYTc9p5gg2ZVw8VceW6CEXcRc5btL?= =?us-ascii?Q?nlBpSYktkyawKcJtD4hOyEhL3qa+31NoqoeT2aFkTIeQBoknW2BgBhn4skr2?= =?us-ascii?Q?mo0Jiw6KeeY6i7loFLfvTJmQ666hCvC8LI5gNMap0A3CgaUyuFEN3B4yBJUd?= =?us-ascii?Q?+EGOPsYV1D8oEMu55PE+tQV0xLMocxutBtCX9EYH22SeR+lykQOQONVVAS6d?= =?us-ascii?Q?69L7+d0T8Ar9blTf8eStr8xtm8unIYpN0/iJziqEePRgSxv+qvn+ORoB11yw?= =?us-ascii?Q?VDncNYQxFLH/fDkGmwz7wBLEzzGBhtXOdjrOwbjUY6EO8XTItla4w09WF1Zf?= =?us-ascii?Q?EdvTJ4OSq/NWcyVZZy1NAPSZcsIeSmV/ue2zIiVWQr6BKswJLxaDLnAa6vNA?= =?us-ascii?Q?pHUVlcBeov0f4IUeQ+O1ckf9Lqlh1FF7UMTD/Ayt3uf8pAgUeGZNYHJj0tfc?= =?us-ascii?Q?iSlFYTSs688rgk9w3z63b6VQapNptzR/cf7msMFDra4w86DEEGSyCDKqErHW?= =?us-ascii?Q?dE7MYeHyPilNm7xZUW66SXCxXn7czz+RarAJKtcEFxCUmpxkH94wlAFubTrw?= =?us-ascii?Q?07zAucccGSCOlzFt6eLy2G6D9+jw0UBG3LkKTva22LoxOl49mZUt30r3h8UV?= =?us-ascii?Q?aW9puyTUR7GH6DdCgc7wXcOvH77Ias5PeGW4mA8Jn7Fx/zv5QXrcpvFMKRKc?= =?us-ascii?Q?RSChBY5bT7zb/2FHzGCh9Kp12/TXRWq8QvjP6ku810A4wBkiyjY6DJyWXSsb?= =?us-ascii?Q?xzTQsmBOc55t8/gjJlXkEUFfrANTP1Wk0zYsJoo7g/VLEfM+fN0raMQGVBU6?= =?us-ascii?Q?ShP9LjR3YdfALe8eILwr4BhhGCIf4ocEx/3GOIIkhU3iXw=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; SN2PR0801MB558; 31:A/VqWx7Bgj8tSjvgyfLoIRSMqxyryriVtSFgQAYhsMpYNOi4BiQoJxEfi1ojlTk7HcmhlEJYtxOb+3Zpc6AKPTmbp8EHEWFFH0qZ1jl540Mq511cyxWe2tWCRIvphfanaH3mG/X+Iy0uBfqPo6LW89hvrtr5cwenZEh7IMyDB2r/bOsFUipYg46nSylByEUt4/Snqq/s2fiWhHzRp1MlrradIEr3et1/ap5T3fXgU8g=; 20:TQnkGyPbdVeOVKJ56oNxFI3IMTRd7IjNSlECdv8ZUitUPIVD7yvqcXDFeyDqSYQq2pzKiSQoz3qqVjZykwLxi0o1AE5xIh5dQtpWJRkf8cu4H6B2N2LAF60I47eNTocHmvPXvrzgLYnCy3A9yECawiWXsWflLi7N7CFOYtjTEOY=; 4:n+HogUAvq+vQlwrQLuqhaAPdjFvTz0VtM368ldzO7QPHqWV9j8YvjrfzFjWljYtxhoDPcq8xMoAgdhmqEOI/Jh9BUmW+xlO8FL2r5covsRyFrYLFShhw7SJ7BWi7d65ey7kzozYxLjr9/YWgRFbJNw1WfP1S/SrfVuptsFGdrTfF6xPbRibCJkUDbDrQW5GnryLNM5yct/HoADvY6DjuAU4aVyxv+StPJgaxB+k4X1RXL8vb39DsjKN2i6zndkGtdADyGrvFAgQYZeM92Ve/bvPIDHAEse37ZIlh4WGmmrUYwCsmF1StDLNV4cprt4kwh8rucd1k7M6fRcvIsHXFYakezyoWNOeXh3RJ7XVBZkvsT1ONLHF+5h3f6mShi28y/hm5ucLF04JP5BunS2QSG+l466/kRr31AC1NFWUsw+Ev5yt4aOqjzD5RX0h70i6w X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(146099531331640); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:SN2PR0801MB558; BCL:0; PCL:0; RULEID:; SRVR:SN2PR0801MB558; X-Forefront-PRVS: 00514A2FE6 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(7916002)(377454003)(24454002)(199003)(189002)(75432002)(105586002)(42186005)(77096005)(512944002)(110136002)(2950100001)(107886002)(189998001)(450100001)(89122001)(15975445007)(16236675004)(4001350100001)(97736004)(90282001)(65806001)(68736007)(31686004)(15974865002)(16601075003)(19617315012)(106356001)(86362001)(50986999)(8676002)(101416001)(65956001)(92566002)(36756003)(33646002)(31696002)(2906002)(81166006)(65826007)(76176999)(2351001)(6116002)(7736002)(69596002)(19580395003)(84326002)(5660300001)(54356999)(53416004)(586003)(19580405001)(64126003)(7846002)(7906003)(88552002)(83506001)(81156014)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR0801MB558; H:i2-denv-103.internet2.edu; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: internet2.edu does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN2PR0801MB558; 23:ycPLFVoFQxaFNzgfDqZ5OQmpFwAICWx9llQKIfww?= =?us-ascii?Q?C8zF7hC6CKddjEiCrP6aOPf5fpBcPXq/PxZpkIRZEctGJxiuVdnE1Dfgv13O?= =?us-ascii?Q?KjP0Sr5sfJI2GdrHYN0jA7Ke8VrEOpQ2Zvp4fe55H6prJSXTuBRM+zT2Ei8s?= =?us-ascii?Q?t+qbisyNd+bMhBnkOYXySkjA2i4Y8+FVoFKzlDofwPLcBOlza0P3/Sr0mdwh?= =?us-ascii?Q?fm1HhgpWjYyW23tt5Sd7riQBadgse+99tyesIf3NyTzu9PCf879P0YwQ6AFs?= =?us-ascii?Q?FiblVqfCbXtr8Xq6gUbBwP1lw31Kggn7nzLgsYWZRc6DiDzbDvU5c9ORaYew?= =?us-ascii?Q?U6mEFaKjQeHQw0YNBnRoDEwW+wbfCR6DKqZc87K4zWvaf6oIXmZ/ZVFGt+Yx?= =?us-ascii?Q?sv7xju7Ou0xKqteeHyhKlh00wm7oGdeH4FrbIFW6LLmwXFqGq5X9B0GQ4omG?= =?us-ascii?Q?gAe73XD2Y7H9ioUREvLaM8BuI7lH9PPVgV/e74UOX6MTrBs18obOdyJ5oXgS?= =?us-ascii?Q?uRstTDXsSx2Er4q5BBYqi0U0u2pnNDTNNBVbu6C37NCVPVyP4+pTrhLMU7P0?= =?us-ascii?Q?roJqvs8W94yWO7vFPxucjcm2Lj3pInwjepg4TJP37t4sOpShZlKpS6sPfs49?= =?us-ascii?Q?A7BXBJ9NqHGCfkJxOHa6NQ9f98x4BsFy22ETd1RRYBnU6yuJ3aXto3UxSlW8?= =?us-ascii?Q?tAS9LwYrsdJrWbH1rN/C911dzd45fP93mcW4BtzYzYw6boZVzM1FZV9KRBVg?= =?us-ascii?Q?SRuxjskIdrWIECEH2htmLceYJW0aVch3z77iaHaWPgI14a5TgmHm3SQWWY3T?= =?us-ascii?Q?7tvy/VJ0rpQGfrrkSlBcag1MCgxoaIxms+wPhNe7qak/cimaZeQIkHec1H5s?= =?us-ascii?Q?2ya4YqmgEpPcnyXqUwK6P88ncpCnr8iIRROCEY1SrytrUXCHUaUFAfa5yV/k?= =?us-ascii?Q?jE9JAtZL6JMHPB9YM6kRzuXCiJZQwcytXlfoKWHxsyhd0P2YAp5EpL9XiHK1?= =?us-ascii?Q?x/lIOGbquFXoMcTXCvql6uXe4qMEHpmWjtbS62tbOnq4V40xKVMrA95CCfOw?= =?us-ascii?Q?9tTd8yB0sWitA0TjV29bftUMTF4+3kW4KArxFmHZq/CJRu0cRzYeBcOlU1VI?= =?us-ascii?Q?jYa4FwczPWZ1dvr7GUisYdk4Iuiyr8aU53qDE7bzDPLjqFFUEYMpIpYiWCoH?= =?us-ascii?Q?YcsPG6h5F/rPtbozyqHYN3dWBofh8la2JxVJkJuc9FXBz9qPlR01F/rOgSnf?= =?us-ascii?Q?K0dXwMNSbveiOrtYBPNsUo/j+4Ftxk8uKfwfOTWxtjXdu2YUhmFiiV4dri57?= =?us-ascii?Q?IT7pvEo8X93hteNyte96EJuZVsmGeSkC1extmhX0LSexQoYPga+jGV56IBob?= =?us-ascii?Q?KPIJFr/NYJW9Bf/LU1vxBKim7oIz7qCakwE3lyjzIx9BisxMYJwJBVeynv/l?= =?us-ascii?Q?I9fDO6gY3en6SjTnYW+wBKMUrL6K76LqIqwRUWHyJMHHXceWY6UxPLfzWl+m?= =?us-ascii?Q?U0I1X0XoRJD+gg=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; SN2PR0801MB558; 6:kSEt8lqmT586cRaPN+lBR79DhMSCbqxaYKULreuSd+ZzDFFgnynfLAHfEhciBRgixINTjotvk6mXo5F+I9uO9VmwBzM8h03LTglB4kUyzi1g8WQJPNSp5qHr/Ivkc1J+0UKAr0DYrXZ0Q5W+lG3QM9jttjVKa9HPy1Ahup6bUIKQ1r2kIH+Jew0ge27lBEBbX17eTq24pUjD5erCUQJqdLPUsbC3XBPR19vBize2TXf9FrvlyX9JTBdLdkKqo+29TtBNgfbLBginkzlgDrYq05gTvKPExSGfH+TUi3hDKZ0=; 5:VR7OBEjJkii1ifwbATtNQMd1IgEfXxpUZyhe40BvZ9vbajqA6QQ19TWeoLsrNyHbR+nPj6j3ilbE5wzd1RjDmmEC12S2A8Qbsz0NqiIWnLobpbrHX/wSXgslawFfyrrh9l2SvHVOxTpBJNM+WtPFfQ==; 24:2ZJQ84o6tdlDqN1SOMfc8o/+70cpvwt3/i+Kgg6dDo736/LpjoFLK0mtGTskRKTMiFB8LY3pe1uxmhYQWaGhwUbJGQeVF5f7PoqBRzKbe24=; 7:ZI/OtGSDS4sA6L3Lh/lddie027y+m8P1RluC35GV3tqUAROcfXgAb2iF+t3topSIGIUwCsej7EkrPhV5NV7ycJ4Re0Ch0nW29BGirYM7cKNRpX7sVwaFD4yoUgFMUhJ1tqJIcah5uEA0OPgjCxuGXfTZh5Bafv5sEhGuK6bmvm88HaZv3za2X/Q6nqkUKi5zJikEIncSpo9SLHTozEAUY/fRYn1pSwRtd+U05JD6ltKlBW2ACrLptE3QTzBAiCFY SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: internet2.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Aug 2016 19:28:11.8815 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR0801MB558 Archived-At: Subject: Re: [Id-event] Editorial discussion: Attributes or Claims X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 31 Aug 2016 19:28:16 -0000 --------------51F509566AF9615DD3A89837 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit +1 to this change, too. Nick On 8/31/16 12:20 PM, Phil Hunt wrote: > For the next draft, I realized that draft 03 uses a mix of the terms > “attribute” and “claims”. In part this occured because the draft > originally came out of SCIM and then we switched to using JWTs. > > While the terms are used synonymously, it would probably be less > confusing to readers to use one term or the other and to properly > define its use. My feeling is that “attribute” fits better as we are > saying a SET is a statement of fact from the perspective of the > issuer. The statement about attributes that are not in dispute (x was > changed). This is very different from an access token or an > authentication assertion where there is a degree of confidence in the > value. > > For draft 04, I have revised the draft to consistently use > “attributes” while providing an explanation/definition. > > I wanted to call your attention to this in advance and hopefully get > some discussion. I would like to make clear that we can switch to > “claims” if people feel strongly that consistency with 7519 provided > we can all agree to redefine the term “claim” as being factual in a > SET. I can see how people will view simplicity and consistency in > different ways here. > > In the end, I do not want to spend to much time on this as it doesn’t > change SETs normatively. This is just editorial cleanliness and we > should avoid too much bike shedding here. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event --------------51F509566AF9615DD3A89837 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit +1 to this change, too.

Nick

On 8/31/16 12:20 PM, Phil Hunt wrote:
For the next draft, I realized that draft 03 uses a mix of the terms “attribute” and “claims”.  In part this occured because the draft originally came out of SCIM and then we switched to using JWTs.

While the terms are used synonymously, it would probably be less confusing to readers to use one term or the other and to properly define its use. My feeling is that “attribute” fits better as we are saying a SET is a statement of fact from the perspective of the issuer.  The statement about attributes that are not in dispute (x was changed).  This is very different from an access token or an authentication assertion where there is a degree of confidence in the value.

For draft 04, I have revised the draft to consistently use “attributes” while providing an explanation/definition.  

I wanted to call your attention to this in advance and hopefully get some discussion.  I would like to make clear that we can switch to “claims” if people feel strongly that consistency with 7519 provided we can all agree to redefine the term “claim” as being factual in a SET.  I can see how people will view simplicity and consistency in different ways here.

In the end, I do not want to spend to much time on this as it doesn’t change SETs normatively. This is just editorial cleanliness and we should avoid too much bike shedding here.



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

--------------51F509566AF9615DD3A89837-- From nobody Wed Aug 31 12:48:52 2016 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 799D312D76C for ; Wed, 31 Aug 2016 12:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 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] 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 c7yuL2-3yVF4 for ; Wed, 31 Aug 2016 12:48:34 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0095.outbound.protection.outlook.com [104.47.34.95]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB11F12D773 for ; Wed, 31 Aug 2016 12:48:32 -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=AXguqPIwOwUNf4HOH5upK3pK+66p8KcmeWIHEPrfR0A=; b=OZUqV5r2IDsT0rJp9iLrD68/kkemhVayzZk8E9a3PClxISnIi6Hx+1kMx81ZWQ2IXnT28KBWvvV/JteJxdD92RX/nk/rxGXfZPK2V3gVzVfYFmXBXgesfNMTZ35tSGjr2YmnYeWAMDZELZ/xaWmWPQHxEw8WUQ2HhwJmc/5dn7I= Received: from DM2PR0301MB0637.namprd03.prod.outlook.com (10.160.96.11) by DM2PR0301MB0639.namprd03.prod.outlook.com (10.160.96.13) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.13; Wed, 31 Aug 2016 19:48:29 +0000 Received: from DM2PR0301MB0637.namprd03.prod.outlook.com ([10.160.96.11]) by DM2PR0301MB0637.namprd03.prod.outlook.com ([10.160.96.11]) with mapi id 15.01.0599.010; Wed, 31 Aug 2016 19:48:29 +0000 From: Mike Jones To: Nick Roy , "id-event@ietf.org" Thread-Topic: [Id-event] Use of "exp" - recommend SHOULD NOT be used Thread-Index: AQHSA7MPjKRclMR4N0KCBO7pdkLppaBjc+KAgAADYFA= Date: Wed, 31 Aug 2016 19:48:29 +0000 Message-ID: References: <2CD2401D-4FBD-4F39-8722-AB8D8333D856@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.91.120] x-ms-office365-filtering-correlation-id: ba16b0d6-5877-408e-04a7-08d3d1d7c82c x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0639; 6:zoTpP7ogjiz97R5KM2isQSxwphhouoql7dlmi7vK7C9JtY1dJEp7VDV0FMSRFZQbuBBsSOpLDvk2gglf0+rv1H6JaXwNzdKU1K9ihvzRpJe/Ij/pI+6WYjr/xRYukFUUMVBiy01xZ7hk5fyFacKoAVSFOLE4tGP9BxDEpnZcoLhBcN5MbyaM6RxA6w4yGlyU4ouGiEHoOkLf8Z379PB4UXLKDhsSh69fP8KOoPTwdiayItI0gZ9CAyhmsTwVn3tqUfV+rDU52alLOKTP4hs5CPBhxUQynfE7rMJ6b6KmdsnMbOYCUJQW8d7kYNjk4yZwkBOKU2DDG1kO23XWlrP01Q==; 5:mqESl2pUmKsB/cDEFCY+G2wduwBpQEz4WSXYit8HtCSDmHp5okFfpfybilt9G1AYZFY/tnpY+KAbX/GFQk1oWn4eZk/vGwKgj+pw4POhFLf9Ci0z0E+7ea4q3q7cRiWSaax/5nE63zmZLmiKCaYfPQ==; 24:qkjkHJgVXvCQ9W/3IBZ8iAtE3N/fB8ez3RFYUZV3mT+4jzRJguqbXtPlO9SsUhe4aID9Xxk6MbEeqNSZr6eSnuqfqab0kFD+FcYXu3AdzYk=; 7:zsq+CSyj7+PH/dyB5ek0Oo344J/tcYbuAVGXzKTKvVrDQPt31680933AebD6Z67LBxYfB5Uc39k2H1zEXuZY8o1noJ7k1+GDb0UMFcuE8G6JDxGFLDMknfijvs6BOpppM3IvYxQOVEiXfs/it/zKO8jEvtiNxTdVyPN12oDh1nf2YKP7kWKB8r++5mWhMSQDK9XN3BjuybGIs1Ix2ThLqHJzUxwJLx1/3Sogvx1LEIW6kiegrb9ile0vqo+xV5fq x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0639; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155)(146099531331640); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:DM2PR0301MB0639; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0639; x-forefront-prvs: 00514A2FE6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(377454003)(189002)(24454002)(199003)(50986999)(66066001)(86362001)(586003)(19300405004)(6116002)(5660300001)(10400500002)(2950100001)(87936001)(19580405001)(5005710100001)(10290500002)(11100500001)(2171001)(77096005)(2900100001)(101416001)(10090500001)(8990500004)(7696003)(3280700002)(7736002)(81156014)(19580395003)(8676002)(81166006)(7906003)(790700001)(106356001)(7846002)(76576001)(1680700002)(99286002)(5001770100001)(68736007)(19625215002)(92566002)(19617315012)(2906002)(8936002)(74316002)(15975445007)(3660700001)(16601075003)(122556002)(3846002)(9686002)(107886002)(33656002)(105586002)(54356999)(5002640100001)(86612001)(2501003)(189998001)(97736004)(102836003)(106116001)(76176999)(16236675004)(217873001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0639; H:DM2PR0301MB0637.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM2PR0301MB0637557A9F9EC1D93963DC66F5E30DM2PR0301MB0637_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2016 19:48:29.4362 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0639 Archived-At: Subject: Re: [Id-event] Use of "exp" - recommend SHOULD NOT be used X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 31 Aug 2016 19:48:49 -0000 --_000_DM2PR0301MB0637557A9F9EC1D93963DC66F5E30DM2PR0301MB0637_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm fine with making a non-normative rationale statement that "exp" isn't i= ncluded in the set of recommended claims for the reasons Phil stated, as lo= ng as the text doesn't try to preclude some kinds of events from using it. -- Mike From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Nick Roy Sent: Wednesday, August 31, 2016 12:27 PM To: id-event@ietf.org Subject: Re: [Id-event] Use of "exp" - recommend SHOULD NOT be used +1 to your assessment of the situation Nick On 8/31/16 12:10 PM, Phil Hunt wrote: I had an offline email discussion with Mike Jones about "exp". I thought I = should share with the broader group. We discussed if "exp" should have any meaning in a SET. When you look at a= ccess tokens there are 3 things it is being used for: 1. Validation: is the token valid (not valid after exp) 2. Sessions: the token is not valid when the assertion expires A SET however is a statement of a fact at a point in time. "Token WAS revo= ked". One could say it is permanent and cannot expire since the fact will n= ot change. While we may not want to rule "exp" out, it does feel like the = use of it should be avoided. Any opinions here? Phil @independentid www.independentid.com phil.hunt@oracle.com _______________________________________________ Id-event mailing list Id-event@ietf.org https://www.ietf.org/mailman/listinfo/id-event --_000_DM2PR0301MB0637557A9F9EC1D93963DC66F5E30DM2PR0301MB0637_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m fine with making a non-norm= ative rationale statement that “exp” isn’t included in th= e set of recommended claims for the reasons Phil stated, as long as the text doesn’t try to preclude some kinds of events from using it.

 

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

&nbs= p;

From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Nick Roy
Sent: Wednesday, August 31, 2016 12:27 PM
To: id-event@ietf.org
Subject: Re: [Id-event] Use of "exp" - recommend SHOULD NO= T be used

 

+1 to your assess= ment of the situation

Nick

On 8/31/16 12:10 PM, Phil Hunt wrote:

I had an offline email discussion with Mike Jones ab= out “exp”. I thought I should share with the broader group.

 

We discussed if “exp” should have any me= aning in a SET.  When you look at access tokens there are 3 things it = is being used for:

 

1. Validation: is the token valid (not valid after e= xp)

2. Sessions:  the token is not valid when the a= ssertion expires

 

A SET however is a statement of a fact at a point in= time.  “Token WAS revoked”. One could say it is permanent= and cannot expire since the fact will not change.  While we may not w= ant to rule “exp" out, it does feel like the use of it should be avoided.

 

Any opinions here?

 

 

 

 




_______________________________________________
Id-event mailing list
Id-event@ietf.org<=
/pre>

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

 

--_000_DM2PR0301MB0637557A9F9EC1D93963DC66F5E30DM2PR0301MB0637_-- From nobody Wed Aug 31 12:56:39 2016 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 83A7412D764 for ; Wed, 31 Aug 2016 12:56:37 -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 exkXo_nrO7dV for ; Wed, 31 Aug 2016 12:56:34 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0103.outbound.protection.outlook.com [104.47.38.103]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81B8012D763 for ; Wed, 31 Aug 2016 12:56:34 -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=Ert1M8ZX1Jtv6BC0RGJI20zcbkhIOC3ea3BZzOMWRc4=; b=mSkb+R/Tp9n6U/OS/lfJiDsD4OjYbXHvq9GMcBWNAgA6FsMLFP7rWP+PY77CXkZCbrbR4odJx9YkgXZEgcdpWuHRF8nNNbYaArz3xhKaMPQ4somn3IRuZhKUbZH6ZebFMAEZYot5j3ES14T+bJAJSCs3XDKC/8PAke2yWLBvDU8= Received: from DM2PR0301MB0637.namprd03.prod.outlook.com (10.160.96.11) by DM2PR0301MB0639.namprd03.prod.outlook.com (10.160.96.13) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.13; Wed, 31 Aug 2016 19:56:24 +0000 Received: from DM2PR0301MB0637.namprd03.prod.outlook.com ([10.160.96.11]) by DM2PR0301MB0637.namprd03.prod.outlook.com ([10.160.96.11]) with mapi id 15.01.0599.010; Wed, 31 Aug 2016 19:56:24 +0000 From: Mike Jones To: Phil Hunt , "id-event@ietf.org" Thread-Topic: [Id-event] Editorial discussion: Attributes or Claims Thread-Index: AQHSA7RhVqCApnafUkqYiTReCHYYraBjefrA Date: Wed, 31 Aug 2016 19:56:24 +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: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.91.120] x-ms-office365-filtering-correlation-id: 272c7151-241e-4170-0d1b-08d3d1d8e325 x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0639; 6:SkrF50/k4LlFkzIeGP5oao3JosL223zzIAGPEEhTMz6NVYgmx4bEGltKlsazHQcHwTOBtTuG4Wm77UjotReAlxKcDtQUmnyl935gUXQhOUGcAmiOmja3rLQizKoGJEJVcePnu4vMJ4RxxeafXMAfXVOiwYoi7+qtLt3CE+l1kwp7om3rUWUNY1IYNguI80dpDw58QEHRHfdyWmIk8bK1OmmbkPBNGlN+xvAirjy6I8R4Fci3rw98VsFEB6G7Bko9xgqKPMZBI8Sbn/fGAIZ5J87iELNTh43s2up+buscndc+hRqxc1jNS7G88W0uuBiKyxCGHVizOvLY4UCrVoTUJg==; 5:vGe3cg8e+SFr+h+BbvkFEpbiKYt5/MTvVBOCOuc/5h3yZTeUgO4EpI/lg0Hxvm1/JPXyFsl5TXQ7LZy9AFA3Vh5DK+kwxcdje110B7k7Vk6sYIJs49zJBk+QebGSbhfSfwXX7pqoCJlQIq8okc/fgQ==; 24:8KaRwLvmAOkyvcuw+nN15Zo15rs7SbwaKQFSQ2euKSgPxSJB7+hLKGKpmWCYxn/FqTmSRV3EHf2SxWFBVKA8Zc6R9ifpwwemAjzYO4HwffE=; 7:4TO/fW3w/Cqp2jfVY8uh8sxXzuyyPXkTuGg9KNpAn41h/MNWFTjMzxBOQh5Frln2L9UsJ+akEDppnJJ37NJGeNLF70Sk6GAusV2zAb9kmnKP0uyuIzj+MhqdU7ZzNdbONYUMmhVPqNnspzJl0BBtNqI5bC9kAjl3ZLWXOq9lJXg7/Nu8lVUSTyAFv1unIGV1URiDzg1Mid8rcrYH6k3fQeKLGaxB9r4mEA+9oiBLLZD7R8lW0lGVO+yYbz0zlEKr x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0639; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155)(146099531331640); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:DM2PR0301MB0639; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0639; x-forefront-prvs: 00514A2FE6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(189002)(377454003)(3660700001)(16601075003)(122556002)(19617315012)(2906002)(92566002)(15975445007)(8936002)(74316002)(3846002)(99286002)(68736007)(19625215002)(5001770100001)(97736004)(102836003)(189998001)(16236675004)(106116001)(76176999)(105586002)(54356999)(9686002)(107886002)(33656002)(5002640100001)(2501003)(86612001)(87936001)(5005710100001)(19580405001)(10290500002)(77096005)(2900100001)(19609705001)(11100500001)(66066001)(86362001)(50986999)(5660300001)(6116002)(10400500002)(2950100001)(586003)(19300405004)(7906003)(81166006)(8676002)(790700001)(81156014)(19580395003)(106356001)(76576001)(7846002)(1680700002)(101416001)(3280700002)(7736002)(7696003)(10090500001)(8990500004); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0639; H:DM2PR0301MB0637.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM2PR0301MB0637A1638624E4E4D7CB4FACF5E30DM2PR0301MB0637_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2016 19:56:24.1607 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0639 Archived-At: Subject: Re: [Id-event] Editorial discussion: Attributes or Claims X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 31 Aug 2016 19:56:37 -0000 --_000_DM2PR0301MB0637A1638624E4E4D7CB4FACF5E30DM2PR0301MB0637_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB3b3VsZCBhZHZvY2F0ZSB1c2luZyB0aGUgdGVybSDigJxjbGFpbeKAnSwgc2luY2UgdGhhdOKA mXMgY29uc2lzdGVudCB3aXRoIG90aGVyIEpXVCB1c2FnZS4gIEZvciBpbnN0YW5jZSwgbm90ZSB0 aGF0IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NTIzIHVzZXMgdGhlIHRlcm0g4oCc Y2xhaW3igJ0gZm9yIHRoaXMgcmVhc29uLCBldmVuIHRob3VnaCB0aGUgcGFyYWxsZWwgc3BlYyB1 c2luZyBTQU1MIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NTIyIHVzZXMg4oCcYXR0 cmlidXRl4oCdIHRvIGJlIGNvbnNpc3RlbnQgd2l0aCBTQU1MIHRlcm1pbm9sb2d5IHVzYWdlLg0K DQpBIGNsYWltIGlzIGV4YWN0bHkgYSBzdGF0ZW1lbnQgYmVpbmcgbWFkZSBieSBhbiBpc3N1ZXIu ICAoSXTigJlzIHN0aWxsIHVwIHRvIHRoZSByZWNlaXZlciBvZiB0aGUgSldUIHRvIGRlY2lkZSB3 aGF0IGFjdGlvbnMgdG8gdGFrZSBiYXNlZCBvbiB0aG9zZSBzdGF0ZW1lbnRzIGJ5IHRoZSBpc3N1 ZXIsIGJhc2VkIGluIHBhcnQgYWJvdXQgd2hhdCBpdHMgcmVsYXRpb25zaGlwIHRvIHRoZSBpc3N1 ZXIgaXMuKSAgU28gSSBkb27igJl0IHRoaW5rIHRoZXJl4oCZcyBhbnkgdGVybWlub2xvZ3kgYWR2 YW50YWdlIG9mIOKAnGFzc2VydGlvbuKAnSBvdmVyIOKAnGNsYWlt4oCdLg0KDQpJbiB0aGUgZW5k LCBJIHRoaW5rIHdl4oCZbGwganVzdCBjb25mdXNlIHBlb3BsZSBieSB1c2luZyDigJxhc3NlcnRp b27igJ0gd2l0aCBKV1RzIGJlY2F1c2UgYWxsIG90aGVyIEpXVCBzcGVjcyB0aGF0IEkga25vdyBv ZiB1c2UgdGhlIHRlcm0g4oCcY2xhaW3igJ0uICBUaGV54oCZbGwgYXNrIOKAnHdoeSBpcyBhIGRp ZmZlcmVudCB0ZXJtIGJlaW5nIHVzZWQ/4oCdIGFuZCB0aGVyZSB3b27igJl0IGJlIGFueSBzdWJz dGFudGl2ZSByZWFzb24gd2UgY2FuIGNpdGUuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IElkLWV2ZW50IFtt YWlsdG86aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFBoaWwgSHVudA0K U2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMzEsIDIwMTYgMTE6MjAgQU0NClRvOiBpZC1ldmVudEBp ZXRmLm9yZw0KU3ViamVjdDogW0lkLWV2ZW50XSBFZGl0b3JpYWwgZGlzY3Vzc2lvbjogQXR0cmli dXRlcyBvciBDbGFpbXMNCg0KRm9yIHRoZSBuZXh0IGRyYWZ0LCBJIHJlYWxpemVkIHRoYXQgZHJh ZnQgMDMgdXNlcyBhIG1peCBvZiB0aGUgdGVybXMg4oCcYXR0cmlidXRl4oCdIGFuZCDigJxjbGFp bXPigJ0uICBJbiBwYXJ0IHRoaXMgb2NjdXJlZCBiZWNhdXNlIHRoZSBkcmFmdCBvcmlnaW5hbGx5 IGNhbWUgb3V0IG9mIFNDSU0gYW5kIHRoZW4gd2Ugc3dpdGNoZWQgdG8gdXNpbmcgSldUcy4NCg0K V2hpbGUgdGhlIHRlcm1zIGFyZSB1c2VkIHN5bm9ueW1vdXNseSwgaXQgd291bGQgcHJvYmFibHkg YmUgbGVzcyBjb25mdXNpbmcgdG8gcmVhZGVycyB0byB1c2Ugb25lIHRlcm0gb3IgdGhlIG90aGVy IGFuZCB0byBwcm9wZXJseSBkZWZpbmUgaXRzIHVzZS4gTXkgZmVlbGluZyBpcyB0aGF0IOKAnGF0 dHJpYnV0ZeKAnSBmaXRzIGJldHRlciBhcyB3ZSBhcmUgc2F5aW5nIGEgU0VUIGlzIGEgc3RhdGVt ZW50IG9mIGZhY3QgZnJvbSB0aGUgcGVyc3BlY3RpdmUgb2YgdGhlIGlzc3Vlci4gIFRoZSBzdGF0 ZW1lbnQgYWJvdXQgYXR0cmlidXRlcyB0aGF0IGFyZSBub3QgaW4gZGlzcHV0ZSAoeCB3YXMgY2hh bmdlZCkuICBUaGlzIGlzIHZlcnkgZGlmZmVyZW50IGZyb20gYW4gYWNjZXNzIHRva2VuIG9yIGFu IGF1dGhlbnRpY2F0aW9uIGFzc2VydGlvbiB3aGVyZSB0aGVyZSBpcyBhIGRlZ3JlZSBvZiBjb25m aWRlbmNlIGluIHRoZSB2YWx1ZS4NCg0KRm9yIGRyYWZ0IDA0LCBJIGhhdmUgcmV2aXNlZCB0aGUg ZHJhZnQgdG8gY29uc2lzdGVudGx5IHVzZSDigJxhdHRyaWJ1dGVz4oCdIHdoaWxlIHByb3ZpZGlu ZyBhbiBleHBsYW5hdGlvbi9kZWZpbml0aW9uLg0KDQpJIHdhbnRlZCB0byBjYWxsIHlvdXIgYXR0 ZW50aW9uIHRvIHRoaXMgaW4gYWR2YW5jZSBhbmQgaG9wZWZ1bGx5IGdldCBzb21lIGRpc2N1c3Np b24uICBJIHdvdWxkIGxpa2UgdG8gbWFrZSBjbGVhciB0aGF0IHdlIGNhbiBzd2l0Y2ggdG8g4oCc Y2xhaW1z4oCdIGlmIHBlb3BsZSBmZWVsIHN0cm9uZ2x5IHRoYXQgY29uc2lzdGVuY3kgd2l0aCA3 NTE5IHByb3ZpZGVkIHdlIGNhbiBhbGwgYWdyZWUgdG8gcmVkZWZpbmUgdGhlIHRlcm0g4oCcY2xh aW3igJ0gYXMgYmVpbmcgZmFjdHVhbCBpbiBhIFNFVC4gIEkgY2FuIHNlZSBob3cgcGVvcGxlIHdp bGwgdmlldyBzaW1wbGljaXR5IGFuZCBjb25zaXN0ZW5jeSBpbiBkaWZmZXJlbnQgd2F5cyBoZXJl Lg0KDQpJbiB0aGUgZW5kLCBJIGRvIG5vdCB3YW50IHRvIHNwZW5kIHRvIG11Y2ggdGltZSBvbiB0 aGlzIGFzIGl0IGRvZXNu4oCZdCBjaGFuZ2UgU0VUcyBub3JtYXRpdmVseS4gVGhpcyBpcyBqdXN0 IGVkaXRvcmlhbCBjbGVhbmxpbmVzcyBhbmQgd2Ugc2hvdWxkIGF2b2lkIHRvbyBtdWNoIGJpa2Ug c2hlZGRpbmcgaGVyZS4NCg0KUGhpbA0KDQpAaW5kZXBlbmRlbnRpZA0Kd3d3LmluZGVwZW5kZW50 aWQuY29tPGh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20+DQpwaGlsLmh1bnRAb3JhY2xlLmNv bTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+DQoNCg0KDQoNCg== --_000_DM2PR0301MB0637A1638624E4E4D7CB4FACF5E30DM2PR0301MB0637_ 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 dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uYXBwbGUtc3R5bGUt c3Bhbg0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1zdHlsZS1zcGFuO30NCnNwYW4uRW1haWxTdHls ZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMDAyMDYwIj5JIHdvdWxkIGFkdm9jYXRlIHVzaW5nIHRoZSB0ZXJtIOKAnGNs YWlt4oCdLCBzaW5jZSB0aGF04oCZcyBjb25zaXN0ZW50IHdpdGggb3RoZXIgSldUIHVzYWdlLiZu YnNwOyBGb3IgaW5zdGFuY2UsIG5vdGUgdGhhdA0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL3JmYzc1MjMiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NTIzPC9h PiB1c2VzIHRoZSB0ZXJtIOKAnGNsYWlt4oCdIGZvciB0aGlzIHJlYXNvbiwgZXZlbiB0aG91Z2gg dGhlIHBhcmFsbGVsIHNwZWMgdXNpbmcgU0FNTA0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL3JmYzc1MjIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NTIyPC9h PiB1c2VzIOKAnGF0dHJpYnV0ZeKAnSB0byBiZSBjb25zaXN0ZW50IHdpdGggU0FNTCB0ZXJtaW5v bG9neSB1c2FnZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPkEg Y2xhaW0gaXMgZXhhY3RseSBhIHN0YXRlbWVudCBiZWluZyBtYWRlIGJ5IGFuIGlzc3Vlci4mbmJz cDsgKEl04oCZcyBzdGlsbCB1cCB0byB0aGUgcmVjZWl2ZXIgb2YgdGhlIEpXVCB0byBkZWNpZGUg d2hhdCBhY3Rpb25zIHRvIHRha2UgYmFzZWQgb24gdGhvc2Ugc3RhdGVtZW50cyBieQ0KIHRoZSBp c3N1ZXIsIGJhc2VkIGluIHBhcnQgYWJvdXQgd2hhdCBpdHMgcmVsYXRpb25zaGlwIHRvIHRoZSBp c3N1ZXIgaXMuKSZuYnNwOyBTbyBJIGRvbuKAmXQgdGhpbmsgdGhlcmXigJlzIGFueSB0ZXJtaW5v bG9neSBhZHZhbnRhZ2Ugb2Yg4oCcYXNzZXJ0aW9u4oCdIG92ZXIg4oCcY2xhaW3igJ0uPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5JbiB0aGUgZW5kLCBJIHRoaW5r IHdl4oCZbGwganVzdCBjb25mdXNlIHBlb3BsZSBieSB1c2luZyDigJxhc3NlcnRpb27igJ0gd2l0 aCBKV1RzIGJlY2F1c2UgYWxsIG90aGVyIEpXVCBzcGVjcyB0aGF0IEkga25vdyBvZiB1c2UgdGhl IHRlcm0g4oCcY2xhaW3igJ0uJm5ic3A7IFRoZXnigJlsbCBhc2sg4oCcd2h5DQogaXMgYSBkaWZm ZXJlbnQgdGVybSBiZWluZyB1c2VkP+KAnSBhbmQgdGhlcmUgd29u4oCZdCBiZSBhbnkgc3Vic3Rh bnRpdmUgcmVhc29uIHdlIGNhbiBjaXRlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1p a2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJf TWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbEVu ZENvbXBvc2UiPjwvc3Bhbj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiBJZC1ldmVudCBbbWFpbHRvOmlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmdd DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlBoaWwgSHVudDxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNk YXksIEF1Z3VzdCAzMSwgMjAxNiAxMToyMCBBTTxicj4NCjxiPlRvOjwvYj4gaWQtZXZlbnRAaWV0 Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW0lkLWV2ZW50XSBFZGl0b3JpYWwgZGlzY3Vzc2lv bjogQXR0cmlidXRlcyBvciBDbGFpbXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5Gb3IgdGhlIG5leHQgZHJhZnQsIEkgcmVhbGl6ZWQgdGhhdCBkcmFmdCAw MyB1c2VzIGEgbWl4IG9mIHRoZSB0ZXJtcyDigJxhdHRyaWJ1dGXigJ0gYW5kIOKAnGNsYWltc+KA nS4gJm5ic3A7SW4gcGFydCB0aGlzIG9jY3VyZWQgYmVjYXVzZSB0aGUgZHJhZnQgb3JpZ2luYWxs eSBjYW1lIG91dCBvZiBTQ0lNIGFuZCB0aGVuIHdlIHN3aXRjaGVkIHRvIHVzaW5nIEpXVHMuPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGlsZSB0aGUgdGVy bXMgYXJlIHVzZWQgc3lub255bW91c2x5LCBpdCB3b3VsZCBwcm9iYWJseSBiZSBsZXNzIGNvbmZ1 c2luZyB0byByZWFkZXJzIHRvIHVzZSBvbmUgdGVybSBvciB0aGUgb3RoZXIgYW5kIHRvIHByb3Bl cmx5IGRlZmluZSBpdHMgdXNlLiBNeSBmZWVsaW5nIGlzIHRoYXQg4oCcYXR0cmlidXRl4oCdIGZp dHMgYmV0dGVyIGFzIHdlIGFyZSBzYXlpbmcgYSBTRVQgaXMgYSBzdGF0ZW1lbnQgb2YgZmFjdA0K IGZyb20gdGhlIHBlcnNwZWN0aXZlIG9mIHRoZSBpc3N1ZXIuICZuYnNwO1RoZSBzdGF0ZW1lbnQg YWJvdXQgYXR0cmlidXRlcyB0aGF0IGFyZSBub3QgaW4gZGlzcHV0ZSAoeCB3YXMgY2hhbmdlZCku ICZuYnNwO1RoaXMgaXMgdmVyeSBkaWZmZXJlbnQgZnJvbSBhbiBhY2Nlc3MgdG9rZW4gb3IgYW4g YXV0aGVudGljYXRpb24gYXNzZXJ0aW9uIHdoZXJlIHRoZXJlIGlzIGEgZGVncmVlIG9mIGNvbmZp ZGVuY2UgaW4gdGhlIHZhbHVlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5Gb3IgZHJhZnQgMDQsIEkgaGF2ZSByZXZpc2VkIHRoZSBkcmFmdCB0 byBjb25zaXN0ZW50bHkgdXNlIOKAnGF0dHJpYnV0ZXPigJ0gd2hpbGUgcHJvdmlkaW5nIGFuIGV4 cGxhbmF0aW9uL2RlZmluaXRpb24uICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHdhbnRlZCB0byBjYWxsIHlvdXIgYXR0ZW50aW9u IHRvIHRoaXMgaW4gYWR2YW5jZSBhbmQgaG9wZWZ1bGx5IGdldCBzb21lIGRpc2N1c3Npb24uICZu YnNwO0kgd291bGQgbGlrZSB0byBtYWtlIGNsZWFyIHRoYXQgd2UgY2FuIHN3aXRjaCB0byDigJxj bGFpbXPigJ0gaWYgcGVvcGxlIGZlZWwgc3Ryb25nbHkgdGhhdCBjb25zaXN0ZW5jeSB3aXRoIDc1 MTkgcHJvdmlkZWQgd2UgY2FuIGFsbCBhZ3JlZSB0byByZWRlZmluZSB0aGUNCiB0ZXJtIOKAnGNs YWlt4oCdIGFzIGJlaW5nIGZhY3R1YWwgaW4gYSBTRVQuICZuYnNwO0kgY2FuIHNlZSBob3cgcGVv cGxlIHdpbGwgdmlldyBzaW1wbGljaXR5IGFuZCBjb25zaXN0ZW5jeSBpbiBkaWZmZXJlbnQgd2F5 cyBoZXJlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JbiB0aGUgZW5kLCBJIGRvIG5vdCB3YW50IHRvIHNwZW5kIHRvIG11Y2ggdGltZSBvbiB0 aGlzIGFzIGl0IGRvZXNu4oCZdCBjaGFuZ2UgU0VUcyBub3JtYXRpdmVseS4gVGhpcyBpcyBqdXN0 IGVkaXRvcmlhbCBjbGVhbmxpbmVzcyBhbmQgd2Ugc2hvdWxkIGF2b2lkIHRvbyBtdWNoIGJpa2Ug c2hlZGRpbmcgaGVyZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlBoaWw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+QGluZGVwZW5k ZW50aWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxhIGhyZWY9Imh0dHA6Ly93d3cuaW5k ZXBlbmRlbnRpZC5jb20iPnd3dy5pbmRlcGVuZGVudGlkLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBv cmFjbGUuY29tIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_DM2PR0301MB0637A1638624E4E4D7CB4FACF5E30DM2PR0301MB0637_-- From nobody Wed Aug 31 13:30:37 2016 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 A507712D09D for ; Wed, 31 Aug 2016 13:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.738 X-Spam-Level: X-Spam-Status: No, score=-4.738 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=-0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 1sPr2vptDc7T for ; Wed, 31 Aug 2016 13:30:33 -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 AFE1B12D5BC for ; Wed, 31 Aug 2016 13:30:33 -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 u7VKUW1e030490 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 31 Aug 2016 20:30:32 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u7VKUWkD006056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 31 Aug 2016 20:30:32 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u7VKUSSj020149; Wed, 31 Aug 2016 20:30:31 GMT Received: from [10.0.1.4] (/24.86.208.48) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 31 Aug 2016 13:30:28 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-53882879-FF88-4198-9370-297FD6AEC0BF Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (13G36) In-Reply-To: Date: Wed, 31 Aug 2016 13:30:27 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <2CD2401D-4FBD-4F39-8722-AB8D8333D856@oracle.com> To: Mike Jones X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: Nick Roy , "id-event@ietf.org" Subject: Re: [Id-event] Use of "exp" - recommend SHOULD NOT be used X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 31 Aug 2016 20:30:36 -0000 --Apple-Mail-53882879-FF88-4198-9370-297FD6AEC0BF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I had wondered if events might reflect a temporary state change that expires= . I would not preclude it, but inquire if in such cases an access token asse= rtion is more appropriate rather than an event? Phil > On Aug 31, 2016, at 12:48 PM, Mike Jones wro= te: >=20 > I=E2=80=99m fine with making a non-normative rationale statement that =E2=80= =9Cexp=E2=80=9D isn=E2=80=99t included in the set of recommended claims for t= he reasons Phil stated, as long as the text doesn=E2=80=99t try to preclude s= ome kinds of events from using it. > =20 > -- Mike > =20 > From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Nick Roy > Sent: Wednesday, August 31, 2016 12:27 PM > To: id-event@ietf.org > Subject: Re: [Id-event] Use of "exp" - recommend SHOULD NOT be used > =20 > +1 to your assessment of the situation >=20 > Nick >=20 > On 8/31/16 12:10 PM, Phil Hunt wrote: > I had an offline email discussion with Mike Jones about =E2=80=9Cexp=E2=80= =9D. I thought I should share with the broader group. > =20 > We discussed if =E2=80=9Cexp=E2=80=9D should have any meaning in a SET. W= hen you look at access tokens there are 3 things it is being used for: > =20 > 1. Validation: is the token valid (not valid after exp) > 2. Sessions: the token is not valid when the assertion expires > =20 > A SET however is a statement of a fact at a point in time. =E2=80=9CToken= WAS revoked=E2=80=9D. One could say it is permanent and cannot expire since= the fact will not change. While we may not want to rule =E2=80=9Cexp" out,= it does feel like the use of it should be avoided. > =20 > Any opinions here? > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > =20 > =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 --Apple-Mail-53882879-FF88-4198-9370-297FD6AEC0BF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I had wondered if events might reflect= a temporary state change that expires. I would not preclude it, but inquire= if in such cases an access token assertion is more appropriate rather than a= n event?

Phil

On Aug 3= 1, 2016, at 12:48 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

=

I=E2=80=99m fine with making a non-norm= ative rationale statement that =E2=80=9Cexp=E2=80=9D isn=E2=80=99t included i= n the set of recommended claims for the reasons Phil stated, as long as the text doesn=E2=80=99t try to preclude some kinds of events from using it.

 

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

 =

From:= Id-event [mailto:id-event-boun= ces@ietf.org] On Behalf Of Nick Roy
Sent: Wednesday, August 31, 2016 12:27 PM
To: id-event@ietf.org
Subject: Re: [Id-event] Use of "exp" - recommend SHOULD NOT be used

 

+1 to your assessment o= f the situation

Nick

On 8/31/16 12:10 PM, Phil Hunt wrote:

I had an offline email discussion with Mike Jones abo= ut =E2=80=9Cexp=E2=80=9D. I thought I should share with the broader group.

 

We discussed if =E2=80=9Cexp=E2=80=9D should have any= meaning in a SET.  When you look at access tokens there are 3 things i= t is being used for:

 

1. Validation: is the token valid (not valid after ex= p)

2. Sessions:  the token is not valid when the as= sertion expires

 

A SET however is a statement of a fact at a point in t= ime.  =E2=80=9CToken WAS revoked=E2=80=9D. One could say it is permanen= t and cannot expire since the fact will not change.  While we may not w= ant to rule =E2=80=9Cexp" out, it does feel like the use of it should be avoided.

 

Any opinions here?

 

 

 

 




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

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

 

____________________= ___________________________
Id-event mailing list
= Id-event@ietf.org
<= span>https://www.= ietf.org/mailman/listinfo/id-event
<= /html>= --Apple-Mail-53882879-FF88-4198-9370-297FD6AEC0BF-- From nobody Wed Aug 31 23:49:01 2016 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 3325612D119 for ; Wed, 31 Aug 2016 23:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 rz9o2suP7Uxe for ; Wed, 31 Aug 2016 23:48:58 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (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 44D9012D0C6 for ; Wed, 31 Aug 2016 23:48:57 -0700 (PDT) X-AuditID: 1209190c-327ff70000007d2a-31-57c7cf564f2d 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 (Symantec Messaging Gateway) with SMTP id 43.EB.32042.65FC7C75; Thu, 1 Sep 2016 02:48:55 -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 u816mrsq008789; Thu, 1 Sep 2016 02:48:53 -0400 Received: from [192.168.43.53] (37-219-150-235.nat.bb.dnainternet.fi [37.219.150.235]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u816mguu005864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Sep 2016 02:48:51 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_76D25B97-24E9-43CB-ACFB-1EC2F6564F53" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Justin Richer In-Reply-To: Date: Thu, 1 Sep 2016 09:48:41 +0300 Message-Id: References: To: Phil Hunt X-Mailer: Apple Mail (2.3124) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplleLIzCtJLcpLzFFi42IR4hTV1g0/fzzcYN4icYuOBd1MFgvmN7Jb 7N52gN2B2WPGjkksHkuW/GTy+Pj0FksAcxSXTUpqTmZZapG+XQJXxv579gU7PSsaFy5na2Bc 5tDFyMkhIWAi8efobfYuRi4OIYE2Jomv/+YzgSSEBDYwStzstIdIXGKS+H/sBytIglkgQWL3 lE5mEJtXQE9i0/q3YA3CArYSKzYeYASx2QRUJaavaQGLcwrYSXQum8wOYrMIqEi8uzOZBWKO ncTv0y1sXYwcQHOsJHrPFkDsamKUaFh9HqxeBKj+29XrjBCXyko8ObmIZQIj/ywkZ8xCcgZE XFti2cLXzBC2psT+7uUsmOIaEp3fJrIuYGRbxSibklulm5uYmVOcmqxbnJyYl5dapGuol5tZ opeaUrqJERzqkjw7GM+88TrEKMDBqMTD6/DmWLgQa2JZcWXuIUZJDiYlUV61uOPhQnxJ+SmV GYnFGfFFpTmpxYcYJTiYlUR4i84C5XhTEiurUovyYVLSHCxK4rxdMw6ECwmkJ5akZqemFqQW wWRlODiUJHh/gDQKFqWmp1akZeaUIKSZODhBhvMADdc+BzK8uCAxtzgzHSJ/ilFRSpw3FqRZ ACSRUZoH1wtKRaq3p71+xSgO9Iowbw9IOw8wjcF1vwIazAQ0uODOYZDBJYkIKakGRjlNzqfC Tz3rdCwXqNm3NQiuNcy44C8+T3Z7EHuDjXVb6o3gwoXKX7JqJEQyY/4Vys8vefEj4dyzKdfy 4oJdnd/7n1TrSJ83a0PJzdm6B7y/FxnUrqvO9TxxoytQZdkLszUX+zZt/X9Dxubptp+p3vyH pN5Z3TPqTP0q21EnG16h8K5S/80mJZbijERDLeai4kQAv9iPYSADAAA= Archived-At: Cc: Sarah Squire , id-event@ietf.org Subject: Re: [Id-event] SET examples for a healthcare context X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 01 Sep 2016 06:49:00 -0000 --Apple-Mail=_76D25B97-24E9-43CB-ACFB-1EC2F6564F53 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 You can specify a recommended direction for the profiles. So, the sub in = the event stack =E2=80=9CSHOULD=E2=80=9D have a certain set of = semantics, for parallelism. I think it=E2=80=99s actually a good idea to = provide that kind of guidance. =E2=80=94 Justin > On Aug 31, 2016, at 9:29 PM, Phil Hunt wrote: >=20 > Sarah, >=20 > Your examples highlight some issues around =E2=80=9Csub=E2=80=9D that = are still in a flux. For draft 04, the emerging consensus seems to be to = use =E2=80=9Csub=E2=80=9D to be used at the top level as it is already = defined as a JWT claim. Yet for some systems, the problem is that = =E2=80=9Csub=E2=80=9D is not a URI and without an =E2=80=9Ciss=E2=80=9D = is incomplete. This becomes problematic then if =E2=80=9Ciss=E2=80=9D = of the event is not the =E2=80=9Ciss=E2=80=9D of the =E2=80=9Csub=E2=80=9D= . >=20 > Your examples actually show this - for example = heart-parallel-auth.json >=20 > For now, I=E2=80=99m just taking the editorial position that =E2=80=9Csu= b=E2=80=9D in the envelope or =E2=80=9Csub=E2=80=9D in the payload is up = to the profiling specification to decide. That gives me some worry = about inconsistency between specs, but I think it may not be that big a = deal in practice since people will tend to worry about one family of = events at a time in the context of a single subscriber. >=20 > Phil >=20 > @independentid > www.independentid.com = phil.hunt@oracle.com = >=20 >=20 >=20 >=20 >=20 >> On Aug 31, 2016, at 11:02 AM, Sarah Squire > wrote: >>=20 >> Hi all, >>=20 >> I've been putting together some examples based on the = idevent-token-03 draft. You can find them here: >>=20 >> https://github.com/id-event/examples = >>=20 >> There are three examples of an idp-to-rp SET - consent, token = revocation, and userinfo update. >>=20 >> There are two examples of an rp-to-idp SET - parallel authentication = and suspected fraud. >>=20 >> This format seems workable for our use cases. Note that none of these = include or require "sub" at the top level. >>=20 >> Sarah >>=20 >> Sarah Squire >> Engage Identity >> http://engageidentity.com = ______________________________________________= _ >> 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=_76D25B97-24E9-43CB-ACFB-1EC2F6564F53 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 You can specify a recommended direction for the profiles. So, = the sub in the event stack =E2=80=9CSHOULD=E2=80=9D have a certain set = of semantics, for parallelism. I think it=E2=80=99s actually a good idea = to provide that kind of guidance.

 =E2=80=94 Justin

On = Aug 31, 2016, at 9:29 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Sarah,

Your examples highlight = some issues around =E2=80=9Csub=E2=80=9D that are still in a flux. For = draft 04, the emerging consensus seems to be to use =E2=80=9Csub=E2=80=9D = to be used at the top level as it is already defined as a JWT claim. =  Yet for some systems, the problem is that =E2=80=9Csub=E2=80=9D is = not a URI and without an =E2=80=9Ciss=E2=80=9D is incomplete.  This = becomes problematic then if =E2=80=9Ciss=E2=80=9D of the event is not = the =E2=80=9Ciss=E2=80=9D of the =E2=80=9Csub=E2=80=9D.

Your examples actually = show this - for example heart-parallel-auth.json

For now, I=E2=80=99m just taking the = editorial position that =E2=80=9Csub=E2=80=9D in the envelope or = =E2=80=9Csub=E2=80=9D in the payload is up to the profiling = specification to decide.  That gives me some worry about = inconsistency between specs, but I think it may not be that big a deal = in practice since people will tend to worry about one family of events = at a time in the context of a single subscriber.





On Aug 31, 2016, at 11:02 AM, Sarah Squire <sarah@engageidentity.com> wrote:

Hi all,

I've been putting together some examples based on the = idevent-token-03 draft. You can find them here:

https://github.com/id-event/examples

There are three examples of an idp-to-rp SET - consent, token = revocation, and userinfo update.

There are two examples of an rp-to-idp = SET - parallel authentication and suspected fraud.

This format seems = workable for our use cases. Note that none of these include or require = "sub" at the top level.

Sarah

Sarah Squire
Engage Identity
http://engageidentity.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=_76D25B97-24E9-43CB-ACFB-1EC2F6564F53-- From nobody Wed Aug 31 23:50:36 2016 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 3B2E212B032 for ; Wed, 31 Aug 2016 23:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.758 X-Spam-Level: X-Spam-Status: No, score=-4.758 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.548, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 XXp8XuCgKKMF for ; Wed, 31 Aug 2016 23:50:32 -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 1B1FC12D0C6 for ; Wed, 31 Aug 2016 23:50:32 -0700 (PDT) X-AuditID: 12074422-317ff700000051ba-ba-57c7cfb64a1c 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 (Symantec Messaging Gateway) with SMTP id 72.4B.20922.6BFC7C75; Thu, 1 Sep 2016 02:50: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 u816oTTC001510; Thu, 1 Sep 2016 02:50:30 -0400 Received: from [192.168.43.53] (37-219-150-235.nat.bb.dnainternet.fi [37.219.150.235]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u816oJG2006134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Sep 2016 02:50:25 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_48C6082D-0021-484A-91DF-A64E0CAACD83" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Justin Richer In-Reply-To: Date: Thu, 1 Sep 2016 09:50:18 +0300 Message-Id: <69A95C99-816C-4FA4-9E83-8A296FDAAF7D@mit.edu> References: <2CD2401D-4FBD-4F39-8722-AB8D8333D856@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.3124) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFKsWRmVeSWpSXmKPExsUixG6nrrvt/PFwg5NnjSw6FnQzWeyd9onF 4t/uMosF8xvZHVg8liz5yeQx9d9nNo/WHX/ZPT4+vcUSwBLFZZOSmpNZllqkb5fAlbF0wSvG gp3TGSvmPfRvYGxpZexi5OSQEDCRuPXsL5DNxSEk0MYkMWn9CShnA6NEz6MlzBDOJSaJc79u s4O0MAskSLTc6mYFsXkF9CQ2rX/LBGILCzhLLO37zAZiswmoSkxf0wIW5xSwk5jz8BAziM0i oCLx9vZhJog5tRId67qZIeZYSTxre8UEsewno8SkhzdZQBIiQA3frl6HulVW4snJRSwTGPln IbljFpI7IOLaEssWvmaGsDUl9ncvZ8EU15Do/DaRdQEj2ypG2ZTcKt3cxMyc4tRk3eLkxLy8 1CJdU73czBK91JTSTYzgKHBR2sE48Z/XIUYBDkYlHl6HN8fChVgTy4orcw8xSnIwKYnyqsUd DxfiS8pPqcxILM6ILyrNSS0+xCjBwawkwlt0FijHm5JYWZValA+TkuZgURLn7ZpxIFxIID2x JDU7NbUgtQgmK8PBoSTBW3sOqFGwKDU9tSItM6cEIc3EwQkynAdoeCZIDW9xQWJucWY6RP4U o6KUOO8ikIQASCKjNA+uF5SkVG9Pe/2KURzoFWHeHpAqHmCCg+t+BTSYCWhwwZ3DIINLEhFS Ug2MDmVrE1xE7U6uPXSq5G5KRFn5h3/L0h603dzj3/dUSHjNge8qZk032Wedsr5+xV7aLG+x wYZopi+/7lgV7XDcf0hnSuCLn8XTLLd0LX+arfQ6MGhH2bHo9DMbN26dVhVsaXPv5FGvg818 mv+EmaQFY/aWX+jkUvI9bD37a8lWw3/ng3NnnBVOUmIpzkg01GIuKk4EAB04+XAtAwAA Archived-At: Cc: Mike Jones , Nick Roy , "id-event@ietf.org" Subject: Re: [Id-event] Use of "exp" - recommend SHOULD NOT be used X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 01 Sep 2016 06:50:34 -0000 --Apple-Mail=_48C6082D-0021-484A-91DF-A64E0CAACD83 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Events should be able to use it just fine, but =E2=80=9Cexp=E2=80=9D in = the envelope doesn=E2=80=99t make a lot of sense in the SET context. =E2=80=94 Justin > On Aug 31, 2016, at 11:30 PM, Phil Hunt (IDM) = wrote: >=20 > I had wondered if events might reflect a temporary state change that = expires. I would not preclude it, but inquire if in such cases an access = token assertion is more appropriate rather than an event? >=20 > Phil >=20 > On Aug 31, 2016, at 12:48 PM, Mike Jones > wrote: >=20 >> I=E2=80=99m fine with making a non-normative rationale statement that = =E2=80=9Cexp=E2=80=9D isn=E2=80=99t included in the set of recommended = claims for the reasons Phil stated, as long as the text doesn=E2=80=99t = try to preclude some kinds of events from using it. >> =20 >> -- Mike >> =C2=A0 <> >> From: Id-event [mailto:id-event-bounces@ietf.org = ] On Behalf Of Nick Roy >> Sent: Wednesday, August 31, 2016 12:27 PM >> To: id-event@ietf.org >> Subject: Re: [Id-event] Use of "exp" - recommend SHOULD NOT be used >> =20 >> +1 to your assessment of the situation >>=20 >> Nick >>=20 >> On 8/31/16 12:10 PM, Phil Hunt wrote: >> I had an offline email discussion with Mike Jones about =E2=80=9Cexp=E2= =80=9D. I thought I should share with the broader group. >> =20 >> We discussed if =E2=80=9Cexp=E2=80=9D should have any meaning in a = SET. When you look at access tokens there are 3 things it is being used = for: >> =20 >> 1. Validation: is the token valid (not valid after exp) >> 2. Sessions: the token is not valid when the assertion expires >> =20 >> A SET however is a statement of a fact at a point in time. =E2=80=9CTo= ken WAS revoked=E2=80=9D. One could say it is permanent and cannot = expire since the fact will not change. While we may not want to rule = =E2=80=9Cexp" out, it does feel like the use of it should be avoided. >> =20 >> Any opinions here? >> =20 >> Phil >> =20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> =20 >> =20 >> =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 = > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event = --Apple-Mail=_48C6082D-0021-484A-91DF-A64E0CAACD83 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Events should be able to use it just fine, but =E2=80=9Cexp=E2=80= =9D in the envelope doesn=E2=80=99t make a lot of sense in the SET = context.

 =E2=80=94= Justin

On Aug 31, 2016, at 11:30 PM, Phil Hunt = (IDM) <phil.hunt@oracle.com> wrote:

I had wondered if events = might reflect a temporary state change that expires. I would not = preclude it, but inquire if in such cases an access token assertion is = more appropriate rather than an event?

Phil

On Aug 31, 2016, at 12:48 PM, Mike Jones = <Michael.Jones@microsoft.com> wrote:

I=E2=80=99m fine with making a non-normative = rationale statement that =E2=80=9Cexp=E2=80=9D isn=E2=80=99t included in = the set of recommended claims for the reasons Phil stated, as long as = the text doesn=E2=80=99t try to preclude some kinds of events from using = it.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;       -- Mike
 
From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf = Of Nick Roy
Sent: Wednesday, August 31, 2016 = 12:27 PM
To: id-event@ietf.org
Subject: Re: [Id-event] Use of "exp" = - recommend SHOULD NOT be used
 

+1 to your assessment of the situation

Nick

On 8/31/16 12:10 PM, Phil Hunt wrote:
I = had an offline email discussion with Mike Jones about =E2=80=9Cexp=E2=80=9D= . I thought I should share with the broader group.
 
We discussed if =E2=80=9Cexp=E2=80=9D = should have any meaning in a SET.  When you look at access tokens = there are 3 things it is being used for:
 
1. Validation: is the token valid (not = valid after exp)
2. Sessions:  the token is not valid = when the assertion expires
 
A SET however is a statement of a fact at a point in = time.  =E2=80=9CToken WAS revoked=E2=80=9D. One could say it is = permanent and cannot expire since the fact will not change.  While = we may not want to rule =E2=80=9Cexp" out, it does feel like the use of = it should be avoided.
 
Any opinions here?
 
Phil
 
@independentid
www.independentid.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
_______________________________________________
Id-event mailing = list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event

= --Apple-Mail=_48C6082D-0021-484A-91DF-A64E0CAACD83--