From nobody Fri Jul 1 08:05:45 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7223E12D095 for ; Fri, 1 Jul 2016 08:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 TSR5VmhRsfiw for ; Fri, 1 Jul 2016 08:05:43 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9B97128E19 for ; Fri, 1 Jul 2016 08:05:42 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id a125so207355063qkc.2 for ; Fri, 01 Jul 2016 08:05:42 -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 :content-transfer-encoding:message-id:references:to; bh=vEPqUX+8SbJg7PMb79nMa4/rcn5tohdrTgGvgLyMyZs=; b=cUHtUN7q/VleYsanKLqXv/qx5aKE3+E6KER9YFzqYW5W4PAUJlRevBGhwKmIsLOfXi wrYKUhy9uiYIEs5R5blpvA6CD/q7fM/GV6yIDcOStMlVQzBYtrRjZXGvWbQ1GjkYWdxK Jyxo98Lesi9TBn0PtEUU62i0TJE4o3xH/OXI+9kF2LTsECHRf8eLDSbEH3NIN5ISKky9 3xVC2L5YZQ6KRyoX8rODSEF1y/7tcc1X7aSQe2SXw0v4BtEdw+uPih/ma8mAP+gwv8r7 bWHIeQ+X8e/BmCYVR9o6HD/vFxcVeHU+LIix4TI9QBli41bg58ujryDVD4CW9S2jJDp0 9IGQ== 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 :content-transfer-encoding:message-id:references:to; bh=vEPqUX+8SbJg7PMb79nMa4/rcn5tohdrTgGvgLyMyZs=; b=P1IFLy41ST6hcfqr9xD0aoppbcyzNMJcDJHjtfmln4xcKs5koSMPw264xYy0z2ww2C tIem9BQqgeVLr2ki973su8KeSs9TXiOIWReYAox/mhC7aQTmd1MzbjTtZt63G9rN4HlC lUoBmNNYZC4Qyo0nTFttx0hCDtD/zrGdTWEBThB4zPN+r3ZeTSuLTrCPMK7ApSaYfert yTLWLa4umjUIiGdbGipwGnm1ZMUm/C+YvCyaZpNnR0xce99rsDi2WfUNfBRbYegHCSkx SqkjwK8hL8Rn57kbnhcAj2etrTypHkCR9ESkahuSB7k5OJ0tldP+Z/H4aixdhzEdqDhM F1Dw== X-Gm-Message-State: ALyK8tI4UigRu1Px0f5889OVik5nSW0ijVvSJFNoITCK1axxWFYLQAHvqcSR/4UF1tGSVw== X-Received: by 10.55.182.131 with SMTP id g125mr26374133qkf.171.1467385541770; Fri, 01 Jul 2016 08:05:41 -0700 (PDT) Received: from [192.168.1.41] ([191.115.55.42]) by smtp.gmail.com with ESMTPSA id 56sm1279537qtt.31.2016.07.01.08.05.22 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 01 Jul 2016 08:05:41 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: John Bradley In-Reply-To: <5773D3D1.9070105@gmx.net> Date: Fri, 1 Jul 2016 11:04:53 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5773D3D1.9070105@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-jwsreq-07 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 15:05:45 -0000 Thanks, I will try and get to the changes before the cut off. John B. > On Jun 29, 2016, at 9:57 AM, Hannes Tschofenig = wrote: >=20 > Hi Nat, Hi John, >=20 > thanks for your work on draft-ietf-oauth-jwsreq. I would like to get = the > document ready for the IESG and have therefore reviewed it. >=20 > Despite some minor issues I believe the document is in good shape. >=20 > Here are my comments: >=20 > ** Introduction >=20 > The example request in the introduction is longer than 72 characters. >=20 > s/textaual nature/textual nature >=20 > s/The request may be encrypted so that end-to-end confidentiality > may be obtained even if in the case TLS connection is terminated > at a gateway or a similar device. > /The request may be encrypted so that end-to-end confidentiality > can be provided even if the TLS connection is terminated > at a gateway. >=20 > FROM: >=20 >=20 > 1. The request can be signed so that an integrity check can be > implemented. If a suitable algorithm is used for the signing, > then it will provide verification of the client making the > request. >=20 > TO: > 1. The request may be signed so that the signer can be = authenticated > and the integrity of the request can be checked. >=20 >=20 > There are a few cases that request by reference are useful such as: >=20 > FROM: >=20 > 1. When it is desirable to reduced the size of transmitted request. > Since we are using application layer security, it may > substantially increase the size of the request particulary in = the > case of using public key cryptography. >=20 > TO: >=20 > 1. When it is desirable to reduce the size of transmitted request. > The use of application layer security increases the size of the = request, > particularly when public key cryptography is used. >=20 >=20 > You write: >=20 > 2. Static signature: The client can make a signed Request Object = and > put it at a place that the Authorization Server can access. = This > may just be done by a client utility or other process, so that > the private key does not have to reside on the client, > simplifying programming. Downside of it is that the signed > portion just become a token. >=20 > The downside is that there is that there is no indication of freshness > and I believe this is what you mean by "just became a token". I am not > sure that the term 'static signature' is the right term here. Just > delete the 'Static Signature:'. >=20 >=20 > Is the JWT a good match to encode the parameters of the request? Why > don't you just use a regular JSON object and apply the JOSE security > mechanisms to it. >=20 > Section 3: Request Object >=20 > You write: > " > To encrypt, JWE [RFC7516] is used. Note that JWE is always = integrity > protected, so if only integrity protection is desired, JWS signature > is not needed. > " >=20 > I think the last sentence should say: "... if only integrity = protection > is desired then JWE is not needed." >=20 > You write: >=20 > " > It can also be signed then encrypted. This is sometimes desired to > reduced the repudiation risk from the point of view of the receiver. > In this case, it MUST be signed then encrypted, with the result = being > a Nested JWT, as defined in JWT [RFC7519]. > "client_secret >=20 > What do you mean by "reduced the repudiation risk"? >=20 > It may help if you reference the example in Appendix A.2 of RFC 7519 > regarding a nest JWT. >=20 > You write: >=20 > " > REQUIRED OAuth 2.0 Authorization Request parameters that are not > included in the Request Object MUST be sent as query parameters. If > a required parameter is missing from both the query parameters and > the Request Object, the request is malformed. > " >=20 > s/REQUIRED/Required >=20 > That's a bit unfortunate that you have to send parameters twice -- = once > as query parameters and then again in the request object. > Is there no better way to design this? >=20 > Section 4: Authorization Request >=20 >=20 > You write: >=20 > " > The authorization request object MAY be signed AND/OR encrypted. > " >=20 > Why is this sentence needed when you have extensively spoken about = this > topic already in earlier chapters? > If you include it then write "The authorization request object MAY be > signed and/or encrypted." >=20 > For the entire document I believe it is worthwhile to state in the > terminology section that your usage of the term "signed" means = digitally > signing with asymmetric crypto system as well as using a MAC (which is = a > symmetric key primitive). >=20 >=20 > You write: >=20 > " > Servers MAY cache the contents of the resources referenced by Request > URIs. If the contents of the referenced resource could ever change, > the URI SHOULD include the base64url encoded SHA-256 hash as defined > in FIPS180-2 [FIPS180-2] of the referenced resource contents as the > fragment component of the URI. If the fragment value used for a URI > changes, that signals the server that any cached value for that URI > with the old fragment value is no longer valid. > " >=20 > I am not sure what this means. Can you provide an example? >=20 >=20 > You list a couple of restrictions of the request URI below" >=20 > " > The entire Request URI MUST NOT exceed 512 ASCII characters. There > are three reasons for this restriction. >=20 > 1. Many WAP / feature phones do not accept large payloads. The > restriction are typically either 512 or 1024 ASCII characters. >=20 > 2. The maximum URL length supported by older versions of Internet > Explorer is 2083 ASCII characters. >=20 > 3. On a slow connection such as 2G mobile connection, a large URL > would cause the slow response and using such is not advisable > from the user experience point of view. > " >=20 > I wonder how relevant they are (given that the size of the URI is > substantially increased due to the use of JWT & the JOSE work). > For example, are there still many WAP phones around that want to use > this mechanism? Are old versions of the Internet Explorer still an = issue? >=20 > Is a request by value even an option for a 2g mobile phone? >=20 > Section 5. Validating JWT-Based Requests >=20 > You write: "The Authorization Server MUST return an error if = decryption > fails." and "The Authorization Server MUST return an error if = signature > validation fails." Could you be a bit more precise about the error > message that is returned? =46rom Section 6 I don't see what the right > error response would be. >=20 >=20 > Section 8. Security Considerations: >=20 > FROM: >=20 > In addition to the all the security considerations discussed in = OAuth > 2.0 [RFC6819], the following security considerations SHOULD be taken > into account. >=20 > TO: >=20 > In addition to the all the security considerations discussed in = OAuth > 2.0 [RFC6819], the following security considerations should be taken > into account. >=20 > You write: >=20 > " > When sending the authorization request object through "request" > parameter, it SHOULD be signed with then considered appropriate > algorithm using [RFC7515]. The "alg=3Dnone" SHOULD NOT be used in = such > a case. > " >=20 > The use cases presented in the document talk about end-to-end security > and signed / encrypted requests. > Now, in the security consideration section it almost appears if there = is > the possibility that the request object would not experience any > security protection at all. >=20 > That does not appear right. It does not make sense to just send the > parameters in a different encoding only, or does it? I would only see = a > disadvantage doing that, namely the much larger size. >=20 >=20 > You write: >=20 > " > If the request object contains personally identifiable or sensitive > information, the "request_uri" MUST be of one-time use and MUST have > large enough entropy deemed necessary with applicable security > policy. For higher security requirement, using [RFC7516] is > client_secretstrongly > recommended. > " >=20 > Why is this so? Today, we send the same request in OAuth over TLS. > Why is there only a problem with the request_uri and not with sending > the request object? >=20 > I believe the biggest issue that should be discussed in the security > consideration section is the possibility that the request object may = not > be fresh. This introduces the possibility for replay attacks and = lowers > the quality of the end-to-end security protection. >=20 > It may also be good to motivate the application layer security > mechanisms a bit more. For example, what information is in the request > itself that requires encryption? >=20 > When I looked at the example I noticed the client_id and the absence = of > the client_secret. I wonder how the mechanism intersects with the > client_id and the client_secret. If a client has, for example, a = public > / private key pair configured then the use of JWS (with those > credentials) would provide much better security than a client_id and a > client_secret. >=20 > ** Section 11: References >=20 > [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security > (TLS) Protocol Version 1.2", RFC 5246, > DOI 10.17487/RFC5246, August 2008, > . >=20 > Could you reference the TLS BCP instead? > https://tools.ietf.org/html/rfc7525 >=20 >=20 > [FIPS180-2] > U.S. Department of Commerce and National Institute of > Standards and Technology, "Secure Hash Signature > Standard", FIPS 180-2, August 2002. >=20 > Defines Secure Hash Algorithm 256 (SHA256) >=20 > Could you reference RFC 6234 instead? > https://tools.ietf.org/html/rfc6234 >=20 >=20 > Ciao > Hannes >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Fri Jul 1 10:05:43 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3078212D76D for ; Fri, 1 Jul 2016 10:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.145 X-Spam-Level: X-Spam-Status: No, score=-4.145 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 mmtfaF7f4XdD for ; Fri, 1 Jul 2016 10:05:31 -0700 (PDT) Received: from nm19-vm0.bullet.mail.bf1.yahoo.com (nm19-vm0.bullet.mail.bf1.yahoo.com [98.139.213.162]) (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 C885A12D775 for ; Fri, 1 Jul 2016 10:05:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1467392723; bh=WIUif1lGEqKZHwhuzPQAHblEGPvWUA/M2akhCNqwPW8=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=QURewdsyGKSrZr+qssG6kWjFOhgDEhlxRSzfqWs+LzbPZmFP/+o1CJp4/x19cAQz9m7GXGSNfhkijNDmKWGM1xkj1u7k3Q5hvN9c5YZaXXnS9yQ+BqLkNRNGSpulVTms6/UZ6tYmPt83uQgCaRaYQb+kKjq4stH+Vi2saEfKro2RaeGSO4oIdBKt+Oemz8N2JxrNDZj2u4kU+nDR7Nfx69mxEviLuoxpHkQaKVQterFgWUp91g8u4QF2rZmUolaQjBAQeX01caEwR3IE/nFwO5s8DwSNTJOmWWZJm7UlsuUp0URBa3DbgIkJ4OxYhY8Mduks/dIT+gl2x0THOBJkOQ== Received: from [66.196.81.173] by nm19.bullet.mail.bf1.yahoo.com with NNFMP; 01 Jul 2016 17:05:23 -0000 Received: from [98.139.212.215] by tm19.bullet.mail.bf1.yahoo.com with NNFMP; 01 Jul 2016 17:05:23 -0000 Received: from [127.0.0.1] by omp1024.mail.bf1.yahoo.com with NNFMP; 01 Jul 2016 17:05:23 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 803670.22572.bm@omp1024.mail.bf1.yahoo.com X-YMail-OSG: ArvkQxkVM1lC0r3t5RYrzqP8IpnXWEX0C5VlDGLCHiIsdPvee0doT_KWNSRMAqr 4UxPVS22CU6eA4.9ov5e24ErYFqq0Ax3mPuwXGCbptV_VZooqXFa5_jlNJh7LCSwDLXpl5tMAoWy C636_kkvgKDR941nwoVyHdc.9hgg6rorZgMP8RDLMFjWritNZDk68ZMu_D.9dkIv91BOH06v7pHL XipNTYMyYyl2w9FjV0H1U9yOXXfYr8f1BDk5JNtjcwCgbSPoiNLcVYdH27jupSr_YA2XgiSCCyE2 FScBGn_7Jug50nrpfNiRZKWcY2rtg6CA_BDGCGi.YdzysCHivB4J2AwSzz7PYCZHWO5nJmfTRsMo ..J4.D3D.Z.Cy2KUabYyG4DpW.xqSp9hYKkgA6EdPB.TAJSdZR0vL8sAD4DsT3DHqC3lX9yONVs2 Qr7tkL8cnBuUt9mvsChHT4agEfVl03zpYMARJZ4YZiny6KBB78uDEhMZkjqYWXFaA144kCxtTWQx PMSWbl_t0FpKARgD1Wo0tAa5EwLwZuB4VthEJvg-- Received: from jws106131.mail.bf1.yahoo.com by sendmailws165.mail.bf1.yahoo.com; Fri, 01 Jul 2016 17:05:23 +0000; 1467392723.337 Date: Fri, 1 Jul 2016 17:05:09 +0000 (UTC) From: Oleg Gryb To: Jim Manico , "ve7jtb@ve7jtb.com" Message-ID: <235316006.458279.1467392709447.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: <994121658.55005.1467329084208.JavaMail.yahoo@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_458278_727064084.1467392709432" Archived-At: Cc: "oauth@ietf.org" , Liyu Yi Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Oleg Gryb List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 17:05:43 -0000 ------=_Part_458278_727064084.1467392709432 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable "Browsers now re-append =C2=A0fragments across 302 redirects unless they ar= e explicitly cleared this makes fragment encoding less safe than it was =C2= =A0when originally specified" - thanks Jim. Looks like a good reason for ve= tting this flow out. John,Please provide more details/links about re-appending fragments.=C2=A0 Thanks,Oleg. =20 From: Jim Manico To: Oleg Gryb =20 Cc: "oauth@ietf.org" ; Liyu Yi Sent: Thursday, June 30, 2016 10:25 PM Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit gran= t =20 Oleg! Hello! Great to see you pop up here with a similar concern. John Bradley just answered this thread with the details I was looking for (= thanks John, hat tip your way). He also mentioned details about fragment leakage: "Browsers now re-append =C2=A0fragments across 302 redirects unless they ar= e explicitly cleared this makes fragment encoding less safe than it was whe= n originally specified" Again, I'm new here but I'm grateful for this conversation. Aloha,--Jim Manico@Manicode On Jul 1, 2016, at 1:24 AM, Oleg Gryb wrote: We've discussed access tokens in URI back in 2010 (https://www.ietf.org/mai= l-archive/web/oauth/current/msg04043.html). There were two major objectives= when I was saying that it's not secure: 1. Fragment is not sent to a server by a browser. When I've asked if this i= s true for every browser in the world, nobody was able to answer.2. Replaci= ng with POST would mean a significant performance impact in some high volum= e implementations (I think it was Goole folks who were saying this, but I d= on't remember now). AFAIR, nobody was arguing about browsing history, so it's valid. So, 6 years later we're at square one with this and I hope that this time t= he community will be more successful with getting rid of secrets in URL. BTW, Jim, if you can come up with other scenarios when fragments can leak, = please share. It'll probably help the community with solving this problem f= aster than in 6 years. Thanks,Oleg. =20 From: Jim Manico To: Liyu Yi ; oauth@ietf.org=20 Sent: Wednesday, June 29, 2016 7:30 AM Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit gran= t =20 > Shouldn=E2=80=99t it be more secure if we change to use a post method fo= r access token, similar to the SAML does? I say yes. But please note I'm ve= ry new at this and someone with more experience will have more to say or co= rrect my comments. Here are a few more details to consider. 1) OAuth is a framework and not a standard, per se. Different authorizati= on servers will have different implementations that are not necessarily com= patible with other service providers. So there is no standard to break, per= se. 2) Sensitive data in a URI is a bad idea. They leak all over the place ev= en over HTTPS. Even in fragments. 3) Break the "rules" and find a way to submit sensitive data like access = tokens, session information or any other (even short term) sensitive data i= n a secure fashion. This includes POST, JSON data payloads over PUT/PATCH a= nd other verbs - all over well configured HTTPS. 4) If you really must submit sensitive data over GET , consider JWT/JWS/J= WE (with limited scopes/lifetimes) to provide message level confidentiality= and integrity. Aloha, Jim Manico Manicode Security https://www.manicode.com=20 On 6/27/16 9:30 PM, Liyu Yi wrote: =20 While we are working on a project with OAuth2 implementation, one questio= n arises from our engineers. We noticed at https://tools.ietf.org/html/draf= t-ietf-oauth-v2-31#page-30, it is specified that =C2=A0=C2=A0 (C)=C2=A0 Ass= uming the resource owner grants access, the authorization =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 server redirects the user-agent back to the cli= ent using the =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 redirection URI pr= ovided earlier.=C2=A0 The redirection URI includes =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 the access token in the URI fragment. =C2=A0 For my unde= rstanding, the browser keeps the URI fragment in the history, and this intr= oduces unexpected exposure of the access token. A user without authorizati= on for the resource can get the access token as long as he has the access t= o the browser. This can happen in a shared computer in library, or for an I= T staff who works on other employee=E2=80=99s computer. =C2=A0 Shouldn=E2= =80=99t it be more secure if we change to use a post method for access toke= n, similar to the SAML does? I feel there might be something I missed here.= Any advices will be appreciated. =20 =20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 =20 --=20 =20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 =20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 ------=_Part_458278_727064084.1467392709432 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
"Browse= rs now re-append  fragments across 302 redirects unless they are expli= citly cleared this makes fragment encoding less safe than it was  when= originally specified" - thanks Jim. Looks like a good reason for vetting t= his flow out.

John,
Please provide more details/links about re-appending fragments.&n= bsp;

Thanks,
Oleg.


=
From: Jim Manico <jim@manicode.com>
To: Oleg Gryb <oleg@gryb.info>=
Cc: "oauth@ietf.org" = <oauth@ietf.org>; Liyu Yi <liyuyi@gmail.com>
Sent: Thursday, June 30, 2016 10:25 PM Subject: Re: [OAUTH-WG]= Security concern for URI fragment as Implicit grant
Oleg! Hello! Great to see= you pop up here with a similar concern.

John Bradley just answered this thread with the details I was look= ing for (thanks John, hat tip your way).

He also mentioned details about fragment leakage:

"Browsers now re-append  fragments across 302 redirects u= nless they are explicitly cleared this makes fragment encoding less safe th= an it was when originally specified"

Again, I'm new here but I'm grateful for this conversation.

Aloha,
--
Jim Manico
@Manicode

On Jul 1, 2016, at 1:= 24 AM, Oleg Gryb <o= leg_gryb@yahoo.com> wrote:

We've discussed access tokens in URI back in= 2010 (https://www.ietf.org/mail-archive/web/o= auth/current/msg04043.html). There were two major objectives when I was= saying that it's not secure:

1. Fragment is no= t sent to a server by a browser. When I've asked if this is true for every = browser in the world, nobody was able to answer.
2. Replacing with PO= ST would mean a significant performance impact in some high volume implemen= tations (I think it was Goole folks who were saying this, but I don't remem= ber now).

AFAIR, nobody was arguing about brows= ing history, so it's valid.

So, 6 years later w= e're at square one with this and I hope that this time the community will b= e more successful with getting rid of secrets in URL.

BTW, Jim, if you can come up with other scenarios when fragments can= leak, please share. It'll probably help the community with solving this pr= oblem faster than in 6 years.

Thanks,
Oleg.=


<= div class=3D"yiv3279037857yahoo_quoted" id=3D"yiv3279037857yui_3_16_0_ym19_= 1_1467328188922_4614" style=3D"display:block;">

> Shouldn=E2=80=99t it be more secure if we change to use a post method for access token, similar to the SAML does?
I say yes= . But please note I'm very new at this and someone with more experience will have more to say or correct my comments.
Here are = a few more details to consider.
1) OAuth = is a framework and not a standard, per se. Different authorization servers will have different implementations that are not necessarily compatible with other service providers. So there is no standard to break, per se.
2) Sensitive data in a URI is a bad idea. They leak all over the place even over HTTPS. Even in fragments.
3) Break the "rules" and find a way to submit sensitive data like access tokens, session information or any other (even short term) sensitive data in a secure fashion. This includes POST, JSON data payloads over PUT/PATCH and other verbs - all over well configured HTTPS.
4) If you really must submit sensitive data over GET , consider JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level confidentiality and integrity.
Aloha,
Jim Manico
Manicode Security
https://www.manic=
ode.com

=
On 6/27/16 9:30 PM, Liyu Yi wro= te:
While we= are working on a project with OAuth2 implementation, one question arises from our engineers.
We notic= ed at https://tools.ietf.org/html/draft-ietf-oa= uth-v2-31#page-30, it is specified that
  
(C) = ; Assuming the resource owner grants access, the authorization
 &n= bsp;      server redirects the user-agent back to the client using the
 &n= bsp;      redirection URI provided earlier.  The redirection URI includes
 &n= bsp;      the access token in the URI fragment.
 
For my u= nderstanding, the browser keeps the URI fragment in the history, and this introduces unexpected exposure of the access token. A user without authorization for the resource can get the access token as long as he has the access to the browser. This can happen in a shared computer in library, or for an IT staff who works on other employee=E2=80=99s computer.
 
Shouldn= =E2=80=99t it be more secure if we change to use a post method for access token, similar to the SAML does?
I feel t= here might be something I missed here. Any advices will be appreciated.


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


--=20

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


=

_____________________________________= __________
OAuth mailing list
= OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth


------=_Part_458278_727064084.1467392709432-- From nobody Fri Jul 1 11:34:23 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A237412D5A2 for ; Fri, 1 Jul 2016 11:34:21 -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 9SrLhBHYTBb7 for ; Fri, 1 Jul 2016 11:34:18 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D132312D526 for ; Fri, 1 Jul 2016 11:34:17 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id c34so61919576qte.0 for ; Fri, 01 Jul 2016 11:34:17 -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=b6gUm7U5dwpZfVuTQrcVwP2KMXameBw25ZWVFVKLKsM=; b=urx7ucDB5Br/13wY/dFfDXzEydPhxFbxcd6Wu+nA/P4aSLIpXUjC3xnmFXRjV7KShO jUEUEkUMBYCjoh36NyHEXzKEaCa53hDWogzpjvumzo1mHfay4X+YsxyVkSrY+xnyFnwm 6x6rlSGl8Wu1B0TRreb/VQ/uCAs8vAmiuGPTxrbSRXQoalIYzA6XfyX3fnJ75+iY+GZM ROaVsKTbMzdfv3nX/mWeQNEpzaQu5fc6tOp6w6QfKyWZtuKJjkjECQATE4J3pUPURYh5 /XQ2iK8xRZNEhxRCBWH5ekFdmmJf2LH2kaAx2n+kAcAR2ArokG1s733T1Uf9yo/yiF68 Vv4A== 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=b6gUm7U5dwpZfVuTQrcVwP2KMXameBw25ZWVFVKLKsM=; b=BA2FC37LbmHv0JarOJCOBlBW+Pv1vMgg3U6p9x6Edbh5zt2iHpLDWrDkhJ7Ws1M9s4 QPfzxX67/RyJ31kedL7PgZU562UFXBFb9Gngrrv7qSqG3uWSmG6B7anxdVgVC9RjLp1+ 5eeF0C/ctpFdhCSbFyuAoiZ8F3bcHZ7sIrE5fTgUGe403raJPlPs6B/89EmqjWqtyFX9 Ae39qtDmgCniD80SsnzYwmRP+RLoLxpbUFcqPfdMCMq+exYR3IPaxDiD42Qdig4HYnMa poVjeYSSSlrRoED2Ck8BYkmPlBjLj34TVHZD+7+BM/Nr4EFUg26aqOaxSbaBKKgL39T7 /ekA== X-Gm-Message-State: ALyK8tJljqJ731GTBpgMsp21HCE2z+rq0T6B/OfOdpqBAXOl3S2ciXNMUtYbhEcXxRsAng== X-Received: by 10.237.42.65 with SMTP id c59mr8320151qtd.6.1467398056663; Fri, 01 Jul 2016 11:34:16 -0700 (PDT) Received: from [192.168.1.41] ([191.115.51.34]) by smtp.gmail.com with ESMTPSA id e187sm2538059qkc.19.2016.07.01.11.33.48 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 01 Jul 2016 11:34:16 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_47343B88-71A2-40CC-A986-465AD94C91FC" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: John Bradley In-Reply-To: <235316006.458279.1467392709447.JavaMail.yahoo@mail.yahoo.com> Date: Fri, 1 Jul 2016 14:33:15 -0400 Message-Id: <6584BD74-B18F-4174-9E69-5C7B4B76F895@ve7jtb.com> References: <994121658.55005.1467329084208.JavaMail.yahoo@mail.yahoo.com> <235316006.458279.1467392709447.JavaMail.yahoo@mail.yahoo.com> To: Oleg Gryb X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "oauth@ietf.org" , Liyu Yi Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 18:34:21 -0000 --Apple-Mail=_47343B88-71A2-40CC-A986-465AD94C91FC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This behaviour started changing around 2011 =46rom HTTP/1.1 See https://tools.ietf.org/html/rfc7231#section-7.1.2 = I f the Location value provided in a 3xx (Redirection) response does not have a fragment component, a user agent MUST process the redirection as if the value inherits the fragment component of the URI reference used to generate the request target (i.e., the redirection inherits the original reference's fragment, if any). For example, a GET request generated for the URI reference "http://www.example.org/~tim" might result in a 303 (See Other) response containing the header field: Location: /People.html#tim which suggests that the user agent redirect to "http://www.example.org/People.html#tim=E2=80=9D Likewise, a GET request generated for the URI reference "http://www.example.org/index.html#larry" might result in a 301 (Moved Permanently) response containing the header field: Location: http://www.example.net/index.html which suggests that the user agent redirect to "http://www.example.net/index.html#larry", preserving the original fragment identifier. This blog also explores the change. = https://blogs.msdn.microsoft.com/ieinternals/2011/05/16/url-fragments-and-= redirects/ = > On Jul 1, 2016, at 1:05 PM, Oleg Gryb wrote: >=20 > "Browsers now re-append fragments across 302 redirects unless they = are explicitly cleared this makes fragment encoding less safe than it = was when originally specified" - thanks Jim. Looks like a good reason = for vetting this flow out. >=20 > John, > Please provide more details/links about re-appending fragments.=20 >=20 > Thanks, > Oleg. >=20 >=20 > From: Jim Manico > To: Oleg Gryb =20 > Cc: "oauth@ietf.org" ; Liyu Yi > Sent: Thursday, June 30, 2016 10:25 PM > Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit = grant >=20 > Oleg! Hello! Great to see you pop up here with a similar concern. >=20 > John Bradley just answered this thread with the details I was looking = for (thanks John, hat tip your way). >=20 > He also mentioned details about fragment leakage: >=20 > "Browsers now re-append fragments across 302 redirects unless they = are explicitly cleared this makes fragment encoding less safe than it = was when originally specified" >=20 > Again, I'm new here but I'm grateful for this conversation. >=20 > Aloha, > -- > Jim Manico > @Manicode >=20 > On Jul 1, 2016, at 1:24 AM, Oleg Gryb > wrote: >=20 >> We've discussed access tokens in URI back in 2010 = (https://www.ietf.org/mail-archive/web/oauth/current/msg04043.html = ). = There were two major objectives when I was saying that it's not secure: >>=20 >> 1. Fragment is not sent to a server by a browser. When I've asked if = this is true for every browser in the world, nobody was able to answer. >> 2. Replacing with POST would mean a significant performance impact in = some high volume implementations (I think it was Goole folks who were = saying this, but I don't remember now). >>=20 >> AFAIR, nobody was arguing about browsing history, so it's valid. >>=20 >> So, 6 years later we're at square one with this and I hope that this = time the community will be more successful with getting rid of secrets = in URL. >>=20 >> BTW, Jim, if you can come up with other scenarios when fragments can = leak, please share. It'll probably help the community with solving this = problem faster than in 6 years. >>=20 >> Thanks, >> Oleg. >>=20 >>=20 >> From: Jim Manico > >> To: Liyu Yi >; = oauth@ietf.org =20 >> Sent: Wednesday, June 29, 2016 7:30 AM >> Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit = grant >>=20 >> > Shouldn=E2=80=99t it be more secure if we change to use a post = method for access token, similar to the SAML does? >> I say yes. But please note I'm very new at this and someone with more = experience will have more to say or correct my comments. >> Here are a few more details to consider. >> 1) OAuth is a framework and not a standard, per se. Different = authorization servers will have different implementations that are not = necessarily compatible with other service providers. So there is no = standard to break, per se. >> 2) Sensitive data in a URI is a bad idea. They leak all over the = place even over HTTPS. Even in fragments. >> 3) Break the "rules" and find a way to submit sensitive data like = access tokens, session information or any other (even short term) = sensitive data in a secure fashion. This includes POST, JSON data = payloads over PUT/PATCH and other verbs - all over well configured = HTTPS. >> 4) If you really must submit sensitive data over GET , consider = JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level = confidentiality and integrity. >> Aloha, >> Jim Manico >> Manicode Security >> https://www.manicode.com >> On 6/27/16 9:30 PM, Liyu Yi wrote: >>> While we are working on a project with OAuth2 implementation, one = question arises from our engineers. >>> We noticed at = https://tools.= ietf.org/html/draft-ietf-oauth-v2-31#page-30 = , it is = specified that >>> =20 >>> (C) Assuming the resource owner grants access, the authorization >>> server redirects the user-agent back to the client using the >>> redirection URI provided earlier. The redirection URI = includes >>> the access token in the URI fragment. >>> =20 >>> For my understanding, the browser keeps the URI fragment in the = history, and this introduces unexpected exposure of the access token. A = user without authorization for the resource can get the access token as = long as he has the access to the browser. This can happen in a shared = computer in library, or for an IT staff who works on other employee=E2=80=99= s computer. >>> =20 >>> Shouldn=E2=80=99t it be more secure if we change to use a post = method for access token, similar to the SAML does? >>> I feel there might be something I missed here. Any advices will be = appreciated. >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >> --=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >>=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 --Apple-Mail=_47343B88-71A2-40CC-A986-465AD94C91FC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 This behaviour started changing around 2011

=46rom HTTP/1.1
See https://tools.ietf.org/html/rfc7231#section-7.1.2I
      f the Location value provided in a 3xx = (Redirection) response does
   not =
have a fragment component, a user agent MUST process the
   redirection as if the value inherits the fragment component of the
   URI reference used to generate the request target (i.e., the
   redirection inherits the original reference's fragment, if any).

   For example, a GET request generated for the URI reference
   "http://www.example.org/~tim" might result in a 303 (See =
Other)
   response containing the header field:

     Location: /People.html#tim

   which suggests that the user agent redirect to
   "http://www.example.org/People.html#tim=E2=80=9D

Likewise, a GET request generated = for the URI reference "http://www.example.org/index.html#larry" might result in = a 301 (Moved Permanently) response containing the header field: Location: http://www.example.net/index.html which suggests that the user agent redirect to "http://www.example.net/index.html#larry", preserving the = original fragment identifier.


This blog also explores the = change.
https://blogs.msdn.microsoft.com/ieinternals/2011/05/16/url-fra= gments-and-redirects/


On Jul 1, 2016, at 1:05 PM, Oleg Gryb <oleg_gryb@yahoo.com>= wrote:

"Browsers now = re-append  fragments across 302 redirects unless they are = explicitly cleared this makes fragment encoding less safe than it was =  when originally specified" - thanks Jim. Looks like a good reason = for vetting this flow out.

John,
Please = provide more details/links about re-appending = fragments. 

Thanks,
Oleg.


=
=
= From: Jim Manico <jim@manicode.com>
To: Oleg Gryb <oleg@gryb.info>
Cc: "oauth@ietf.org" <oauth@ietf.org>; Liyu = Yi <liyuyi@gmail.com>
Sent: Thursday, June = 30, 2016 10:25 PM
Subject: Re: [OAUTH-WG] Security concern = for URI fragment as Implicit grant

Oleg! Hello! = Great to see you pop up here with a similar concern.

John Bradley just answered this thread with the details I was = looking for (thanks John, hat tip your way).

He= also mentioned details about fragment leakage:

"Browsers now re-append  fragments across 302 redirects = unless they are explicitly cleared this makes fragment encoding less = safe than it was when originally specified"

Again, I'm new here but I'm grateful for this = conversation.

Aloha,
--
Jim = Manico
@Manicode

On Jul 1, 2016, at 1:24 AM, Oleg Gryb <oleg_gryb@yahoo.com>= wrote:

We've = discussed access tokens in URI back in 2010 (https://www.ietf.org/mail-archive/web/oauth/current/msg04043.ht= ml). There were two major objectives when I was saying that it's not = secure:

1. = Fragment is not sent to a server by a browser. When I've asked if this = is true for every browser in the world, nobody was able to = answer.
2. = Replacing with POST would mean a significant performance impact in some = high volume implementations (I think it was Goole folks who were saying = this, but I don't remember now).

AFAIR,= nobody was arguing about browsing history, so it's valid.

So, = 6 years later we're at square one with this and I hope that this time = the community will be more successful with getting rid of secrets in = URL.

BTW, = Jim, if you can come up with other scenarios when fragments can leak, = please share. It'll probably help the community with solving this = problem faster than in 6 years.

Thanks,
Oleg.


=
From: Jim Manico <jim@manicode.com>
To: Liyu Yi <liyuyi@gmail.com>; oauth@ietf.org
Sent: Wednesday, June = 29, 2016 7:30 AM
Subject: Re: = [OAUTH-WG] Security concern for URI fragment as Implicit grant

> Shouldn=E2=80=99t= it be more secure if we change to use a post method for access token, similar to the SAML = does?
I say yes. But please note I'm very new at this and someone = with more experience will have more to say or correct my = comments.
Here are a few more details to consider.
1) OAuth is a framework and not a standard, per se. Different authorization servers will have different implementations that are not necessarily compatible with other service providers. So there is no standard to break, per se.
2) Sensitive data in a URI is a bad idea. They leak = all over the place even over HTTPS. Even in fragments.
3) Break the "rules" and find a way to submit = sensitive data like access tokens, session information or any other (even short term) sensitive data in a secure fashion. This includes POST, JSON data payloads over PUT/PATCH and other verbs - all over well configured HTTPS.
4) If you really must submit sensitive data over GET = , consider JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level confidentiality and integrity.
Aloha,
Jim Manico
Manicode Security
https://www.manicode.com

On 6/27/16 9:30 PM, Liyu Yi = wrote:
While = we are working on a project with OAuth2 implementation, one question arises from our engineers.
We = noticed at https:= //tools.ietf.org/html/draft-ietf-oauth-v2-31#page-30, it is specified that
  
(C)  Assuming the resource owner grants access, the authorization
        = server redirects the user-agent back to the client using the
        = redirection URI provided earlier.  The redirection URI includes
        the = access token in the URI fragment.
 
For = my understanding, the browser keeps the URI fragment in the history, and this introduces unexpected exposure of the access token. A user without authorization for the resource can get the access token as long as he has the access to the browser. This can happen in a shared computer in library, or for an IT staff who works on other employee=E2=80=99s computer.
 
Shouldn=E2=80=99t it be more secure if we change to use a post method for access token, similar to the SAML does?
I = feel there might be something I missed here. Any advices will be appreciated.


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


--=20

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


=

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


=
=

= --Apple-Mail=_47343B88-71A2-40CC-A986-465AD94C91FC-- From nobody Fri Jul 1 13:51:57 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0831E12B016 for ; Fri, 1 Jul 2016 13:51: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 g4egOOfCZQU5 for ; Fri, 1 Jul 2016 13:51:52 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d: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 5B3BC12D11C for ; Fri, 1 Jul 2016 13:51:52 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id j2so167794104qkf.3 for ; Fri, 01 Jul 2016 13:51:52 -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=Z2qfyLYMwSXOZ0NQbO/765S2abg/sdiHvu3u7mKX4TU=; b=RlFPvFcYZs0iwOoNELhMldbs/dc7uh2wYGCtCtFRh3DvE04TjZPYWv/Mm8wK5p/Q2J 6Q1yf0PGqN473xuNYDUQ6V157lscQar80/NB2u/KfG9w6BtmWpIOAoixrHYlWYJg0VUB pQw7xoHNhWEdwJP/gTMmQlh6sEl/w45CCcBNQoHzlx5W3+RuUqC6+YFKWcC+6ECb04gF iNamAg3N1fP8PC+SnLwmjjxFyIVByJN+Ke+yhcwz+lphCQrj3lNt8raL3DlvNzBI6OR5 KgcunQ3PeeBRjFq2uRFxPa/hO7hLfwxVAyZAshCjtNfw/pBdDY8YLQCFWmGrBgiccZHk tWwg== 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=Z2qfyLYMwSXOZ0NQbO/765S2abg/sdiHvu3u7mKX4TU=; b=SzMmlk2be8O4LjMxhNcmUVAgtB2UB4ETKtNRU2cN2YQiZm5W7SBYhCmasjZYYgumSE jx6ZEJ0SZnk7B8zroZhHQ+bMvXgZZFQ82u+meuYzCVde6XG2t/7G9uHBJ7AWlPWZkqYA YS5cbvxAowTVw1SRqp+1enoZUwQY+kc6HKtIt5v1PQ6hmcXaXw+G9Sp22LEc5LFVCoS3 v+XPqZpreWPCyP6GKv818BFSn1xXmzng+7McgQgnhsz18jITlIdwt/smL1WFj6PU9UtJ fHNt7U1P07bGdbAM+YsF8UKKsDMWDPi09abPyvwjSb/U/H6emojQLu6SbWMAF6lTvBv1 B93g== X-Gm-Message-State: ALyK8tKIQuCgdl+1+1c34nI40Yl5Z+jNPgXGsKOEeAIku+qrBafukapbGjztbOAU5U9/BeXuHn7vYiplkkI0228b X-Received: by 10.37.96.11 with SMTP id u11mr165177ybb.26.1467406311362; Fri, 01 Jul 2016 13:51:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.221.132 with HTTP; Fri, 1 Jul 2016 13:51:50 -0700 (PDT) X-Originating-IP: [191.115.51.34] In-Reply-To: References: <994121658.55005.1467329084208.JavaMail.yahoo@mail.yahoo.com> <235316006.458279.1467392709447.JavaMail.yahoo@mail.yahoo.com> <6584BD74-B18F-4174-9E69-5C7B4B76F895@ve7jtb.com> From: John Bradley Date: Fri, 1 Jul 2016 16:51:50 -0400 Message-ID: To: Liyu Yi Content-Type: multipart/alternative; boundary=001a1143edc4ee6c22053699278a Archived-At: Cc: Oleg Gryb , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 20:51:56 -0000 --001a1143edc4ee6c22053699278a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes but POST doesn't really work for in browser apps. If it is a server app it should be using the code flow with GET or POST as you like. If we do a post message based binding it will be targeted at in browser applications. John B. On Fri, Jul 1, 2016 at 4:42 PM, Liyu Yi wrote: > BTW, I do not see any significant performance concerns for post. Parsing > and executing the Javascript logic for post operation will be on the clie= nt > side, no extra server load is introduced. > > Plus post will remove the size restriction of the URL length. > > -- Liyu > > On Fri, Jul 1, 2016 at 1:35 PM, Liyu Yi wrote: > >> Thanks for the great comments and advices. >> >> I think it is a good idea for the working group to revise the fragment >> part in the spec, since there might be public available tools already >> implemented this approach and people can end up with a solution with >> serious security loopholes. >> >> The re-append issue can be mitigate by a logic on Resource Server which >> carefully re-writes/removes the fragment in any redirect, if the the >> redirect can not be avoided. >> >> -- Liyu >> >> >> On Fri, Jul 1, 2016 at 11:33 AM, John Bradley wrote: >> >>> This behaviour started changing around 2011 >>> >>> From HTTP/1.1 >>> See https://tools.ietf.org/html/rfc7231#section-7.1.2I >>> f the Location value provided in a 3xx (Redirection) response doe= s >>> >>> not have a fragment component, a user agent MUST process the >>> redirection as if the value inherits the fragment component of the >>> URI reference used to generate the request target (i.e., the >>> redirection inherits the original reference's fragment, if any). >>> >>> For example, a GET request generated for the URI reference >>> "http://www.example.org/~tim" might result in a 303 (See Other) >>> response containing the header field: >>> >>> Location: /People.html#tim >>> >>> which suggests that the user agent redirect to >>> "http://www.example.org/People.html#tim=E2=80=9D >>> >>> >>> Likewise, a GET request generated for the URI reference >>> "http://www.example.org/index.html#larry" might result in a 301 >>> (Moved Permanently) response containing the header field: >>> >>> Location: http://www.example.net/index.html >>> >>> which suggests that the user agent redirect to >>> "http://www.example.net/index.html#larry", preserving the original >>> fragment identifier. >>> >>> >>> >>> This blog also explores the change. >>> >>> https://blogs.msdn.microsoft.com/ieinternals/2011/05/16/url-fragments-a= nd-redirects/ >>> >>> >>> On Jul 1, 2016, at 1:05 PM, Oleg Gryb wrote: >>> >>> "Browsers now re-append fragments across 302 redirects unless they are >>> explicitly cleared this makes fragment encoding less safe than it was = when >>> originally specified" - thanks Jim. Looks like a good reason for vettin= g >>> this flow out. >>> >>> John, >>> Please provide more details/links about re-appending fragments. >>> >>> Thanks, >>> Oleg. >>> >>> >>> ------------------------------ >>> *From:* Jim Manico >>> *To:* Oleg Gryb >>> *Cc:* "oauth@ietf.org" ; Liyu Yi >>> *Sent:* Thursday, June 30, 2016 10:25 PM >>> *Subject:* Re: [OAUTH-WG] Security concern for URI fragment as Implicit >>> grant >>> >>> Oleg! Hello! Great to see you pop up here with a similar concern. >>> >>> John Bradley just answered this thread with the details I was looking >>> for (thanks John, hat tip your way). >>> >>> He also mentioned details about fragment leakage: >>> >>> "Browsers now re-append fragments across 302 redirects unless they are >>> explicitly cleared this makes fragment encoding less safe than it was w= hen >>> originally specified" >>> >>> Again, I'm new here but I'm grateful for this conversation. >>> >>> Aloha, >>> -- >>> Jim Manico >>> @Manicode >>> >>> On Jul 1, 2016, at 1:24 AM, Oleg Gryb wrote: >>> >>> We've discussed access tokens in URI back in 2010 ( >>> https://www.ietf.org/mail-archive/web/oauth/current/msg04043.html). >>> There were two major objectives when I was saying that it's not secure: >>> >>> 1. Fragment is not sent to a server by a browser. When I've asked if >>> this is true for every browser in the world, nobody was able to answer. >>> 2. Replacing with POST would mean a significant performance impact in >>> some high volume implementations (I think it was Goole folks who were >>> saying this, but I don't remember now). >>> >>> AFAIR, nobody was arguing about browsing history, so it's valid. >>> >>> So, 6 years later we're at square one with this and I hope that this >>> time the community will be more successful with getting rid of secrets = in >>> URL. >>> >>> BTW, Jim, if you can come up with other scenarios when fragments can >>> leak, please share. It'll probably help the community with solving this >>> problem faster than in 6 years. >>> >>> Thanks, >>> Oleg. >>> >>> >>> ------------------------------ >>> *From:* Jim Manico >>> *To:* Liyu Yi ; oauth@ietf.org >>> *Sent:* Wednesday, June 29, 2016 7:30 AM >>> *Subject:* Re: [OAUTH-WG] Security concern for URI fragment as Implicit >>> grant >>> >>> > Shouldn=E2=80=99t it be more secure if we change to use a post method= for >>> access token, similar to the SAML does? >>> I say yes. But please note I'm very new at this and someone with more >>> experience will have more to say or correct my comments. >>> Here are a few more details to consider. >>> 1) OAuth is a framework and not a standard, per se. Different >>> authorization servers will have different implementations that are not >>> necessarily compatible with other service providers. So there is no >>> standard to break, per se. >>> 2) Sensitive data in a URI is a bad idea. They leak all over the place >>> even over HTTPS. Even in fragments. >>> 3) Break the "rules" and find a way to submit sensitive data like acces= s >>> tokens, session information or any other (even short term) sensitive da= ta >>> in a secure fashion. This includes POST, JSON data payloads over PUT/PA= TCH >>> and other verbs - all over well configured HTTPS. >>> 4) If you really must submit sensitive data over GET , consider >>> JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level >>> confidentiality and integrity. >>> Aloha, >>> >>> Jim Manico >>> Manicode Securityhttps://www.manicode.com >>> >>> >>> On 6/27/16 9:30 PM, Liyu Yi wrote: >>> >>> While we are working on a project with OAuth2 implementation, one >>> question arises from our engineers. >>> We noticed at >>> >>> https://tools.ietf.org/html/draft-ietf-oauth-v2-31#page-30, it is >>> specified that >>> >>> (C) Assuming the resource owner grants access, the authorization >>> server redirects the user-agent back to the client using the >>> redirection URI provided earlier. The redirection URI includes >>> the access token in the URI fragment. >>> >>> For my understanding, the browser keeps the URI fragment in the history= , >>> and this introduces unexpected exposure of the access token. A user wit= hout >>> authorization for the resource can get the access token as long as he h= as >>> the access to the browser. This can happen in a shared computer in libr= ary, >>> or for an IT staff who works on other employee=E2=80=99s computer. >>> >>> Shouldn=E2=80=99t it be more secure if we change to use a post method f= or access >>> token, similar to the SAML does? >>> I feel there might be something I missed here. Any advices will be >>> appreciated. >>> >>> >>> _______________________________________________ >>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/o= auth >>> >>> >>> -- >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> >> > --001a1143edc4ee6c22053699278a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes but POST doesn't really work for in browser apps.<= div>
If it is a server app it should be using the code flow w= ith GET or POST as you like.

If we do a =C2=A0post= message based binding it will be targeted at in browser applications.

John B.

On Fri, Jul 1, 2016 at 4:42 PM, Liyu Yi <liyuyi@gmai= l.com> wrote:
BTW, I do not see any significant performance concerns for post. Parsin= g and executing the Javascript logic for post operation will be on the clie= nt side, no extra server load is introduced.

Plus post w= ill remove the size restriction of the URL length.

-- Liyu=C2=A0
<= /span>

On Fri, Jul 1, 2016 at 1:35 PM, Liyu Yi = <liyuyi@gmail.com> wrote:
<= div dir=3D"ltr">
Thanks for the great comments and advices.
<= br>
I think it is a good idea for the working group to revise the frag= ment part in the spec, since there might be public available tools already = implemented this approach and people can end up with a solution with seriou= s security loopholes.

The re-append issue can be mitigat= e by a logic on Resource Server which carefully re-writes/removes the fragm= ent in any redirect, if the the redirect can not be avoided.

-- Liyu
=C2=A0

On Fri, Jul 1, 2016 at 11:33 AM, John Bradley <ve7jtb@= ve7jtb.com> wrote:
This behaviour started changing around 2011
From HTTP/1.1
=C2=A0 =C2=A0 =C2=A0 f the = Location value provided in a 3xx (Redirection) response does
not have a fragment component, a user agent MUST process the redirection as if the value inherits the fragment component of the URI reference used to generate the request target (i.e., the redirection inherits the original reference's fragment, if any). For example, a GET request generated for the URI reference "http://w= ww.example.org/~tim" might result in a 303 (See Other) response containing the header field: Location: /People.html#tim which suggests that the user agent redirect to "http://www.example.org/People.html#tim=E2=80=9D
   Likewise, a GET request generated for the URI re=
ference
   "http://www.example.org/index.html#larry" might result in a 301
   (Moved Permanently) response containing the header field:

     Location: http://www.example.net/index.html

   which suggests that the user agent redirect to
   "http://www.example.net/index.html#larry", preserving the origi=
nal
   fragment identifier.


This blog also explores the = change.
https://blogs.msd= n.microsoft.com/ieinternals/2011/05/16/url-fragments-and-redirects/


On = Jul 1, 2016, at 1:05 PM, Oleg Gryb <oleg_gryb@yahoo.com> wrote:

=
"Brow= sers now re-append =C2=A0fragments across 302 redirects unless they are exp= licitly cleared this makes fragment encoding less safe than it was =C2=A0wh= en originally specified" - thanks Jim. Looks like a good reason for ve= tting this flow out.

=
John,
Please provide more details/links a= bout re-appending fragments.=C2=A0

=
Thanks,
Oleg.


From: Jim Manico= <jim@manicode.com= >
To: Oleg Gryb &= lt;oleg@gryb.info&g= t;
Cc: "oauth@ietf.org" <oauth@ietf.org>; Liyu= Yi <liyuyi@gmail.= com>
Sent: Thursd= ay, June 30, 2016 10:25 PM
Subject:= Re: [OAUTH-WG] Security concern for URI fragment as Implicit gr= ant

Oleg! Hello! Great to see yo= u pop up here with a similar concern.

John Bradley just answered this thread with the details I was looking fo= r (thanks John, hat tip your way).

= He also mentioned details about fragment leakage:

"Browsers now re-append =C2=A0fragments across 30= 2 redirects unless they are explicitly cleared this makes fragment encoding= less safe than it was when originally specified"
Again, I'm new here but I'm grateful for= this conversation.

Aloha,
--
Jim Manico
@Manicode
On Jul 1, 2016, at 1:24 AM, Oleg Gryb <ole= g_gryb@yahoo.com> wrote:

=
We've discussed access tokens in URI ba= ck in 2010 (htt= ps://www.ietf.org/mail-archive/web/oauth/current/msg04043.html). There = were two major objectives when I was saying that it's not secure:
=

1. Fragment is n= ot sent to a server by a browser. When I've asked if this is true for e= very browser in the world, nobody was able to answer.
2. Replacing with POST would mean a significant performance impact in some= high volume implementations (I think it was Goole folks who were saying th= is, but I don't remember now).

AFAIR, nobody was arguing about browsing history, s= o it's valid.

So, 6 years later we're at square one with this and I hope tha= t this time the community will be more successful with getting rid of secre= ts in URL.

= BTW, Jim, if you can come up with other scenarios when fragments can leak, = please share. It'll probably help the community with solving this probl= em faster than in 6 years.

<= div dir=3D"ltr">Thanks,
Oleg.


From: Jim Manico <jim@manicode.com><= br clear=3D"none"> To: Liyu = Yi <liyuyi@gmail.com>; oauth@ietf.org Sent: Wedne= sday, June 29, 2016 7:30 AM
Subject: Re: [OAUTH-WG] Security concern for URI fragmen= t as Implicit grant

> Shouldn=E2=80=99t it be more secure if we change to use a post method for access token, similar to the SAML does?
I say yes. But please note I'm very new at this and someone wi= th more experience will have more to say or correct my comments.
Here are a few more details to consider.
1) OAuth is a framework and not a standard, per se. Different authorization servers will have different implementations that are not necessarily compatible with other service providers. So there is no standard to break, per se.
2) Sensitive data in a URI is a bad idea. They leak all over the place even over HTTPS. Even in fragments.
3) Break the "rules" and find a way to submit sensitive = data like access tokens, session information or any other (even short term) sensitive data in a secure fashion. This includes POST, JSON data payloads over PUT/PATCH and other verbs - all over well configured HTTPS.
4) If you really must submit sensitive data over GET , consider JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level confidentiality and integrity.
Aloha,
Jim Manico
Manicode Security
https://www.manicode.com

On 6/27/16 9:30 PM, Liyu Yi wrote:
While we are working on a project with OAuth2 implementation, one question arises from our engineers.
=C2=A0=C2=A0
(C)=C2=A0 Assuming the resource owner grants access, the authorization
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 server redire= cts the user-agent back to the client using the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 redirection U= RI provided earlier.=C2=A0 The redirection URI includes
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the access to= ken in the URI fragment.
=C2=A0
For my understanding, the browser keeps the URI fragment in the history, and this introduces unexpected exposure of the access token. A user without authorization for the resource can get the access token as long as he has the access to the browser. This can happen in a shared computer in library, or for an IT staff who works on other employee=E2=80=99s computer.
=C2=A0
Shouldn=E2=80=99t it be more secure if we change to use a post method for access token, similar to the SAML does?
I feel there might be something I missed here. Any advices will be appreciated.


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


--=20




____________________________= ___________________
OAuth mailing list
= OAuth@ie= tf.org
https://www.ietf.org/mailman/lis= tinfo/oauth






--001a1143edc4ee6c22053699278a-- From nobody Fri Jul 1 13:52:54 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1863612D1EB for ; Fri, 1 Jul 2016 13:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 UnOo3LEY-Kwd for ; Fri, 1 Jul 2016 13:52:50 -0700 (PDT) Received: from nm38-vm9.bullet.mail.bf1.yahoo.com (nm38-vm9.bullet.mail.bf1.yahoo.com [72.30.239.25]) (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 8023012B016 for ; Fri, 1 Jul 2016 13:52:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1467406369; bh=xTQsDnb706kmWQ8hIzN42c+d49n+l7QyseqcMaY2HXE=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=WXlqsRdlwgzvljIjsXl/nEQ5w2iTF3zeKWwakhAH2t5DrVfIrbA/l1Vvzrfklm/0N5CchtzzNP7OiRUVxJ2HU399rNLKbhtYE12Qi43VDEt+ZKTqvZ23ai6LfS+rfg9WRXDdAjCOLE8DJ2f9heARhshTakKJ41OOm/iZzgnVwJW17WQGCdDMKwcaoAzWLmdm513w349GsMzHcZWwAB9JNL1tB1plLqoKH6eMuWs8FVgP8Rnz10JTQ3543FO+t7ykunQiPJqwFOd7jOahrDzvNzKpEpr0onG9URCuYt9Aq/M1wSt4xl6mfXhzH285iPuvHwdfqwMBKKdAZr+VRRSt/A== Received: from [98.139.215.143] by nm38.bullet.mail.bf1.yahoo.com with NNFMP; 01 Jul 2016 20:52:49 -0000 Received: from [98.139.212.192] by tm14.bullet.mail.bf1.yahoo.com with NNFMP; 01 Jul 2016 20:52:49 -0000 Received: from [127.0.0.1] by omp1001.mail.bf1.yahoo.com with NNFMP; 01 Jul 2016 20:52:49 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 459502.88600.bm@omp1001.mail.bf1.yahoo.com X-YMail-OSG: UNEM09cVM1m_qAIgKrSrQ6HQwz5P7_qjfTdP_uoz3dAXUQU0a469xa9fWody1ay i4GO99xKCil3TVzEDOgCd6fnOSO1xRCx9TAufmJXsI6rxQyQGQOco.Mb1NafMXynii15mCFtMSVu tOF8f1l6lvfANo_B.hXfa8Ye0eYEuOmUqgYWz0auSs4Y2TYu1ZeCuL9zJN4R6uuVlzXfJFdzAjF7 bLdA6a__4vS.21nyb9KJ17WgzGuW0F6_9H6NqHJ_YfZ8N7yFXz6GVcIj6Qv4nsY1c5mG8fvEtdG3 wAEsmIXPgSgjgX9IvLkLyCtJZi9FBeC.vQgJrJsaq1VeRTTP1l8UdTfNqV9LphihMETHngD7bvRU C6kuXsm8O2Hu2cS5ZH4twI3zRq3ThzTzOO156ufgC89jTawmF_o.Xox6Oj8Vo.caWcyMDysi_ft1 yvZQQafMaQYPkK6b1_eRdXiW5MfKvhepmgr_ZqrdlFRr0X7M_34CK.RcBlSRHD.O9AYyUBiEqf9R 9sGx1UYzxYu2GAP72JQ4vQcEla1M- Received: from jws10628.mail.bf1.yahoo.com by sendmailws110.mail.bf1.yahoo.com; Fri, 01 Jul 2016 20:52:48 +0000; 1467406368.890 Date: Fri, 1 Jul 2016 20:52:48 +0000 (UTC) From: Oleg Gryb To: John Bradley , Oleg Gryb Message-ID: <717734404.555393.1467406368492.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <6584BD74-B18F-4174-9E69-5C7B4B76F895@ve7jtb.com> References: <994121658.55005.1467329084208.JavaMail.yahoo@mail.yahoo.com> <235316006.458279.1467392709447.JavaMail.yahoo@mail.yahoo.com> <6584BD74-B18F-4174-9E69-5C7B4B76F895@ve7jtb.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_555392_1405352965.1467406368475" Archived-At: Cc: "oauth@ietf.org" , Liyu Yi Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Oleg Gryb List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 20:52:54 -0000 ------=_Part_555392_1405352965.1467406368475 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable John, Thanks, very useful. However, I'm still trying to figure out why it's dange= rous. Fragment doesn't travel to a server in this new flow either. Appendin= g it to Location header is done by the browser who needs to memorize what t= he original request was. If the original request had a fragment and the bro= wser got redirected, Location header will be appended by the browser. Are you saying that this is dangerous because the browser would *always* ne= ed to store the fragment somewhere in its memory just in case if a server d= ecides to redirect? So an attack vector here is that an imposter can try to retrieve the fragme= nt from the browser's memory somehow. Is my understanding correct? Oleg. =20 From: John Bradley To: Oleg Gryb =20 Cc: "oauth@ietf.org" ; Liyu Yi Sent: Friday, July 1, 2016 11:33 AM Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit gran= t =20 This behaviour started changing around 2011 >From HTTP/1.1See=C2=A0https://tools.ietf.org/html/rfc7231#section-7.1.2I=C2= =A0 =C2=A0 =C2=A0 f the Location value provided in a 3xx (Redirection) resp= onse does not have a fragment component, a user agent MUST process the redirection as if the value inherits the fragment component of the URI reference used to generate the request target (i.e., the redirection inherits the original reference's fragment, if any). For example, a GET request generated for the URI reference "http://www.example.org/~tim" might result in a 303 (See Other) response containing the header field: Location: /People.html#tim which suggests that the user agent redirect to "http://www.example.org/People.html#tim=E2=80=9D Likewise, a GET request generated for the URI reference "http://www.example.org/index.html#larry" might result in a 301 (Moved Permanently) response containing the header field: Location: http://www.example.net/index.html which suggests that the user agent redirect to "http://www.example.net/index.html#larry", preserving the original fragment identifier. This blog also explores the change.https://blogs.msdn.microsoft.com/ieinter= nals/2011/05/16/url-fragments-and-redirects/ On Jul 1, 2016, at 1:05 PM, Oleg Gryb wrote: "Browsers now re-append =C2=A0fragments across 302 redirects unless they ar= e explicitly cleared this makes fragment encoding less safe than it was =C2= =A0when originally specified" - thanks Jim. Looks like a good reason for ve= tting this flow out. John,Please provide more details/links about re-appending fragments.=C2=A0 Thanks,Oleg. =20 From: Jim Manico To: Oleg Gryb =20 Cc: "oauth@ietf.org" ; Liyu Yi Sent: Thursday, June 30, 2016 10:25 PM Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit gran= t =20 Oleg! Hello! Great to see you pop up here with a similar concern. John Bradley just answered this thread with the details I was looking for (= thanks John, hat tip your way). He also mentioned details about fragment leakage: "Browsers now re-append =C2=A0fragments across 302 redirects unless they ar= e explicitly cleared this makes fragment encoding less safe than it was whe= n originally specified" Again, I'm new here but I'm grateful for this conversation. Aloha,--Jim Manico@Manicode On Jul 1, 2016, at 1:24 AM, Oleg Gryb wrote: We've discussed access tokens in URI back in 2010 (https://www.ietf.org/mai= l-archive/web/oauth/current/msg04043.html). There were two major objectives= when I was saying that it's not secure: 1. Fragment is not sent to a server by a browser. When I've asked if this i= s true for every browser in the world, nobody was able to answer.2. Replaci= ng with POST would mean a significant performance impact in some high volum= e implementations (I think it was Goole folks who were saying this, but I d= on't remember now). AFAIR, nobody was arguing about browsing history, so it's valid. So, 6 years later we're at square one with this and I hope that this time t= he community will be more successful with getting rid of secrets in URL. BTW, Jim, if you can come up with other scenarios when fragments can leak, = please share. It'll probably help the community with solving this problem f= aster than in 6 years. Thanks,Oleg. =20 From: Jim Manico To: Liyu Yi ; oauth@ietf.org=20 Sent: Wednesday, June 29, 2016 7:30 AM Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit gran= t =20 > Shouldn=E2=80=99t it be more secure if we change to use a post method fo= r access token, similar to the SAML does? I say yes. But please note I'm ve= ry new at this and someone with more experience will have more to say or co= rrect my comments. Here are a few more details to consider. 1) OAuth is a framework and not a standard, per se. Different authorizati= on servers will have different implementations that are not necessarily com= patible with other service providers. So there is no standard to break, per= se. 2) Sensitive data in a URI is a bad idea. They leak all over the place ev= en over HTTPS. Even in fragments. 3) Break the "rules" and find a way to submit sensitive data like access = tokens, session information or any other (even short term) sensitive data i= n a secure fashion. This includes POST, JSON data payloads over PUT/PATCH a= nd other verbs - all over well configured HTTPS. 4) If you really must submit sensitive data over GET , consider JWT/JWS/J= WE (with limited scopes/lifetimes) to provide message level confidentiality= and integrity. Aloha, Jim Manico Manicode Security https://www.manicode.com=20 On 6/27/16 9:30 PM, Liyu Yi wrote: =20 While we are working on a project with OAuth2 implementation, one questio= n arises from our engineers. We noticed at https://tools.ietf.org/html/draf= t-ietf-oauth-v2-31#page-30, it is specified that =C2=A0=C2=A0 (C)=C2=A0 Ass= uming the resource owner grants access, the authorization =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 server redirects the user-agent back to the cli= ent using the =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 redirection URI pr= ovided earlier.=C2=A0 The redirection URI includes =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 the access token in the URI fragment. =C2=A0 For my unde= rstanding, the browser keeps the URI fragment in the history, and this intr= oduces unexpected exposure of the access token. A user without authorizati= on for the resource can get the access token as long as he has the access t= o the browser. This can happen in a shared computer in library, or for an I= T staff who works on other employee=E2=80=99s computer. =C2=A0 Shouldn=E2= =80=99t it be more secure if we change to use a post method for access toke= n, similar to the SAML does? I feel there might be something I missed here.= Any advices will be appreciated. =20 =20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 =20 --=20 =20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 =20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 =20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 ------=_Part_555392_1405352965.1467406368475 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
John,

Thanks, very useful. However, I'm still trying= to figure out why it's dangerous. Fragment doesn't travel to a server in t= his new flow either. Appending it to Location header is done by the browser= who needs to memorize what the original request was. If the original reque= st had a fragment and the browser got redirected, Location header will be a= ppended by the browser.

Are you sayin= g that this is dangerous because the browser would *always* need to store t= he fragment somewhere in its memory just in case if a server decides to red= irect?

So an attack vector here is th= at an imposter can try to retrieve the fragment from the browser's memory s= omehow. Is my understanding correct?

= Oleg.


From: John B= radley <ve7jtb@ve7jtb.com>
= To: Oleg Gryb <oleg@gryb.info>
Cc: "oauth@ietf.org" <oauth@ietf.org>; Liyu= Yi <liyuyi@gmail.com>
Sent= : Friday, July 1, 2016 11:33 AM
Subject: Re: [OAUTH-WG] Security concern for URI fragm= ent as Implicit grant
This behaviour started changing around 2011=

From HTTP/1.1
See = https://tools.ietf.org/html/rfc7231#section-7.1.2I
      f the Location value provided in a 3xx (Red= irection) response does
   not have a fragment component, a user agent MUST process t=
he
   redirection as if the value inherits the fragment component of the
   URI reference used to generate the request target (i.e., the
   redirection inherits the original reference's fragment, if any).

   For example, a GET request generated for the URI reference
   "http://www.example.org/~tim"=
 might result in a 303 (See Other)
   response containing the header field:

     Location: /People.html#tim

   which suggests that the user agent redirect to
   "http://www.example.or=
g/People.html#tim=E2=80=9D

   =
Likewise, a GET request generated for the URI reference
   "http://www.example.o=
rg/index.html#larry" might result in a 301
   (Moved Permanently) response containing the header field:

     Location: http://www.exam=
ple.net/index.html

   which suggests that the user agent redirect to
   "http://www.example.n=
et/index.html#larry", preserving the original
   fragment identifier.


This blog also explores the= change.
https://blo= gs.msdn.microsoft.com/ieinternals/2011/05/16/url-fragments-and-redirects/


On Jul 1, 2016, at 1:05 PM, Oleg Gryb <oleg_gryb@yahoo.co= m> wrote:

"Browsers now = re-append  fragments across 302 redirects unless they are explicitly c= leared this makes fragment encoding less safe than it was  when origin= ally specified" - thanks Jim. Looks like a good reason for vetting this flo= w out.

John,
Please provide more details/links about re-appending fragments. =

Thanks,
Oleg.
<= div class=3D"yiv0584073324qtdSeparateBR" id=3D"yiv0584073324yui_3_16_0_ym19= _1_1467392120814_3456">

From:<= /b> Jim Manico <jim@manicode.com>
To: Oleg Gryb <oleg@gryb.info>
Cc: "oauth@ietf.org" <oauth@ietf.= org>; Liyu Yi <liyuyi@gmail.com>
Sent: Thursday, June 30, 2016 10:25 PM Subject: Re:= [OAUTH-WG] Security concern for URI fragment as Implicit grant

Oleg! Hello! Great to see you pop up here wi= th a similar concern.

John Bradley = just answered this thread with the details I was looking for (thanks John, = hat tip your way).

He also mentione= d details about fragment leakage:

=
"= Browsers now re-append  fragments across 302 re= directs unless they are explicitly cleared this makes fragment encoding les= s safe than it was when originally specified"

Again, I'm new here but I'm grateful for this conversatio= n.

Aloha,
--
Jim Manico
@Manicode

On Jul 1, 2016, at 1:24 AM, Oleg Gryb <oleg= _gryb@yahoo.com> wrote:
We've discussed access tokens in URI back in 2010 (https://www.ie= tf.org/mail-archive/web/oauth/current/msg04043.html). There were two ma= jor objectives when I was saying that it's not secure:

1. Fragment is not sent to a server by a browser. When I've asked if t= his is true for every browser in the world, nobody was able to answer.
2. Replacing with POST would mean a significant per= formance impact in some high volume implementations (I think it was Goole f= olks who were saying this, but I don't remember now).

AFAIR, nobody was arguing about browsing history, so it's valid.
<= div class=3D"yiv0584073324" dir=3D"ltr" id=3D"yiv0584073324yui_3_16_0_ym19_= 1_1467328188922_4546">
So, 6 years later we're at square one with this and I ho= pe that this time the community will be more successful with getting rid of= secrets in URL.

BTW, Jim, if you can come up with= other scenarios when fragments can leak, please share. It'll probably help= the community with solving this problem faster than in 6 years.

Thanks,
Oleg.


From: Jim Manic= o <jim@manicode.com>
To: Liyu Yi <liyuyi@gmail.com>; oauth@ietf.org
Sent: Wednesday, June 29, 2016 7:30 AM
Subject: Re: [OAUTH-WG] Security concern for URI fragment as Im= plicit grant

> Shouldn=E2=80=99t it be more secure if we c= hange to use a post method for access token, similar to the SAML does?
I say yes. But please note I'm very new at this and someone = with more experience will have more to say or correct my comments.
Here are a few more details to consider.
1) OAuth is a framework and not a standard, per se. Differen= t authorization servers will have different implementations that are not necessarily compatible with other service providers. So there is no standard to break, per se.
2) Sensitive data in a URI is a bad idea. = They leak all over the place even over HTTPS. Even in fragments.
3) Break the "rules" and find a way to sub= mit sensitive data like access tokens, session information or any other (even short term) sensitive data in a secure fashion. This includes POST, JSON data payloads over PUT/PATCH and other verbs - all over well configured HTTPS.
4) If you really must submit sensitive dat= a over GET , consider JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level confidentiality and integrity.
Aloha,
Jim Manico
Manicode Security
https://www.manic=
ode.com

=
On 6/27/16 9:30 PM, Liyu Yi wro= te:
While we= are working on a project with OAuth2 implementation, one question arises from our engineers.
We notic= ed at https://tools.iet= f.org/html/draft-ietf-oauth-v2-31#page-30, it is specified that
  
(C) = ; Assuming the resource owner grants access, the authorization
 &n= bsp;      server redirects the user-agent back to the client using the
 &n= bsp;      redirection URI provided earlier.  The redirection URI includes
 &n= bsp;      the access token in the URI fragment.
 
For my u= nderstanding, the browser keeps the URI fragment in the history, and this introduces unexpected exposure of the access token. A user without authorization for the resource can get the access token as long as he has the access to the browser. This can happen in a shared computer in library, or for an IT staff who works on other employee=E2=80=99s computer.
 
Shouldn= =E2=80=99t it be more secure if we change to use a post method for access token, similar to the SAML does?
I feel t= here might be something I missed here. Any advices will be appreciated.


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


--=20

______________________= _________________________
OAuth m= ailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



_______________________________________________
OAuth mailing list
OAuth@ietf.org
<= a rel=3D"nofollow" shape=3D"rect" class=3D"yiv0584073324" target=3D"_blank"= href=3D"https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.org/= mailman/listinfo/oauth
=


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


<= /div> ------=_Part_555392_1405352965.1467406368475-- From nobody Fri Jul 1 13:56:58 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AACE312D7E9 for ; Fri, 1 Jul 2016 13:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OcRZP532Il3O for ; Fri, 1 Jul 2016 13:56:54 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d: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 8AAC412D7BA for ; Fri, 1 Jul 2016 13:56:51 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id e3so20131767qkd.0 for ; Fri, 01 Jul 2016 13:56:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EoJ3ORZFlbE9fdrK8hLpMgqZU3/mDwGmdY/pY20T1rk=; b=EcwYfYLgU0fBErh7fdpYdPFzOgEIC7puhdo4/qBu90En/Li2a1y0rSkBc895ulo5P3 ZDI0hCTV5CWI2zMlVAZm3i1DUyAKGHD2PJk31avrD6Ielij/W5FofSoCsWLG2ynRuY8J UPn7Jk/FQQF53rJwTQft6bAMOvWdkKlx7YMriUQJ55rbZK+274LPqq75khgujIx4dmBx iaBPcGIZFt+NScRUG4rnezirRSotnzG8CgsJM3c4puSXeVQ+5xX31JvGg0O+P/SCdiMt 10C31wdrSfC2CgtTRsb1QWaxj0FpdO1asV25OCuGC9aDLC8foLaAgVQBxgRqa16rek2J jNTA== 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=EoJ3ORZFlbE9fdrK8hLpMgqZU3/mDwGmdY/pY20T1rk=; b=BTDgRPVBuvT8dVRcROymrL4U6yA8/D+LzHmCRVYxWEFtqfkdxB6nG+KDy88m3sIpIn ioSlW4r6Di0mPt2EQUugyasQHB6TjODCsOEL6MZ96czO6dP9EcIrNe7k+V2lAUAKDWV8 8HEpef0OUfu1idjJtklut8c/gD74ufQCl9s5ihyO7G7827WGn/a7WTOO0MDBgdL131BN sqLakjk3j40mD0cvcUGNDiO07UjrN3bYe4j3kQsZQUacElEaS6v8r+3ZCHZG59+k7bwc vPHpPdpNae0tLY/x+3Madth01Dg9ugUdhD0Y7LHN4u6Xty6njuSziqAaZ/BQIlKAS9Ql TKCQ== X-Gm-Message-State: ALyK8tIvD36aUHVeT07O2ghLnqizWntLYbuDJ6F/yG9piySStAUrUTsC456TItI4LRE5kxOWv0XQOt37Y4yOZg== X-Received: by 10.129.154.208 with SMTP id r199mr149332ywg.119.1467406610643; Fri, 01 Jul 2016 13:56:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.69.65 with HTTP; Fri, 1 Jul 2016 13:56:31 -0700 (PDT) In-Reply-To: References: <994121658.55005.1467329084208.JavaMail.yahoo@mail.yahoo.com> <235316006.458279.1467392709447.JavaMail.yahoo@mail.yahoo.com> <6584BD74-B18F-4174-9E69-5C7B4B76F895@ve7jtb.com> From: Josh Mandel Date: Fri, 1 Jul 2016 16:56:31 -0400 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=94eb2c0b85d0c4c6f205369939f0 Archived-At: Cc: Oleg Gryb , "oauth@ietf.org" , Liyu Yi Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 20:56:58 -0000 --94eb2c0b85d0c4c6f205369939f0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable John, Could you clarify what you mean by "POST doesn't really work"? Do you just mean that CORS support (e.g., http://caniuse.com/#feat=3Dcors) isn't universal, or something more? On Fri, Jul 1, 2016 at 4:51 PM, John Bradley wrote: > Yes but POST doesn't really work for in browser apps. > > If it is a server app it should be using the code flow with GET or POST a= s > you like. > > If we do a post message based binding it will be targeted at in browser > applications. > > John B. > > On Fri, Jul 1, 2016 at 4:42 PM, Liyu Yi wrote: > >> BTW, I do not see any significant performance concerns for post. Parsing >> and executing the Javascript logic for post operation will be on the cli= ent >> side, no extra server load is introduced. >> >> Plus post will remove the size restriction of the URL length. >> >> -- Liyu >> >> On Fri, Jul 1, 2016 at 1:35 PM, Liyu Yi wrote: >> >>> Thanks for the great comments and advices. >>> >>> I think it is a good idea for the working group to revise the fragment >>> part in the spec, since there might be public available tools already >>> implemented this approach and people can end up with a solution with >>> serious security loopholes. >>> >>> The re-append issue can be mitigate by a logic on Resource Server which >>> carefully re-writes/removes the fragment in any redirect, if the the >>> redirect can not be avoided. >>> >>> -- Liyu >>> >>> >>> On Fri, Jul 1, 2016 at 11:33 AM, John Bradley wrote= : >>> >>>> This behaviour started changing around 2011 >>>> >>>> From HTTP/1.1 >>>> See https://tools.ietf.org/html/rfc7231#section-7.1.2I >>>> f the Location value provided in a 3xx (Redirection) response do= es >>>> >>>> not have a fragment component, a user agent MUST process the >>>> redirection as if the value inherits the fragment component of the >>>> URI reference used to generate the request target (i.e., the >>>> redirection inherits the original reference's fragment, if any). >>>> >>>> For example, a GET request generated for the URI reference >>>> "http://www.example.org/~tim" might result in a 303 (See Other) >>>> response containing the header field: >>>> >>>> Location: /People.html#tim >>>> >>>> which suggests that the user agent redirect to >>>> "http://www.example.org/People.html#tim=E2=80=9D >>>> >>>> >>>> Likewise, a GET request generated for the URI reference >>>> "http://www.example.org/index.html#larry" might result in a 301 >>>> (Moved Permanently) response containing the header field: >>>> >>>> Location: http://www.example.net/index.html >>>> >>>> which suggests that the user agent redirect to >>>> "http://www.example.net/index.html#larry", preserving the original >>>> fragment identifier. >>>> >>>> >>>> >>>> This blog also explores the change. >>>> >>>> https://blogs.msdn.microsoft.com/ieinternals/2011/05/16/url-fragments-= and-redirects/ >>>> >>>> >>>> On Jul 1, 2016, at 1:05 PM, Oleg Gryb wrote: >>>> >>>> "Browsers now re-append fragments across 302 redirects unless they >>>> are explicitly cleared this makes fragment encoding less safe than it = was >>>> when originally specified" - thanks Jim. Looks like a good reason for >>>> vetting this flow out. >>>> >>>> John, >>>> Please provide more details/links about re-appending fragments. >>>> >>>> Thanks, >>>> Oleg. >>>> >>>> >>>> ------------------------------ >>>> *From:* Jim Manico >>>> *To:* Oleg Gryb >>>> *Cc:* "oauth@ietf.org" ; Liyu Yi >>>> *Sent:* Thursday, June 30, 2016 10:25 PM >>>> *Subject:* Re: [OAUTH-WG] Security concern for URI fragment as >>>> Implicit grant >>>> >>>> Oleg! Hello! Great to see you pop up here with a similar concern. >>>> >>>> John Bradley just answered this thread with the details I was looking >>>> for (thanks John, hat tip your way). >>>> >>>> He also mentioned details about fragment leakage: >>>> >>>> "Browsers now re-append fragments across 302 redirects unless they >>>> are explicitly cleared this makes fragment encoding less safe than it = was >>>> when originally specified" >>>> >>>> Again, I'm new here but I'm grateful for this conversation. >>>> >>>> Aloha, >>>> -- >>>> Jim Manico >>>> @Manicode >>>> >>>> On Jul 1, 2016, at 1:24 AM, Oleg Gryb wrote: >>>> >>>> We've discussed access tokens in URI back in 2010 ( >>>> https://www.ietf.org/mail-archive/web/oauth/current/msg04043.html). >>>> There were two major objectives when I was saying that it's not secure= : >>>> >>>> 1. Fragment is not sent to a server by a browser. When I've asked if >>>> this is true for every browser in the world, nobody was able to answer= . >>>> 2. Replacing with POST would mean a significant performance impact in >>>> some high volume implementations (I think it was Goole folks who were >>>> saying this, but I don't remember now). >>>> >>>> AFAIR, nobody was arguing about browsing history, so it's valid. >>>> >>>> So, 6 years later we're at square one with this and I hope that this >>>> time the community will be more successful with getting rid of secrets= in >>>> URL. >>>> >>>> BTW, Jim, if you can come up with other scenarios when fragments can >>>> leak, please share. It'll probably help the community with solving thi= s >>>> problem faster than in 6 years. >>>> >>>> Thanks, >>>> Oleg. >>>> >>>> >>>> ------------------------------ >>>> *From:* Jim Manico >>>> *To:* Liyu Yi ; oauth@ietf.org >>>> *Sent:* Wednesday, June 29, 2016 7:30 AM >>>> *Subject:* Re: [OAUTH-WG] Security concern for URI fragment as >>>> Implicit grant >>>> >>>> > Shouldn=E2=80=99t it be more secure if we change to use a post metho= d for >>>> access token, similar to the SAML does? >>>> I say yes. But please note I'm very new at this and someone with more >>>> experience will have more to say or correct my comments. >>>> Here are a few more details to consider. >>>> 1) OAuth is a framework and not a standard, per se. Different >>>> authorization servers will have different implementations that are not >>>> necessarily compatible with other service providers. So there is no >>>> standard to break, per se. >>>> 2) Sensitive data in a URI is a bad idea. They leak all over the place >>>> even over HTTPS. Even in fragments. >>>> 3) Break the "rules" and find a way to submit sensitive data like >>>> access tokens, session information or any other (even short term) sens= itive >>>> data in a secure fashion. This includes POST, JSON data payloads over >>>> PUT/PATCH and other verbs - all over well configured HTTPS. >>>> 4) If you really must submit sensitive data over GET , consider >>>> JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level >>>> confidentiality and integrity. >>>> Aloha, >>>> >>>> Jim Manico >>>> Manicode Securityhttps://www.manicode.com >>>> >>>> >>>> On 6/27/16 9:30 PM, Liyu Yi wrote: >>>> >>>> While we are working on a project with OAuth2 implementation, one >>>> question arises from our engineers. >>>> We noticed at >>>> >>>> https://tools.ietf.org/html/draft-ietf-oauth-v2-31#page-30, it is >>>> specified that >>>> >>>> (C) Assuming the resource owner grants access, the authorization >>>> server redirects the user-agent back to the client using the >>>> redirection URI provided earlier. The redirection URI include= s >>>> the access token in the URI fragment. >>>> >>>> For my understanding, the browser keeps the URI fragment in the >>>> history, and this introduces unexpected exposure of the access token. = A >>>> user without authorization for the resource can get the access token a= s >>>> long as he has the access to the browser. This can happen in a shared >>>> computer in library, or for an IT staff who works on other employee=E2= =80=99s >>>> computer. >>>> >>>> Shouldn=E2=80=99t it be more secure if we change to use a post method = for >>>> access token, similar to the SAML does? >>>> I feel there might be something I missed here. Any advices will be >>>> appreciated. >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/= oauth >>>> >>>> >>>> -- >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> >>>> >>> >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --94eb2c0b85d0c4c6f205369939f0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
John,

Could you clarify what you mean b= y "POST doesn't really work"= ? Do you just mean that CORS support (e.g.,=C2=A0http://caniuse.com/#feat=3Dcors) is= n't universal, or something more?

On Fri, Jul 1, 2016 at 4:51 PM, John Bradl= ey <ve7jtb@ve7jtb.com> wrote:
Yes but POST doesn't really work for in browser ap= ps.

If it is a server app it should be using the code fl= ow with GET or POST as you like.

If we do a =C2=A0= post message based binding it will be targeted at in browser applications.<= /div>

John B.

=
On Fri, Jul 1, 2016 at 4:42 PM, Liyu Yi <liyuyi@= gmail.com> wrote:
BTW, I do not see any significant performance concerns for post. P= arsing and executing the Javascript logic for post operation will be on the= client side, no extra server load is introduced.

Plus p= ost will remove the size restriction of the URL length.

-- Liyu=C2=A0
=

On Fri,= Jul 1, 2016 at 1:35 PM, Liyu Yi <liyuyi@gmail.com> wrote:
Thanks for the great = comments and advices.

I think it is a good idea for the= working group to revise the fragment part in the spec, since there might b= e public available tools already implemented this approach and people can e= nd up with a solution with serious security loopholes.

T= he re-append issue can be mitigate by a logic on Resource Server which care= fully re-writes/removes the fragment in any redirect, if the the redirect c= an not be avoided.

<= div>-- Liyu
=C2=A0
=

On Fri, Jul = 1, 2016 at 11:33 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:=
This= behaviour started changing around 2011

From HTTP/1.1
=C2=A0 =C2=A0 =C2=A0 f the Location value provided in a 3xx= (Redirection) response does
   not have a fragment=
 component, a user agent MUST process the
   redirection as if the value inherits the fragment component of the
   URI reference used to generate the request target (i.e., the
   redirection inherits the original reference's fragment, if any).

   For example, a GET request generated for the URI reference
   "http://w=
ww.example.org/~tim" might result in a 303 (See Other)
   response containing the header field:

     Location: /People.html#tim

   which suggests that the user agent redirect to
   "http://www.example.org/People.html#tim=E2=80=9D
   Likewise, a GET request generated for the URI re=
ference
   "http://www.example.org/index.html#larry" might result in a 301
   (Moved Permanently) response containing the header field:

     Location: http://www.example.net/index.html

   which suggests that the user agent redirect to
   "http://www.example.net/index.html#larry", preserving the origi=
nal
   fragment identifier.


This blog also explores the = change.
https://blogs.msd= n.microsoft.com/ieinternals/2011/05/16/url-fragments-and-redirects/


On = Jul 1, 2016, at 1:05 PM, Oleg Gryb <oleg_gryb@yahoo.com> wrote:

=
"Brow= sers now re-append =C2=A0fragments across 302 redirects unless they are exp= licitly cleared this makes fragment encoding less safe than it was =C2=A0wh= en originally specified" - thanks Jim. Looks like a good reason for ve= tting this flow out.

=
John,
Please provide more details/links a= bout re-appending fragments.=C2=A0

=
Thanks,
Oleg.


From: Jim Manico= <jim@manicode.com= >
To: Oleg Gryb &= lt;oleg@gryb.info&g= t;
Cc: "oauth@ietf.org" <oauth@ietf.org>; Liyu= Yi <liyuyi@gmail.= com>
Sent: Thursd= ay, June 30, 2016 10:25 PM
Subject:= Re: [OAUTH-WG] Security concern for URI fragment as Implicit gr= ant

Oleg! Hello! Great to see yo= u pop up here with a similar concern.

John Bradley just answered this thread with the details I was looking fo= r (thanks John, hat tip your way).

= He also mentioned details about fragment leakage:

"Browsers now re-append =C2=A0fragments across 30= 2 redirects unless they are explicitly cleared this makes fragment encoding= less safe than it was when originally specified"
Again, I'm new here but I'm grateful for= this conversation.

Aloha,
--
Jim Manico
@Manicode
On Jul 1, 2016, at 1:24 AM, Oleg Gryb <ole= g_gryb@yahoo.com> wrote:

=
We've discussed access tokens in URI ba= ck in 2010 (htt= ps://www.ietf.org/mail-archive/web/oauth/current/msg04043.html). There = were two major objectives when I was saying that it's not secure:
=

1. Fragment is n= ot sent to a server by a browser. When I've asked if this is true for e= very browser in the world, nobody was able to answer.
2. Replacing with POST would mean a significant performance impact in some= high volume implementations (I think it was Goole folks who were saying th= is, but I don't remember now).

AFAIR, nobody was arguing about browsing history, s= o it's valid.

So, 6 years later we're at square one with this and I hope tha= t this time the community will be more successful with getting rid of secre= ts in URL.

= BTW, Jim, if you can come up with other scenarios when fragments can leak, = please share. It'll probably help the community with solving this probl= em faster than in 6 years.

<= div dir=3D"ltr">Thanks,
Oleg.


From: Jim Manico <jim@manicode.com><= br clear=3D"none"> To: Liyu = Yi <liyuyi@gmail.com>; oauth@ietf.org Sent: Wedne= sday, June 29, 2016 7:30 AM
Subject: Re: [OAUTH-WG] Security concern for URI fragmen= t as Implicit grant

> Shouldn=E2=80=99t it be more secure if we change to use a post method for access token, similar to the SAML does?
I say yes. But please note I'm very new at this and someone wi= th more experience will have more to say or correct my comments.
Here are a few more details to consider.
1) OAuth is a framework and not a standard, per se. Different authorization servers will have different implementations that are not necessarily compatible with other service providers. So there is no standard to break, per se.
2) Sensitive data in a URI is a bad idea. They leak all over the place even over HTTPS. Even in fragments.
3) Break the "rules" and find a way to submit sensitive = data like access tokens, session information or any other (even short term) sensitive data in a secure fashion. This includes POST, JSON data payloads over PUT/PATCH and other verbs - all over well configured HTTPS.
4) If you really must submit sensitive data over GET , consider JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level confidentiality and integrity.
Aloha,
Jim Manico
Manicode Security
https://www.manicode.com

On 6/27/16 9:30 PM, Liyu Yi wrote:
While we are working on a project with OAuth2 implementation, one question arises from our engineers.
=C2=A0=C2=A0
(C)=C2=A0 Assuming the resource owner grants access, the authorization
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 server redire= cts the user-agent back to the client using the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 redirection U= RI provided earlier.=C2=A0 The redirection URI includes
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the access to= ken in the URI fragment.
=C2=A0
For my understanding, the browser keeps the URI fragment in the history, and this introduces unexpected exposure of the access token. A user without authorization for the resource can get the access token as long as he has the access to the browser. This can happen in a shared computer in library, or for an IT staff who works on other employee=E2=80=99s computer.
=C2=A0
Shouldn=E2=80=99t it be more secure if we change to use a post method for access token, similar to the SAML does?
I feel there might be something I missed here. Any advices will be appreciated.


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


--=20




____________________________= ___________________
OAuth mailing list
= OAuth@ie= tf.org
https://www.ietf.org/mailman/lis= tinfo/oauth







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


--94eb2c0b85d0c4c6f205369939f0-- From nobody Fri Jul 1 14:00:12 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D65112D5D7 for ; Fri, 1 Jul 2016 14:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, 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 CNZ4vW1_nCQp for ; Fri, 1 Jul 2016 14:00:07 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (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 62A6B12D11C for ; Fri, 1 Jul 2016 14:00:07 -0700 (PDT) X-AuditID: 12074425-8fbff7000000033a-28-5776d9d5298d 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 3F.91.00826.5D9D6775; Fri, 1 Jul 2016 17:00:05 -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 u61L04wd011323; Fri, 1 Jul 2016 17:00:04 -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 u61L01qf028460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 1 Jul 2016 17:00:02 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_73D62D92-FF3A-4AB6-9428-EACD5E880D20" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Justin Richer In-Reply-To: Date: Fri, 1 Jul 2016 17:00:00 -0400 Message-Id: References: <994121658.55005.1467329084208.JavaMail.yahoo@mail.yahoo.com> <235316006.458279.1467392709447.JavaMail.yahoo@mail.yahoo.com> <6584BD74-B18F-4174-9E69-5C7B4B76F895@ve7jtb.com> To: Josh Mandel X-Mailer: Apple Mail (2.3124) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPKsWRmVeSWpSXmKPExsUixCmqrXv1Zlm4wc02MYvfk9ezWLS8fcRu cfLtKzaLpkk6Fqvv/mVzYPXYOesuu8eef1eZPJYs+cnkcfv2RpYAligum5TUnMyy1CJ9uwSu jNeHbjEXrJ/EVPG97QRzA+Pu14xdjBwcEgImEn/3c3UxcnEICbQxSfQfPMcO4WxglHj3+QGU 84BJ4uGlicxdjJwczAIJEl/+HWQEsXkF9CQ2rX/LBGILC3hLzG3dzApiswmoSkxf0wIW5xQI lPi9tROsnkVARWLqyiVQc7oYJU6t4oGYYyWxo2UzI8Sy3ywSC+/+YgdJiAgoS8z6eRqsWUJA VuLJyUUsExj5ZyG5YxaSOyDi2hLLFr5mhrA1JfZ3L2fBFNeQ6Pw2kXUBI9sqRtmU3Crd3MTM nOLUZN3i5MS8vNQiXQu93MwSvdSU0k2MoHhgd1HdwTjnr9chRgEORiUeXoHZpeFCrIllxZW5 hxglOZiURHkzLpWFC/El5adUZiQWZ8QXleakFh9ilOBgVhLhvXIVKMebklhZlVqUD5OS5mBR EudlZGBgEBJITyxJzU5NLUgtgsnKcHAoSfBm3gBqFCxKTU+tSMvMKUFIM3FwggznARq+HqSG t7ggMbc4Mx0if4pRUUqc9+t1oIQASCKjNA+uF5SuEt4eNn3FKA70ijDvHpB2HmCqg+t+BTSY CWgwc2kxyOCSRISUVANjRMxx6crO7FfpB3qPtMV5Zn0zdRZIerbNudLRLuCgU0T9ZAHdJ284 lVdcNs454PjyZE1ma3jnxdPC+Xebr2bEtL/cG5z6NHJHwFqlHM3Je4ou9OcvnGNndfWVptbH xb2PnKX4TmyQb3/69NueIC3l7772HDVz3mvW7v7kljjD6JxYc9W7kGwlluKMREMt5qLiRADl CbAdMgMAAA== Archived-At: Cc: Oleg Gryb , "" , Liyu Yi Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 21:00:11 -0000 --Apple-Mail=_73D62D92-FF3A-4AB6-9428-EACD5E880D20 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 POST will send things to the server, which isn=E2=80=99t desirable if = your client is solely in the browser. postMessage is a browser API and = not to be confused with HTTP POST. postMessage messages stay (or can = stay) within the browser, which is the intent here. =E2=80=94 Justin > On Jul 1, 2016, at 4:56 PM, Josh Mandel wrote: >=20 > John, >=20 > Could you clarify what you mean by "POST doesn't really work"? Do you = just mean that CORS support (e.g., http://caniuse.com/#feat=3Dcors = ) isn't universal, or something more? >=20 > On Fri, Jul 1, 2016 at 4:51 PM, John Bradley > wrote: > Yes but POST doesn't really work for in browser apps. >=20 > If it is a server app it should be using the code flow with GET or = POST as you like. >=20 > If we do a post message based binding it will be targeted at in = browser applications. >=20 > John B. >=20 > On Fri, Jul 1, 2016 at 4:42 PM, Liyu Yi > wrote: > BTW, I do not see any significant performance concerns for post. = Parsing and executing the Javascript logic for post operation will be on = the client side, no extra server load is introduced. >=20 > Plus post will remove the size restriction of the URL length. >=20 > -- Liyu=20 >=20 > On Fri, Jul 1, 2016 at 1:35 PM, Liyu Yi > wrote: > Thanks for the great comments and advices. >=20 > I think it is a good idea for the working group to revise the fragment = part in the spec, since there might be public available tools already = implemented this approach and people can end up with a solution with = serious security loopholes. >=20 > The re-append issue can be mitigate by a logic on Resource Server = which carefully re-writes/removes the fragment in any redirect, if the = the redirect can not be avoided. >=20 > -- Liyu > =20 >=20 > On Fri, Jul 1, 2016 at 11:33 AM, John Bradley > wrote: > This behaviour started changing around 2011 >=20 > =46rom HTTP/1.1 > See https://tools.ietf.org/html/rfc7231#section-7.1.2 = I > f the Location value provided in a 3xx (Redirection) response = does > not have a fragment component, a user agent MUST process the > redirection as if the value inherits the fragment component of the > URI reference used to generate the request target (i.e., the > redirection inherits the original reference's fragment, if any). >=20 > For example, a GET request generated for the URI reference > "http://www.example.org/~tim " might = result in a 303 (See Other) > response containing the header field: >=20 > Location: /People.html#tim >=20 > which suggests that the user agent redirect to > "http://www.example.org/People.html#tim = =E2=80=9D >=20 > Likewise, a GET request generated for the URI reference > "http://www.example.org/index.html#larry = " might result in a 301 > (Moved Permanently) response containing the header field: >=20 > Location: http://www.example.net/index.html = >=20 > which suggests that the user agent redirect to > "http://www.example.net/index.html#larry = ", preserving the original > fragment identifier. >=20 >=20 > This blog also explores the change. > = https://blogs.msdn.microsoft.com/ieinternals/2011/05/16/url-fragments-and-= redirects/ = >=20 >=20 >> On Jul 1, 2016, at 1:05 PM, Oleg Gryb > wrote: >>=20 >> "Browsers now re-append fragments across 302 redirects unless they = are explicitly cleared this makes fragment encoding less safe than it = was when originally specified" - thanks Jim. Looks like a good reason = for vetting this flow out. >>=20 >> John, >> Please provide more details/links about re-appending fragments.=20 >>=20 >> Thanks, >> Oleg. >>=20 >>=20 >> From: Jim Manico > >> To: Oleg Gryb >=20 >> Cc: "oauth@ietf.org " >; Liyu Yi > >> Sent: Thursday, June 30, 2016 10:25 PM >> Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit = grant >>=20 >> Oleg! Hello! Great to see you pop up here with a similar concern. >>=20 >> John Bradley just answered this thread with the details I was looking = for (thanks John, hat tip your way). >>=20 >> He also mentioned details about fragment leakage: >>=20 >> "Browsers now re-append fragments across 302 redirects unless they = are explicitly cleared this makes fragment encoding less safe than it = was when originally specified" >>=20 >> Again, I'm new here but I'm grateful for this conversation. >>=20 >> Aloha, >> -- >> Jim Manico >> @Manicode >>=20 >> On Jul 1, 2016, at 1:24 AM, Oleg Gryb > wrote: >>=20 >>> We've discussed access tokens in URI back in 2010 = (https://www.ietf.org/mail-archive/web/oauth/current/msg04043.html = ). = There were two major objectives when I was saying that it's not secure: >>>=20 >>> 1. Fragment is not sent to a server by a browser. When I've asked if = this is true for every browser in the world, nobody was able to answer. >>> 2. Replacing with POST would mean a significant performance impact = in some high volume implementations (I think it was Goole folks who were = saying this, but I don't remember now). >>>=20 >>> AFAIR, nobody was arguing about browsing history, so it's valid. >>>=20 >>> So, 6 years later we're at square one with this and I hope that this = time the community will be more successful with getting rid of secrets = in URL. >>>=20 >>> BTW, Jim, if you can come up with other scenarios when fragments can = leak, please share. It'll probably help the community with solving this = problem faster than in 6 years. >>>=20 >>> Thanks, >>> Oleg. >>>=20 >>>=20 >>> From: Jim Manico > >>> To: Liyu Yi >; = oauth@ietf.org =20 >>> Sent: Wednesday, June 29, 2016 7:30 AM >>> Subject: Re: [OAUTH-WG] Security concern for URI fragment as = Implicit grant >>>=20 >>> > Shouldn=E2=80=99t it be more secure if we change to use a post = method for access token, similar to the SAML does? >>> I say yes. But please note I'm very new at this and someone with = more experience will have more to say or correct my comments. >>> Here are a few more details to consider. >>> 1) OAuth is a framework and not a standard, per se. Different = authorization servers will have different implementations that are not = necessarily compatible with other service providers. So there is no = standard to break, per se. >>> 2) Sensitive data in a URI is a bad idea. They leak all over the = place even over HTTPS. Even in fragments. >>> 3) Break the "rules" and find a way to submit sensitive data like = access tokens, session information or any other (even short term) = sensitive data in a secure fashion. This includes POST, JSON data = payloads over PUT/PATCH and other verbs - all over well configured = HTTPS. >>> 4) If you really must submit sensitive data over GET , consider = JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level = confidentiality and integrity. >>> Aloha, >>> Jim Manico >>> Manicode Security >>> https://www.manicode.com >>> On 6/27/16 9:30 PM, Liyu Yi wrote: >>>> While we are working on a project with OAuth2 implementation, one = question arises from our engineers. >>>> We noticed at = https://tools.= ietf.org/html/draft-ietf-oauth-v2-31#page-30 = , it is = specified that >>>> =20 >>>> (C) Assuming the resource owner grants access, the authorization >>>> server redirects the user-agent back to the client using = the >>>> redirection URI provided earlier. The redirection URI = includes >>>> the access token in the URI fragment. >>>> =20 >>>> For my understanding, the browser keeps the URI fragment in the = history, and this introduces unexpected exposure of the access token. A = user without authorization for the resource can get the access token as = long as he has the access to the browser. This can happen in a shared = computer in library, or for an IT staff who works on other employee=E2=80=99= s computer. >>>> =20 >>>> Shouldn=E2=80=99t it be more secure if we change to use a post = method for access token, similar to the SAML does? >>>> I feel there might be something I missed here. Any advices will be = appreciated. >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth = >>>=20 >>> --=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >>>=20 >>>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >>=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_73D62D92-FF3A-4AB6-9428-EACD5E880D20 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 POST will send things to the server, which isn=E2=80=99t = desirable if your client is solely in the browser. postMessage is a = browser API and not to be confused with HTTP POST. postMessage messages = stay (or can stay) within the browser, which is the intent here.

 =E2=80=94 = Justin

On Jul 1, 2016, at 4:56 PM, Josh Mandel = <jmandel@gmail.com> wrote:

John,

Could you clarify what you mean by = "POST doesn't really work"? = Do you just mean that CORS support (e.g., http://caniuse.com/#feat=3Dcors) isn't universal, or = something more?

On Fri, Jul 1, 2016 at 4:51 PM, John Bradley = <ve7jtb@ve7jtb.com> wrote:
Yes but POST doesn't really work for in browser apps.

If it is a server app it = should be using the code flow with GET or POST as you like.

If we do a  post = message based binding it will be targeted at in browser = applications.

John B.

On Fri, Jul 1, 2016 at 4:42 PM, = Liyu Yi <liyuyi@gmail.com> wrote:
BTW, I do not see any significant performance concerns for = post. Parsing and executing the Javascript logic for post operation will = be on the client side, no extra server load is introduced.

Plus post will remove = the size restriction of the URL length.

-- Liyu 

On Fri, Jul 1, 2016 at 1:35 PM, Liyu Yi <liyuyi@gmail.com> wrote:
Thanks for the great comments and = advices.

I think it is a good = idea for the working group to revise the fragment part in the spec, = since there might be public available tools already implemented this = approach and people can end up with a solution with serious security = loopholes.

The = re-append issue can be mitigate by a logic on Resource Server which = carefully re-writes/removes the fragment in any redirect, if the the = redirect can not be avoided.

-- Liyu
 

On Fri, Jul 1, 2016 at 11:33 AM, = John Bradley <ve7jtb@ve7jtb.com> wrote:
This behaviour started = changing around 2011

=46rom HTTP/1.1
See https://tools.ietf.org/html/rfc7231#section-7.1.2I
    =   f the Location value provided in a 3xx (Redirection) response = does
   not have a fragment component, a user agent MUST =
process the
   redirection as if the value inherits the fragment component of the
   URI reference used to generate the request target (i.e., the
   redirection inherits the original reference's fragment, if any).

   For example, a GET request generated for the URI reference
   "http://www.example.org/~tim" might result in a 303 (See =
Other)
   response containing the header field:

     Location: /People.html#tim

   which suggests that the user agent redirect to
   "http://www.example.org/People.html#tim=E2=80=9D

   Likewise, a GET request generated for the URI =
reference
   "http://www.example.org/index.html#larry" might result in =
a 301
   (Moved Permanently) response containing the header field:

     Location: http://www.example.net/index.html

   which suggests that the user agent redirect to
   "http://www.example.net/index.html#larry", preserving the =
original
   fragment identifier.


This blog also explores the = change.
https://blogs.msdn.microsoft.com/ieinternals/2011/05/16/url-fra= gments-and-redirects/


On Jul = 1, 2016, at 1:05 PM, Oleg Gryb <oleg_gryb@yahoo.com> wrote:

"Browsers now = re-append  fragments across 302 redirects unless they are = explicitly cleared this makes fragment encoding less safe than it was =  when originally specified" - thanks Jim. Looks like a good reason = for vetting this flow out.

John,
Please provide more = details/links about re-appending fragments. 

Thanks,
Oleg.


=
= From:= Jim Manico <jim@manicode.com>
To: Oleg Gryb <oleg@gryb.info>
Cc: "oauth@ietf.org" <oauth@ietf.org>; Liyu Yi <liyuyi@gmail.com>
Sent: Thursday, June = 30, 2016 10:25 PM
Subject: Re: [OAUTH-WG] = Security concern for URI fragment as Implicit grant
=

Oleg! Hello! Great to see you pop up here = with a similar concern.

John Bradley just answered this thread = with the details I was looking for (thanks John, hat tip your = way).

He also mentioned details about fragment leakage:

"Browsers now re-append  fragments across 302 redirects = unless they are explicitly cleared this makes fragment encoding less = safe than it was when originally specified"

Again, = I'm new here but I'm grateful for this conversation.

Aloha,
--
Jim Manico
@Manicode

On Jul 1, 2016, = at 1:24 AM, Oleg Gryb <oleg_gryb@yahoo.com> wrote:

We've discussed access tokens in URI back in = 2010 (https://www.ietf.org/mail-archive/web/oauth/current/msg04043.ht= ml). There were two major objectives when I was saying that it's not = secure:

1. Fragment is not sent to = a server by a browser. When I've asked if this is true for every browser = in the world, nobody was able to answer.
2. Replacing with POST would mean a significant performance = impact in some high volume implementations (I think it was Goole folks = who were saying this, but I don't remember now).

AFAIR, nobody was arguing about browsing history, so it's = valid.

So, 6 years later we're at = square one with this and I hope that this time the community will be = more successful with getting rid of secrets in URL.

BTW, Jim, if you can come up with other scenarios when = fragments can leak, please share. It'll probably help the community with = solving this problem faster than in 6 years.

Thanks,
Oleg.


=
From: Jim Manico <jim@manicode.com>
To: = Liyu Yi <liyuyi@gmail.com>; oauth@ietf.org
Sent: = Wednesday, June 29, 2016 7:30 AM
Subject:= Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

> Shouldn=E2=80=99t it be more = secure if we change to use a post method for access token, similar to the SAML = does?
I say yes. But please note I'm very new at this and = someone with more experience will have more to say or correct my = comments.
Here are a few more details to consider.
1) OAuth is a framework and not a standard, per se. = Different authorization servers will have different implementations that are not necessarily compatible with other service providers. So there is no standard to break, per se.
2) Sensitive data in a URI is a bad idea. They leak = all over the place even over HTTPS. Even in fragments.
3) Break the "rules" and find a way to submit = sensitive data like access tokens, session information or any other (even short term) sensitive data in a secure fashion. This includes POST, JSON data payloads over PUT/PATCH and other verbs - all over well configured HTTPS.
4) If you really must submit sensitive data over GET = , consider JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level confidentiality and integrity.
Aloha,
Jim Manico
Manicode Security
https://www.manicode.com

On 6/27/16 9:30 PM, Liyu Yi = wrote:
While we are working on a = project with OAuth2 implementation, one question arises from our engineers.
We noticed at https://tools.ietf.org/html/draft-ietf-oauth-v2-31#page-30<= /span>, it is specified that
  
(C)  Assuming the resource = owner grants access, the authorization
        server redirects = the user-agent back to the client using the
        redirection URI = provided earlier.  The redirection URI includes
        the access token = in the URI fragment.
 
For my understanding, the = browser keeps the URI fragment in the history, and this introduces unexpected exposure of the access token. A user without authorization for the resource can get the access token as long as he has the access to the browser. This can happen in a shared computer in library, or for an IT staff who works on other employee=E2=80=99s computer.
 
Shouldn=E2=80=99t it be more = secure if we change to use a post method for access token, similar to the SAML does?
I feel there might be something = I missed here. Any advices will be appreciated.


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


--=20

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


=

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


=
=





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


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

= --Apple-Mail=_73D62D92-FF3A-4AB6-9428-EACD5E880D20-- From nobody Fri Jul 1 14:02:13 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9059A12D7EA for ; Fri, 1 Jul 2016 14:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.145 X-Spam-Level: X-Spam-Status: No, score=-4.145 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 53_ozaXe9SR1 for ; Fri, 1 Jul 2016 14:02:07 -0700 (PDT) Received: from nm43-vm9.bullet.mail.bf1.yahoo.com (nm43-vm9.bullet.mail.bf1.yahoo.com [216.109.114.170]) (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 5D81112D11C for ; Fri, 1 Jul 2016 14:02:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1467406926; bh=aos7HC/g4/CEuteSo7xXFt94b9cjDVVjsdr+Gw+h8rk=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=AbIqoluDs8MDDqAay8rI49Gf6TLlSgLwAtP/JPDeRagjVU4kRt7XZTwTOAs1WtSClLTMU3ejuG0plqQx422tTS+igJ2MwUxmRUKnrMU0VDZlwJ/gjgals849FGshvz/Jzw1S9rherlRYI9j6s3pP+/3NGhjTc47NI0PkAHMgETfFf3pUMov8uO9ysy7bmvEEqL97rX44GzMCZTPleDNP/Rg5UfJeM689Tjj/xecJ3rc/ofBUWafR37vzxI/qYZ+NcRJZY6O7C8pV7dDLuqDzqR8qSF4BwZmmitEueo2tm6sY6Z/HBcAR9Zoabxj8AaDzddSIC5s91wXSl9Hh6vb5Rw== Received: from [66.196.81.170] by nm43.bullet.mail.bf1.yahoo.com with NNFMP; 01 Jul 2016 21:02:06 -0000 Received: from [98.139.212.238] by tm16.bullet.mail.bf1.yahoo.com with NNFMP; 01 Jul 2016 21:02:06 -0000 Received: from [127.0.0.1] by omp1047.mail.bf1.yahoo.com with NNFMP; 01 Jul 2016 21:02:06 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 425570.1993.bm@omp1047.mail.bf1.yahoo.com X-YMail-OSG: ILG8BKkVM1maCaKL2zXSaa23jQJ_AV3Bkx7VYIe99i.tJdwsIzmPuXYpVZLc5M1 WqaNLYfXd6mRAJeZuXR3tWAYH8YFt34CaHC3swnISmtNreHRjZlGpuxypHqDN1B6AgoKMC9OfahW PlOcDzhNAtmeUYsRVM4.3KZPcKq9CvojTxnvP6rRnsU1i.JOlKuh1ZIW9sb7NtW9W9Wn.9QWNIgv FOx4uxCeqavcmnKTk4YL.j_u5WpcaneU5KGm90mJ5Hn2rIJcgXFOaiba3LRqBQ5Cww_w41PfknV9 OdRNhbnwfwXpo.2v9US7rl_uIETpF3mj0nLuFPzcHjY4QUY6cz1LB43025PTvXj6YKJNjIBJmlHk aE8RToBN2GLczWAIzhs7U7MrXcQ6fLf3C1m5rZO4oGTK44xrKxBd6l5lxy1MFqWHHj5BlJuQ6aDE CkbwSLVoSjzzWYTaL.HUwcXwup6sp6_eoiCE7AHt5158x9f2C3nOeErvJvhgfloCkDY2uyqtUAFt 00x_MdQ8r0mUShFEezuTUzhKhtGw- Received: from jws10635.mail.bf1.yahoo.com by sendmailws149.mail.bf1.yahoo.com; Fri, 01 Jul 2016 21:02:05 +0000; 1467406925.861 Date: Fri, 1 Jul 2016 21:01:52 +0000 (UTC) From: Oleg Gryb To: Liyu Yi , John Bradley Message-ID: <861873527.537281.1467406912735.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: <994121658.55005.1467329084208.JavaMail.yahoo@mail.yahoo.com> <235316006.458279.1467392709447.JavaMail.yahoo@mail.yahoo.com> <6584BD74-B18F-4174-9E69-5C7B4B76F895@ve7jtb.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_537280_1450455183.1467406912717" Archived-At: Cc: Oleg Gryb , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Oleg Gryb List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 21:02:11 -0000 ------=_Part_537280_1450455183.1467406912717 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable AFAIR, they were talking about cost of this additional POST on the server s= ide, which was not good for high volume traffic (millions requests per day)= . I'll try to dig it out to find more details.=20 =20 From: Liyu Yi To: John Bradley =20 Cc: Oleg Gryb ; Jim Manico ; "oauth@ietf.= org" Sent: Friday, July 1, 2016 1:42 PM Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit gran= t =20 BTW, I do not see any significant performance concerns for post. Parsing an= d executing the Javascript logic for post operation will be on the client s= ide, no extra server load is introduced. Plus post will remove the size restriction of the URL length. -- Liyu=C2=A0 On Fri, Jul 1, 2016 at 1:35 PM, Liyu Yi wrote: Thanks for the great comments and advices. I think it is a good idea for the working group to revise the fragment part= in the spec, since there might be public available tools already implement= ed this approach and people can end up with a solution with serious securit= y loopholes. The re-append issue can be mitigate by a logic on Resource Server which car= efully re-writes/removes the fragment in any redirect, if the the redirect = can not be avoided. -- Liyu=C2=A0 On Fri, Jul 1, 2016 at 11:33 AM, John Bradley wrote: This behaviour started changing around 2011 >From HTTP/1.1See=C2=A0https://tools.ietf.org/html/rfc7231#section-7.1.2I=C2= =A0 =C2=A0 =C2=A0 f the Location value provided in a 3xx (Redirection) resp= onse does not have a fragment component, a user agent MUST process the redirection as if the value inherits the fragment component of the URI reference used to generate the request target (i.e., the redirection inherits the original reference's fragment, if any). For example, a GET request generated for the URI reference "http://www.example.org/~tim" might result in a 303 (See Other) response containing the header field: Location: /People.html#tim which suggests that the user agent redirect to "http://www.example.org/People.html#tim=E2=80=9D Likewise, a GET request generated for the URI reference "http://www.example.org/index.html#larry" might result in a 301 (Moved Permanently) response containing the header field: Location: http://www.example.net/index.html which suggests that the user agent redirect to "http://www.example.net/index.html#larry", preserving the original fragment identifier. This blog also explores the change.https://blogs.msdn.microsoft.com/ieinter= nals/2011/05/16/url-fragments-and-redirects/ On Jul 1, 2016, at 1:05 PM, Oleg Gryb wrote: "Browsers now re-append =C2=A0fragments across 302 redirects unless they ar= e explicitly cleared this makes fragment encoding less safe than it was =C2= =A0when originally specified" - thanks Jim. Looks like a good reason for ve= tting this flow out. John,Please provide more details/links about re-appending fragments.=C2=A0 Thanks,Oleg. =20 From: Jim Manico To: Oleg Gryb =20 Cc: "oauth@ietf.org" ; Liyu Yi Sent: Thursday, June 30, 2016 10:25 PM Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit gran= t =20 Oleg! Hello! Great to see you pop up here with a similar concern. John Bradley just answered this thread with the details I was looking for (= thanks John, hat tip your way). He also mentioned details about fragment leakage: "Browsers now re-append =C2=A0fragments across 302 redirects unless they ar= e explicitly cleared this makes fragment encoding less safe than it was whe= n originally specified" Again, I'm new here but I'm grateful for this conversation. Aloha,--Jim Manico@Manicode On Jul 1, 2016, at 1:24 AM, Oleg Gryb wrote: We've discussed access tokens in URI back in 2010 (https://www.ietf.org/mai= l-archive/web/oauth/current/msg04043.html). There were two major objectives= when I was saying that it's not secure: 1. Fragment is not sent to a server by a browser. When I've asked if this i= s true for every browser in the world, nobody was able to answer.2. Replaci= ng with POST would mean a significant performance impact in some high volum= e implementations (I think it was Goole folks who were saying this, but I d= on't remember now). AFAIR, nobody was arguing about browsing history, so it's valid. So, 6 years later we're at square one with this and I hope that this time t= he community will be more successful with getting rid of secrets in URL. BTW, Jim, if you can come up with other scenarios when fragments can leak, = please share. It'll probably help the community with solving this problem f= aster than in 6 years. Thanks,Oleg. =20 From: Jim Manico To: Liyu Yi ; oauth@ietf.org=20 Sent: Wednesday, June 29, 2016 7:30 AM Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit gran= t =20 > Shouldn=E2=80=99t it be more secure if we change to use a post method fo= r access token, similar to the SAML does? I say yes. But please note I'm ve= ry new at this and someone with more experience will have more to say or co= rrect my comments. Here are a few more details to consider. 1) OAuth is a framework and not a standard, per se. Different authorizati= on servers will have different implementations that are not necessarily com= patible with other service providers. So there is no standard to break, per= se. 2) Sensitive data in a URI is a bad idea. They leak all over the place ev= en over HTTPS. Even in fragments. 3) Break the "rules" and find a way to submit sensitive data like access = tokens, session information or any other (even short term) sensitive data i= n a secure fashion. This includes POST, JSON data payloads over PUT/PATCH a= nd other verbs - all over well configured HTTPS. 4) If you really must submit sensitive data over GET , consider JWT/JWS/J= WE (with limited scopes/lifetimes) to provide message level confidentiality= and integrity. Aloha, Jim Manico Manicode Security https://www.manicode.com=20 On 6/27/16 9:30 PM, Liyu Yi wrote: =20 While we are working on a project with OAuth2 implementation, one questio= n arises from our engineers. We noticed at https://tools.ietf.org/html/draf= t-ietf-oauth-v2-31#page-30, it is specified that =C2=A0=C2=A0 (C)=C2=A0 Ass= uming the resource owner grants access, the authorization =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 server redirects the user-agent back to the cli= ent using the =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 redirection URI pr= ovided earlier.=C2=A0 The redirection URI includes =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 the access token in the URI fragment. =C2=A0 For my unde= rstanding, the browser keeps the URI fragment in the history, and this intr= oduces unexpected exposure of the access token. A user without authorizati= on for the resource can get the access token as long as he has the access t= o the browser. This can happen in a shared computer in library, or for an I= T staff who works on other employee=E2=80=99s computer. =C2=A0 Shouldn=E2= =80=99t it be more secure if we change to use a post method for access toke= n, similar to the SAML does? I feel there might be something I missed here.= Any advices will be appreciated. =20 =20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 =20 --=20 =20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 =20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 =20 =20 ------=_Part_537280_1450455183.1467406912717 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
AFAIR, they were tal= king about cost of this additional POST on the server side, which was not g= ood for high volume traffic (millions requests per day). I'll try to dig it= out to find more details.


From:<= /span> Liyu Yi <liyuyi@gmail.com>
To: John Bradley <ve7jtb@ve7jtb.com>
Cc: Oleg Gryb <oleg@gryb.info= >; Jim Manico <jim@manicode.com>; "oauth@ietf.org" <oauth@ietf.= org>
Sent: Friday, = July 1, 2016 1:42 PM
Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant<= br>

BTW, I do not see any significant performance concerns for post.= Parsing and executing the Javascript logic for post operation will be on t= he client side, no extra server load is introduced.

Plus post will remove the size restriction of the U= RL length.

-- Liyu&nb= sp;

On Fri, Jul 1, 2016 at 1:35= PM, Liyu Yi <liyuyi@gmail.com> wrote:
Thanks= for the great comments and advices.

I t= hink it is a good idea for the working group to revise the fragment part in= the spec, since there might be public available tools already implemented = this approach and people can end up with a solution with serious security l= oopholes.

The re-append issue can be mitigate by a logic on Resource Ser= ver which carefully re-writes/removes the fragment in any redirect, if the = the redirect can not be avoided.
<= font color=3D"#888888">

-- Liyu
 
=
On Fri, Jul 1, 2= 016 at 11:33 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
This behaviour started changing around 2011

From HTTP/1.1
      f the Location value provided in a 3xx (Re= direction) response does
   not have a fragment co=
mponent, a user agent MUST process the
   redirection as if the value inherits the fragment component of the
   URI reference used to generate the request target (i.e., the
   redirection inherits the original reference's fragment, if any).

   For example, a GET request generated for the URI reference
   "http://www.example.org/~tim" might result in a 303 (=
See Other)
   response containing the header field:

     Location: /People.html#tim

   which suggests that the user agent redirect to
   "http://www.example.org/People.html#tim=E2=
=80=9D

   Like=
wise, a GET request generated for the URI reference
   "http://www.example.org/index.html#larry"=
 might result in a 301
   (Moved Permanently) response containing the header field:

     Location: http://www.example.net/index.html

   which suggests that the user agent redirect to
   "http://www.example.net/index.html#larry"=
, preserving the original
   fragment identifier.


This blog also explores the change.


On Jul 1, 2016, at 1:05 PM, Oleg Gryb <oleg_gryb@yahoo.com> wrote:
"Browsers now re-append &= nbsp;fragments across 302 redirects unless they are explicitly cleared this= makes fragment encoding less safe than it was  when originally specif= ied" - thanks Jim. Looks like a good reason for vetting this flow out.

<= /span>
John,
Please provide more details/links about re-appending= fragments. 

Thanks,
Oleg.


From: Jim Manico <jim@manicode.com>
To: Oleg Gryb <oleg@gryb.info>
Cc: "oauth@ietf.org" <oauth@ietf.org>; Liyu Yi <liyuyi@gmail.com>
Sent: Thursday, June 30, 2016 10:25 PM Subject: R= e: [OAUTH-WG] Security concern for URI fragment as Implicit grant

Oleg! Hello! Grea= t to see you pop up here with a similar concern.

John Bradley just answered this thread with the details I was= looking for (thanks John, hat tip your way).

=
He also mentioned details about fragment leakage:

"Browsers now re-append  fragments acr= oss 302 redirects unless they are explicitly cleared this makes fragment en= coding less safe than it was when originally specified"
Again, I'm new here but I'm grateful for this c= onversation.

Aloha,
= --
Jim Manico
@Manicode

On Jul 1, 2016, at 1:24 AM, Oleg Gryb <oleg_gryb@yahoo.com> wrote:

We've discussed access to= kens in URI back in 2010 (https://www.ietf.org/mail-archive/web/oauth/current/msg04043.ht= ml). There were two major objectives when I was saying that it's not se= cure:

1. Fr= agment is not sent to a server by a browser. When I've asked if this is tru= e for every browser in the world, nobody was able to answer.
2. Replacing with POST would mean a significant performance impact= in some high volume implementations (I think it was Goole folks who were s= aying this, but I don't remember now).

AFAIR, nobody was arguing about browsing histor= y, so it's valid.

So, 6 years later we're at square one with this and I hope that th= is time the community will be more successful with getting rid of secrets i= n URL.

BTW,= Jim, if you can come up with other scenarios when fragments can leak, plea= se share. It'll probably help the community with solving this problem faste= r than in 6 years.

Thanks,
Oleg.

<= br clear=3D"none">
From: Jim Manico <jim@manicode.com>
To: Liyu Yi <liyuyi@gmail.com>; oauth@ietf.org
Sent: Wednesday, June 29, 2016 7:30 AM Subject: = Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

> Shouldn=E2=80=99t it be more secure if we change to use a post method for access token, similar to the SAML does?
I say yes. But please note I'm very new at this and someone with more experience will have more to say or correct my comments.
Here are a few more details to consider.
1) OAuth is a framework and not a standard, per se. Different authorization servers will have different implementations that are not necessarily compatible with other service providers. So there is no standard to break, per se.
2) Sensitive data in a URI is a bad idea. They leak all over the place even over HTTPS. Even in fragments.
3) Break the "rules" and find a way to submit sensitive data like access tokens, session information or any other (even short term) sensitive data in a secure fashion. This includes POST, JSON data payloads over PUT/PATCH and other verbs - all over well configured HTTPS.
4) If you really must submit sensitive data over GET , consider JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level confidentiality and integrity.
Aloha,
Jim Manico
Manicode Security
https://www.manicode.com

On 6/27/16 9:30 PM, Liyu Yi wrote:
While we are working on a project with OAuth2 implementation, one question arises from our engineers.
  
(C)  Assuming the resource owner grants access, the authorization
        server redire= cts the user-agent back to the client using the
        redirection U= RI provided earlier.  The redirection URI includes
        the access to= ken in the URI fragment.
 
For my understanding, the browser keeps the URI fragment in the history, and this introduces unexpected exposure of the access token. A user without authorization for the resource can get the access token as long as he has the access to the browser. This can happen in a shared computer in library, or for an IT staff who works on other employee=E2=80=99s computer.
 
Shouldn=E2=80=99t it be more secure if we change to use a post method for access token, similar to the SAML does?
I feel there might be something I missed here. Any advices will be appreciated.


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


--=20



=

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



<= /div>


<= br>
------=_Part_537280_1450455183.1467406912717-- From nobody Fri Jul 1 14:10:05 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFC36128874 for ; Fri, 1 Jul 2016 14:10:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.145 X-Spam-Level: X-Spam-Status: No, score=-4.145 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 MZHEP3GhUwVC for ; Fri, 1 Jul 2016 14:10:00 -0700 (PDT) Received: from nm33-vm2.bullet.mail.bf1.yahoo.com (nm33-vm2.bullet.mail.bf1.yahoo.com [72.30.239.202]) (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 BA2A9126579 for ; Fri, 1 Jul 2016 14:09:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1467407398; bh=/jYJF4thYR6EBLzD47L5yN2cIzCXCGzzbNQGbEj0/6A=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=XCwMVNIY4naPGJC2Gfi3hmJ9Hzr+InjStje3bFlr3Wo0+vF/Yx6LaPtjgeJgP8qU6VFAn11ZwTEtU3zhAHkzlmJc/NkZqAxbK7ztq06wVYcZbU3BP9xYFd+F6eVb3DjfW7AGavIlwQyoJ6HuYp6gXan7Bsyd958R8M3zN0uGt366e41zoHf149fT65g18qBycY8cVFj5oADEkZcqwgyZQ4kw/FUdS6uChsZx9I7KKhLthhvch34VzyG5A5oBoFzQqblH71l9Tu2++2P75BffwCK71LFdOQK0YO76vsZjYDNl1U1iqkPx9jdtuz/GsKm5s2OibHwfcBHxIZ4ZltUnuQ== Received: from [98.139.170.180] by nm33.bullet.mail.bf1.yahoo.com with NNFMP; 01 Jul 2016 21:09:58 -0000 Received: from [98.139.212.239] by tm23.bullet.mail.bf1.yahoo.com with NNFMP; 01 Jul 2016 21:09:58 -0000 Received: from [127.0.0.1] by omp1048.mail.bf1.yahoo.com with NNFMP; 01 Jul 2016 21:09:58 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 557031.24926.bm@omp1048.mail.bf1.yahoo.com X-YMail-OSG: jvzQfvwVM1kjaZnYqxv_7BbWT7XEYMYij8AcDRfnyKjuFTiL7aHKBuevaM3M7A4 faILxoiZGraH20.zETMzvlyScosSsbkGA2.F5YTthfBka3j0sbaK00SLIhRhMjVP1vyhinMO4zfs bnMrJRWdDBE0dQ0RTvlqDn8SGm3nmPnMeFKAPluBjffgqIBuCuHc4AvDJasPQWiXc8QsC1wlmIp9 KZwhqLsZ7rOHx0zI2r_Zc_IYpgQ60zQM_fKax8eKS01LYVcY_jRIzKpSrXvSn71Xu1WYsIAwRlIf Vvln8QUkhS1xp9EaB6nyu_lTWwOuuASSK8dWe5vKs3r4eK_C.zFXwH3p52tm5RQBJT7JB_c0dGyH SAt4sNsx6aSJK_8tz.UQ0lFGn4z2T64kKw4qTuMIW2HKKOrX9hgfrnrDZ.7e1ou2tNqTKqB8Uegk e39_jRilys7nmjO6HHriT7Hynqw7KdxoHC2X9WOIP9eBaK5t5RWnNQi8Lg7vcjZc5kcbSSn_4ogT 61u9KNd9ovf._a7JQUwW2TQfuD8s- Received: from jws10691.mail.bf1.yahoo.com by sendmailws124.mail.bf1.yahoo.com; Fri, 01 Jul 2016 21:09:58 +0000; 1467407398.068 Date: Fri, 1 Jul 2016 21:09:57 +0000 (UTC) From: Oleg Gryb To: Justin Richer , Josh Mandel Message-ID: <410908395.555462.1467407397629.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: <994121658.55005.1467329084208.JavaMail.yahoo@mail.yahoo.com> <235316006.458279.1467392709447.JavaMail.yahoo@mail.yahoo.com> <6584BD74-B18F-4174-9E69-5C7B4B76F895@ve7jtb.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_555461_2134628620.1467407397605" Archived-At: Cc: Oleg Gryb , "" , Liyu Yi Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Oleg Gryb List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 21:10:04 -0000 ------=_Part_555461_2134628620.1467407397605 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > POST will send things to the server, which isn=E2=80=99t desirable if you= r client is solely in the browserWhy it's not desirable, assuming that we d= isregard performance? You can generate HTTP POST from JS, e.g. through an A= JAX call. What is wrong with this? =20 From: Justin Richer To: Josh Mandel =20 Cc: Oleg Gryb ; "" ; Liyu Y= i Sent: Friday, July 1, 2016 2:00 PM Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit gran= t =20 POST will send things to the server, which isn=E2=80=99t desirable if your = client is solely in the browser. postMessage is a browser API and not to be= confused with HTTP POST. postMessage messages stay (or can stay) within th= e browser, which is the intent here. =C2=A0=E2=80=94 Justin On Jul 1, 2016, at 4:56 PM, Josh Mandel wrote: John, Could you clarify what you mean by "POST doesn't really work"? Do you just = mean that CORS support (e.g.,=C2=A0http://caniuse.com/#feat=3Dcors) isn't u= niversal, or something more? On Fri, Jul 1, 2016 at 4:51 PM, John Bradley wrote: Yes but POST doesn't really work for in browser apps. If it is a server app it should be using the code flow with GET or POST as = you like. If we do a =C2=A0post message based binding it will be targeted at in brows= er applications. John B. On Fri, Jul 1, 2016 at 4:42 PM, Liyu Yi wrote: BTW, I do not see any significant performance concerns for post. Parsing an= d executing the Javascript logic for post operation will be on the client s= ide, no extra server load is introduced. Plus post will remove the size restriction of the URL length. -- Liyu=C2=A0 On Fri, Jul 1, 2016 at 1:35 PM, Liyu Yi wrote: Thanks for the great comments and advices. I think it is a good idea for the working group to revise the fragment part= in the spec, since there might be public available tools already implement= ed this approach and people can end up with a solution with serious securit= y loopholes. The re-append issue can be mitigate by a logic on Resource Server which car= efully re-writes/removes the fragment in any redirect, if the the redirect = can not be avoided. -- Liyu=C2=A0 On Fri, Jul 1, 2016 at 11:33 AM, John Bradley wrote: This behaviour started changing around 2011 >From HTTP/1.1See=C2=A0https://tools.ietf.org/html/rfc7231#section-7.1.2I=C2= =A0 =C2=A0 =C2=A0 f the Location value provided in a 3xx (Redirection) resp= onse does not have a fragment component, a user agent MUST process the redirection as if the value inherits the fragment component of the URI reference used to generate the request target (i.e., the redirection inherits the original reference's fragment, if any). For example, a GET request generated for the URI reference "http://www.example.org/~tim" might result in a 303 (See Other) response containing the header field: Location: /People.html#tim which suggests that the user agent redirect to "http://www.example.org/People.html#tim=E2=80=9D Likewise, a GET request generated for the URI reference "http://www.example.org/index.html#larry" might result in a 301 (Moved Permanently) response containing the header field: Location: http://www.example.net/index.html which suggests that the user agent redirect to "http://www.example.net/index.html#larry", preserving the original fragment identifier. This blog also explores the change.https://blogs.msdn.microsoft.com/ieinter= nals/2011/05/16/url-fragments-and-redirects/ On Jul 1, 2016, at 1:05 PM, Oleg Gryb wrote: "Browsers now re-append =C2=A0fragments across 302 redirects unless they ar= e explicitly cleared this makes fragment encoding less safe than it was =C2= =A0when originally specified" - thanks Jim. Looks like a good reason for ve= tting this flow out. John,Please provide more details/links about re-appending fragments.=C2=A0 Thanks,Oleg. =20 From: Jim Manico To: Oleg Gryb =20 Cc: "oauth@ietf.org" ; Liyu Yi Sent: Thursday, June 30, 2016 10:25 PM Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit gran= t =20 Oleg! Hello! Great to see you pop up here with a similar concern. John Bradley just answered this thread with the details I was looking for (= thanks John, hat tip your way). He also mentioned details about fragment leakage: "Browsers now re-append =C2=A0fragments across 302 redirects unless they ar= e explicitly cleared this makes fragment encoding less safe than it was whe= n originally specified" Again, I'm new here but I'm grateful for this conversation. Aloha,--Jim Manico@Manicode On Jul 1, 2016, at 1:24 AM, Oleg Gryb wrote: We've discussed access tokens in URI back in 2010 (https://www.ietf.org/mai= l-archive/web/oauth/current/msg04043.html). There were two major objectives= when I was saying that it's not secure: 1. Fragment is not sent to a server by a browser. When I've asked if this i= s true for every browser in the world, nobody was able to answer.2. Replaci= ng with POST would mean a significant performance impact in some high volum= e implementations (I think it was Goole folks who were saying this, but I d= on't remember now). AFAIR, nobody was arguing about browsing history, so it's valid. So, 6 years later we're at square one with this and I hope that this time t= he community will be more successful with getting rid of secrets in URL. BTW, Jim, if you can come up with other scenarios when fragments can leak, = please share. It'll probably help the community with solving this problem f= aster than in 6 years. Thanks,Oleg. =20 From: Jim Manico To: Liyu Yi ; oauth@ietf.org=20 Sent: Wednesday, June 29, 2016 7:30 AM Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit gran= t =20 > Shouldn=E2=80=99t it be more secure if we change to use a post method fo= r access token, similar to the SAML does? I say yes. But please note I'm ve= ry new at this and someone with more experience will have more to say or co= rrect my comments. Here are a few more details to consider. 1) OAuth is a framework and not a standard, per se. Different authorizati= on servers will have different implementations that are not necessarily com= patible with other service providers. So there is no standard to break, per= se. 2) Sensitive data in a URI is a bad idea. They leak all over the place ev= en over HTTPS. Even in fragments. 3) Break the "rules" and find a way to submit sensitive data like access = tokens, session information or any other (even short term) sensitive data i= n a secure fashion. This includes POST, JSON data payloads over PUT/PATCH a= nd other verbs - all over well configured HTTPS. 4) If you really must submit sensitive data over GET , consider JWT/JWS/J= WE (with limited scopes/lifetimes) to provide message level confidentiality= and integrity. Aloha, Jim Manico Manicode Security https://www.manicode.com=20 On 6/27/16 9:30 PM, Liyu Yi wrote: =20 While we are working on a project with OAuth2 implementation, one questio= n arises from our engineers. We noticed at https://tools.ietf.org/html/draf= t-ietf-oauth-v2-31#page-30, it is specified that =C2=A0=C2=A0 (C)=C2=A0 Ass= uming the resource owner grants access, the authorization =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 server redirects the user-agent back to the cli= ent using the =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 redirection URI pr= ovided earlier.=C2=A0 The redirection URI includes =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 the access token in the URI fragment. =C2=A0 For my unde= rstanding, the browser keeps the URI fragment in the history, and this intr= oduces unexpected exposure of the access token. A user without authorizati= on for the resource can get the access token as long as he has the access t= o the browser. This can happen in a shared computer in library, or for an I= T staff who works on other employee=E2=80=99s computer. =C2=A0 Shouldn=E2= =80=99t it be more secure if we change to use a post method for access toke= n, similar to the SAML does? I feel there might be something I missed here.= Any advices will be appreciated. =20 =20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 =20 --=20 =20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 =20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 =20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 ------=_Part_555461_2134628620.1467407397605 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> POST will send things to the server, whi= ch isn=E2=80=99t desirable if your client is solely in the browser
Why it's not des= irable, assuming that we disregard performance? You can generate HTTP POST = from JS, e.g. through an AJAX call. What is wrong with this?


From= : Justin Richer <jricher@mit.edu>
To: Josh Mandel <jmandel@gmail.com>
= Cc: Oleg Gryb <oleg@gry= b.info>; "<oauth@ietf.org>" <oauth@ietf.org>; Liyu Yi <li= yuyi@gmail.com>
Sent: Friday, July 1, 2016 2:00 PM
S= ubject: Re: [OAUTH-WG] Security concern for URI fragment as Impl= icit grant

POST will send things to the server, wh= ich isn=E2=80=99t desirable if your client is solely in the browser. postMe= ssage is a browser API and not to be confused with HTTP POST. postMessage m= essages stay (or can stay) within the browser, which is the intent here.
=
&= nbsp;=E2=80=94 Justin

=
On Jul 1, 2016, at 4:56 PM, Josh Mandel <jman= del@gmail.com> wrote:

=
John,
<= div class=3D"yiv5953070106">Could you clarify what you mean by "POST doesn't really work"? D= o you just mean that CORS support (e.g., http://caniuse.com/#feat=3Dcors) isn't universal, or some= thing more?

O= n Fri, Jul 1, 2016 at 4:51 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
Yes but POST doesn't really work for in brow= ser apps.

If it is a server app it should be= using the code flow with GET or POST as you like.

If we do a  post message based binding it will be targete= d at in browser applications.

John B= .

On Fri, Jul 1,= 2016 at 4:42 PM, Liyu Yi <liyuyi@= gmail.com> wrote:
<= blockquote class=3D"yiv5953070106gmail_quote" style=3D"margin:0 0 0 .8ex;bo= rder-left:1px #ccc solid;padding-left:1ex;">
BTW, I do not see any significant performance concerns for post. = Parsing and executing the Javascript logic for post operation will be on th= e client side, no extra server load is introduced.

Plus post will remove the size restriction of the URL length.
<= span class=3D"yiv5953070106">

-- Liyu 

On Fri, Jul 1, 2016 at 1:35 PM, Liyu Yi <liyuyi@gmail.com> wrote:=
Thanks for the great comments and advices.

I think it is a = good idea for the working group to revise the fragment part in the spec, si= nce there might be public available tools already implemented this approach= and people can end up with a solution with serious security loopholes.
<= div class=3D"yiv5953070106">The re-append issue can be mitigate by a logic = on Resource Server which carefully re-writes/removes the fragment in any re= direct, if the the redirect can not be avoided.

-- Liyu
 

On Fri, Jul 1,= 2016 at 11:33 AM, John Bradley &= lt;ve7jtb@ve7jtb.com> wrote:
This behaviour started changing ar= ound 2011

From HTTP/1.1
See https://tools.ietf.org/html/rfc7231#section-7.1.2I
      f the Location value provided in a 3xx (Redirecti= on) response does
   not h=
ave a fragment component, a user agent MUST process the
   redirection as if the value inherits the fragment component of the
   URI reference used to generate the request target (i.e., the
   redirection inherits the original reference's fragment, if any).

   For example, a GET request generated for the URI reference
   "http://www.example.org/~tim"=
 might result in a 303 (See Other)
   response containing the header field:

     Location: /People.html#tim

   which suggests that the user agent redirect to
   "http://www.example.or=
g/People.html#tim=E2=80=9D
   Likewise, a GET request generated =
for the URI reference
   "http://www.example.o=
rg/index.html#larry" might result in a 301
   (Moved Permanently) response containing the header field:

     Location: http://www.exam=
ple.net/index.html

   which suggests that the user agent redirect to
   "http://www.example.n=
et/index.html#larry", preserving the original
   fragment identifier.


This blog also explores the= change.
https://blo= gs.msdn.microsoft.com/ieinternals/2011/05/16/url-fragments-and-redirects/


On Jul 1, 2016, at 1:05 PM, Oleg Gryb <oleg_gr= yb@yahoo.com> wrote:

"Browsers now re-append  fragments across 302 = redirects unless they are explicitly cleared this makes fragment encoding l= ess safe than it was  when originally specified" - thanks Jim. Looks l= ike a good reason for vetting this flow out.

John,
Please provide more details/links ab= out re-appending fragments. 

= Thanks,
Oleg.


From: Jim Manico <<= a rel=3D"nofollow" shape=3D"rect" class=3D"yiv5953070106" ymailto=3D"mailto= :jim@manicode.com" target=3D"_blank" href=3D"mailto:jim@manicode.com">jim@m= anicode.com>
To= : Oleg Gryb <oleg@gryb.info>
Cc: "oauth@ietf.org" <oauth@ietf.org>; Liyu Yi= <liyuyi@gmail.com>
Sent: Thursday, June 30, 2016 10:25 PM
Subject: Re: [OAUTH-WG] Security= concern for URI fragment as Implicit grant

=
Oleg! Hello! Great to see you pop up here with= a similar concern.

John Bradley just = answered this thread with the details I was looking for (thanks John, hat t= ip your way).

He also mentioned detail= s about fragment leakage:

"Browsers now re-append  fragments across 302 redire= cts unless they are explicitly cleared this makes fragment encoding less sa= fe than it was when originally specified"

Again, I'm new here but I'm grateful for this conversation.

Aloha,
<= div class=3D"yiv5953070106">--
Jim Manico=
@Manicode

On Jul 1, 2016, at 1:24 AM, Oleg Gryb <oleg_gryb@yahoo.com= > wrote:

We've discussed access tokens in URI back in 2010 (ht= tps://www.ietf.org/mail-archive/web/oauth/current/msg04043.html). There= were two major objectives when I was saying that it's not secure:

1. Fragment is not sen= t to a server by a browser. When I've asked if this is true for every brows= er in the world, nobody was able to answer.
2. Replacing with POST would mean a significant performance = impact in some high volume implementations (I think it was Goole folks who = were saying this, but I don't remember now).

AFAIR, nobody was arguing about browsing his= tory, so it's valid.

So, 6 years later we're at square one with this and I hope that th= is time the community will be more successful with getting rid of secrets i= n URL.

BTW, Ji= m, if you can come up with other scenarios when fragments can leak, please = share. It'll probably help the community with solving this problem faster t= han in 6 years.

Thanks,
Oleg.


From: Jim Manico <jim@manicode.com>= ;
To: Liyu = Yi <liyuyi@gmail.com>; oauth@ietf.org
Sent: Wednesday, June 29, 2016 7:30 AM Subject: Re: = [OAUTH-WG] Security concern for URI fragment as Implicit grant

> Shouldn= =E2=80=99t it be more secure if we change to use a post method for access token, similar to the SAML does?
I say yes. But please note I'm very new at= this and someone with more experience will have more to say or correct my comments.
Here are a few more details to consider.
1) OAuth is a framework and not a standard= , per se. Different authorization servers will have different implementations that are not necessarily compatible with other service providers. So there is no standard to break, per se.
2) Sensitive data in a URI is a bad idea. = They leak all over the place even over HTTPS. Even in fragments.
3) Break the "rules" and find a way to sub= mit sensitive data like access tokens, session information or any other (even short term) sensitive data in a secure fashion. This includes POST, JSON data payloads over PUT/PATCH and other verbs - all over well configured HTTPS.
4) If you really must submit sensitive dat= a over GET , consider JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level confidentiality and integrity.
Aloha,
Jim Manico
Manicode Security
https://www.manicode.com

On 6/27/16 9:= 30 PM, Liyu Yi wrote:
While we= are working on a project with OAuth2 implementation, one question arises from our engineers.
We notic= ed at https://tools.ietf.org/html/draft-ietf= -oauth-v2-31#page-30, it is specified that
  
(C) = ; Assuming the resource owner grants access, the authorization
 &n= bsp;      server redirects the user-agent back to the client using the
 &n= bsp;      redirection URI provided earlier.  The redirection URI includes
 &n= bsp;      the access token in the URI fragment.
 
For my u= nderstanding, the browser keeps the URI fragment in the history, and this introduces unexpected exposure of the access token. A user without authorization for the resource can get the access token as long as he has the access to the browser. This can happen in a shared computer in library, or for an IT staff who works on other employee=E2=80=99s computer.
 
Shouldn= =E2=80=99t it be more secure if we change to use a post method for access token, similar to the SAML does?
I feel t= here might be something I missed here. Any advices will be appreciated.


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


--=20

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


<= /div>

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


<= /div>



<= /div>
________________________________= _______________
OAuth mailing list
OAuth@ie= tf.org
https://www.ietf.org= /mailman/listinfo/oauth


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


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


------=_Part_555461_2134628620.1467407397605-- From nobody Fri Jul 1 14:15:25 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81E2212B015 for ; Fri, 1 Jul 2016 14:15:24 -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 RM7LH9smPhgl for ; Fri, 1 Jul 2016 14:15:21 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19BD3128874 for ; Fri, 1 Jul 2016 14:15:20 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id m2so63955836qtd.1 for ; Fri, 01 Jul 2016 14:15:20 -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=ECybZYpGdrOaveNfgKQ0cxUJ+oQp/8j5IEGmETkkFvo=; b=En8snxM4OD7qN/PB3jEKOvrMFY5OueNYdsxElZFg5rDEs8y25Xcl5yngotIJ9qUXav 4oXUQIXnHS7fFM8NKgWaWwEBCoAUP+AA/LscbohoUSgbOmsc2oDpH6/4g8xRufNWcJdn uwLjPQBsIbWIzMhVEVELam+tyDSCyZTEF/UrMsAVDY+2slzkampYN1L71W1qTTMiS/CF anYwS1il9kURKCleQ9QZiE6d8PP/ph6rxzIhJz4HMHY40ChFUSh+AjzKM09FSTwQPFoM hfi0jnTN098cOHF/PcouQvYQa7U9RukYLjWgIOGsPlD43gy0k4tpVm40flcPGebIsejG JRhA== 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=ECybZYpGdrOaveNfgKQ0cxUJ+oQp/8j5IEGmETkkFvo=; b=cpW6CeTKdDNTNZ6w2aOXbfEbm2t/w8kes8uRJzr37OeTBcBpGcAN7oOP4gV7mdKcQ7 JimdC0pgtuP/l5DcprrDzV6qrWnK+AqBW8syP4bzFZSTxDbabEsdj7U7lzM4dbmG7pIF SFrxtmhWex7Tcqh4LU4VLKkrYL5zV4Hsnfchmv5KFxXBgPfmdsZJ/T3jWrTKZHzxlGam NI2WgL440R8ocDAKwoQeB/Eoe1cZO3NiZxfxkwBVBlzh7h0F3HJV+x9fKb2fqW5iZVIX wMr4NYKMiYmSqH4xh+VTJNoqytkbAWmsFV3i0cnPhvbMu6TPa7p32CHscdeBNXFA4vjs tb4g== X-Gm-Message-State: ALyK8tL9tD+NFT0GpZTzfo2dCE7DgYf/tOYpNxXHeNF1SlYz2evvSUFib55aHk+cPUiF6CyO X-Received: by 10.237.37.99 with SMTP id w32mr504125qtc.95.1467407719810; Fri, 01 Jul 2016 14:15:19 -0700 (PDT) Received: from [192.168.1.41] ([191.115.51.34]) by smtp.gmail.com with ESMTPSA id b63sm1367698qkf.23.2016.07.01.14.15.11 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 01 Jul 2016 14:15:18 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_A4B6E44F-BC5A-437A-81EF-C8B597D475DD" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: John Bradley In-Reply-To: <861873527.537281.1467406912735.JavaMail.yahoo@mail.yahoo.com> Date: Fri, 1 Jul 2016 17:15:02 -0400 Message-Id: <7CCCDE86-B9BD-49D8-BF65-3BE08068C145@ve7jtb.com> References: <994121658.55005.1467329084208.JavaMail.yahoo@mail.yahoo.com> <235316006.458279.1467392709447.JavaMail.yahoo@mail.yahoo.com> <6584BD74-B18F-4174-9E69-5C7B4B76F895@ve7jtb.com> <861873527.537281.1467406912735.JavaMail.yahoo@mail.yahoo.com> To: Oleg Gryb X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "oauth@ietf.org" , Liyu Yi Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 21:15:24 -0000 --Apple-Mail=_A4B6E44F-BC5A-437A-81EF-C8B597D475DD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Justin is correct. They may have been trying to avoid the client POST to the token endpoint = with the code. =20 That is a separate issue from the question of using a fragment encoded = GET 302 or a JS POST redirect to return from the authorization endpoint. The response via the browser is smaller and faster if you are using = code. The direct call via the back channel from the client to the server = should not be a big deal in reality. If they are larger than Google and have a real performance issue we can = talk. In the mean time for server based clients the recommendation is to use a = confidential client with code. John B. > On Jul 1, 2016, at 5:01 PM, Oleg Gryb wrote: >=20 > AFAIR, they were talking about cost of this additional POST on the = server side, which was not good for high volume traffic (millions = requests per day). I'll try to dig it out to find more details.=20 >=20 >=20 > From: Liyu Yi > To: John Bradley =20 > Cc: Oleg Gryb ; Jim Manico ; = "oauth@ietf.org" > Sent: Friday, July 1, 2016 1:42 PM > Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit = grant >=20 > BTW, I do not see any significant performance concerns for post. = Parsing and executing the Javascript logic for post operation will be on = the client side, no extra server load is introduced. >=20 > Plus post will remove the size restriction of the URL length. >=20 > -- Liyu=20 >=20 > On Fri, Jul 1, 2016 at 1:35 PM, Liyu Yi > wrote: > Thanks for the great comments and advices. >=20 > I think it is a good idea for the working group to revise the fragment = part in the spec, since there might be public available tools already = implemented this approach and people can end up with a solution with = serious security loopholes. >=20 > The re-append issue can be mitigate by a logic on Resource Server = which carefully re-writes/removes the fragment in any redirect, if the = the redirect can not be avoided. >=20 > -- Liyu > =20 >=20 > On Fri, Jul 1, 2016 at 11:33 AM, John Bradley > wrote: > This behaviour started changing around 2011 >=20 > =46rom HTTP/1.1 > See https://tools.ietf.org/html/rfc7231#section-7.1.2 = I > f the Location value provided in a 3xx (Redirection) response = does > not have a fragment component, a user agent MUST process the > redirection as if the value inherits the fragment component of the > URI reference used to generate the request target (i.e., the > redirection inherits the original reference's fragment, if any). >=20 > For example, a GET request generated for the URI reference > "http://www.example.org/~tim " might = result in a 303 (See Other) > response containing the header field: >=20 > Location: /People.html#tim >=20 > which suggests that the user agent redirect to > "http://www.example.org/People.html#tim = =E2=80=9D >=20 > Likewise, a GET request generated for the URI reference > "http://www.example.org/index.html#larry = " might result in a 301 > (Moved Permanently) response containing the header field: >=20 > Location: http://www.example.net/index.html = >=20 > which suggests that the user agent redirect to > "http://www.example.net/index.html#larry = ", preserving the original > fragment identifier. >=20 >=20 > This blog also explores the change. > = https://blogs.msdn.microsoft.com/ieinternals/2011/05/16/url-fragments-and-= redirects/ = >=20 >=20 >> On Jul 1, 2016, at 1:05 PM, Oleg Gryb > wrote: >>=20 >> "Browsers now re-append fragments across 302 redirects unless they = are explicitly cleared this makes fragment encoding less safe than it = was when originally specified" - thanks Jim. Looks like a good reason = for vetting this flow out. >>=20 >> John, >> Please provide more details/links about re-appending fragments.=20 >>=20 >> Thanks, >> Oleg. >>=20 >>=20 >> From: Jim Manico > >> To: Oleg Gryb >=20 >> Cc: "oauth@ietf.org " >; Liyu Yi > >> Sent: Thursday, June 30, 2016 10:25 PM >> Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit = grant >>=20 >> Oleg! Hello! Great to see you pop up here with a similar concern. >>=20 >> John Bradley just answered this thread with the details I was looking = for (thanks John, hat tip your way). >>=20 >> He also mentioned details about fragment leakage: >>=20 >> "Browsers now re-append fragments across 302 redirects unless they = are explicitly cleared this makes fragment encoding less safe than it = was when originally specified" >>=20 >> Again, I'm new here but I'm grateful for this conversation. >>=20 >> Aloha, >> -- >> Jim Manico >> @Manicode >>=20 >> On Jul 1, 2016, at 1:24 AM, Oleg Gryb > wrote: >>=20 >>> We've discussed access tokens in URI back in 2010 = (https://www.ietf.org/mail-archive/web/oauth/current/msg04043.html = ). = There were two major objectives when I was saying that it's not secure: >>>=20 >>> 1. Fragment is not sent to a server by a browser. When I've asked if = this is true for every browser in the world, nobody was able to answer. >>> 2. Replacing with POST would mean a significant performance impact = in some high volume implementations (I think it was Goole folks who were = saying this, but I don't remember now). >>>=20 >>> AFAIR, nobody was arguing about browsing history, so it's valid. >>>=20 >>> So, 6 years later we're at square one with this and I hope that this = time the community will be more successful with getting rid of secrets = in URL. >>>=20 >>> BTW, Jim, if you can come up with other scenarios when fragments can = leak, please share. It'll probably help the community with solving this = problem faster than in 6 years. >>>=20 >>> Thanks, >>> Oleg. >>>=20 >>>=20 >>> From: Jim Manico > >>> To: Liyu Yi >; = oauth@ietf.org =20 >>> Sent: Wednesday, June 29, 2016 7:30 AM >>> Subject: Re: [OAUTH-WG] Security concern for URI fragment as = Implicit grant >>>=20 >>> > Shouldn=E2=80=99t it be more secure if we change to use a post = method for access token, similar to the SAML does? >>> I say yes. But please note I'm very new at this and someone with = more experience will have more to say or correct my comments. >>> Here are a few more details to consider. >>> 1) OAuth is a framework and not a standard, per se. Different = authorization servers will have different implementations that are not = necessarily compatible with other service providers. So there is no = standard to break, per se. >>> 2) Sensitive data in a URI is a bad idea. They leak all over the = place even over HTTPS. Even in fragments. >>> 3) Break the "rules" and find a way to submit sensitive data like = access tokens, session information or any other (even short term) = sensitive data in a secure fashion. This includes POST, JSON data = payloads over PUT/PATCH and other verbs - all over well configured = HTTPS. >>> 4) If you really must submit sensitive data over GET , consider = JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level = confidentiality and integrity. >>> Aloha, >>> Jim Manico >>> Manicode Security >>> https://www.manicode.com >>> On 6/27/16 9:30 PM, Liyu Yi wrote: >>>> While we are working on a project with OAuth2 implementation, one = question arises from our engineers. >>>> We noticed at = https://tools.= ietf.org/html/draft-ietf-oauth-v2-31#page-30 = , it is = specified that >>>> =20 >>>> (C) Assuming the resource owner grants access, the authorization >>>> server redirects the user-agent back to the client using = the >>>> redirection URI provided earlier. The redirection URI = includes >>>> the access token in the URI fragment. >>>> =20 >>>> For my understanding, the browser keeps the URI fragment in the = history, and this introduces unexpected exposure of the access token. A = user without authorization for the resource can get the access token as = long as he has the access to the browser. This can happen in a shared = computer in library, or for an IT staff who works on other employee=E2=80=99= s computer. >>>> =20 >>>> Shouldn=E2=80=99t it be more secure if we change to use a post = method for access token, similar to the SAML does? >>>> I feel there might be something I missed here. Any advices will be = appreciated. >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth = >>>=20 >>> --=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >>>=20 >>>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >>=20 >=20 >=20 >=20 >=20 >=20 --Apple-Mail=_A4B6E44F-BC5A-437A-81EF-C8B597D475DD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Justin is correct.

They may have been trying to avoid the client POST to the = token endpoint with the code.  

That is a separate issue from the = question of using a fragment encoded GET 302 or a JS POST redirect to = return from the authorization endpoint.

The response via the browser is smaller = and faster if you are using code.

The direct call via the back channel = from the client to the server should not be a big deal in = reality.

If = they are larger than Google and have a real performance issue we can = talk.

In the = mean time for server based clients the recommendation is to use a = confidential client with code.

John B.
On Jul 1, 2016, at 5:01 PM, = Oleg Gryb <oleg_gryb@yahoo.com> wrote:

AFAIR, they were talking about cost of this additional POST = on the server side, which was not good for high volume traffic (millions = requests per day). I'll try to dig it out to find more details.


=
=
From: Liyu Yi <liyuyi@gmail.com>
To: John Bradley <ve7jtb@ve7jtb.com> =
Cc: Oleg Gryb <oleg@gryb.info>; Jim Manico <jim@manicode.com>; = "oauth@ietf.org" <oauth@ietf.org>
Sent: Friday, July 1, 2016 1:42 PM
= Subject: Re: [OAUTH-WG] Security concern for URI = fragment as Implicit grant

BTW, = I do not see any significant performance concerns for post. Parsing and = executing the Javascript logic for post operation will be on the client = side, no extra server load is introduced.

Plus post will remove the size restriction of the URL = length.

-- = Liyu 

On Fri, Jul 1, 2016 at 1:35 PM, Liyu = Yi <liyuyi@gmail.com> wrote:
Thanks for the great comments and advices.

I think it is a good idea = for the working group to revise the fragment part in the spec, since = there might be public available tools already implemented this approach = and people can end up with a solution with serious security = loopholes.

The re-append issue can = be mitigate by a logic on Resource Server which carefully = re-writes/removes the fragment in any redirect, if the the redirect can = not be avoided.

-- = Liyu
 

On Fri, Jul 1, 2016 at 11:33 AM, John = Bradley <ve7jtb@ve7jtb.com> wrote:
This behaviour started changing around 2011

=46rom = HTTP/1.1
See https://tools.ietf.org/html/rfc7231#section-7.1.2I
    =   f the Location value provided in a 3xx (Redirection) response = does
   not have a fragment component, a user agent MUST =
process the
   redirection as if the value inherits the fragment component of the
   URI reference used to generate the request target (i.e., the
   redirection inherits the original reference's fragment, if any).

   For example, a GET request generated for the URI reference
   "http://www.example.org/~tim" might result in a 303 (See =
Other)
   response containing the header field:

     Location: /People.html#tim

   which suggests that the user agent redirect to
   "http://www.example.org/People.html#tim=E2=80=9D

   Likewise, a GET request generated for the URI =
reference
   "http://www.example.org/index.html#larry" might result in =
a 301
   (Moved Permanently) response containing the header field:

     Location: http://www.example.net/index.html

   which suggests that the user agent redirect to
   "http://www.example.net/index.html#larry", preserving the =
original
   fragment identifier.


This blog = also explores the change.
https://blogs.msdn.microsoft.com/ieinternals/2011/05/16/url-fra= gments-and-redirects/


On Jul 1, 2016, at 1:05 PM, Oleg Gryb <oleg_gryb@yahoo.com> wrote:

"Browsers now re-append  fragments across 302 redirects = unless they are explicitly cleared this makes fragment encoding less = safe than it was  when originally specified" - thanks Jim. Looks = like a good reason for vetting this flow out.

John,
Please provide more details/links = about re-appending fragments. 

Thanks,
Oleg.


From: Jim Manico <jim@manicode.com>
To: Oleg Gryb <oleg@gryb.info>
Cc: "oauth@ietf.org" <oauth@ietf.org>; Liyu Yi <liyuyi@gmail.com>
Sent: Thursday, June 30, 2016 10:25 PM
Subject: Re: [OAUTH-WG] Security concern for URI = fragment as Implicit grant

Oleg! Hello! Great to see you pop up here = with a similar concern.

John Bradley just answered this thread = with the details I was looking for (thanks John, hat tip your = way).

He also mentioned details about fragment leakage:

"Browsers now re-append  fragments across 302 redirects = unless they are explicitly cleared this makes fragment encoding less = safe than it was when originally specified"

Again, = I'm new here but I'm grateful for this conversation.

Aloha,
--
Jim Manico
@Manicode

On Jul 1, 2016, = at 1:24 AM, Oleg Gryb <oleg_gryb@yahoo.com>= wrote:

We've discussed access tokens in URI back in = 2010 (https://www.ietf.org/mail-archive/web/oauth/current/msg04043.ht= ml). There were two major objectives when I was saying that it's not = secure:

1. Fragment is not sent to = a server by a browser. When I've asked if this is true for every browser = in the world, nobody was able to answer.
2. Replacing with POST would mean a significant performance = impact in some high volume implementations (I think it was Goole folks = who were saying this, but I don't remember now).

AFAIR, nobody was arguing about browsing history, so it's = valid.

So, 6 years later we're at = square one with this and I hope that this time the community will be = more successful with getting rid of secrets in URL.

BTW, Jim, if you can come up with other scenarios when = fragments can leak, please share. It'll probably help the community with = solving this problem faster than in 6 years.

Thanks,
Oleg.


From: Jim Manico <jim@manicode.com>
To: Liyu Yi <liyuyi@gmail.com>; oauth@ietf.org
Sent: = Wednesday, June 29, 2016 7:30 AM
Subject: Re: [OAUTH-WG] Security concern for URI = fragment as Implicit grant

> Shouldn=E2=80=99t it be more = secure if we change to use a post method for access token, similar to the SAML = does?
I say yes. But please note I'm very new at this and = someone with more experience will have more to say or correct my = comments.
Here are a few more details to consider.
1) OAuth is a framework and not a standard, per se. = Different authorization servers will have different implementations that are not necessarily compatible with other service providers. So there is no standard to break, per se.
2) Sensitive data in a URI is a bad idea. They leak = all over the place even over HTTPS. Even in fragments.
3) Break the "rules" and find a way to submit = sensitive data like access tokens, session information or any other (even short term) sensitive data in a secure fashion. This includes POST, JSON data payloads over PUT/PATCH and other verbs - all over well configured HTTPS.
4) If you really must submit sensitive data over GET = , consider JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level confidentiality and integrity.
Aloha,
Jim Manico
Manicode Security
https://www.manicode.com

On 6/27/16 9:30 PM, Liyu Yi = wrote:
While we are working on a = project with OAuth2 implementation, one question arises from our engineers.
We noticed at https://tools.ietf.org/html/draft-ietf-oauth-v2-31#page-30<= /span>, it is specified that
  
(C)  Assuming the resource = owner grants access, the authorization
        server redirects = the user-agent back to the client using the
        redirection URI = provided earlier.  The redirection URI includes
        the access token = in the URI fragment.
 
For my understanding, the = browser keeps the URI fragment in the history, and this introduces unexpected exposure of the access token. A user without authorization for the resource can get the access token as long as he has the access to the browser. This can happen in a shared computer in library, or for an IT staff who works on other employee=E2=80=99s computer.
 
Shouldn=E2=80=99t it be more = secure if we change to use a post method for access token, similar to the SAML does?
I feel there might be something = I missed here. Any advices will be appreciated.


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


--=20

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


=

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


=





= =
= --Apple-Mail=_A4B6E44F-BC5A-437A-81EF-C8B597D475DD-- From nobody Fri Jul 1 14:17:16 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3EF912B016 for ; Fri, 1 Jul 2016 14:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ttR25cjmxwD for ; Fri, 1 Jul 2016 14:17:10 -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 7D330128874 for ; Fri, 1 Jul 2016 14:17:10 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id t127so222877524qkf.1 for ; Fri, 01 Jul 2016 14:17:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=V5hbV1Ahm7fqZCS6IS3ix307qllfHMCEyD0a8iqKc8I=; b=RLnchOK4+PhVqVyiT7QvI6ntkCf5TD42oHMxrDGyYeVzDPnLnA5EPpWDvk6tyuPjgp Sx65o5xsG2RbB+obCydLCwoSjkiwpy5GDcjR/r69YAw6WhHzREBZcpvDkRZOpwTpfCye I4JmbHKYotac4WAH/fNqeuVr2JSlp+5f4nfBT2BQ+Jm5l5tONRR22HdjTAQeFufZYqdB VbNfqqOMIpaAc2n4gT83bMR+piyBTV4T/c7/o4YA65UtjTQviT7gaq64wYwRoGJGYM0C zTw+53DScU2C2L1oWjlVt0E2kgyiG3zNhlM66lQxqjHgrx1Gz50tA5qVkgQffJVI/a6p 4w5g== 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=V5hbV1Ahm7fqZCS6IS3ix307qllfHMCEyD0a8iqKc8I=; b=KXUBJeEyCUjzF9it+99Ixa3yy9TIK9xlWjp6zPxspOqxyZQIuhkfThrcQ6GxhKp1Um wVXN/QX8Ca9cZ/bk34VBJJVct0Sl6/GhTYiD5NcfYMm9NBcNe4Eg6vZ3K9q5+nEeARVu ZgHep61f7wzPj5Gun8JFUsOPhCCN/SvPwxzcwEvXsip+e4JCIu4YJVGjzTdUpaU/XlJZ QNghxadkrwBYpEh27R+NaExefvucmtiK81NB78U3H+pN/pm77sinzZg0YYFJ6dm0diT1 afxtpiI5DM78fRE8ML8xR91Z4VAdezFMwMfEIBbOCy/wx44kaQYbZOalZzd6tnXq4sgD oArw== X-Gm-Message-State: ALyK8tJ28oqoLDeKENjdYY9rokMLpqK2E5UA5C89KKagrob74wXg6idMdqt6x4k2NLDdnNMNqdSR7BkNULrNXQ== X-Received: by 10.129.90.7 with SMTP id o7mr190504ywb.313.1467407825364; Fri, 01 Jul 2016 14:17:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.69.65 with HTTP; Fri, 1 Jul 2016 14:16:45 -0700 (PDT) In-Reply-To: <410908395.555462.1467407397629.JavaMail.yahoo@mail.yahoo.com> References: <994121658.55005.1467329084208.JavaMail.yahoo@mail.yahoo.com> <235316006.458279.1467392709447.JavaMail.yahoo@mail.yahoo.com> <6584BD74-B18F-4174-9E69-5C7B4B76F895@ve7jtb.com> <410908395.555462.1467407397629.JavaMail.yahoo@mail.yahoo.com> From: Josh Mandel Date: Fri, 1 Jul 2016 17:16:45 -0400 Message-ID: To: Oleg Gryb Content-Type: multipart/alternative; boundary=001a11491f962bec65053699825b Archived-At: Cc: Liyu Yi , "" Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 21:17:14 -0000 --001a11491f962bec65053699825b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Justin, To clarify: John's comment and my question were about POST. (I do understand the behavior of HTTP POST and of window.postMessage; these are totally different things.) From my perspective in SMART Health IT, we use the OAuth 2.0 authorization code flow, including HTTP POST, in our authorization spec even for public clients, and it has worked very well for us, with about a dozen electronic health record servers supporting this approach. That's why I was curious to hear John's perspective about limitations. -J On Fri, Jul 1, 2016 at 5:09 PM, Oleg Gryb wrote: > > POST will send things to the server, which isn=E2=80=99t desirable if y= our > client is solely in the browser > Why it's not desirable, assuming that we disregard performance? You can > generate HTTP POST from JS, e.g. through an AJAX call. What is wrong with > this? > > > ------------------------------ > *From:* Justin Richer > *To:* Josh Mandel > *Cc:* Oleg Gryb ; "" ; > Liyu Yi > *Sent:* Friday, July 1, 2016 2:00 PM > > *Subject:* Re: [OAUTH-WG] Security concern for URI fragment as Implicit > grant > > POST will send things to the server, which isn=E2=80=99t desirable if you= r client > is solely in the browser. postMessage is a browser API and not to be > confused with HTTP POST. postMessage messages stay (or can stay) within t= he > browser, which is the intent here. > > =E2=80=94 Justin > > On Jul 1, 2016, at 4:56 PM, Josh Mandel wrote: > > John, > > Could you clarify what you mean by "POST doesn't really work"? Do you > just mean that CORS support (e.g., http://caniuse.com/#feat=3Dcors) isn't > universal, or something more? > > On Fri, Jul 1, 2016 at 4:51 PM, John Bradley wrote: > > Yes but POST doesn't really work for in browser apps. > > If it is a server app it should be using the code flow with GET or POST a= s > you like. > > If we do a post message based binding it will be targeted at in browser > applications. > > John B. > > On Fri, Jul 1, 2016 at 4:42 PM, Liyu Yi wrote: > > BTW, I do not see any significant performance concerns for post. Parsing > and executing the Javascript logic for post operation will be on the clie= nt > side, no extra server load is introduced. > > Plus post will remove the size restriction of the URL length. > > -- Liyu > > On Fri, Jul 1, 2016 at 1:35 PM, Liyu Yi wrote: > > Thanks for the great comments and advices. > > I think it is a good idea for the working group to revise the fragment > part in the spec, since there might be public available tools already > implemented this approach and people can end up with a solution with > serious security loopholes. > > The re-append issue can be mitigate by a logic on Resource Server which > carefully re-writes/removes the fragment in any redirect, if the the > redirect can not be avoided. > > -- Liyu > > > On Fri, Jul 1, 2016 at 11:33 AM, John Bradley wrote: > > This behaviour started changing around 2011 > > From HTTP/1.1 > See https://tools.ietf.org/html/rfc7231#section-7.1.2I > f the Location value provided in a 3xx (Redirection) response does > > not have a fragment component, a user agent MUST process the > redirection as if the value inherits the fragment component of the > URI reference used to generate the request target (i.e., the > redirection inherits the original reference's fragment, if any). > > For example, a GET request generated for the URI reference > "http://www.example.org/~tim" might result in a 303 (See Other) > response containing the header field: > > Location: /People.html#tim > > which suggests that the user agent redirect to > "http://www.example.org/People.html#tim=E2=80=9D > > > Likewise, a GET request generated for the URI reference > "http://www.example.org/index.html#larry" might result in a 301 > (Moved Permanently) response containing the header field: > > Location: http://www.example.net/index.html > > which suggests that the user agent redirect to > "http://www.example.net/index.html#larry", preserving the original > fragment identifier. > > > > This blog also explores the change. > > https://blogs.msdn.microsoft.com/ieinternals/2011/05/16/url-fragments-and= -redirects/ > > > On Jul 1, 2016, at 1:05 PM, Oleg Gryb wrote: > > "Browsers now re-append fragments across 302 redirects unless they are > explicitly cleared this makes fragment encoding less safe than it was wh= en > originally specified" - thanks Jim. Looks like a good reason for vetting > this flow out. > > John, > Please provide more details/links about re-appending fragments. > > Thanks, > Oleg. > > > ------------------------------ > *From:* Jim Manico > *To:* Oleg Gryb > *Cc:* "oauth@ietf.org" ; Liyu Yi > *Sent:* Thursday, June 30, 2016 10:25 PM > *Subject:* Re: [OAUTH-WG] Security concern for URI fragment as Implicit > grant > > Oleg! Hello! Great to see you pop up here with a similar concern. > > John Bradley just answered this thread with the details I was looking for > (thanks John, hat tip your way). > > He also mentioned details about fragment leakage: > > "Browsers now re-append fragments across 302 redirects unless they are > explicitly cleared this makes fragment encoding less safe than it was whe= n > originally specified" > > Again, I'm new here but I'm grateful for this conversation. > > Aloha, > -- > Jim Manico > @Manicode > > On Jul 1, 2016, at 1:24 AM, Oleg Gryb wrote: > > We've discussed access tokens in URI back in 2010 ( > https://www.ietf.org/mail-archive/web/oauth/current/msg04043.html). There > were two major objectives when I was saying that it's not secure: > > 1. Fragment is not sent to a server by a browser. When I've asked if this > is true for every browser in the world, nobody was able to answer. > 2. Replacing with POST would mean a significant performance impact in som= e > high volume implementations (I think it was Goole folks who were saying > this, but I don't remember now). > > AFAIR, nobody was arguing about browsing history, so it's valid. > > So, 6 years later we're at square one with this and I hope that this time > the community will be more successful with getting rid of secrets in URL. > > BTW, Jim, if you can come up with other scenarios when fragments can leak= , > please share. It'll probably help the community with solving this problem > faster than in 6 years. > > Thanks, > Oleg. > > > ------------------------------ > *From:* Jim Manico > *To:* Liyu Yi ; oauth@ietf.org > *Sent:* Wednesday, June 29, 2016 7:30 AM > *Subject:* Re: [OAUTH-WG] Security concern for URI fragment as Implicit > grant > > > Shouldn=E2=80=99t it be more secure if we change to use a post method f= or > access token, similar to the SAML does? > I say yes. But please note I'm very new at this and someone with more > experience will have more to say or correct my comments. > Here are a few more details to consider. > 1) OAuth is a framework and not a standard, per se. Different > authorization servers will have different implementations that are not > necessarily compatible with other service providers. So there is no > standard to break, per se. > 2) Sensitive data in a URI is a bad idea. They leak all over the place > even over HTTPS. Even in fragments. > 3) Break the "rules" and find a way to submit sensitive data like access > tokens, session information or any other (even short term) sensitive data > in a secure fashion. This includes POST, JSON data payloads over PUT/PATC= H > and other verbs - all over well configured HTTPS. > 4) If you really must submit sensitive data over GET , consider > JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level > confidentiality and integrity. > Aloha, > > Jim Manico > Manicode Securityhttps://www.manicode.com > > > On 6/27/16 9:30 PM, Liyu Yi wrote: > > While we are working on a project with OAuth2 implementation, one questio= n > arises from our engineers. > We noticed at > https://tools.ietf.org/html/draft-ietf-oauth-v2-31#page-30, it is > specified that > > (C) Assuming the resource owner grants access, the authorization > server redirects the user-agent back to the client using the > redirection URI provided earlier. The redirection URI includes > the access token in the URI fragment. > > For my understanding, the browser keeps the URI fragment in the history, > and this introduces unexpected exposure of the access token. A user witho= ut > authorization for the resource can get the access token as long as he has > the access to the browser. This can happen in a shared computer in librar= y, > or for an IT staff who works on other employee=E2=80=99s computer. > > Shouldn=E2=80=99t it be more secure if we change to use a post method for= access > token, similar to the SAML does? > I feel there might be something I missed here. Any advices will be > appreciated. > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > > -- > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --001a11491f962bec65053699825b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Justin,

To clarify: John's c= omment and my question were about POST. (I do understand the behavior of HT= TP POST and of window.postMessage; these are totally different things.) Fro= m my perspective in SMART Health IT, we use the OAuth 2.0 authorization cod= e flow, including HTTP POST, in our authorization spec=C2=A0even for pu= blic clients, and it has worked very well for us, with about a dozen electr= onic health record servers supporting this approach. That's why I was c= urious to hear John's perspective about limitations.

=C2=A0 -J

On Fri, Jul 1, 2016 at 5:09 PM, Oleg Gryb <oleg_gryb@yahoo.com&= gt; wrote:
> POST will send things to the server, which isn=E2=80=99= t desirable if your client is solely in the browser
Why it's not desirable, assuming that we disregard performance? Y= ou can generate HTTP POST from JS, e.g. through an AJAX call. What is wrong= with this?


From: Justin Richer <jricher@mit.edu>
= To: Josh Mandel <jmandel@gmail.com> <= br>Cc: Oleg Gryb <oleg@gryb.info>; "= <oauth@ietf.org&= gt;" <oauth@iet= f.org>; Liyu Yi <liyuyi@gmail.com>
Sent= : Friday, July 1, 2016 2:00 PM

Subject: Re: [OAUTH-WG] Security concern for UR= I fragment as Implicit grant
=
POST will send things to the server, which isn=E2=80=99t desi= rable if your client is solely in the browser. postMessage is a browser API= and not to be confused with HTTP POST. postMessage messages stay (or can s= tay) within the browser, which is the intent here.

<= /div>
=C2=A0=E2=80=94 Justin

On Jul 1, 2016, at 4:56 PM, Josh Mandel <jmandel@gmail.com> wrote:

John,
Could you clarify what you mean by "POST doesn't really work"? Do you ju= st mean that CORS support (e.g.,=C2=A0http://caniuse.com= /#feat=3Dcors) isn't universal, or something more?

On Fri, Jul 1, 2016 at 4:51 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
Yes but POST doesn't really work = for in browser apps.

If it is a server ap= p it should be using the code flow with GET or POST as you like.
=
If we do a =C2=A0post message based binding i= t will be targeted at in browser applications.

John B.

On Fri, Jul 1, = 2016 at 4:42 PM, Liyu Yi <liyuyi@gmail.com<= /a>> wrote:
BTW, I do= not see any significant performance concerns for post. Parsing and executi= ng the Javascript logic for post operation will be on the client side, no e= xtra server load is introduced.

Plus post= will remove the size restriction of the URL length.

-- Liyu=C2=A0=

On Fri, Jul 1, 2016 at 1= :35 PM, Liyu Yi <liyuyi@gmail.com> wrote:
Thanks for th= e great comments and advices.

I think it= is a good idea for the working group to revise the fragment part in the sp= ec, since there might be public available tools already implemented this ap= proach and people can end up with a solution with serious security loophole= s.

The re-append issue can be mitigate by= a logic on Resource Server which carefully re-writes/removes the fragment = in any redirect, if the the redirect can not be avoided.

-- L= iyu
=C2=A0

On Fri, Jul 1, 2016 at 11:33 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
=
This behaviour started changin= g around 2011

From HTTP/1.1
=C2=A0 =C2=A0 =C2=A0 f the Location va= lue provided in a 3xx (Redirection) response does
 =
  not have a fragment component, a user agent MUST process the
   redirection as if the value inherits the fragment component of the
   URI reference used to generate the request target (i.e., the
   redirection inherits the original reference's fragment, if any).

   For example, a GET request generated for the URI reference
   "http://www.example.org/~tim" might result =
in a 303 (See Other)
   response containing the header field:

     Location: /People.html#tim

   which suggests that the user agent redirect to
   "http://www.example.org/People.html#tim=E2=80=9D

   L=
ikewise, a GET request generated for the URI reference
   "http://www.example.org/index.html#larry=
" might result in a 301
   (Moved Permanently) response containing the header field:

     Location: http://www.example.net/index.html

   which suggests that the user agent redirect to
   "http://www.example.net/index.html#larry=
", preserving the original
   fragment identifier.


This blog also explores the change.


On Jul 1, 2016, at 1:05 PM, Oleg Gryb <ole= g_gryb@yahoo.com> wrote:

"Browsers now re-append =C2=A0fragments across 302 redirects unle= ss they are explicitly cleared this makes fragment encoding less safe than = it was =C2=A0when originally specified" - thanks Jim. Looks like a goo= d reason for vetting this flow out.

John,
Please provide more details/links about re-ap= pending fragments.=C2=A0

Thanks,
Oleg.


=
From: Jim M= anico <jim@manicode.com>
To: Oleg Gryb <oleg@gryb.i= nfo>
Cc: "oauth@ietf.org" <oauth@ietf.org<= /a>>; Liyu Yi <liyuyi@gmail.com>
= Sent: Thursday, June 30, 20= 16 10:25 PM
Subject:= Re: [OAUTH-WG] Security concern for URI fragment as Implicit gr= ant

Oleg!= Hello! Great to see you pop up here with a similar concern.

John Bradley just answered this thread with the d= etails I was looking for (thanks John, hat tip your way).

He also mentioned details about fragment leakage:

"Browsers now re-append = =C2=A0fragments across 302 redirects unless they are explicitly cleared thi= s makes fragment encoding less safe than it was when originally specified&q= uot;

Again, I'm new here= but I'm grateful for this conversation.

<= /div>
Aloha,
--
Jim Manico
@Manicode=

On Jul 1, 2016, at 1:24 AM, Oleg G= ryb <oleg_gryb@yahoo.com> wrote:
=
We've discusse= d access tokens in URI back in 2010 (https://www.ietf.org/mail-archive/web/oauth/current/m= sg04043.html). There were two major objectives when I was saying that i= t's not secure:

1. Fragment is not sent to a server by a browser. When I've as= ked if this is true for every browser in the world, nobody was able to answ= er.
2. Replacing with POST would mean a significant p= erformance impact in some high volume implementations (I think it was Goole= folks who were saying this, but I don't remember now).

AFAIR, nobody was arguin= g about browsing history, so it's valid.

So, 6 years later we're at square one= with this and I hope that this time the community will be more successful = with getting rid of secrets in URL.

BTW, Jim, if you can come up with other scenarios = when fragments can leak, please share. It'll probably help the communit= y with solving this problem faster than in 6 years.
<= br clear=3D"none">
Thanks,
Oleg= .


<= span style=3D"font-weight:bold">From: Jim Manico <= jim@manicode.com>
To: Liyu Yi <liyuyi@gmail.com>; oauth@ietf.org
Sent: Wednesday, June 29, 2016 7:30 AM
= Subject: Re: [OAUTH-WG] Securit= y concern for URI fragment as Implicit grant

> Shouldn=E2=80=99t it be more secure if we change to use a post method for access token, similar to the SAML does?
I say yes. But please note I'm very new at this and someone wi= th more experience will have more to say or correct my comments.
Here are a few more details to consider.
1) OAuth is a framework and not a standard, per se. Different authorization servers will have different implementations that are not necessarily compatible with other service providers. So there is no standard to break, per se.
2) Sensitive data in a URI is a bad idea. They leak all over the place even over HTTPS. Even in fragments.
3) Break the "rules" and find a way to submit sensitive = data like access tokens, session information or any other (even short term) sensitive data in a secure fashion. This includes POST, JSON data payloads over PUT/PATCH and other verbs - all over well configured HTTPS.
4) If you really must submit sensitive data over GET , consider JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level confidentiality and integrity.
Aloha,
Jim Manico
Manicode Security
https://www.manicode.com

On 6/27/16 9:30 PM, Liyu Yi wrote:
While we are working on a project with OAuth2 implementation, one question arises from our engineers.
=C2=A0=C2=A0
(C)=C2=A0 Assuming the resource owner grants access, the authorization
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 server redire= cts the user-agent back to the client using the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 redirection U= RI provided earlier.=C2=A0 The redirection URI includes
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the access to= ken in the URI fragment.
=C2=A0
For my understanding, the browser keeps the URI fragment in the history, and this introduces unexpected exposure of the access token. A user without authorization for the resource can get the access token as long as he has the access to the browser. This can happen in a shared computer in library, or for an IT staff who works on other employee=E2=80=99s computer.
=C2=A0
Shouldn=E2=80=99t it be more secure if we change to use a post method for access token, similar to the SAML does?
I feel there might be something I missed here. Any advices will be appreciated.


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


--=20




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


=





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


_______________________________________________
OAuth mai= ling list
OAuth@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">ht= tps://www.ietf.org/mailman/listinfo/oauth


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



--001a11491f962bec65053699825b-- From nobody Fri Jul 1 14:22:27 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF1312B025 for ; Fri, 1 Jul 2016 14:22:25 -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 KgBifM-9BYeS for ; Fri, 1 Jul 2016 14:22:22 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::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 F1538128874 for ; Fri, 1 Jul 2016 14:22:20 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id t127so223060725qkf.1 for ; Fri, 01 Jul 2016 14:22:20 -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=ubItE6LKw2orB7v2AcimbpgL8pxky4TfNwxAxcARPqM=; b=uXndps73DyH6NxXq2g2o+aZfxPIWHJELwHVmgakGzoquOArVHOZqhU6wm2e3QQFskU pSkqSXpVv2MNjAWWJFtm7uQGI96+xGe6G6zaYU3Xx6OQoKQh/GOsgshMcylgFcO5prv9 fVxyoKDRFDz6dQlLok5Qr5xrHOSdDQEh0QLH1pec6ZI8eshuboQA2MUBESiBX0ChBNdB EDc60sq7w0uWBx6mFyzEM9uMpELtEPvTOQVhm+E/InlH+Dkxl5EHjrqKx5kMVdinhkRD 1MdNqXHSGvTCiI2MAEJtuGYQs4L2PZJU+OskmLyyCOlNZV4cRsY/PDjhkIJBCUI03Qv9 xEAQ== 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=ubItE6LKw2orB7v2AcimbpgL8pxky4TfNwxAxcARPqM=; b=SCYj2iNGMMaWatQpxh+m8vc/dUOlwOPzQUIbWLlEMECJMGtL7Xvp60KjFK0Zr5kKFD O2hb+GlPYnPlMwpVKe6pnnq0v+5fOVlsK9ZcxMr/XCjUkZsUakv3HpW4Z+eIzYD7+p2Q Som+uswe4Q7WJZstxfPJnYYFsJBnBXoUDDeZfrHl+kojLDYncyZtHHtXJEa6NgTeuORN P82quLoaKBHBZipJsW8aug/m3Msfyu3xxkhruqzqX/Io8s6r0zBdMVq4sNPv/O8gRFwq 71QTDvp5b9S8bmHMdFssjgN7lGnaPIZDWZy+2SGQmt4W7snkKW6+xciTHDkS9ZGby5MI oW3g== X-Gm-Message-State: ALyK8tIgkh1LPZrvxxFMa+73NMU5CXXgIRVSlKUji8/hDvweQLYLgYqvkwB7FC9GHNxfMcOh X-Received: by 10.55.41.30 with SMTP id p30mr484428qkh.111.1467408139926; Fri, 01 Jul 2016 14:22:19 -0700 (PDT) Received: from [192.168.1.41] ([191.115.51.34]) by smtp.gmail.com with ESMTPSA id 13sm1398530qki.3.2016.07.01.14.22.10 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 01 Jul 2016 14:22:19 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_B6FB0DF1-91AB-4F8A-B6C7-CF23279074A3" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: John Bradley In-Reply-To: <717734404.555393.1467406368492.JavaMail.yahoo@mail.yahoo.com> Date: Fri, 1 Jul 2016 17:21:49 -0400 Message-Id: <65E833F7-E277-4F7D-AB1B-B5B61B91BE5B@ve7jtb.com> References: <994121658.55005.1467329084208.JavaMail.yahoo@mail.yahoo.com> <235316006.458279.1467392709447.JavaMail.yahoo@mail.yahoo.com> <6584BD74-B18F-4174-9E69-5C7B4B76F895@ve7jtb.com> <717734404.555393.1467406368492.JavaMail.yahoo@mail.yahoo.com> To: Oleg Gryb X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "oauth@ietf.org" , Liyu Yi Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 21:22:25 -0000 --Apple-Mail=_B6FB0DF1-91AB-4F8A-B6C7-CF23279074A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 If the attacker can modify the redirect URI to anything like an embedded = add that will do a 302 redirect then the recipient of the redirect can = load JS to extract the access token. This has happened at Facebook so many times I have lost count. It is = not theoretical, it happens all the time. One reason you need to do exact redirect_uri matching in the AS but = people are not so good at following that and take redirects to any URI = on the host in some cases. When used correctly for a real in web client it is fine. For a web = server client it introduces unnecessary risks over the code flow, or = hybrid flow using POST. Others may differ with my opinion. John B. > On Jul 1, 2016, at 4:52 PM, Oleg Gryb wrote: >=20 > John, >=20 > Thanks, very useful. However, I'm still trying to figure out why it's = dangerous. Fragment doesn't travel to a server in this new flow either. = Appending it to Location header is done by the browser who needs to = memorize what the original request was. If the original request had a = fragment and the browser got redirected, Location header will be = appended by the browser. >=20 > Are you saying that this is dangerous because the browser would = *always* need to store the fragment somewhere in its memory just in case = if a server decides to redirect? >=20 > So an attack vector here is that an imposter can try to retrieve the = fragment from the browser's memory somehow. Is my understanding correct? >=20 > Oleg. >=20 >=20 > From: John Bradley > To: Oleg Gryb =20 > Cc: "oauth@ietf.org" ; Liyu Yi > Sent: Friday, July 1, 2016 11:33 AM > Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit = grant >=20 > This behaviour started changing around 2011 >=20 > =46rom HTTP/1.1 > See https://tools.ietf.org/html/rfc7231#section-7.1.2 = I > f the Location value provided in a 3xx (Redirection) response = does > not have a fragment component, a user agent MUST process the > redirection as if the value inherits the fragment component of the > URI reference used to generate the request target (i.e., the > redirection inherits the original reference's fragment, if any). >=20 > For example, a GET request generated for the URI reference > "http://www.example.org/~tim " might = result in a 303 (See Other) > response containing the header field: >=20 > Location: /People.html#tim >=20 > which suggests that the user agent redirect to > "http://www.example.org/People.html#tim = =E2=80=9D >=20 > Likewise, a GET request generated for the URI reference > "http://www.example.org/index.html#larry = " might result in a 301 > (Moved Permanently) response containing the header field: >=20 > Location: http://www.example.net/index.html = >=20 > which suggests that the user agent redirect to > "http://www.example.net/index.html#larry = ", preserving the original > fragment identifier. >=20 >=20 > This blog also explores the change. > = https://blogs.msdn.microsoft.com/ieinternals/2011/05/16/url-fragments-and-= redirects/ = >=20 >=20 >> On Jul 1, 2016, at 1:05 PM, Oleg Gryb > wrote: >>=20 >> "Browsers now re-append fragments across 302 redirects unless they = are explicitly cleared this makes fragment encoding less safe than it = was when originally specified" - thanks Jim. Looks like a good reason = for vetting this flow out. >>=20 >> John, >> Please provide more details/links about re-appending fragments.=20 >>=20 >> Thanks, >> Oleg. >>=20 >>=20 >> From: Jim Manico > >> To: Oleg Gryb >=20 >> Cc: "oauth@ietf.org " >; Liyu Yi > >> Sent: Thursday, June 30, 2016 10:25 PM >> Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit = grant >>=20 >> Oleg! Hello! Great to see you pop up here with a similar concern. >>=20 >> John Bradley just answered this thread with the details I was looking = for (thanks John, hat tip your way). >>=20 >> He also mentioned details about fragment leakage: >>=20 >> "Browsers now re-append fragments across 302 redirects unless they = are explicitly cleared this makes fragment encoding less safe than it = was when originally specified" >>=20 >> Again, I'm new here but I'm grateful for this conversation. >>=20 >> Aloha, >> -- >> Jim Manico >> @Manicode >>=20 >> On Jul 1, 2016, at 1:24 AM, Oleg Gryb > wrote: >>=20 >>> We've discussed access tokens in URI back in 2010 = (https://www.ietf.org/mail-archive/web/oauth/current/msg04043.html = ). = There were two major objectives when I was saying that it's not secure: >>>=20 >>> 1. Fragment is not sent to a server by a browser. When I've asked if = this is true for every browser in the world, nobody was able to answer. >>> 2. Replacing with POST would mean a significant performance impact = in some high volume implementations (I think it was Goole folks who were = saying this, but I don't remember now). >>>=20 >>> AFAIR, nobody was arguing about browsing history, so it's valid. >>>=20 >>> So, 6 years later we're at square one with this and I hope that this = time the community will be more successful with getting rid of secrets = in URL. >>>=20 >>> BTW, Jim, if you can come up with other scenarios when fragments can = leak, please share. It'll probably help the community with solving this = problem faster than in 6 years. >>>=20 >>> Thanks, >>> Oleg. >>>=20 >>>=20 >>> From: Jim Manico > >>> To: Liyu Yi >; = oauth@ietf.org =20 >>> Sent: Wednesday, June 29, 2016 7:30 AM >>> Subject: Re: [OAUTH-WG] Security concern for URI fragment as = Implicit grant >>>=20 >>> > Shouldn=E2=80=99t it be more secure if we change to use a post = method for access token, similar to the SAML does? >>> I say yes. But please note I'm very new at this and someone with = more experience will have more to say or correct my comments. >>> Here are a few more details to consider. >>> 1) OAuth is a framework and not a standard, per se. Different = authorization servers will have different implementations that are not = necessarily compatible with other service providers. So there is no = standard to break, per se. >>> 2) Sensitive data in a URI is a bad idea. They leak all over the = place even over HTTPS. Even in fragments. >>> 3) Break the "rules" and find a way to submit sensitive data like = access tokens, session information or any other (even short term) = sensitive data in a secure fashion. This includes POST, JSON data = payloads over PUT/PATCH and other verbs - all over well configured = HTTPS. >>> 4) If you really must submit sensitive data over GET , consider = JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level = confidentiality and integrity. >>> Aloha, >>> Jim Manico >>> Manicode Security >>> https://www.manicode.com >>> On 6/27/16 9:30 PM, Liyu Yi wrote: >>>> While we are working on a project with OAuth2 implementation, one = question arises from our engineers. >>>> We noticed at = https://tools.= ietf.org/html/draft-ietf-oauth-v2-31#page-30 = , it is = specified that >>>> =20 >>>> (C) Assuming the resource owner grants access, the authorization >>>> server redirects the user-agent back to the client using = the >>>> redirection URI provided earlier. The redirection URI = includes >>>> the access token in the URI fragment. >>>> =20 >>>> For my understanding, the browser keeps the URI fragment in the = history, and this introduces unexpected exposure of the access token. A = user without authorization for the resource can get the access token as = long as he has the access to the browser. This can happen in a shared = computer in library, or for an IT staff who works on other employee=E2=80=99= s computer. >>>> =20 >>>> Shouldn=E2=80=99t it be more secure if we change to use a post = method for access token, similar to the SAML does? >>>> I feel there might be something I missed here. Any advices will be = appreciated. >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth = >>>=20 >>> --=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >>>=20 >>>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >>=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 --Apple-Mail=_B6FB0DF1-91AB-4F8A-B6C7-CF23279074A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 If the attacker can modify the redirect URI to anything like = an embedded add that will do a 302 redirect then the recipient of the = redirect can load JS to extract the access token.

This has happened at Facebook so many = times I have lost count.   It is not theoretical, it happens all = the time.
One reason you need to do exact = redirect_uri matching in the AS but people are not so good at following = that and take redirects to any URI on the host in some cases.

When used correctly for = a real in web client it is fine.  For a web server client it = introduces unnecessary risks over the code flow, or hybrid flow using = POST.

Others = may differ with my opinion.

John B.

On = Jul 1, 2016, at 4:52 PM, Oleg Gryb <oleg_gryb@yahoo.com>= wrote:

John,

Thanks, very = useful. However, I'm still trying to figure out why it's dangerous. = Fragment doesn't travel to a server in this new flow either. Appending = it to Location header is done by the browser who needs to memorize what = the original request was. If the original request had a fragment and the = browser got redirected, Location header will be appended by the = browser.

Are you saying = that this is dangerous because the browser would *always* need to store = the fragment somewhere in its memory just in case if a server decides to = redirect?

So an attack = vector here is that an imposter can try to retrieve the fragment from = the browser's memory somehow. Is my understanding correct?

Oleg.


=
From: John Bradley <ve7jtb@ve7jtb.com>
To: Oleg Gryb <oleg@gryb.info>
Cc: "oauth@ietf.org" <oauth@ietf.org>; Liyu = Yi <liyuyi@gmail.com>
Sent: Friday, July 1, = 2016 11:33 AM
Subject: Re: [OAUTH-WG] Security concern = for URI fragment as Implicit grant

This behaviour started changing around = 2011

=46rom = HTTP/1.1
See https://tools.i= etf.org/html/rfc7231#section-7.1.2I
      f the = Location value provided in a 3xx (Redirection) response = does
   not have a fragment component, a user agent MUST =
process the
   redirection as if the value inherits the fragment component of the
   URI reference used to generate the request target (i.e., the
   redirection inherits the original reference's fragment, if any).

   For example, a GET request generated for the URI reference
   "http://www.example.org/~tim" =
might result in a 303 (See Other)
   response containing the header field:

     Location: /People.html#tim

   which suggests that the user agent redirect to
   "http://www.example.org/Peo=
ple.html#tim=E2=80=9D

   Likewise, a GET request generated for the URI =
reference
   "http://www.example.org/in=
dex.html#larry" might result in a 301
   (Moved Permanently) response containing the header field:

     Location: http://www.example.net/index.ht=
ml

   which suggests that the user agent redirect to
   "http://www.example.net/in=
dex.html#larry", preserving the original
   fragment identifier.


This blog also explores the change.
https://blogs.msdn.microsoft.com/ieinternals/2011/05/1= 6/url-fragments-and-redirects/


On Jul 1, 2016, at 1:05 PM, Oleg Gryb <oleg_gryb@yahoo.com> = wrote:

"Browsers now re-append  fragments across 302 redirects = unless they are explicitly cleared this makes fragment encoding less = safe than it was  when originally specified" - thanks Jim. Looks = like a good reason for vetting this flow out.

John,
Please= provide more details/links about re-appending = fragments. 

Thanks,
Oleg.


=
From: Jim Manico <jim@manicode.com>
To: Oleg = Gryb <oleg@gryb.info>
Cc: "oauth@ietf.org" <oauth@ietf.org>; = Liyu Yi <liyuyi@gmail.com>
Sent: = Thursday, June 30, 2016 10:25 PM
Subject: Re: [OAUTH-WG] Security = concern for URI fragment as Implicit grant

Oleg! Hello! = Great to see you pop up here with a similar concern.

John Bradley just answered this = thread with the details I was looking for (thanks John, hat tip your = way).

He also mentioned details about = fragment leakage:

"Browsers now re-append  fragments across 302 redirects = unless they are explicitly cleared this makes fragment encoding less = safe than it was when originally specified"

Again, I'm new here but I'm = grateful for this conversation.

Aloha,
--
Jim = Manico
@Manicode

On Jul 1, 2016, at 1:24 AM, Oleg = Gryb <oleg_gryb@yahoo.com> = wrote:

We've discussed = access tokens in URI back in 2010 (https://www.ietf.org/mail-archive/web/oauth/current/msg04043.html). = There were two major objectives when I was saying that it's not = secure:

1. = Fragment is not sent to a server by a browser. When I've asked if this = is true for every browser in the world, nobody was able to = answer.
2. Replacing = with POST would mean a significant performance impact in some high = volume implementations (I think it was Goole folks who were saying this, = but I don't remember now).

AFAIR, nobody = was arguing about browsing history, so it's valid.

So, = 6 years later we're at square one with this and I hope that this time = the community will be more successful with getting rid of secrets in = URL.

BTW, = Jim, if you can come up with other scenarios when fragments can leak, = please share. It'll probably help the community with solving this = problem faster than in 6 years.

Thanks,
Oleg.


=
From: Jim Manico <jim@manicode.com>
To: Liyu = Yi <liyuyi@gmail.com>; oauth@ietf.org
Sent: Wednesday, June 29, 2016 = 7:30 AM
Subject: Re: [OAUTH-WG] Security = concern for URI fragment as Implicit grant

> Shouldn=E2=80=99t= it be more secure if we change to use a post method for access token, similar to the SAML = does?
I say yes. But = please note I'm very new at this and someone with more experience will have more to say or correct my = comments.
Here are a few = more details to consider.
1) OAuth is a = framework and not a standard, per se. Different authorization servers will have different implementations that are not necessarily compatible with other service providers. So there is no standard to break, per se.
2) Sensitive data in a URI is a bad = idea. They leak all over the place even over HTTPS. Even in fragments.
3) Break the "rules" and find a way to = submit sensitive data like access tokens, session information or any other (even short term) sensitive data in a secure fashion. This includes POST, JSON data payloads over PUT/PATCH and other verbs - all over well configured HTTPS.
4) If you really must submit sensitive = data over GET , consider JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level confidentiality and integrity.
Aloha,
Jim Manico
Manicode Security
https://www.manicode.com

On 6/27/16 9:30 PM, Liyu Yi = wrote:
While = we are working on a project with OAuth2 implementation, one question arises from our engineers.
We = noticed at https:= //tools.ietf.org/html/draft-ietf-oauth-v2-31#page-30, it is specified that
  
(C)  Assuming the resource owner grants access, the authorization
        = server redirects the user-agent back to the client using the
        = redirection URI provided earlier.  The redirection URI includes
        the = access token in the URI fragment.
 
For = my understanding, the browser keeps the URI fragment in the history, and this introduces unexpected exposure of the access token. A user without authorization for the resource can get the access token as long as he has the access to the browser. This can happen in a shared computer in library, or for an IT staff who works on other employee=E2=80=99s computer.
 
Shouldn=E2=80=99t it be more secure if we change to use a post method for access token, similar to the SAML does?
I = feel there might be something I missed here. Any advices will be appreciated.


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


--=20

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


=

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


=


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


= =
= --Apple-Mail=_B6FB0DF1-91AB-4F8A-B6C7-CF23279074A3-- From nobody Fri Jul 1 14:27:32 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3DE512B030 for ; Fri, 1 Jul 2016 14:27:30 -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 7mhWZsud-Fi4 for ; Fri, 1 Jul 2016 14:27:26 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::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 78DE512B020 for ; Fri, 1 Jul 2016 14:27:26 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id w59so64043810qtd.3 for ; Fri, 01 Jul 2016 14:27:26 -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=aDpiar7x5qGALVlQPUH8FgHVZjP5qNP1rS1gtbkOqzU=; b=YQizrHLQ6nsSQjQaevZcei/ThzbYJzM07Rsz6va2tpK7+aZYQwkn+sOo+pkq77hc2G R3IHk7d13qqrEvvZuEedk6q/vBSHUHRv0P6See2ON3jZstkIQxbFJDqa4I+GWmhqouDe DRg42dDSwY0pHBra6L7/wqE0D3x0+ykmKL8Bo+/PLKQOWNYtkuW2wlGl06zhXBQeRDN5 DlNGxpWDV8E7pNF98qVh0dHTMv2CCGbA4NcVIYJQ+2RdP35S8lXQnzZVUVCifFFU5So/ H28VBbuQ1ht2r3Y4OqZOJGS52O754zmW2o9SLHJ284cppooze7jjz+5e1orcinOz1fG4 MoSw== 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=aDpiar7x5qGALVlQPUH8FgHVZjP5qNP1rS1gtbkOqzU=; b=H2c/RCzrCiK1sXD79mNWKmbwXVGNe0XQ5GDKGdBy8of0GPNWgdkywIuMIRxgs1qTy9 o+ilGQW7nycvawuLARlFjj8xerj299LduzpXA10Y+Tjhn77pgWfZqH4PKVzb2SXqZyuR 8AKWRkbcEXlTXAOm5Sp//NQxY+4R5y/yheIYpzjKNyzjRrBkNfRGeBLHTOA6gcw4E+4o TLuymbnVlgodhIUuE3loSlN0YRiZc+2krEi2/5ucnDfqt0SjQnJtzjvq8ZgIPKDnpnlP 3NZKh84zrPE4fDLrIWA9DRTn9cifmeoEOkHTMZeBL3xP2y8KrKhZ/RyPY6Czji0dm1or GSHw== X-Gm-Message-State: ALyK8tJLhHXWd0mgeTWYwT7N4k85505yzNQ6Wg8ft7dqBVyUObyI632ZM1cz3ijub/UZ8GFS X-Received: by 10.237.34.213 with SMTP id q21mr602845qtc.53.1467408445236; Fri, 01 Jul 2016 14:27:25 -0700 (PDT) Received: from [192.168.1.41] ([191.115.51.34]) by smtp.gmail.com with ESMTPSA id n89sm2146428qte.38.2016.07.01.14.27.02 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 01 Jul 2016 14:27:24 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_A23E4FCD-7B99-4FD1-8402-488D339D5F9F" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: John Bradley In-Reply-To: Date: Fri, 1 Jul 2016 17:26:45 -0400 Message-Id: References: <994121658.55005.1467329084208.JavaMail.yahoo@mail.yahoo.com> <235316006.458279.1467392709447.JavaMail.yahoo@mail.yahoo.com> <6584BD74-B18F-4174-9E69-5C7B4B76F895@ve7jtb.com> <410908395.555462.1467407397629.JavaMail.yahoo@mail.yahoo.com> To: Josh Mandel X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Oleg Gryb , "" , Liyu Yi Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 21:27:31 -0000 --Apple-Mail=_A23E4FCD-7B99-4FD1-8402-488D339D5F9F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 HEART only supports web server clients at the moment. That might = change in future to support native apps if that an be made to support = the security requirements of Heath IT. So the thing HTTP POST responses won=E2=80=99t work well for is a type = of in browser single page OAuth client. That still needs fragment = encoded responses or the new post-message Java Script API approach. John B. > On Jul 1, 2016, at 5:16 PM, Josh Mandel wrote: >=20 > Thanks Justin, >=20 > To clarify: John's comment and my question were about POST. (I do = understand the behavior of HTTP POST and of window.postMessage; these = are totally different things.) =46rom my perspective in SMART Health IT, = we use the OAuth 2.0 authorization code flow, including HTTP POST, in = our authorization spec = even for public clients, and it has worked very well for us, with about = a dozen electronic health record servers supporting this approach. = That's why I was curious to hear John's perspective about limitations. >=20 > -J >=20 > On Fri, Jul 1, 2016 at 5:09 PM, Oleg Gryb > wrote: > > POST will send things to the server, which isn=E2=80=99t desirable = if your client is solely in the browser > Why it's not desirable, assuming that we disregard performance? You = can generate HTTP POST from JS, e.g. through an AJAX call. What is wrong = with this? >=20 >=20 > From: Justin Richer > > To: Josh Mandel >=20 > Cc: Oleg Gryb >; = ">" >; Liyu Yi > > Sent: Friday, July 1, 2016 2:00 PM >=20 > Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit = grant >=20 > POST will send things to the server, which isn=E2=80=99t desirable if = your client is solely in the browser. postMessage is a browser API and = not to be confused with HTTP POST. postMessage messages stay (or can = stay) within the browser, which is the intent here. >=20 > =E2=80=94 Justin >=20 >> On Jul 1, 2016, at 4:56 PM, Josh Mandel > wrote: >>=20 >=20 > John, >=20 > Could you clarify what you mean by "POST doesn't really work"? Do you = just mean that CORS support (e.g., http://caniuse.com/#feat=3Dcors = ) isn't universal, or something more? >=20 > On Fri, Jul 1, 2016 at 4:51 PM, John Bradley > wrote: > Yes but POST doesn't really work for in browser apps. >=20 > If it is a server app it should be using the code flow with GET or = POST as you like. >=20 > If we do a post message based binding it will be targeted at in = browser applications. >=20 > John B. >=20 > On Fri, Jul 1, 2016 at 4:42 PM, Liyu Yi > wrote: > BTW, I do not see any significant performance concerns for post. = Parsing and executing the Javascript logic for post operation will be on = the client side, no extra server load is introduced. >=20 > Plus post will remove the size restriction of the URL length. >=20 > -- Liyu=20 >=20 > On Fri, Jul 1, 2016 at 1:35 PM, Liyu Yi > wrote: > Thanks for the great comments and advices. >=20 > I think it is a good idea for the working group to revise the fragment = part in the spec, since there might be public available tools already = implemented this approach and people can end up with a solution with = serious security loopholes. >=20 > The re-append issue can be mitigate by a logic on Resource Server = which carefully re-writes/removes the fragment in any redirect, if the = the redirect can not be avoided. >=20 > -- Liyu > =20 >=20 > On Fri, Jul 1, 2016 at 11:33 AM, John Bradley > wrote: > This behaviour started changing around 2011 >=20 > =46rom HTTP/1.1 > See https://tools.ietf.org/html/rfc7231#section-7.1.2 = I > f the Location value provided in a 3xx (Redirection) response = does > not have a fragment component, a user agent MUST process the > redirection as if the value inherits the fragment component of the > URI reference used to generate the request target (i.e., the > redirection inherits the original reference's fragment, if any). >=20 > For example, a GET request generated for the URI reference > "http://www.example.org/~tim " might = result in a 303 (See Other) > response containing the header field: >=20 > Location: /People.html#tim >=20 > which suggests that the user agent redirect to > "http://www.example.org/People.html#tim = =E2=80=9D >=20 > Likewise, a GET request generated for the URI reference > "http://www.example.org/index.html#larry = " might result in a 301 > (Moved Permanently) response containing the header field: >=20 > Location: http://www.example.net/index.html = >=20 > which suggests that the user agent redirect to > "http://www.example.net/index.html#larry = ", preserving the original > fragment identifier. >=20 >=20 > This blog also explores the change. > = https://blogs.msdn.microsoft.com/ieinternals/2011/05/16/url-fragments-and-= redirects/ = >=20 >=20 >> On Jul 1, 2016, at 1:05 PM, Oleg Gryb > wrote: >>=20 >> "Browsers now re-append fragments across 302 redirects unless they = are explicitly cleared this makes fragment encoding less safe than it = was when originally specified" - thanks Jim. Looks like a good reason = for vetting this flow out. >>=20 >> John, >> Please provide more details/links about re-appending fragments.=20 >>=20 >> Thanks, >> Oleg. >>=20 >>=20 >> From: Jim Manico > >> To: Oleg Gryb >=20 >> Cc: "oauth@ietf.org " >; Liyu Yi > >> Sent: Thursday, June 30, 2016 10:25 PM >> Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit = grant >>=20 >> Oleg! Hello! Great to see you pop up here with a similar concern. >>=20 >> John Bradley just answered this thread with the details I was looking = for (thanks John, hat tip your way). >>=20 >> He also mentioned details about fragment leakage: >>=20 >> "Browsers now re-append fragments across 302 redirects unless they = are explicitly cleared this makes fragment encoding less safe than it = was when originally specified" >>=20 >> Again, I'm new here but I'm grateful for this conversation. >>=20 >> Aloha, >> -- >> Jim Manico >> @Manicode >>=20 >> On Jul 1, 2016, at 1:24 AM, Oleg Gryb > wrote: >>=20 >>> We've discussed access tokens in URI back in 2010 = (https://www.ietf.org/mail-archive/web/oauth/current/msg04043.html = ). = There were two major objectives when I was saying that it's not secure: >>>=20 >>> 1. Fragment is not sent to a server by a browser. When I've asked if = this is true for every browser in the world, nobody was able to answer. >>> 2. Replacing with POST would mean a significant performance impact = in some high volume implementations (I think it was Goole folks who were = saying this, but I don't remember now). >>>=20 >>> AFAIR, nobody was arguing about browsing history, so it's valid. >>>=20 >>> So, 6 years later we're at square one with this and I hope that this = time the community will be more successful with getting rid of secrets = in URL. >>>=20 >>> BTW, Jim, if you can come up with other scenarios when fragments can = leak, please share. It'll probably help the community with solving this = problem faster than in 6 years. >>>=20 >>> Thanks, >>> Oleg. >>>=20 >>>=20 >>> From: Jim Manico > >>> To: Liyu Yi >; = oauth@ietf.org =20 >>> Sent: Wednesday, June 29, 2016 7:30 AM >>> Subject: Re: [OAUTH-WG] Security concern for URI fragment as = Implicit grant >>>=20 >>> > Shouldn=E2=80=99t it be more secure if we change to use a post = method for access token, similar to the SAML does? >>> I say yes. But please note I'm very new at this and someone with = more experience will have more to say or correct my comments. >>> Here are a few more details to consider. >>> 1) OAuth is a framework and not a standard, per se. Different = authorization servers will have different implementations that are not = necessarily compatible with other service providers. So there is no = standard to break, per se. >>> 2) Sensitive data in a URI is a bad idea. They leak all over the = place even over HTTPS. Even in fragments. >>> 3) Break the "rules" and find a way to submit sensitive data like = access tokens, session information or any other (even short term) = sensitive data in a secure fashion. This includes POST, JSON data = payloads over PUT/PATCH and other verbs - all over well configured = HTTPS. >>> 4) If you really must submit sensitive data over GET , consider = JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level = confidentiality and integrity. >>> Aloha, >>> Jim Manico >>> Manicode Security >>> https://www.manicode.com >>> On 6/27/16 9:30 PM, Liyu Yi wrote: >>>> While we are working on a project with OAuth2 implementation, one = question arises from our engineers. >>>> We noticed at = https://tools.= ietf.org/html/draft-ietf-oauth-v2-31#page-30 = , it is = specified that >>>> =20 >>>> (C) Assuming the resource owner grants access, the authorization >>>> server redirects the user-agent back to the client using = the >>>> redirection URI provided earlier. The redirection URI = includes >>>> the access token in the URI fragment. >>>> =20 >>>> For my understanding, the browser keeps the URI fragment in the = history, and this introduces unexpected exposure of the access token. A = user without authorization for the resource can get the = access token as long as he has the access to the browser. This can = happen in a shared computer in library, or for an IT staff who works on = other employee=E2=80=99s computer. >>>> =20 >>>> Shouldn=E2=80=99t it be more secure if we change to use a post = method for access token, similar to the SAML does? >>>> I feel there might be something I missed here. Any advices will be = appreciated. >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth = >>>=20 >>> --=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >>>=20 >>>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >>=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_A23E4FCD-7B99-4FD1-8402-488D339D5F9F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 HEART only supports web server clients at the moment.   = That might change in future to support native apps if that an be made to = support the security requirements of Heath IT.

So the thing HTTP POST responses won=E2=80=99t = work well for is a type of in browser single page OAuth client. =  That still needs fragment encoded responses or the new = post-message Java Script API approach.

John B.


On Jul 1, 2016, at 5:16 PM, = Josh Mandel <jmandel@gmail.com> wrote:

Thanks Justin,

To clarify: John's comment and my question were about POST. = (I do understand the behavior of HTTP POST and of window.postMessage; = these are totally different things.) =46rom my perspective in SMART = Health IT, we use the OAuth 2.0 authorization code flow, including HTTP = POST, in our authorization spec even for public = clients, and it has worked very well for us, with about a dozen = electronic health record servers supporting this approach. That's why I = was curious to hear John's perspective about limitations.

  -J

On Fri, = Jul 1, 2016 at 5:09 PM, Oleg Gryb <oleg_gryb@yahoo.com> wrote:
> POST will send things = to the server, which isn=E2=80=99t desirable if your client is solely in = the browser
Why it's not = desirable, assuming that we disregard performance? You can generate HTTP = POST from JS, e.g. through an AJAX call. What is wrong with this?


=
= From:= Justin Richer <jricher@mit.edu>
To: Josh Mandel <jmandel@gmail.com>
Cc: Oleg Gryb <oleg@gryb.info>; "<oauth@ietf.org>" <oauth@ietf.org>; Liyu Yi <liyuyi@gmail.com>
Sent: Friday, July 1, = 2016 2:00 PM

Subject:= Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant
=

POST will = send things to the server, which isn=E2=80=99t desirable if your client = is solely in the browser. postMessage is a browser API and not to be = confused with HTTP POST. postMessage messages stay (or can stay) within = the browser, which is the intent here.

 =E2=80=94 Justin

On Jul = 1, 2016, at 4:56 PM, Josh Mandel <jmandel@gmail.com> wrote:

John,

Could you = clarify what you mean by "POST= doesn't really work"? Do you just mean that CORS support (e.g., http://caniuse.com/#feat=3Dcors) isn't = universal, or something more?

On Fri, Jul 1, 2016 at 4:51 = PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
Yes but = POST doesn't really work for in browser apps.

If it is a server app it = should be using the code flow with GET or POST as you like.

If we do = a  post message based binding it will be targeted at in browser = applications.

John B.

On Fri, Jul 1, 2016 at 4:42 = PM, Liyu Yi <liyuyi@gmail.com> wrote:
BTW, I do = not see any significant performance concerns for post. Parsing and = executing the Javascript logic for post operation will be on the client = side, no extra server load is introduced.

Plus post will remove = the size restriction of the URL length.

-- = Liyu 

On Fri, Jul 1, 2016 at 1:35 = PM, Liyu Yi <liyuyi@gmail.com> wrote:
Thanks for the great comments and advices.

I think it is a good idea = for the working group to revise the fragment part in the spec, since = there might be public available tools already implemented this approach = and people can end up with a solution with serious security = loopholes.

The re-append issue can be mitigate by a logic on Resource = Server which carefully re-writes/removes the fragment in any redirect, = if the the redirect can not be avoided.

-- = Liyu
 

On Fri, Jul 1, 2016 at 11:33 = AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
This behaviour started changing around 2011

=46rom = HTTP/1.1
See https://tools.ietf.org/html/rfc7231#section-7.1.2I
    =   f the Location value provided in a 3xx (Redirection) response = does
   not have a fragment component, a user agent MUST =
process the
   redirection as if the value inherits the fragment component of the
   URI reference used to generate the request target (i.e., the
   redirection inherits the original reference's fragment, if any).

   For example, a GET request generated for the URI reference
   "http://www.example.org/~tim" might result in a 303 (See =
Other)
   response containing the header field:

     Location: /People.html#tim

   which suggests that the user agent redirect to
   "http://www.example.org/People.html#tim=E2=80=9D

   Likewise, a GET request generated for the URI =
reference
   "http://www.example.org/index.html#larry" might result in =
a 301
   (Moved Permanently) response containing the header field:

     Location: http://www.example.net/index.html

   which suggests that the user agent redirect to
   "http://www.example.net/index.html#larry", preserving the =
original
   fragment identifier.


This blog = also explores the change.
https://blogs.msdn.microsoft.com/ieinternals/2011/05/16/url-fra= gments-and-redirects/


On Jul 1, 2016, at 1:05 PM, Oleg Gryb <oleg_gryb@yahoo.com> wrote:

"Browsers now = re-append  fragments across 302 redirects unless they are = explicitly cleared this makes fragment encoding less safe than it was =  when originally specified" - thanks Jim. Looks like a good reason = for vetting this flow out.

John,
Please provide more details/links about re-appending = fragments. 

Thanks,
Oleg.


=
From: Jim Manico <jim@manicode.com>
To: = Oleg Gryb <oleg@gryb.info>
Cc: = "oauth@ietf.org" <oauth@ietf.org>; Liyu Yi <liyuyi@gmail.com>
Sent: = Thursday, June 30, 2016 10:25 PM
Subject:= Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

Oleg! Hello! = Great to see you pop up here with a similar concern.

John = Bradley just answered this thread with the details I was looking for = (thanks John, hat tip your way).

He also mentioned details about = fragment leakage:

"Browsers now = re-append  fragments across 302 redirects unless they are = explicitly cleared this makes fragment encoding less safe than it was = when originally specified"

Again, I'm new here but I'm grateful = for this conversation.

Aloha,
--
Jim Manico
@Manicode

On Jul 1, 2016, at 1:24 AM, Oleg Gryb <oleg_gryb@yahoo.com> wrote:

We've discussed access tokens in URI back in = 2010 (https://www.ietf.org/mail-archive/web/oauth/current/msg04043.ht= ml). There were two major objectives when I was saying that it's not = secure:

1. Fragment is not sent to = a server by a browser. When I've asked if this is true for every browser = in the world, nobody was able to answer.
2. Replacing with POST would mean a significant performance = impact in some high volume implementations (I think it was Goole folks = who were saying this, but I don't remember now).

AFAIR, nobody was arguing about browsing history, so it's = valid.

So, 6 years later we're at = square one with this and I hope that this time the community will be = more successful with getting rid of secrets in URL.

BTW, Jim, if you can come up with other scenarios when = fragments can leak, please share. It'll probably help the community with = solving this problem faster than in 6 years.

Thanks,
Oleg.


=
From: Jim Manico <jim@manicode.com>
To: = Liyu Yi <liyuyi@gmail.com>; oauth@ietf.org
Sent: = Wednesday, June 29, 2016 7:30 AM
Subject:= Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

> Shouldn=E2=80=99t it be more = secure if we change to use a post method for access token, similar to the SAML = does?
I say yes. But please note I'm very new at this and = someone with more experience will have more to say or correct my = comments.
Here are a few more details to consider.
1) OAuth is a framework and not a standard, per se. = Different authorization servers will have different implementations that are not necessarily compatible with other service providers. So there is no standard to break, per se.
2) Sensitive data in a URI is a bad idea. They leak = all over the place even over HTTPS. Even in fragments.
3) Break the "rules" and find a way to submit = sensitive data like access tokens, session information or any other (even short term) sensitive data in a secure fashion. This includes POST, JSON data payloads over PUT/PATCH and other verbs - all over well configured HTTPS.
4) If you really must submit sensitive data over GET = , consider JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level confidentiality and integrity.
Aloha,
Jim Manico
Manicode Security
https://www.manicode.com

On 6/27/16 9:30 PM, Liyu Yi = wrote:
While we are working on a = project with OAuth2 implementation, one question arises from our engineers.
We noticed at https://tools.ietf.org/html/draft-ietf-oauth-v2-31#page-30<= /span>, it is specified that
  
(C)  Assuming the resource = owner grants access, the authorization
        server redirects = the user-agent back to the client using the
        redirection URI = provided earlier.  The redirection URI includes
        the access token = in the URI fragment.
 
For my understanding, the = browser keeps the URI fragment in the history, and this introduces unexpected exposure of the access token. A user without authorization for the resource can get the access token as long as he has the access to the browser. This can happen in a shared computer in library, or for an IT staff who works on other employee=E2=80=99s computer.
 
Shouldn=E2=80=99t it be more = secure if we change to use a post method for access token, similar to the SAML does?
I feel there might be something = I missed here. Any advices will be appreciated.


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


--=20

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


=

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


=





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


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


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


=
=

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

= --Apple-Mail=_A23E4FCD-7B99-4FD1-8402-488D339D5F9F-- From nobody Fri Jul 1 14:33:42 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB8512B048 for ; Fri, 1 Jul 2016 14:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4g80cWq7g8g0 for ; Fri, 1 Jul 2016 14:33:37 -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 0C4CD12B020 for ; Fri, 1 Jul 2016 14:33:37 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id t127so223450521qkf.1 for ; Fri, 01 Jul 2016 14:33:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HVtdjiRwZ2rJO7Q6qWLPVrQ+XiFDmcDSAlQXSAS7mGM=; b=O2lvB/51AxXJLEJRkC/jHlhtdLsiOEvSETrQDuPL9HR7CWbVkjuqRU8aSQplGMDQvA EOjlCpZSPJm2qEv29ExFS5VicodKWBels7cb/QFYu1KucQzoa5wE1Xxy5XPfBIsWl5r8 PgFsdbqBSgk+J+U3BikVaUcEvxOJe2sUuVnWUg3XdE/1RGbY4xAgstyK2R1CDpJHa6VY 2zlp59M0fdTzHl1mW72X61P9SZCo1z/yNlNHg1/opYHRIE3DBXQeyexJ5hB0vKpMU5eB c2mdZVviX+moatDAPK/DUaQ+9wz3vOiU9lpOM0DwrRsyIU9Lf9K1G1Z7UVKgivgeyrcV EmKA== 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=HVtdjiRwZ2rJO7Q6qWLPVrQ+XiFDmcDSAlQXSAS7mGM=; b=Qak9SzODCTjyvqGOhZXX+/34wiNYnZl+8LfDRW/t/Su3YZ/CNkqUUPYpD8Csw7anPm QLOSOmgTbMUKUbLyTFH4A6kfXGizQgIjQSzlWkst043VLpnR/TAlv9WMvC3+RyUq8O8w b3NyBpDJG/3h6mf1+bH5brvGTGG3kpc0h2Fg+atw5f1ShwQCKUHwToRZsDhUNx5lTf5r c9WbTVHnNUC8+m6CCUNNDHpZ94pt3A/iyhDWWO3tyXRJeF4VBBiJwJLCSTsYZctPMavE OCkDqYNm91V9vqXaVGq+2vVOP29dYidbMfPXaOErAa8Rdx5i8jCW+KsSRn7p3A0w37YO Gd3A== X-Gm-Message-State: ALyK8tLOs7XA6GsqZjeLcGjQM3Ul2cGSSyDlGFcIJ8i1u77zo3m4c8m/sVlDbQF+iJSvNdw10ZROUsQllAxmyw== X-Received: by 10.129.3.17 with SMTP id 17mr252536ywd.288.1467408816031; Fri, 01 Jul 2016 14:33:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.69.65 with HTTP; Fri, 1 Jul 2016 14:33:16 -0700 (PDT) In-Reply-To: References: <994121658.55005.1467329084208.JavaMail.yahoo@mail.yahoo.com> <235316006.458279.1467392709447.JavaMail.yahoo@mail.yahoo.com> <6584BD74-B18F-4174-9E69-5C7B4B76F895@ve7jtb.com> <410908395.555462.1467407397629.JavaMail.yahoo@mail.yahoo.com> From: Josh Mandel Date: Fri, 1 Jul 2016 17:33:16 -0400 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=001a1142d7be384dde053699bd92 Archived-At: Cc: Oleg Gryb , "" , Liyu Yi Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 21:33:42 -0000 --001a1142d7be384dde053699bd92 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable John, I appreciate your response. I'm hoping you can clarify why you say that "HTTP POST... won't work well for... [a] single page OAuth client"? We commonly build single-page apps that act as OAuth clients for SMART (e.g. this sample app ), and we've had good experience with the technique. Could you elaborate? -J On Fri, Jul 1, 2016 at 5:26 PM, John Bradley wrote: > HEART only supports web server clients at the moment. That might change > in future to support native apps if that an be made to support the securi= ty > requirements of Heath IT. > > So the thing HTTP POST responses won=E2=80=99t work well for is a type of= in > browser single page OAuth client. That still needs fragment encoded > responses or the new post-message Java Script API approach. > > John B. > > > On Jul 1, 2016, at 5:16 PM, Josh Mandel wrote: > > Thanks Justin, > > To clarify: John's comment and my question were about POST. (I do > understand the behavior of HTTP POST and of window.postMessage; these are > totally different things.) From my perspective in SMART Health IT, we use > the OAuth 2.0 authorization code flow, including HTTP POST, in our author= ization > spec even for public > clients, and it has worked very well for us, with about a dozen electroni= c > health record servers supporting this approach. That's why I was curious = to > hear John's perspective about limitations. > > -J > > On Fri, Jul 1, 2016 at 5:09 PM, Oleg Gryb wrote: > >> > POST will send things to the server, which isn=E2=80=99t desirable if = your >> client is solely in the browser >> Why it's not desirable, assuming that we disregard performance? You can >> generate HTTP POST from JS, e.g. through an AJAX call. What is wrong wit= h >> this? >> >> >> ------------------------------ >> *From:* Justin Richer >> *To:* Josh Mandel >> *Cc:* Oleg Gryb ; "" ; >> Liyu Yi >> *Sent:* Friday, July 1, 2016 2:00 PM >> >> *Subject:* Re: [OAUTH-WG] Security concern for URI fragment as Implicit >> grant >> >> POST will send things to the server, which isn=E2=80=99t desirable if yo= ur client >> is solely in the browser. postMessage is a browser API and not to be >> confused with HTTP POST. postMessage messages stay (or can stay) within = the >> browser, which is the intent here. >> >> =E2=80=94 Justin >> >> On Jul 1, 2016, at 4:56 PM, Josh Mandel wrote: >> >> John, >> >> Could you clarify what you mean by "POST doesn't really work"? Do you >> just mean that CORS support (e.g., http://caniuse.com/#feat=3Dcors) isn'= t >> universal, or something more? >> >> On Fri, Jul 1, 2016 at 4:51 PM, John Bradley wrote: >> >> Yes but POST doesn't really work for in browser apps. >> >> If it is a server app it should be using the code flow with GET or POST >> as you like. >> >> If we do a post message based binding it will be targeted at in browser >> applications. >> >> John B. >> >> On Fri, Jul 1, 2016 at 4:42 PM, Liyu Yi wrote: >> >> BTW, I do not see any significant performance concerns for post. Parsing >> and executing the Javascript logic for post operation will be on the cli= ent >> side, no extra server load is introduced. >> >> Plus post will remove the size restriction of the URL length. >> >> -- Liyu >> >> On Fri, Jul 1, 2016 at 1:35 PM, Liyu Yi wrote: >> >> Thanks for the great comments and advices. >> >> I think it is a good idea for the working group to revise the fragment >> part in the spec, since there might be public available tools already >> implemented this approach and people can end up with a solution with >> serious security loopholes. >> >> The re-append issue can be mitigate by a logic on Resource Server which >> carefully re-writes/removes the fragment in any redirect, if the the >> redirect can not be avoided. >> >> -- Liyu >> >> >> On Fri, Jul 1, 2016 at 11:33 AM, John Bradley wrote: >> >> This behaviour started changing around 2011 >> >> From HTTP/1.1 >> See https://tools.ietf.org/html/rfc7231#section-7.1.2I >> f the Location value provided in a 3xx (Redirection) response does >> >> not have a fragment component, a user agent MUST process the >> redirection as if the value inherits the fragment component of the >> URI reference used to generate the request target (i.e., the >> redirection inherits the original reference's fragment, if any). >> >> For example, a GET request generated for the URI reference >> "http://www.example.org/~tim" might result in a 303 (See Other) >> response containing the header field: >> >> Location: /People.html#tim >> >> which suggests that the user agent redirect to >> "http://www.example.org/People.html#tim=E2=80=9D >> >> >> Likewise, a GET request generated for the URI reference >> "http://www.example.org/index.html#larry" might result in a 301 >> (Moved Permanently) response containing the header field: >> >> Location: http://www.example.net/index.html >> >> which suggests that the user agent redirect to >> "http://www.example.net/index.html#larry", preserving the original >> fragment identifier. >> >> >> >> This blog also explores the change. >> >> https://blogs.msdn.microsoft.com/ieinternals/2011/05/16/url-fragments-an= d-redirects/ >> >> >> On Jul 1, 2016, at 1:05 PM, Oleg Gryb wrote: >> >> "Browsers now re-append fragments across 302 redirects unless they are >> explicitly cleared this makes fragment encoding less safe than it was w= hen >> originally specified" - thanks Jim. Looks like a good reason for vetting >> this flow out. >> >> John, >> Please provide more details/links about re-appending fragments. >> >> Thanks, >> Oleg. >> >> >> ------------------------------ >> *From:* Jim Manico >> *To:* Oleg Gryb >> *Cc:* "oauth@ietf.org" ; Liyu Yi >> *Sent:* Thursday, June 30, 2016 10:25 PM >> *Subject:* Re: [OAUTH-WG] Security concern for URI fragment as Implicit >> grant >> >> Oleg! Hello! Great to see you pop up here with a similar concern. >> >> John Bradley just answered this thread with the details I was looking fo= r >> (thanks John, hat tip your way). >> >> He also mentioned details about fragment leakage: >> >> "Browsers now re-append fragments across 302 redirects unless they are >> explicitly cleared this makes fragment encoding less safe than it was wh= en >> originally specified" >> >> Again, I'm new here but I'm grateful for this conversation. >> >> Aloha, >> -- >> Jim Manico >> @Manicode >> >> On Jul 1, 2016, at 1:24 AM, Oleg Gryb wrote: >> >> We've discussed access tokens in URI back in 2010 ( >> https://www.ietf.org/mail-archive/web/oauth/current/msg04043.html). >> There were two major objectives when I was saying that it's not secure: >> >> 1. Fragment is not sent to a server by a browser. When I've asked if thi= s >> is true for every browser in the world, nobody was able to answer. >> 2. Replacing with POST would mean a significant performance impact in >> some high volume implementations (I think it was Goole folks who were >> saying this, but I don't remember now). >> >> AFAIR, nobody was arguing about browsing history, so it's valid. >> >> So, 6 years later we're at square one with this and I hope that this tim= e >> the community will be more successful with getting rid of secrets in URL= . >> >> BTW, Jim, if you can come up with other scenarios when fragments can >> leak, please share. It'll probably help the community with solving this >> problem faster than in 6 years. >> >> Thanks, >> Oleg. >> >> >> ------------------------------ >> *From:* Jim Manico >> *To:* Liyu Yi ; oauth@ietf.org >> *Sent:* Wednesday, June 29, 2016 7:30 AM >> *Subject:* Re: [OAUTH-WG] Security concern for URI fragment as Implicit >> grant >> >> > Shouldn=E2=80=99t it be more secure if we change to use a post method = for >> access token, similar to the SAML does? >> I say yes. But please note I'm very new at this and someone with more >> experience will have more to say or correct my comments. >> Here are a few more details to consider. >> 1) OAuth is a framework and not a standard, per se. Different >> authorization servers will have different implementations that are not >> necessarily compatible with other service providers. So there is no >> standard to break, per se. >> 2) Sensitive data in a URI is a bad idea. They leak all over the place >> even over HTTPS. Even in fragments. >> 3) Break the "rules" and find a way to submit sensitive data like access >> tokens, session information or any other (even short term) sensitive dat= a >> in a secure fashion. This includes POST, JSON data payloads over PUT/PAT= CH >> and other verbs - all over well configured HTTPS. >> 4) If you really must submit sensitive data over GET , consider >> JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level >> confidentiality and integrity. >> Aloha, >> >> Jim Manico >> Manicode Securityhttps://www.manicode.com >> >> >> On 6/27/16 9:30 PM, Liyu Yi wrote: >> >> While we are working on a project with OAuth2 implementation, one >> question arises from our engineers. >> We noticed at >> >> https://tools.ietf.org/html/draft-ietf-oauth-v2-31#page-30, it is >> specified that >> >> (C) Assuming the resource owner grants access, the authorization >> server redirects the user-agent back to the client using the >> redirection URI provided earlier. The redirection URI includes >> the access token in the URI fragment. >> >> For my understanding, the browser keeps the URI fragment in the history, >> and this introduces unexpected exposure of the access token. A user with= out >> authorization for the resource can get the access token as long as he ha= s >> the access to the browser. This can happen in a shared computer in libra= ry, >> or for an IT staff who works on other employee=E2=80=99s computer. >> >> Shouldn=E2=80=99t it be more secure if we change to use a post method fo= r access >> token, similar to the SAML does? >> I feel there might be something I missed here. Any advices will be >> appreciated. >> >> >> _______________________________________________ >> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oa= uth >> >> >> -- >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --001a1142d7be384dde053699bd92 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
John,

I appreciate your response. I'= ;m hoping you can clarify why you say that "HTTP POST... won't wor= k well for... [a] single page OAuth client"?

We com= monly build single-page apps that act as OAuth clients for SMART (e.g. this sample app=C2= =A0), and we've had good experience with the technique. Could you elabo= rate?

=C2=A0 -J

=
On Fri, Jul 1, 2016 at 5:26 PM, John Bradley <v= e7jtb@ve7jtb.com> wrote:
HEART only supports web server clients at= the moment. =C2=A0 That might change in future to support native apps if t= hat an be made to support the security requirements of Heath IT.

So the thing HTTP POST responses won=E2=80=99t work well for is a type o= f in browser single page OAuth client.=C2=A0 That still needs fragment enco= ded responses or the new post-message Java Script API approach.
<= br>
John B.


On Jul 1, 2016, at 5:16 PM, Josh Mandel <jmandel@gmail.com> w= rote:

Thanks Justin,

To c= larify: John's comment and my question were about POST. (I do understan= d the behavior of HTTP POST and of window.postMessage; these are totally di= fferent things.) From my perspective in SMART Health IT, we use the OAuth 2= .0 authorization code flow, including HTTP POST, in our authorization spec<= /a>=C2=A0even for public clients, and it has worked very well for us, with = about a dozen electronic health record servers supporting this approach. Th= at's why I was curious to hear John's perspective about limitations= .


On Fri, Jul 1, 2016 at 5:09 PM, Oleg Gryb <oleg= _gryb@yahoo.com> wrote:
> POST= will send things to the server, which isn=E2=80=99t desirable if your clie= nt is solely in the browser
Why it's not d= esirable, assuming that we disregard performance? You can generate HTTP POS= T from JS, e.g. through an AJAX call. What is wrong with this?


<= font face=3D"Arial" size=3D"2">
From: Justin Richer <jricher@mit.edu>
To: Josh Mandel <jmandel@gmail.com>
Cc: Oleg Gryb <oleg@gryb.info>; "<oauth@ietf.org>" <oauth@ietf.org>; Liyu Yi <= ;liyuyi@gmail.com= >
Sent: Friday, July = 1, 2016 2:00 PM

Subject:<= /span> Re: [OAUTH-WG] Security concern for URI fragment as Implicit gra= nt

POST will se= nd things to the server, which isn=E2=80=99t desirable if your client is so= lely in the browser. postMessage is a browser API and not to be confused wi= th HTTP POST. postMessage messages stay (or can stay) within the browser, w= hich is the intent here.

=C2=A0=E2=80=94 = Justin

On Jul 1, 2016, at 4:56 PM, Josh Mandel <jmandel@gmail.com= > wrote:

John,

=
Could you clarify what you mean by "POST doesn't really work"? Do you just mean that CORS support = (e.g.,=C2=A0http://caniuse.com/#feat=3Dcors) isn'= ;t universal, or something more?

O= n Fri, Jul 1, 2016 at 4:51 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
Yes but POST doesn't really work for in browser apps.
<= br clear=3D"none">
If it is a server app it should be using the c= ode flow with GET or POST as you like.

<= div>If we do a =C2=A0post message based binding it will be targeted at in b= rowser applications.

John B.
<= /div>

On Fri, Jul 1, 2016 at 4:42 PM, Liyu Yi <= span dir=3D"ltr"><liyuyi@gmail.com> wrote:
BTW, I do not see any significant p= erformance concerns for post. Parsing and executing the Javascript logic fo= r post operation will be on the client side, no extra server load is introd= uced.

Plus post will remove the size rest= riction of the URL length.

-- Liyu=C2=A0

On Fri, Jul 1, 2016 at 1:35 PM, Liyu Yi <liyuyi@gmail.com> wrote:
Thanks for the great comments and advi= ces.

I think it is a good idea for the w= orking group to revise the fragment part in the spec, since there might be = public available tools already implemented this approach and people can end= up with a solution with serious security loopholes.

The re-append issue can be mitigate by a logic on Resource Serv= er which carefully re-writes/removes the fragment in any redirect, if the t= he redirect can not be avoided.
<= /span>

-- Liyu
=C2=A0

On Fri, Jul 1= , 2016 at 11:33 AM, John Bradley <ve7jtb@v= e7jtb.com> wrote:
This behaviour started changing around 2011

From HTTP/1.1
=C2=A0 =C2=A0 =C2=A0 f the Location value provided in a 3xx (Re= direction) response does
   not have a fragment com=
ponent, a user agent MUST process the
   redirection as if the value inherits the fragment component of the
   URI reference used to generate the request target (i.e., the
   redirection inherits the original reference's fragment, if any).

   For example, a GET request generated for the URI reference
   "http://www.example.org/~tim" might result =
in a 303 (See Other)
   response containing the header field:

     Location: /People.html#tim

   which suggests that the user agent redirect to
   "http://www.example.org/People.html#tim=E2=80=9D

   L=
ikewise, a GET request generated for the URI reference
   "http://www.example.org/index.html#larry=
" might result in a 301
   (Moved Permanently) response containing the header field:

     Location: http://www.example.net/index.html

   which suggests that the user agent redirect to
   "http://www.example.net/index.html#larry=
", preserving the original
   fragment identifier.


This blog also explores the change.


On Jul 1, 2016, at 1:05 PM, Oleg Gryb <ole= g_gryb@yahoo.com> wrote:

"Browsers now re-append =C2=A0fragments across 302 redirects unle= ss they are explicitly cleared this makes fragment encoding less safe than = it was =C2=A0when originally specified" - thanks Jim. Looks like a goo= d reason for vetting this flow out.

John,
Please provide more details/links about re-ap= pending fragments.=C2=A0

Thanks,
Oleg.


=
From: Jim M= anico <jim@manicode.com>
To: Oleg Gryb <oleg@gryb.i= nfo>
Cc: "oauth@ietf.org" <oauth@ietf.org<= /a>>; Liyu Yi <liyuyi@gmail.com>
= Sent: Thursday, June 30, 20= 16 10:25 PM
Subject:= Re: [OAUTH-WG] Security concern for URI fragment as Implicit gr= ant

Oleg!= Hello! Great to see you pop up here with a similar concern.

John Bradley just answered this thread with the d= etails I was looking for (thanks John, hat tip your way).

He also mentioned details about fragment leakage:

"Browsers now re-append = =C2=A0fragments across 302 redirects unless they are explicitly cleared thi= s makes fragment encoding less safe than it was when originally specified&q= uot;

Again, I'm new here= but I'm grateful for this conversation.

<= /div>
Aloha,
--
Jim Manico
@Manicode=

On Jul 1, 2016, at 1:24 AM, Oleg G= ryb <oleg_gryb@yahoo.com> wrote:
=
We've discusse= d access tokens in URI back in 2010 (https://www.ietf.org/mail-archive/web/oauth/current/m= sg04043.html). There were two major objectives when I was saying that i= t's not secure:

1. Fragment is not sent to a server by a browser. When I've as= ked if this is true for every browser in the world, nobody was able to answ= er.
2. Replacing with POST would mean a significant p= erformance impact in some high volume implementations (I think it was Goole= folks who were saying this, but I don't remember now).

AFAIR, nobody was arguin= g about browsing history, so it's valid.

So, 6 years later we're at square one= with this and I hope that this time the community will be more successful = with getting rid of secrets in URL.

BTW, Jim, if you can come up with other scenarios = when fragments can leak, please share. It'll probably help the communit= y with solving this problem faster than in 6 years.
<= br clear=3D"none">
Thanks,
Oleg= .


<= span style=3D"font-weight:bold">From: Jim Manico <= jim@manicode.com>
To: Liyu Yi <liyuyi@gmail.com>; oauth@ietf.org
Sent: Wednesday, June 29, 2016 7:30 AM
= Subject: Re: [OAUTH-WG] Securit= y concern for URI fragment as Implicit grant

> Shouldn=E2=80=99t it be more secure if we change to use a post method for access token, similar to the SAML does?
I say yes. But please note I'm very new at this and someone wi= th more experience will have more to say or correct my comments.
Here are a few more details to consider.
1) OAuth is a framework and not a standard, per se. Different authorization servers will have different implementations that are not necessarily compatible with other service providers. So there is no standard to break, per se.
2) Sensitive data in a URI is a bad idea. They leak all over the place even over HTTPS. Even in fragments.
3) Break the "rules" and find a way to submit sensitive = data like access tokens, session information or any other (even short term) sensitive data in a secure fashion. This includes POST, JSON data payloads over PUT/PATCH and other verbs - all over well configured HTTPS.
4) If you really must submit sensitive data over GET , consider JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level confidentiality and integrity.
Aloha,
Jim Manico
Manicode Security
https://www.manicode.com

On 6/27/16 9:30 PM, Liyu Yi wrote:
While we are working on a project with OAuth2 implementation, one question arises from our engineers.
=C2=A0=C2=A0
(C)=C2=A0 Assuming the resource owner grants access, the authorization
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 server redire= cts the user-agent back to the client using the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 redirection U= RI provided earlier.=C2=A0 The redirection URI includes
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the access to= ken in the URI fragment.
=C2=A0
For my understanding, the browser keeps the URI fragment in the history, and this introduces unexpected exposure of the access token. A user without authorization for the resource can get the access token as long as he has the access to the browser. This can happen in a shared computer in library, or for an IT staff who works on other employee=E2=80=99s computer.
=C2=A0
Shouldn=E2=80=99t it be more secure if we change to use a post method for access token, similar to the SAML does?
I feel there might be something I missed here. Any advices will be appreciated.


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


--=20




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


=





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


_______________________________________________
OAuth mai= ling list
OAuth@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">ht= tps://www.ietf.org/mailman/listinfo/oauth


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



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

--001a1142d7be384dde053699bd92-- From nobody Fri Jul 1 14:45:49 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 386D312D0AB for ; Fri, 1 Jul 2016 14:45: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 npw8a8WAbDqw for ; Fri, 1 Jul 2016 14:45:44 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::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 95A5912B01C for ; Fri, 1 Jul 2016 14:45:44 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id w59so64219763qtd.3 for ; Fri, 01 Jul 2016 14:45: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=sE5ofOBMcYhhv825nJVHw07HOHWHzawMX6yapfg5Vwc=; b=ffJgGv2XyfpYoo+O0UmNi79l2AAOZcVTzBMdGgKxB244jmz1dxiuJW8Ci9gEirOON2 yXIhsMHVKnJZ2PoeQbGYRT4vtWSA/tLoZRhRFnV26lbv2Lpwthe+fri67qVe7eMAZqKz EJfrtxkscxSjWJpvVwWFo/8H+y7ukLbcWcVfZPDmFkpbP3+SfM5CVJGOyO/uau/bema+ PH7sfUDofLh+5Jq3iQ+PvOQ0UlyPuvth4GM57Bz7WZfYYSdojjiVUG0yG2B+p6h5IAPH OKJMsqi0KFpGTAP8YzMRcCydhdrYU83MPfV4/aDSf7pohmal6Z7Wba03aAFIGs6r2Ndq upiA== 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=sE5ofOBMcYhhv825nJVHw07HOHWHzawMX6yapfg5Vwc=; b=RibGUeIpteo8fs6tfeHDiCQjL9kkT4I88oMlVOXIkSkRdR//lRWG+AuGhn5VOiGc3K ss0YRa9TI41hoq96uJ4uXfFyZP32+GJonXTglyU+DBsIt6i7C7mjIBRAt3+uRqLJglsU 4H5knT4Q1wSbDfFaBIU1yoLJkkGTEdvDjBLAgq9cVNPLllbCzZPHzqczB2zLfSjF62TQ L167SFtiRTav0GPQSFZLvXgEY7bBmQs/sFq8YPUctaAxKyQJBv9Ml9lIOvyvKHSPsyzJ N8YMlHJjD4rGv1xA0VJc4PGmW4Z3c0VXeIyHY5lSgRlutjye6IhJY2y/dFPXiWuxjWl/ I+7A== X-Gm-Message-State: ALyK8tI0JtEHyq63Z/kf/Q/LfBKgCRYP4ylMN6qGYHlpUTYeThqVS6QWmYI1r0ndvDiTqGMI X-Received: by 10.237.53.115 with SMTP id b48mr671857qte.67.1467409543472; Fri, 01 Jul 2016 14:45:43 -0700 (PDT) Received: from [192.168.1.41] ([191.115.51.34]) by smtp.gmail.com with ESMTPSA id 49sm3105405qtn.16.2016.07.01.14.45.28 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 01 Jul 2016 14:45:42 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_7A82ADD0-8FB7-44A6-A4F6-7CCD67F4DB9F" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: John Bradley In-Reply-To: Date: Fri, 1 Jul 2016 17:45:18 -0400 Message-Id: <8CC41328-C26D-42C0-BFDB-BF0216C7B76C@ve7jtb.com> References: <994121658.55005.1467329084208.JavaMail.yahoo@mail.yahoo.com> <235316006.458279.1467392709447.JavaMail.yahoo@mail.yahoo.com> <6584BD74-B18F-4174-9E69-5C7B4B76F895@ve7jtb.com> <410908395.555462.1467407397629.JavaMail.yahoo@mail.yahoo.com> To: Josh Mandel X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Oleg Gryb , "" , Liyu Yi Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 21:45:48 -0000 --Apple-Mail=_7A82ADD0-8FB7-44A6-A4F6-7CCD67F4DB9F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I don=E2=80=99t think the post response mode is supported by heart so I = suspect that we are talking about different things. You are probably using the supported code flow that uses a 302 get to = return the code to the OAuth client on the server. =20 The Web server is then acting as a confidential client to exchange the = code via a POST (different POST) with the AS token_endpoint. The Token endpoint will return a access token (AT) and optional refresh = token (RT). The web page may be getting the server to make the OAuth calls on it=E2=80= =99s behalf to the Resource Server, or possibly you are passing the AT = from the server back to a Java script app that is using CORES to make = calls directly to the RS without going through the Web server. Passing the AT back to the user agent from the client is not = recommended.=20 For in browser clients where the JS is using the AT to make the calls = directly to the RS via CORES the recommended approach is to use the = fragment encoded response via a 302 to deliver the AT directly to the = client (It never hits the backend Web server). However I believe In browser OAuth clients are not currently supported = in HEART, so I am not quite sure what you are doing. Perhaps Justin has a better answer. John B. > On Jul 1, 2016, at 5:33 PM, Josh Mandel wrote: >=20 > John, >=20 > I appreciate your response. I'm hoping you can clarify why you say = that "HTTP POST... won't work well for... [a] single page OAuth client"? >=20 > We commonly build single-page apps that act as OAuth clients for SMART = (e.g. this sample app = ), and we've had good experience with the = technique. Could you elaborate? >=20 > -J >=20 > On Fri, Jul 1, 2016 at 5:26 PM, John Bradley > wrote: > HEART only supports web server clients at the moment. That might = change in future to support native apps if that an be made to support = the security requirements of Heath IT. >=20 > So the thing HTTP POST responses won=E2=80=99t work well for is a type = of in browser single page OAuth client. That still needs fragment = encoded responses or the new post-message Java Script API approach. >=20 > John B. >=20 >=20 >> On Jul 1, 2016, at 5:16 PM, Josh Mandel > wrote: >>=20 >> Thanks Justin, >>=20 >> To clarify: John's comment and my question were about POST. (I do = understand the behavior of HTTP POST and of window.postMessage; these = are totally different things.) =46rom my perspective in SMART Health IT, = we use the OAuth 2.0 authorization code flow, including HTTP POST, in = our authorization spec = even for public clients, and it has worked very well for us, with about = a dozen electronic health record servers supporting this approach. = That's why I was curious to hear John's perspective about limitations. >>=20 >> -J >>=20 >> On Fri, Jul 1, 2016 at 5:09 PM, Oleg Gryb > wrote: >> > POST will send things to the server, which isn=E2=80=99t desirable = if your client is solely in the browser >> Why it's not desirable, assuming that we disregard performance? You = can generate HTTP POST from JS, e.g. through an AJAX call. What is wrong = with this? >>=20 >>=20 >> From: Justin Richer > >> To: Josh Mandel >=20 >> Cc: Oleg Gryb >; = ">" >; Liyu Yi > >> Sent: Friday, July 1, 2016 2:00 PM >>=20 >> Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit = grant >>=20 >> POST will send things to the server, which isn=E2=80=99t desirable if = your client is solely in the browser. postMessage is a browser API and = not to be confused with HTTP POST. postMessage messages stay (or can = stay) within the browser, which is the intent here. >>=20 >> =E2=80=94 Justin >>=20 >>> On Jul 1, 2016, at 4:56 PM, Josh Mandel > wrote: >>>=20 >>=20 >> John, >>=20 >> Could you clarify what you mean by "POST doesn't really work"? Do you = just mean that CORS support (e.g., http://caniuse.com/#feat=3Dcors = ) isn't universal, or something more? >>=20 >> On Fri, Jul 1, 2016 at 4:51 PM, John Bradley > wrote: >> Yes but POST doesn't really work for in browser apps. >>=20 >> If it is a server app it should be using the code flow with GET or = POST as you like. >>=20 >> If we do a post message based binding it will be targeted at in = browser applications. >>=20 >> John B. >>=20 >> On Fri, Jul 1, 2016 at 4:42 PM, Liyu Yi > wrote: >> BTW, I do not see any significant performance concerns for post. = Parsing and executing the Javascript logic for post operation will be on = the client side, no extra server load is introduced. >>=20 >> Plus post will remove the size restriction of the URL length. >>=20 >> -- Liyu=20 >>=20 >> On Fri, Jul 1, 2016 at 1:35 PM, Liyu Yi > wrote: >> Thanks for the great comments and advices. >>=20 >> I think it is a good idea for the working group to revise the = fragment part in the spec, since there might be public available tools = already implemented this approach and people can end up with a solution = with serious security loopholes. >>=20 >> The re-append issue can be mitigate by a logic on Resource Server = which carefully re-writes/removes the fragment in any redirect, if the = the redirect can not be avoided. >>=20 >> -- Liyu >> =20 >>=20 >> On Fri, Jul 1, 2016 at 11:33 AM, John Bradley > wrote: >> This behaviour started changing around 2011 >>=20 >> =46rom HTTP/1.1 >> See https://tools.ietf.org/html/rfc7231#section-7.1.2 = I >> f the Location value provided in a 3xx (Redirection) response = does >> not have a fragment component, a user agent MUST process the >> redirection as if the value inherits the fragment component of the >> URI reference used to generate the request target (i.e., the >> redirection inherits the original reference's fragment, if any). >>=20 >> For example, a GET request generated for the URI reference >> "http://www.example.org/~tim " might = result in a 303 (See Other) >> response containing the header field: >>=20 >> Location: /People.html#tim >>=20 >> which suggests that the user agent redirect to >> "http://www.example.org/People.html#tim = =E2=80=9D >>=20 >> Likewise, a GET request generated for the URI reference >> "http://www.example.org/index.html#larry = " might result in a 301 >> (Moved Permanently) response containing the header field: >>=20 >> Location: http://www.example.net/index.html = >>=20 >> which suggests that the user agent redirect to >> "http://www.example.net/index.html#larry = ", preserving the original >> fragment identifier. >>=20 >>=20 >> This blog also explores the change. >> = https://blogs.msdn.microsoft.com/ieinternals/2011/05/16/url-fragments-and-= redirects/ = >>=20 >>=20 >>> On Jul 1, 2016, at 1:05 PM, Oleg Gryb > wrote: >>>=20 >>> "Browsers now re-append fragments across 302 redirects unless they = are explicitly cleared this makes fragment encoding less safe than it = was when originally specified" - thanks Jim. Looks like a good reason = for vetting this flow out. >>>=20 >>> John, >>> Please provide more details/links about re-appending fragments.=20 >>>=20 >>> Thanks, >>> Oleg. >>>=20 >>>=20 >>> From: Jim Manico > >>> To: Oleg Gryb >=20 >>> Cc: "oauth@ietf.org " >; Liyu Yi > >>> Sent: Thursday, June 30, 2016 10:25 PM >>> Subject: Re: [OAUTH-WG] Security concern for URI fragment as = Implicit grant >>>=20 >>> Oleg! Hello! Great to see you pop up here with a similar concern. >>>=20 >>> John Bradley just answered this thread with the details I was = looking for (thanks John, hat tip your way). >>>=20 >>> He also mentioned details about fragment leakage: >>>=20 >>> "Browsers now re-append fragments across 302 redirects unless they = are explicitly cleared this makes fragment encoding less safe than it = was when originally specified" >>>=20 >>> Again, I'm new here but I'm grateful for this conversation. >>>=20 >>> Aloha, >>> -- >>> Jim Manico >>> @Manicode >>>=20 >>> On Jul 1, 2016, at 1:24 AM, Oleg Gryb > wrote: >>>=20 >>>> We've discussed access tokens in URI back in 2010 = (https://www.ietf.org/mail-archive/web/oauth/current/msg04043.html = ). = There were two major objectives when I was saying that it's not secure: >>>>=20 >>>> 1. Fragment is not sent to a server by a browser. When I've asked = if this is true for every browser in the world, nobody was able to = answer. >>>> 2. Replacing with POST would mean a significant performance impact = in some high volume implementations (I think it was Goole folks who were = saying this, but I don't remember now). >>>>=20 >>>> AFAIR, nobody was arguing about browsing history, so it's valid. >>>>=20 >>>> So, 6 years later we're at square one with this and I hope that = this time the community will be more successful with getting rid of = secrets in URL. >>>>=20 >>>> BTW, Jim, if you can come up with other scenarios when fragments = can leak, please share. It'll probably help the community with solving = this problem faster than in 6 years. >>>>=20 >>>> Thanks, >>>> Oleg. >>>>=20 >>>>=20 >>>> From: Jim Manico > >>>> To: Liyu Yi >; = oauth@ietf.org =20 >>>> Sent: Wednesday, June 29, 2016 7:30 AM >>>> Subject: Re: [OAUTH-WG] Security concern for URI fragment as = Implicit grant >>>>=20 >>>> > Shouldn=E2=80=99t it be more secure if we change to use a post = method for access token, similar to the SAML does? >>>> I say yes. But please note I'm very new at this and someone with = more experience will have more to say or correct my comments. >>>> Here are a few more details to consider. >>>> 1) OAuth is a framework and not a standard, per se. Different = authorization servers will have different implementations that are not = necessarily compatible with other service providers. So there is no = standard to break, per se. >>>> 2) Sensitive data in a URI is a bad idea. They leak all over the = place even over HTTPS. Even in fragments. >>>> 3) Break the "rules" and find a way to submit sensitive data like = access tokens, session information or any other (even short term) = sensitive data in a secure fashion. This includes POST, JSON data = payloads over PUT/PATCH and other verbs - all over well configured = HTTPS. >>>> 4) If you really must submit sensitive data over GET , consider = JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level = confidentiality and integrity. >>>> Aloha, >>>> Jim Manico >>>> Manicode Security >>>> https://www.manicode.com >>>> On 6/27/16 9:30 PM, Liyu Yi wrote: >>>>> While we are working on a project with OAuth2 implementation, one = question arises from our engineers. >>>>> We noticed at = https://tools.= ietf.org/html/draft-ietf-oauth-v2-31#page-30 = , it is = specified that >>>>> =20 >>>>> (C) Assuming the resource owner grants access, the authorization >>>>> server redirects the user-agent back to the client using = the >>>>> redirection URI provided earlier. The redirection URI = includes >>>>> the access token in the URI fragment. >>>>> =20 >>>>> For my understanding, the browser keeps the URI fragment in the = history, and this introduces unexpected exposure of the access token. A = user without authorization for the resource can get the access token as = long as he has the access to the browser. This can happen in a shared = computer in library, or for an IT staff who works on other employee=E2=80=99= s computer. >>>>> =20 >>>>> Shouldn=E2=80=99t it be more secure if we change to use a post = method for access token, similar to the SAML does? >>>>> I feel there might be something I missed here. Any advices will be = appreciated. >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>=20 >>>> --=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >>>=20 >>>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 --Apple-Mail=_7A82ADD0-8FB7-44A6-A4F6-7CCD67F4DB9F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I don=E2=80=99t think the post response mode is supported by = heart so I suspect that we are talking about different things.

You are probably using = the supported code flow that uses a 302 get to return the code to the = OAuth client on the server.  
The Web server = is then acting as a confidential client to exchange the code via a POST = (different POST) with the AS token_endpoint.

The Token endpoint will return a access = token (AT) and optional refresh token (RT).

The web page may be getting the server = to make the OAuth calls on it=E2=80=99s behalf to the Resource Server, = or possibly you are passing the AT from the server back to a Java script = app that is using CORES to make calls directly to the RS without going = through the Web server.

Passing the AT back to the user agent from the client is not = recommended. 

For in browser clients where the JS is using the AT to make = the calls directly to the RS via CORES the recommended approach is to = use the fragment encoded response via a 302 to deliver the AT directly = to the client (It never hits the backend Web server).

However I believe In = browser OAuth clients are not currently supported in HEART, so I am not = quite sure what you are doing.

Perhaps Justin has a better = answer.

John = B.


On = Jul 1, 2016, at 5:33 PM, Josh Mandel <jmandel@gmail.com> = wrote:

John,

I appreciate your response. I'm hoping you can clarify why = you say that "HTTP POST... won't work well for... [a] single page OAuth = client"?

We commonly = build single-page apps that act as OAuth clients for SMART (e.g. this = sample app ), and we've had good experience with the technique. = Could you elaborate?

  -J

On Fri, Jul 1, 2016 at 5:26 PM, = John Bradley <ve7jtb@ve7jtb.com> wrote:
HEART only supports web server = clients at the moment.   That might change in future to support = native apps if that an be made to support the security requirements of = Heath IT.

So the thing = HTTP POST responses won=E2=80=99t work well for is a type of in browser = single page OAuth client.  That still needs fragment encoded = responses or the new post-message Java Script API approach.

John B.


On Jul 1, 2016, at 5:16 PM, Josh Mandel = <jmandel@gmail.com> wrote:

Thanks Justin,

To clarify: John's comment and my = question were about POST. (I do understand the behavior of HTTP POST and = of window.postMessage; these are totally different things.) =46rom my = perspective in SMART Health IT, we use the OAuth 2.0 authorization code = flow, including HTTP POST, in our authorization spec even for public clients, and it = has worked very well for us, with about a dozen electronic health record = servers supporting this approach. That's why I was curious to hear = John's perspective about limitations.

  -J

On Fri, = Jul 1, 2016 at 5:09 PM, Oleg Gryb <oleg_gryb@yahoo.com> wrote:
> POST will send things to the server, which isn=E2=80=99t = desirable if your client is solely in the browser
Why it's not desirable, assuming that we = disregard performance? You can generate HTTP POST from JS, e.g. through = an AJAX call. What is wrong with this?


=
=
= From:= Justin Richer <jricher@mit.edu>
To: Josh Mandel <jmandel@gmail.com>
Cc: Oleg Gryb <oleg@gryb.info>; "<oauth@ietf.org>" <oauth@ietf.org>; Liyu Yi <liyuyi@gmail.com>
Sent: Friday, July 1, = 2016 2:00 PM

Subject:= Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant
=

POST will = send things to the server, which isn=E2=80=99t desirable if your client = is solely in the browser. postMessage is a browser API and not to be = confused with HTTP POST. postMessage messages stay (or can stay) within = the browser, which is the intent here.

 =E2=80=94 Justin

On Jul = 1, 2016, at 4:56 PM, Josh Mandel <jmandel@gmail.com> wrote:

John,

Could you = clarify what you mean by "POST= doesn't really work"? Do you just mean that CORS support (e.g., http://caniuse.com/#feat=3Dcors) isn't = universal, or something more?

On Fri, Jul 1, 2016 at 4:51 = PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
Yes but = POST doesn't really work for in browser apps.

If it is a server app it = should be using the code flow with GET or POST as you like.

If we do = a  post message based binding it will be targeted at in browser = applications.

John B.

On Fri, Jul 1, 2016 at 4:42 = PM, Liyu Yi <liyuyi@gmail.com> wrote:
BTW, I do = not see any significant performance concerns for post. Parsing and = executing the Javascript logic for post operation will be on the client = side, no extra server load is introduced.

Plus post will remove = the size restriction of the URL length.

-- = Liyu 

On Fri, Jul 1, 2016 at 1:35 = PM, Liyu Yi <liyuyi@gmail.com> wrote:
Thanks for the great comments and advices.

I think it is a good idea = for the working group to revise the fragment part in the spec, since = there might be public available tools already implemented this approach = and people can end up with a solution with serious security = loopholes.

The re-append issue can be mitigate by a logic on Resource = Server which carefully re-writes/removes the fragment in any redirect, = if the the redirect can not be avoided.

-- = Liyu
 

On Fri, Jul 1, 2016 at 11:33 = AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
This behaviour started changing around 2011

=46rom = HTTP/1.1
See https://tools.ietf.org/html/rfc7231#section-7.1.2I
    =   f the Location value provided in a 3xx (Redirection) response = does
   not have a fragment component, a user agent MUST =
process the
   redirection as if the value inherits the fragment component of the
   URI reference used to generate the request target (i.e., the
   redirection inherits the original reference's fragment, if any).

   For example, a GET request generated for the URI reference
   "http://www.example.org/~tim" might result in a 303 (See =
Other)
   response containing the header field:

     Location: /People.html#tim

   which suggests that the user agent redirect to
   "http://www.example.org/People.html#tim=E2=80=9D

   Likewise, a GET request generated for the URI =
reference
   "http://www.example.org/index.html#larry" might result in =
a 301
   (Moved Permanently) response containing the header field:

     Location: http://www.example.net/index.html

   which suggests that the user agent redirect to
   "http://www.example.net/index.html#larry", preserving the =
original
   fragment identifier.


This blog = also explores the change.
https://blogs.msdn.microsoft.com/ieinternals/2011/05/16/url-fra= gments-and-redirects/


On Jul 1, 2016, at 1:05 PM, Oleg Gryb <oleg_gryb@yahoo.com> wrote:

"Browsers now = re-append  fragments across 302 redirects unless they are = explicitly cleared this makes fragment encoding less safe than it was =  when originally specified" - thanks Jim. Looks like a good reason = for vetting this flow out.

John,
Please provide more details/links about re-appending = fragments. 

Thanks,
Oleg.


=
From: Jim Manico <jim@manicode.com>
To: = Oleg Gryb <oleg@gryb.info>
Cc: = "oauth@ietf.org" <oauth@ietf.org>; Liyu Yi <liyuyi@gmail.com>
Sent: = Thursday, June 30, 2016 10:25 PM
Subject:= Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

Oleg! Hello! = Great to see you pop up here with a similar concern.

John = Bradley just answered this thread with the details I was looking for = (thanks John, hat tip your way).

He also mentioned details about = fragment leakage:

"Browsers now = re-append  fragments across 302 redirects unless they are = explicitly cleared this makes fragment encoding less safe than it was = when originally specified"

Again, I'm new here but I'm grateful = for this conversation.

Aloha,
--
Jim Manico
@Manicode

On Jul 1, 2016, at 1:24 AM, Oleg Gryb <oleg_gryb@yahoo.com> wrote:

We've discussed access tokens in URI back in = 2010 (https://www.ietf.org/mail-archive/web/oauth/current/msg04043.ht= ml). There were two major objectives when I was saying that it's not = secure:

1. Fragment is not sent to = a server by a browser. When I've asked if this is true for every browser = in the world, nobody was able to answer.
2. Replacing with POST would mean a significant performance = impact in some high volume implementations (I think it was Goole folks = who were saying this, but I don't remember now).

AFAIR, nobody was arguing about browsing history, so it's = valid.

So, 6 years later we're at = square one with this and I hope that this time the community will be = more successful with getting rid of secrets in URL.

BTW, Jim, if you can come up with other scenarios when = fragments can leak, please share. It'll probably help the community with = solving this problem faster than in 6 years.

Thanks,
Oleg.


=
From: Jim Manico <jim@manicode.com>
To: = Liyu Yi <liyuyi@gmail.com>; oauth@ietf.org
Sent: = Wednesday, June 29, 2016 7:30 AM
Subject:= Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

> Shouldn=E2=80=99t it be more = secure if we change to use a post method for access token, similar to the SAML = does?
I say yes. But please note I'm very new at this and = someone with more experience will have more to say or correct my = comments.
Here are a few more details to consider.
1) OAuth is a framework and not a standard, per se. = Different authorization servers will have different implementations that are not necessarily compatible with other service providers. So there is no standard to break, per se.
2) Sensitive data in a URI is a bad idea. They leak = all over the place even over HTTPS. Even in fragments.
3) Break the "rules" and find a way to submit = sensitive data like access tokens, session information or any other (even short term) sensitive data in a secure fashion. This includes POST, JSON data payloads over PUT/PATCH and other verbs - all over well configured HTTPS.
4) If you really must submit sensitive data over GET = , consider JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level confidentiality and integrity.
Aloha,
Jim Manico
Manicode Security
https://www.manicode.com

On 6/27/16 9:30 PM, Liyu Yi = wrote:
While we are working on a = project with OAuth2 implementation, one question arises from our engineers.
We noticed at https://tools.ietf.org/html/draft-ietf-oauth-v2-31#page-30<= /span>, it is specified that
  
(C)  Assuming the resource = owner grants access, the authorization
        server redirects = the user-agent back to the client using the
        redirection URI = provided earlier.  The redirection URI includes
        the access token = in the URI fragment.
 
For my understanding, the = browser keeps the URI fragment in the history, and this introduces unexpected exposure of the access token. A user without authorization for the resource can get the access token as long as he has the access to the browser. This can happen in a shared computer in library, or for an IT staff who works on other employee=E2=80=99s computer.
 
Shouldn=E2=80=99t it be more = secure if we change to use a post method for access token, similar to the SAML does?
I feel there might be something = I missed here. Any advices will be appreciated.


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


--=20

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


=

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


=





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


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


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


=
=

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



= --Apple-Mail=_7A82ADD0-8FB7-44A6-A4F6-7CCD67F4DB9F-- From nobody Fri Jul 1 14:52:43 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 175E112D0AB for ; Fri, 1 Jul 2016 14:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yLOP3h-2VeET for ; Fri, 1 Jul 2016 14:52:38 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d: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 3184312B01C for ; Fri, 1 Jul 2016 14:52:38 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id t127so224075297qkf.1 for ; Fri, 01 Jul 2016 14:52:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=B4aUJFxlUQnb0DaHdPmsRf0lmef92oIIlLhSIn3Xr+8=; b=Q7M4RUNTW0OIduEvSJNECB+2qdcvng9e4ixWjH2fHGcMW9niNrmgTWJUZK79BvAL40 lXiJ4bAEfIW9VlyYRkLYAdVvxsY8FWmpNgkwY3cDZbnSYLiadonWMMTKmr9T+I2+1iSl pAlQsLDE20Wuipbb8RlrLcHFr2iUxosv36N/f9TZgAyNIy0UDuRyaxXAv8x38jtaPTMB 2aNZ/KrDQZ4txwdFRySGQaXh9Wj7lLGxDRZqFW0klxv3mn6lD6ISjBbMyEj0qQB9bJ50 5YPEe6NFNAUpanPP6frXUsxUp6PMWrHhxJXly27LYdr++tnmRBZ8TcdGQq2HNqrCvtSG wCvA== 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=B4aUJFxlUQnb0DaHdPmsRf0lmef92oIIlLhSIn3Xr+8=; b=a5ZgcI+0t4TfN7Btjju4N98iGlDY4farAO+mEaX8pqlFjwr7J1HqYr76IFQPGUei7L Ou5wncdRwmq+d5nzUmvtK1PdPwyvkXqBbm8jVaGla4fc4UqpvHRsrVBaxVFlKw1sXDgy C21KtBSvOamtRyLita0papUtgTawYe/kymOWNyE7YVMDW9UWK5aiQ3RRhoudf6NWTQvg UCTa6W/nfpcRt0++w0ADrcz7p0G61ctY7sbO0YUMWQHGNa7MOltviEAKhsPFBUcwop64 B3zpvmAU0zVjyt+1ymvQSVCG+VlWEwa765R1Uvfkxr18ZvJJ2vfMdDFd2E5NKht5u88J j9Og== X-Gm-Message-State: ALyK8tIE65QhigdNGN/g9aZllPGiTKJhRxBg9xUVAPUlpOeU/3F4ApSnIa/e6cTvtl+6LTZwCJoDDVAfN7uzeQ== X-Received: by 10.37.35.23 with SMTP id j23mr267236ybj.91.1467409957263; Fri, 01 Jul 2016 14:52:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.69.65 with HTTP; Fri, 1 Jul 2016 14:52:17 -0700 (PDT) In-Reply-To: <8CC41328-C26D-42C0-BFDB-BF0216C7B76C@ve7jtb.com> References: <994121658.55005.1467329084208.JavaMail.yahoo@mail.yahoo.com> <235316006.458279.1467392709447.JavaMail.yahoo@mail.yahoo.com> <6584BD74-B18F-4174-9E69-5C7B4B76F895@ve7jtb.com> <410908395.555462.1467407397629.JavaMail.yahoo@mail.yahoo.com> <8CC41328-C26D-42C0-BFDB-BF0216C7B76C@ve7jtb.com> From: Josh Mandel Date: Fri, 1 Jul 2016 17:52:17 -0400 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=001a113cd0c43e21d205369a0153 Archived-At: Cc: Oleg Gryb , "" , Liyu Yi Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 21:52:42 -0000 --001a113cd0c43e21d205369a0153 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think the confusion here is that I'm not using HEART's OAuth profiles :-) I'm using the SMART profiles, where we do specify the use of an authorization code grant even for browser-based public clients (in which case, no client_secret is issued or used). I'm just trying to understand your perspective eon why this "won't work well". Perhaps you didn't mean this comment to refer to browser-based OAuth clients generally? -Josh On Fri, Jul 1, 2016 at 5:45 PM, John Bradley wrote: > I don=E2=80=99t think the post response mode is supported by heart so I s= uspect > that we are talking about different things. > > You are probably using the supported code flow that uses a 302 get to > return the code to the OAuth client on the server. > The Web server is then acting as a confidential client to exchange the > code via a POST (different POST) with the AS token_endpoint. > > The Token endpoint will return a access token (AT) and optional refresh > token (RT). > > The web page may be getting the server to make the OAuth calls on it=E2= =80=99s > behalf to the Resource Server, or possibly you are passing the AT from th= e > server back to a Java script app that is using CORES to make calls direct= ly > to the RS without going through the Web server. > > Passing the AT back to the user agent from the client is not recommended. > > For in browser clients where the JS is using the AT to make the calls > directly to the RS via CORES the recommended approach is to use the > fragment encoded response via a 302 to deliver the AT directly to the > client (It never hits the backend Web server). > > However I believe In browser OAuth clients are not currently supported in > HEART, so I am not quite sure what you are doing. > > Perhaps Justin has a better answer. > > John B. > > > On Jul 1, 2016, at 5:33 PM, Josh Mandel wrote: > > John, > > I appreciate your response. I'm hoping you can clarify why you say that > "HTTP POST... won't work well for... [a] single page OAuth client"? > > We commonly build single-page apps that act as OAuth clients for SMART > (e.g. this sample app > ), > and we've had good experience with the technique. Could you elaborate? > > -J > > On Fri, Jul 1, 2016 at 5:26 PM, John Bradley wrote: > >> HEART only supports web server clients at the moment. That might chang= e >> in future to support native apps if that an be made to support the secur= ity >> requirements of Heath IT. >> >> So the thing HTTP POST responses won=E2=80=99t work well for is a type o= f in >> browser single page OAuth client. That still needs fragment encoded >> responses or the new post-message Java Script API approach. >> >> John B. >> >> >> On Jul 1, 2016, at 5:16 PM, Josh Mandel wrote: >> >> Thanks Justin, >> >> To clarify: John's comment and my question were about POST. (I do >> understand the behavior of HTTP POST and of window.postMessage; these ar= e >> totally different things.) From my perspective in SMART Health IT, we us= e >> the OAuth 2.0 authorization code flow, including HTTP POST, in our autho= rization >> spec even for public >> clients, and it has worked very well for us, with about a dozen electron= ic >> health record servers supporting this approach. That's why I was curious= to >> hear John's perspective about limitations. >> >> -J >> >> On Fri, Jul 1, 2016 at 5:09 PM, Oleg Gryb wrote: >> >>> > POST will send things to the server, which isn=E2=80=99t desirable if= your >>> client is solely in the browser >>> Why it's not desirable, assuming that we disregard performance? You can >>> generate HTTP POST from JS, e.g. through an AJAX call. What is wrong wi= th >>> this? >>> >>> >>> ------------------------------ >>> *From:* Justin Richer >>> *To:* Josh Mandel >>> *Cc:* Oleg Gryb ; "" ; >>> Liyu Yi >>> *Sent:* Friday, July 1, 2016 2:00 PM >>> >>> *Subject:* Re: [OAUTH-WG] Security concern for URI fragment as Implicit >>> grant >>> >>> POST will send things to the server, which isn=E2=80=99t desirable if y= our >>> client is solely in the browser. postMessage is a browser API and not t= o be >>> confused with HTTP POST. postMessage messages stay (or can stay) within= the >>> browser, which is the intent here. >>> >>> =E2=80=94 Justin >>> >>> On Jul 1, 2016, at 4:56 PM, Josh Mandel wrote: >>> >>> John, >>> >>> Could you clarify what you mean by "POST doesn't really work"? Do you >>> just mean that CORS support (e.g., http://caniuse.com/#feat=3Dcors) isn= 't >>> universal, or something more? >>> >>> On Fri, Jul 1, 2016 at 4:51 PM, John Bradley wrote: >>> >>> Yes but POST doesn't really work for in browser apps. >>> >>> If it is a server app it should be using the code flow with GET or POST >>> as you like. >>> >>> If we do a post message based binding it will be targeted at in browse= r >>> applications. >>> >>> John B. >>> >>> On Fri, Jul 1, 2016 at 4:42 PM, Liyu Yi wrote: >>> >>> BTW, I do not see any significant performance concerns for post. Parsin= g >>> and executing the Javascript logic for post operation will be on the cl= ient >>> side, no extra server load is introduced. >>> >>> Plus post will remove the size restriction of the URL length. >>> >>> -- Liyu >>> >>> On Fri, Jul 1, 2016 at 1:35 PM, Liyu Yi wrote: >>> >>> Thanks for the great comments and advices. >>> >>> I think it is a good idea for the working group to revise the fragment >>> part in the spec, since there might be public available tools already >>> implemented this approach and people can end up with a solution with >>> serious security loopholes. >>> >>> The re-append issue can be mitigate by a logic on Resource Server which >>> carefully re-writes/removes the fragment in any redirect, if the the >>> redirect can not be avoided. >>> >>> -- Liyu >>> >>> >>> On Fri, Jul 1, 2016 at 11:33 AM, John Bradley wrote= : >>> >>> This behaviour started changing around 2011 >>> >>> From HTTP/1.1 >>> See https://tools.ietf.org/html/rfc7231#section-7.1.2I >>> f the Location value provided in a 3xx (Redirection) response doe= s >>> >>> not have a fragment component, a user agent MUST process the >>> redirection as if the value inherits the fragment component of the >>> URI reference used to generate the request target (i.e., the >>> redirection inherits the original reference's fragment, if any). >>> >>> For example, a GET request generated for the URI reference >>> "http://www.example.org/~tim" might result in a 303 (See Other) >>> response containing the header field: >>> >>> Location: /People.html#tim >>> >>> which suggests that the user agent redirect to >>> "http://www.example.org/People.html#tim=E2=80=9D >>> >>> >>> Likewise, a GET request generated for the URI reference >>> "http://www.example.org/index.html#larry" might result in a 301 >>> (Moved Permanently) response containing the header field: >>> >>> Location: http://www.example.net/index.html >>> >>> which suggests that the user agent redirect to >>> "http://www.example.net/index.html#larry", preserving the original >>> fragment identifier. >>> >>> >>> >>> This blog also explores the change. >>> >>> https://blogs.msdn.microsoft.com/ieinternals/2011/05/16/url-fragments-a= nd-redirects/ >>> >>> >>> On Jul 1, 2016, at 1:05 PM, Oleg Gryb wrote: >>> >>> "Browsers now re-append fragments across 302 redirects unless they are >>> explicitly cleared this makes fragment encoding less safe than it was = when >>> originally specified" - thanks Jim. Looks like a good reason for vettin= g >>> this flow out. >>> >>> John, >>> Please provide more details/links about re-appending fragments. >>> >>> Thanks, >>> Oleg. >>> >>> >>> ------------------------------ >>> *From:* Jim Manico >>> *To:* Oleg Gryb >>> *Cc:* "oauth@ietf.org" ; Liyu Yi >>> *Sent:* Thursday, June 30, 2016 10:25 PM >>> *Subject:* Re: [OAUTH-WG] Security concern for URI fragment as Implicit >>> grant >>> >>> Oleg! Hello! Great to see you pop up here with a similar concern. >>> >>> John Bradley just answered this thread with the details I was looking >>> for (thanks John, hat tip your way). >>> >>> He also mentioned details about fragment leakage: >>> >>> "Browsers now re-append fragments across 302 redirects unless they are >>> explicitly cleared this makes fragment encoding less safe than it was w= hen >>> originally specified" >>> >>> Again, I'm new here but I'm grateful for this conversation. >>> >>> Aloha, >>> -- >>> Jim Manico >>> @Manicode >>> >>> On Jul 1, 2016, at 1:24 AM, Oleg Gryb wrote: >>> >>> We've discussed access tokens in URI back in 2010 ( >>> https://www.ietf.org/mail-archive/web/oauth/current/msg04043.html). >>> There were two major objectives when I was saying that it's not secure: >>> >>> 1. Fragment is not sent to a server by a browser. When I've asked if >>> this is true for every browser in the world, nobody was able to answer. >>> 2. Replacing with POST would mean a significant performance impact in >>> some high volume implementations (I think it was Goole folks who were >>> saying this, but I don't remember now). >>> >>> AFAIR, nobody was arguing about browsing history, so it's valid. >>> >>> So, 6 years later we're at square one with this and I hope that this >>> time the community will be more successful with getting rid of secrets = in >>> URL. >>> >>> BTW, Jim, if you can come up with other scenarios when fragments can >>> leak, please share. It'll probably help the community with solving this >>> problem faster than in 6 years. >>> >>> Thanks, >>> Oleg. >>> >>> >>> ------------------------------ >>> *From:* Jim Manico >>> *To:* Liyu Yi ; oauth@ietf.org >>> *Sent:* Wednesday, June 29, 2016 7:30 AM >>> *Subject:* Re: [OAUTH-WG] Security concern for URI fragment as Implicit >>> grant >>> >>> > Shouldn=E2=80=99t it be more secure if we change to use a post method= for >>> access token, similar to the SAML does? >>> I say yes. But please note I'm very new at this and someone with more >>> experience will have more to say or correct my comments. >>> Here are a few more details to consider. >>> 1) OAuth is a framework and not a standard, per se. Different >>> authorization servers will have different implementations that are not >>> necessarily compatible with other service providers. So there is no >>> standard to break, per se. >>> 2) Sensitive data in a URI is a bad idea. They leak all over the place >>> even over HTTPS. Even in fragments. >>> 3) Break the "rules" and find a way to submit sensitive data like acces= s >>> tokens, session information or any other (even short term) sensitive da= ta >>> in a secure fashion. This includes POST, JSON data payloads over PUT/PA= TCH >>> and other verbs - all over well configured HTTPS. >>> 4) If you really must submit sensitive data over GET , consider >>> JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level >>> confidentiality and integrity. >>> Aloha, >>> >>> Jim Manico >>> Manicode Securityhttps://www.manicode.com >>> >>> >>> On 6/27/16 9:30 PM, Liyu Yi wrote: >>> >>> While we are working on a project with OAuth2 implementation, one >>> question arises from our engineers. >>> We noticed at >>> >>> https://tools.ietf.org/html/draft-ietf-oauth-v2-31#page-30, it is >>> specified that >>> >>> (C) Assuming the resource owner grants access, the authorization >>> server redirects the user-agent back to the client using the >>> redirection URI provided earlier. The redirection URI includes >>> the access token in the URI fragment. >>> >>> For my understanding, the browser keeps the URI fragment in the history= , >>> and this introduces unexpected exposure of the access token. A user wit= hout >>> authorization for the resource can get the access token as long as he h= as >>> the access to the browser. This can happen in a shared computer in libr= ary, >>> or for an IT staff who works on other employee=E2=80=99s computer. >>> >>> Shouldn=E2=80=99t it be more secure if we change to use a post method f= or access >>> token, similar to the SAML does? >>> I feel there might be something I missed here. Any advices will be >>> appreciated. >>> >>> >>> _______________________________________________ >>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/o= auth >>> >>> >>> -- >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> > > --001a113cd0c43e21d205369a0153 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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


_______________________________________________
OAuth mai= ling list
OAuth@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">ht= tps://www.ietf.org/mailman/listinfo/oauth


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



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


--001a113cd0c43e21d205369a0153-- From nobody Fri Jul 1 15:02:53 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA1C12D7DC for ; Fri, 1 Jul 2016 15:02:45 -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 Bt5bEh02hLHl for ; Fri, 1 Jul 2016 15:02:40 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D99112D775 for ; Fri, 1 Jul 2016 15:02:39 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id f89so64231165qtd.2 for ; Fri, 01 Jul 2016 15:02:39 -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=5SCHFJdb93S5XrH/58OrKEgPiGr0qX1I1X7wUW5akIU=; b=myI6KApBRp5eQCMfhca5UUiahb86IjmRjBmRxR6N43zsK5f/PNeZUNT8zS/i5LoKQ6 iQ3XsTb7wjY2oOj2fKqmek63+Ugd+cmOc/McJb8wnzNI548MZHI8gs9dWDmRvLkOxOy0 PQwjYc+osScHfTkLDwBzQpDApu829N0jYRl4Winrptf/1lMCtGFDO4Q2IauNAyK9Ijdg S5mNDUsB/kDQa50ovLDseHQmKP5Svknr5bt1G8+Zoo6hugkbE59woxndkenfTjNF2pgM HU5IfJudvaV7zlYvemB90ur9mxWjgvyMdKg3qRqUaRNR7nm1wRVfyHw7ieckVe6gPCxW 2QwQ== 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=5SCHFJdb93S5XrH/58OrKEgPiGr0qX1I1X7wUW5akIU=; b=JAmTuHuWmn7qfTkSmjG34b/3O6Klcdn9xI4lonBam9QFEkKWFSIb4OUxb/+bk+atFB oPia6Bi8kgilW3FinXs88cpnG2W1iLJ2MQ57gTcnPmdfqUhbxoCxw+uA7YoWffgg1eFs VA51c6QWpBYjzERk+/2lDrPGT69B8dfYhckDT8D+Gh30VDa5uE8mFgH81m54dF4j29RP yiQ0IMO5xKNEDfNWL+8tIq+23xSgtQMF0udD20+Lzp5bie+8VPD7goeWURFtq65LvJUK V9RDhlxs5ASFJ0ndH1vK3oXP8IWJFayJxc4KUne4DoZ5W6jxQwT9ePC45wDl8PnhYWuB xPRw== X-Gm-Message-State: ALyK8tIJwPRuh3zPyQuKLQ6/Z9lhm89hhFMvStg2mvBC2y1ndqY2kxgVeT80NRe87j3JrHET X-Received: by 10.237.51.227 with SMTP id v90mr837930qtd.23.1467410558501; Fri, 01 Jul 2016 15:02:38 -0700 (PDT) Received: from [192.168.1.41] ([191.115.51.34]) by smtp.gmail.com with ESMTPSA id o70sm1466030qka.29.2016.07.01.15.02.14 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 01 Jul 2016 15:02:37 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_E3B3C169-59C5-465C-954D-E6D154C4D2F5" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: John Bradley In-Reply-To: Date: Fri, 1 Jul 2016 18:01:40 -0400 Message-Id: <71CE61B3-FEC2-46A7-AB28-B53E89A8E53F@ve7jtb.com> References: <994121658.55005.1467329084208.JavaMail.yahoo@mail.yahoo.com> <235316006.458279.1467392709447.JavaMail.yahoo@mail.yahoo.com> <6584BD74-B18F-4174-9E69-5C7B4B76F895@ve7jtb.com> <410908395.555462.1467407397629.JavaMail.yahoo@mail.yahoo.com> <8CC41328-C26D-42C0-BFDB-BF0216C7B76C@ve7jtb.com> To: Josh Mandel X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Oleg Gryb , "" , Liyu Yi Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 22:02:45 -0000 --Apple-Mail=_E3B3C169-59C5-465C-954D-E6D154C4D2F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I am making a distinction between a browser talking to a Web server that = is acting as a OAuth Client POST response mode =3D good , and a oauth = client running in the browser user agent as a Java script application = (that can=E2=80=99t directly capture a POST response back to the server) So it depends on where the client is actually running. Are you saying that you are using a 302 redirect from the authorization = endpoint back to the server hosting the JS and then loading the JS = including the code and then using CORES to exchange the code for a AT? You can do that but I don=E2=80=99t think a public client like that is = more secure than just using the fragment encoded response and is more = work. It also may give the server a false sense of security. John B. > On Jul 1, 2016, at 5:52 PM, Josh Mandel wrote: >=20 > I think the confusion here is that I'm not using HEART's OAuth = profiles :-) >=20 > I'm using the SMART profiles, where we do specify the use of an = authorization code grant even for browser-based public clients (in which = case, no client_secret is issued or used). I'm just trying to understand = your perspective eon why this "won't work well". Perhaps you didn't mean = this comment to refer to browser-based OAuth clients generally? >=20 > -Josh >=20 > On Fri, Jul 1, 2016 at 5:45 PM, John Bradley > wrote: > I don=E2=80=99t think the post response mode is supported by heart so = I suspect that we are talking about different things. >=20 > You are probably using the supported code flow that uses a 302 get to = return the code to the OAuth client on the server. =20 > The Web server is then acting as a confidential client to exchange the = code via a POST (different POST) with the AS token_endpoint. >=20 > The Token endpoint will return a access token (AT) and optional = refresh token (RT). >=20 > The web page may be getting the server to make the OAuth calls on = it=E2=80=99s behalf to the Resource Server, or possibly you are passing = the AT from the server back to a Java script app that is using CORES to = make calls directly to the RS without going through the Web server. >=20 > Passing the AT back to the user agent from the client is not = recommended.=20 >=20 > For in browser clients where the JS is using the AT to make the calls = directly to the RS via CORES the recommended approach is to use the = fragment encoded response via a 302 to deliver the AT directly to the = client (It never hits the backend Web server). >=20 > However I believe In browser OAuth clients are not currently supported = in HEART, so I am not quite sure what you are doing. >=20 > Perhaps Justin has a better answer. >=20 > John B. >=20 >=20 >> On Jul 1, 2016, at 5:33 PM, Josh Mandel > wrote: >>=20 >> John, >>=20 >> I appreciate your response. I'm hoping you can clarify why you say = that "HTTP POST... won't work well for... [a] single page OAuth client"? >>=20 >> We commonly build single-page apps that act as OAuth clients for = SMART (e.g. this sample app = ), and we've had good experience with the = technique. Could you elaborate? >>=20 >> -J >>=20 >> On Fri, Jul 1, 2016 at 5:26 PM, John Bradley > wrote: >> HEART only supports web server clients at the moment. That might = change in future to support native apps if that an be made to support = the security requirements of Heath IT. >>=20 >> So the thing HTTP POST responses won=E2=80=99t work well for is a = type of in browser single page OAuth client. That still needs fragment = encoded responses or the new post-message Java Script API approach. >>=20 >> John B. >>=20 >>=20 >>> On Jul 1, 2016, at 5:16 PM, Josh Mandel > wrote: >>>=20 >>> Thanks Justin, >>>=20 >>> To clarify: John's comment and my question were about POST. (I do = understand the behavior of HTTP POST and of window.postMessage; these = are totally different things.) =46rom my perspective in SMART Health IT, = we use the OAuth 2.0 authorization code flow, including HTTP POST, in = our authorization spec = even for public clients, and it has worked very well for us, with about = a dozen electronic health record servers supporting this approach. = That's why I was curious to hear John's perspective about limitations. >>>=20 >>> -J >>>=20 >>> On Fri, Jul 1, 2016 at 5:09 PM, Oleg Gryb > wrote: >>> > POST will send things to the server, which isn=E2=80=99t desirable = if your client is solely in the browser >>> Why it's not desirable, assuming that we disregard performance? You = can generate HTTP POST from JS, e.g. through an AJAX call. What is wrong = with this? >>>=20 >>>=20 >>> From: Justin Richer > >>> To: Josh Mandel >=20 >>> Cc: Oleg Gryb >; = ">" >; Liyu Yi > >>> Sent: Friday, July 1, 2016 2:00 PM >>>=20 >>> Subject: Re: [OAUTH-WG] Security concern for URI fragment as = Implicit grant >>>=20 >>> POST will send things to the server, which isn=E2=80=99t desirable = if your client is solely in the browser. postMessage is a browser API = and not to be confused with HTTP POST. postMessage messages stay (or can = stay) within the browser, which is the intent here. >>>=20 >>> =E2=80=94 Justin >>>=20 >>>> On Jul 1, 2016, at 4:56 PM, Josh Mandel > wrote: >>>>=20 >>>=20 >>> John, >>>=20 >>> Could you clarify what you mean by "POST doesn't really work"? Do = you just mean that CORS support (e.g., http://caniuse.com/#feat=3Dcors = ) isn't universal, or something more? >>>=20 >>> On Fri, Jul 1, 2016 at 4:51 PM, John Bradley > wrote: >>> Yes but POST doesn't really work for in browser apps. >>>=20 >>> If it is a server app it should be using the code flow with GET or = POST as you like. >>>=20 >>> If we do a post message based binding it will be targeted at in = browser applications. >>>=20 >>> John B. >>>=20 >>> On Fri, Jul 1, 2016 at 4:42 PM, Liyu Yi > wrote: >>> BTW, I do not see any significant performance concerns for post. = Parsing and executing the Javascript logic for post operation will be on = the client side, no extra server load is introduced. >>>=20 >>> Plus post will remove the size restriction of the URL length. >>>=20 >>> -- Liyu=20 >>>=20 >>> On Fri, Jul 1, 2016 at 1:35 PM, Liyu Yi > wrote: >>> Thanks for the great comments and advices. >>>=20 >>> I think it is a good idea for the working group to revise the = fragment part in the spec, since there might be public available tools = already implemented this approach and people can end up with a solution = with serious security loopholes. >>>=20 >>> The re-append issue can be mitigate by a logic on Resource Server = which carefully re-writes/removes the fragment in any redirect, if the = the redirect can not be avoided. >>>=20 >>> -- Liyu >>> =20 >>>=20 >>> On Fri, Jul 1, 2016 at 11:33 AM, John Bradley > wrote: >>> This behaviour started changing around 2011 >>>=20 >>> =46rom HTTP/1.1 >>> See https://tools.ietf.org/html/rfc7231#section-7.1.2 = I >>> f the Location value provided in a 3xx (Redirection) response = does >>> not have a fragment component, a user agent MUST process the >>> redirection as if the value inherits the fragment component of = the >>> URI reference used to generate the request target (i.e., the >>> redirection inherits the original reference's fragment, if any). >>>=20 >>> For example, a GET request generated for the URI reference >>> "http://www.example.org/~tim " might = result in a 303 (See Other) >>> response containing the header field: >>>=20 >>> Location: /People.html#tim >>>=20 >>> which suggests that the user agent redirect to >>> "http://www.example.org/People.html#tim = =E2=80=9D >>>=20 >>> Likewise, a GET request generated for the URI reference >>> "http://www.example.org/index.html#larry = " might result in a 301 >>> (Moved Permanently) response containing the header field: >>>=20 >>> Location: http://www.example.net/index.html = >>>=20 >>> which suggests that the user agent redirect to >>> "http://www.example.net/index.html#larry = ", preserving the original >>> fragment identifier. >>>=20 >>>=20 >>> This blog also explores the change. >>> = https://blogs.msdn.microsoft.com/ieinternals/2011/05/16/url-fragments-and-= redirects/ = >>>=20 >>>=20 >>>> On Jul 1, 2016, at 1:05 PM, Oleg Gryb > wrote: >>>>=20 >>>> "Browsers now re-append fragments across 302 redirects unless they = are explicitly cleared this makes fragment encoding less safe than it = was when originally specified" - thanks Jim. Looks like a good reason = for vetting this flow out. >>>>=20 >>>> John, >>>> Please provide more details/links about re-appending fragments.=20 >>>>=20 >>>> Thanks, >>>> Oleg. >>>>=20 >>>>=20 >>>> From: Jim Manico > >>>> To: Oleg Gryb >=20 >>>> Cc: "oauth@ietf.org " >; Liyu Yi > >>>> Sent: Thursday, June 30, 2016 10:25 PM >>>> Subject: Re: [OAUTH-WG] Security concern for URI fragment as = Implicit grant >>>>=20 >>>> Oleg! Hello! Great to see you pop up here with a similar concern. >>>>=20 >>>> John Bradley just answered this thread with the details I was = looking for (thanks John, hat tip your way). >>>>=20 >>>> He also mentioned details about fragment leakage: >>>>=20 >>>> "Browsers now re-append fragments across 302 redirects unless they = are explicitly cleared this makes fragment encoding less safe than it = was when originally specified" >>>>=20 >>>> Again, I'm new here but I'm grateful for this conversation. >>>>=20 >>>> Aloha, >>>> -- >>>> Jim Manico >>>> @Manicode >>>>=20 >>>> On Jul 1, 2016, at 1:24 AM, Oleg Gryb > wrote: >>>>=20 >>>>> We've discussed access tokens in URI back in 2010 = (https://www.ietf.org/mail-archive/web/oauth/current/msg04043.html = ). = There were two major objectives when I was saying that it's not secure: >>>>>=20 >>>>> 1. Fragment is not sent to a server by a browser. When I've asked = if this is true for every browser in the world, nobody was able to = answer. >>>>> 2. Replacing with POST would mean a significant performance impact = in some high volume implementations (I think it was Goole folks who were = saying this, but I don't remember now). >>>>>=20 >>>>> AFAIR, nobody was arguing about browsing history, so it's valid. >>>>>=20 >>>>> So, 6 years later we're at square one with this and I hope that = this time the community will be more successful with getting rid of = secrets in URL. >>>>>=20 >>>>> BTW, Jim, if you can come up with other scenarios when fragments = can leak, please share. It'll probably help the community with solving = this problem faster than in 6 years. >>>>>=20 >>>>> Thanks, >>>>> Oleg. >>>>>=20 >>>>>=20 >>>>> From: Jim Manico > >>>>> To: Liyu Yi >; = oauth@ietf.org =20 >>>>> Sent: Wednesday, June 29, 2016 7:30 AM >>>>> Subject: Re: [OAUTH-WG] Security concern for URI fragment as = Implicit grant >>>>>=20 >>>>> > Shouldn=E2=80=99t it be more secure if we change to use a post = method for access token, similar to the SAML does? >>>>> I say yes. But please note I'm very new at this and someone with = more experience will have more to say or correct my comments. >>>>> Here are a few more details to consider. >>>>> 1) OAuth is a framework and not a standard, per se. Different = authorization servers will have different implementations that are not = necessarily compatible with other service providers. So there is no = standard to break, per se. >>>>> 2) Sensitive data in a URI is a bad idea. They leak all over the = place even over HTTPS. Even in fragments. >>>>> 3) Break the "rules" and find a way to submit sensitive data like = access tokens, session information or any other (even short term) = sensitive data in a secure fashion. This includes POST, JSON data = payloads over PUT/PATCH and other verbs - all over well configured = HTTPS. >>>>> 4) If you really must submit sensitive data over GET , consider = JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level = confidentiality and integrity. >>>>> Aloha, >>>>> Jim Manico >>>>> Manicode Security >>>>> https://www.manicode.com >>>>> On 6/27/16 9:30 PM, Liyu Yi wrote: >>>>>> While we are working on a project with OAuth2 implementation, one = question arises from our engineers. >>>>>> We noticed at = https://tools.= ietf.org/html/draft-ietf-oauth-v2-31#page-30 = , it is = specified that >>>>>> =20 >>>>>> (C) Assuming the resource owner grants access, the authorization >>>>>> server redirects the user-agent back to the client using = the >>>>>> redirection URI provided earlier. The redirection URI = includes >>>>>> the access token in the URI fragment. >>>>>> =20 >>>>>> For my understanding, the browser keeps the URI fragment in the = history, and this introduces unexpected exposure of the access token. A = user without authorization for the resource can get the access token as = long as he has the access to the browser. This can happen in a shared = computer in library, or for an IT staff who works on other employee=E2=80=99= s computer. >>>>>> =20 >>>>>> Shouldn=E2=80=99t it be more secure if we change to use a post = method for access token, similar to the SAML does? >>>>>> I feel there might be something I missed here. Any advices will = be appreciated. >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>=20 >>>>> --=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>=20 >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >>=20 >=20 >=20 --Apple-Mail=_E3B3C169-59C5-465C-954D-E6D154C4D2F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I am making a distinction between a browser talking to a Web = server that is acting as a OAuth Client POST response mode =3D good , = and a oauth client running in the browser user agent as a Java script = application (that can=E2=80=99t directly capture a POST response back to = the server)

So it = depends on where the client is actually running.

Are you saying that you are using a 302 = redirect from the authorization endpoint back to the server hosting the = JS and then loading the JS including the code and then using CORES =  to exchange the code for a AT?

You can do that but I don=E2=80=99t = think a public client like that is more secure than just using the = fragment encoded response and is more work.
It also = may give the server a false sense of security.

John B.
On Jul 1, 2016, at 5:52 PM, = Josh Mandel <jmandel@gmail.com> wrote:

I think the confusion here is that I'm not using HEART's = OAuth profiles :-)

I'm= using the SMART profiles, where we do specify the use of an = authorization code grant even for browser-based public clients (in which = case, no client_secret is issued or used). I'm just trying to understand = your perspective eon why this "won't work well". Perhaps you didn't mean = this comment to refer to browser-based OAuth clients = generally?

  -Josh

On Fri, Jul 1, 2016 at 5:45 PM, = John Bradley <ve7jtb@ve7jtb.com> wrote:
I don=E2=80=99t think the post = response mode is supported by heart so I suspect that we are talking = about different things.

You are probably using the supported code flow that uses a = 302 get to return the code to the OAuth client on the server. =  
The Web server is then acting as a = confidential client to exchange the code via a POST (different POST) = with the AS token_endpoint.

The Token endpoint will return a access token (AT) and = optional refresh token (RT).

The web page may be getting the server = to make the OAuth calls on it=E2=80=99s behalf to the Resource Server, = or possibly you are passing the AT from the server back to a Java script = app that is using CORES to make calls directly to the RS without going = through the Web server.

Passing the AT back to the user agent from the client is not = recommended. 

For in browser clients where the JS is using the AT to make = the calls directly to the RS via CORES the recommended approach is to = use the fragment encoded response via a 302 to deliver the AT directly = to the client (It never hits the backend Web server).

However I believe In = browser OAuth clients are not currently supported in HEART, so I am not = quite sure what you are doing.

Perhaps Justin has a better = answer.

John = B.


On Jul = 1, 2016, at 5:33 PM, Josh Mandel <jmandel@gmail.com> wrote:

John,

I appreciate your = response. I'm hoping you can clarify why you say that "HTTP POST... = won't work well for... [a] single page OAuth client"?

We commonly build single-page apps that = act as OAuth clients for SMART (e.g. this = sample app ), and we've had good experience with the technique. = Could you elaborate?

  -J

On Fri, Jul 1, 2016 at 5:26 PM, = John Bradley <ve7jtb@ve7jtb.com> wrote:
HEART only supports web server = clients at the moment.   That might change in future to support = native apps if that an be made to support the security requirements of = Heath IT.

So the thing = HTTP POST responses won=E2=80=99t work well for is a type of in browser = single page OAuth client.  That still needs fragment encoded = responses or the new post-message Java Script API approach.

John B.


On Jul 1, 2016, at 5:16 PM, Josh Mandel = <jmandel@gmail.com> wrote:

Thanks Justin,

To clarify: John's comment and my = question were about POST. (I do understand the behavior of HTTP POST and = of window.postMessage; these are totally different things.) =46rom my = perspective in SMART Health IT, we use the OAuth 2.0 authorization code = flow, including HTTP POST, in our authorization spec even for public clients, and it = has worked very well for us, with about a dozen electronic health record = servers supporting this approach. That's why I was curious to hear = John's perspective about limitations.

  -J

On Fri, = Jul 1, 2016 at 5:09 PM, Oleg Gryb <oleg_gryb@yahoo.com> wrote:
> POST will send things to the server, which isn=E2=80=99t = desirable if your client is solely in the browser
Why it's not desirable, assuming that we = disregard performance? You can generate HTTP POST from JS, e.g. through = an AJAX call. What is wrong with this?


=
=
= From:= Justin Richer <jricher@mit.edu>
To: Josh Mandel <jmandel@gmail.com>
Cc: Oleg Gryb <oleg@gryb.info>; "<oauth@ietf.org>" <oauth@ietf.org>; Liyu Yi <liyuyi@gmail.com>
Sent: Friday, July 1, = 2016 2:00 PM

Subject:= Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant
=

POST will = send things to the server, which isn=E2=80=99t desirable if your client = is solely in the browser. postMessage is a browser API and not to be = confused with HTTP POST. postMessage messages stay (or can stay) within = the browser, which is the intent here.

 =E2=80=94 Justin

On Jul = 1, 2016, at 4:56 PM, Josh Mandel <jmandel@gmail.com> wrote:

John,

Could you = clarify what you mean by "POST= doesn't really work"? Do you just mean that CORS support (e.g., http://caniuse.com/#feat=3Dcors) isn't = universal, or something more?

On Fri, Jul 1, 2016 at 4:51 = PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
Yes but = POST doesn't really work for in browser apps.

If it is a server app it = should be using the code flow with GET or POST as you like.

If we do = a  post message based binding it will be targeted at in browser = applications.

John B.

On Fri, Jul 1, 2016 at 4:42 = PM, Liyu Yi <liyuyi@gmail.com> wrote:
BTW, I do = not see any significant performance concerns for post. Parsing and = executing the Javascript logic for post operation will be on the client = side, no extra server load is introduced.

Plus post will remove = the size restriction of the URL length.

-- = Liyu 

On Fri, Jul 1, 2016 at 1:35 = PM, Liyu Yi <liyuyi@gmail.com> wrote:
Thanks for the great comments and advices.

I think it is a good idea = for the working group to revise the fragment part in the spec, since = there might be public available tools already implemented this approach = and people can end up with a solution with serious security = loopholes.

The re-append issue can be mitigate by a logic on Resource = Server which carefully re-writes/removes the fragment in any redirect, = if the the redirect can not be avoided.

-- = Liyu
 

On Fri, Jul 1, 2016 at 11:33 = AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
This behaviour started changing around 2011

=46rom = HTTP/1.1
See https://tools.ietf.org/html/rfc7231#section-7.1.2I
    =   f the Location value provided in a 3xx (Redirection) response = does
   not have a fragment component, a user agent MUST =
process the
   redirection as if the value inherits the fragment component of the
   URI reference used to generate the request target (i.e., the
   redirection inherits the original reference's fragment, if any).

   For example, a GET request generated for the URI reference
   "http://www.example.org/~tim" might result in a 303 (See =
Other)
   response containing the header field:

     Location: /People.html#tim

   which suggests that the user agent redirect to
   "http://www.example.org/People.html#tim=E2=80=9D

   Likewise, a GET request generated for the URI =
reference
   "http://www.example.org/index.html#larry" might result in =
a 301
   (Moved Permanently) response containing the header field:

     Location: http://www.example.net/index.html

   which suggests that the user agent redirect to
   "http://www.example.net/index.html#larry", preserving the =
original
   fragment identifier.


This blog = also explores the change.
https://blogs.msdn.microsoft.com/ieinternals/2011/05/16/url-fra= gments-and-redirects/


On Jul 1, 2016, at 1:05 PM, Oleg Gryb <oleg_gryb@yahoo.com> wrote:

"Browsers now = re-append  fragments across 302 redirects unless they are = explicitly cleared this makes fragment encoding less safe than it was =  when originally specified" - thanks Jim. Looks like a good reason = for vetting this flow out.

John,
Please provide more details/links about re-appending = fragments. 

Thanks,
Oleg.


=
From: Jim Manico <jim@manicode.com>
To: = Oleg Gryb <oleg@gryb.info>
Cc: = "oauth@ietf.org" <oauth@ietf.org>; Liyu Yi <liyuyi@gmail.com>
Sent: = Thursday, June 30, 2016 10:25 PM
Subject:= Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

Oleg! Hello! = Great to see you pop up here with a similar concern.

John = Bradley just answered this thread with the details I was looking for = (thanks John, hat tip your way).

He also mentioned details about = fragment leakage:

"Browsers now = re-append  fragments across 302 redirects unless they are = explicitly cleared this makes fragment encoding less safe than it was = when originally specified"

Again, I'm new here but I'm grateful = for this conversation.

Aloha,
--
Jim Manico
@Manicode

On Jul 1, 2016, at 1:24 AM, Oleg Gryb <oleg_gryb@yahoo.com> wrote:

We've discussed access tokens in URI back in = 2010 (https://www.ietf.org/mail-archive/web/oauth/current/msg04043.ht= ml). There were two major objectives when I was saying that it's not = secure:

1. Fragment is not sent to = a server by a browser. When I've asked if this is true for every browser = in the world, nobody was able to answer.
2. Replacing with POST would mean a significant performance = impact in some high volume implementations (I think it was Goole folks = who were saying this, but I don't remember now).

AFAIR, nobody was arguing about browsing history, so it's = valid.

So, 6 years later we're at = square one with this and I hope that this time the community will be = more successful with getting rid of secrets in URL.

BTW, Jim, if you can come up with other scenarios when = fragments can leak, please share. It'll probably help the community with = solving this problem faster than in 6 years.

Thanks,
Oleg.


=
From: Jim Manico <jim@manicode.com>
To: = Liyu Yi <liyuyi@gmail.com>; oauth@ietf.org
Sent: = Wednesday, June 29, 2016 7:30 AM
Subject:= Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

> Shouldn=E2=80=99t it be more = secure if we change to use a post method for access token, similar to the SAML = does?
I say yes. But please note I'm very new at this and = someone with more experience will have more to say or correct my = comments.
Here are a few more details to consider.
1) OAuth is a framework and not a standard, per se. = Different authorization servers will have different implementations that are not necessarily compatible with other service providers. So there is no standard to break, per se.
2) Sensitive data in a URI is a bad idea. They leak = all over the place even over HTTPS. Even in fragments.
3) Break the "rules" and find a way to submit = sensitive data like access tokens, session information or any other (even short term) sensitive data in a secure fashion. This includes POST, JSON data payloads over PUT/PATCH and other verbs - all over well configured HTTPS.
4) If you really must submit sensitive data over GET = , consider JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level confidentiality and integrity.
Aloha,
Jim Manico
Manicode Security
https://www.manicode.com

On 6/27/16 9:30 PM, Liyu Yi = wrote:
While we are working on a = project with OAuth2 implementation, one question arises from our engineers.
We noticed at https://tools.ietf.org/html/draft-ietf-oauth-v2-31#page-30<= /span>, it is specified that
  
(C)  Assuming the resource = owner grants access, the authorization
        server redirects = the user-agent back to the client using the
        redirection URI = provided earlier.  The redirection URI includes
        the access token = in the URI fragment.
 
For my understanding, the = browser keeps the URI fragment in the history, and this introduces unexpected exposure of the access token. A user without authorization for the resource can get the access token as long as he has the access to the browser. This can happen in a shared computer in library, or for an IT staff who works on other employee=E2=80=99s computer.
 
Shouldn=E2=80=99t it be more = secure if we change to use a post method for access token, similar to the SAML does?
I feel there might be something = I missed here. Any advices will be appreciated.


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


--=20

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


=

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


=





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


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


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


=
=

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





= --Apple-Mail=_E3B3C169-59C5-465C-954D-E6D154C4D2F5-- From nobody Fri Jul 1 15:13:16 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C68F12D0AB for ; Fri, 1 Jul 2016 15:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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=manicode-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 mmURTYvJosl1 for ; Fri, 1 Jul 2016 15:13:12 -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 411E612B058 for ; Fri, 1 Jul 2016 15:13:12 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id v199so41294462wmv.0 for ; Fri, 01 Jul 2016 15:13:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1nhoQnhyC7DDr4PQyn0s5bv4hKLIqO7Ik5ypFoWRjpo=; b=jgByDmm9lOaYoU4Wuk7GQbOM5SoYlBTxl6DHWPYH8Wzdmo6RG2iO4lqk7wb1gQZPFr oMGq/+UP0AfqTOiUqhyJc+/kAJZweSZVP3A57dF91SkqKaO+pvgJ24phYVUQMYytZAtE glWIU6q5CwyYY4S6b5MmFCbSBlnlrwzQgQmM7uLVDa7lju8N9yQKYDNoIOxq88s1azDh 8OTqN6xK/r5i90fRYuvtPWClE+gIM6GeoWAXb5Pkn9m9menXW9GMM7EZH/etQSN1G9Vi S1sEyCOmz/cB779aUvU6OcX5zOZM/0FnjC+e+Riwu6J4IjU7Xox6dbUj2IPdYqjOT2DR 2alA== 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 :content-transfer-encoding:message-id:references:to; bh=1nhoQnhyC7DDr4PQyn0s5bv4hKLIqO7Ik5ypFoWRjpo=; b=ciHoWIaPOwNJRFNQ/GknrtYh2udj8mkGegqP6aEkswOGaZ6iW/2Qf+Z4cdq8FVR/mX JkP8QF9Zdmn1jVu3c/2SqqdGnnOHcrCkaMOqn4u7FLX5ANrUi52+dqnzfKBeyjfaz/Hv C4RfbBuYiwmT+s+Eb+CEtwZvg7Q/0FR3GywRmXBs6IUy74zXiTRKkfgK52lLswiYyGDz MJ/mEpu9zSjRBzySlng7FQ8VM/qo/bDJ4qy/FyG2jkPE2z2L/cLhFExkZ5kxwiuRB3kZ rtT1utoPYXUM2qBDWV6+TafE0tIOmybdaKQkWfKfsCHD09kRUsbS68XGtynARjprVVCo TJhw== X-Gm-Message-State: ALyK8tKDf6lDMaJJK8detMtY+Q+zy7XJxcD0jXSDY0CD93uD0h/2T+sFicREE2uCWePOFG72 X-Received: by 10.194.81.138 with SMTP id a10mr388343wjy.53.1467411190628; Fri, 01 Jul 2016 15:13:10 -0700 (PDT) Received: from [198.18.208.168] ([213.215.138.237]) by smtp.gmail.com with ESMTPSA id ki4sm5099980wjb.21.2016.07.01.15.13.08 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 01 Jul 2016 15:13:08 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-749964E7-4190-4D88-AFDA-D18C5877F2E5 Mime-Version: 1.0 (1.0) From: Jim Manico X-Mailer: iPhone Mail (13F69) In-Reply-To: <861873527.537281.1467406912735.JavaMail.yahoo@mail.yahoo.com> Date: Sat, 2 Jul 2016 00:13:08 +0200 Content-Transfer-Encoding: 7bit Message-Id: <629A6A52-22D9-44E2-949D-DE35C8774C3D@manicode.com> References: <994121658.55005.1467329084208.JavaMail.yahoo@mail.yahoo.com> <235316006.458279.1467392709447.JavaMail.yahoo@mail.yahoo.com> <6584BD74-B18F-4174-9E69-5C7B4B76F895@ve7jtb.com> <861873527.537281.1467406912735.JavaMail.yahoo@mail.yahoo.com> To: Oleg Gryb Archived-At: Cc: "oauth@ietf.org" , Liyu Yi Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 22:13:15 -0000 --Apple-Mail-749964E7-4190-4D88-AFDA-D18C5877F2E5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable HTTP POST requests are also a lot more difficult to cache server side compar= ed to URI's which are easier to cache. I'm likely not explaining this well, b= ut I believe it's a webscale concern. -- Jim Manico @Manicode > On Jul 1, 2016, at 11:01 PM, Oleg Gryb wrote: >=20 > AFAIR, they were talking about cost of this additional POST on the server s= ide, which was not good for high volume traffic (millions requests per day).= I'll try to dig it out to find more details.=20 >=20 >=20 > From: Liyu Yi > To: John Bradley =20 > Cc: Oleg Gryb ; Jim Manico ; "oauth@ietf= .org" > Sent: Friday, July 1, 2016 1:42 PM > Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit gran= t >=20 > BTW, I do not see any significant performance concerns for post. Parsing a= nd executing the Javascript logic for post operation will be on the client s= ide, no extra server load is introduced. >=20 > Plus post will remove the size restriction of the URL length. >=20 > -- Liyu=20 >=20 > On Fri, Jul 1, 2016 at 1:35 PM, Liyu Yi wrote: > Thanks for the great comments and advices. >=20 > I think it is a good idea for the working group to revise the fragment par= t in the spec, since there might be public available tools already implement= ed this approach and people can end up with a solution with serious security= loopholes. >=20 > The re-append issue can be mitigate by a logic on Resource Server which ca= refully re-writes/removes the fragment in any redirect, if the the redirect c= an not be avoided. >=20 > -- Liyu > =20 >=20 > On Fri, Jul 1, 2016 at 11:33 AM, John Bradley wrote: > This behaviour started changing around 2011 >=20 > =46rom HTTP/1.1 > See https://tools.ietf.org/html/rfc7231#section-7.1.2I > f the Location value provided in a 3xx (Redirection) response does > not have a fragment component, a user agent MUST process the > redirection as if the value inherits the fragment component of the > URI reference used to generate the request target (i.e., the > redirection inherits the original reference's fragment, if any). >=20 > For example, a GET request generated for the URI reference > "http://www.example.org/~tim" might result in a 303 (See Other) > response containing the header field: >=20 > Location: /People.html#tim >=20 > which suggests that the user agent redirect to > "http://www.example.org/People.html#tim=E2=80=9D >=20 > Likewise, a GET request generated for the URI reference > "http://www.example.org/index.html#larry" might result in a 301 > (Moved Permanently) response containing the header field: >=20 > Location: http://www.example.net/index.html >=20 > which suggests that the user agent redirect to > "http://www.example.net/index.html#larry", preserving the original > fragment identifier. >=20 >=20 > This blog also explores the change. > https://blogs.msdn.microsoft.com/ieinternals/2011/05/16/url-fragments-and-= redirects/ >=20 >=20 >> On Jul 1, 2016, at 1:05 PM, Oleg Gryb wrote: >>=20 >> "Browsers now re-append fragments across 302 redirects unless they are e= xplicitly cleared this makes fragment encoding less safe than it was when o= riginally specified" - thanks Jim. Looks like a good reason for vetting this= flow out. >>=20 >> John, >> Please provide more details/links about re-appending fragments.=20 >>=20 >> Thanks, >> Oleg. >>=20 >>=20 >> From: Jim Manico >> To: Oleg Gryb =20 >> Cc: "oauth@ietf.org" ; Liyu Yi >> Sent: Thursday, June 30, 2016 10:25 PM >> Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit gra= nt >>=20 >> Oleg! Hello! Great to see you pop up here with a similar concern. >>=20 >> John Bradley just answered this thread with the details I was looking for= (thanks John, hat tip your way). >>=20 >> He also mentioned details about fragment leakage: >>=20 >> "Browsers now re-append fragments across 302 redirects unless they are e= xplicitly cleared this makes fragment encoding less safe than it was when or= iginally specified" >>=20 >> Again, I'm new here but I'm grateful for this conversation. >>=20 >> Aloha, >> -- >> Jim Manico >> @Manicode >>=20 >>> On Jul 1, 2016, at 1:24 AM, Oleg Gryb wrote: >>>=20 >>> We've discussed access tokens in URI back in 2010 (https://www.ietf.org/= mail-archive/web/oauth/current/msg04043.html). There were two major objectiv= es when I was saying that it's not secure: >>>=20 >>> 1. Fragment is not sent to a server by a browser. When I've asked if thi= s is true for every browser in the world, nobody was able to answer. >>> 2. Replacing with POST would mean a significant performance impact in so= me high volume implementations (I think it was Goole folks who were saying t= his, but I don't remember now). >>>=20 >>> AFAIR, nobody was arguing about browsing history, so it's valid. >>>=20 >>> So, 6 years later we're at square one with this and I hope that this tim= e the community will be more successful with getting rid of secrets in URL. >>>=20 >>> BTW, Jim, if you can come up with other scenarios when fragments can lea= k, please share. It'll probably help the community with solving this problem= faster than in 6 years. >>>=20 >>> Thanks, >>> Oleg. >>>=20 >>>=20 >>> From: Jim Manico >>> To: Liyu Yi ; oauth@ietf.org=20 >>> Sent: Wednesday, June 29, 2016 7:30 AM >>> Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit gr= ant >>>=20 >>> > Shouldn=E2=80=99t it be more secure if we change to use a post method f= or access token, similar to the SAML does? >>> I say yes. But please note I'm very new at this and someone with more ex= perience will have more to say or correct my comments. >>> Here are a few more details to consider. >>> 1) OAuth is a framework and not a standard, per se. Different authorizat= ion servers will have different implementations that are not necessarily com= patible with other service providers. So there is no standard to break, per s= e. >>> 2) Sensitive data in a URI is a bad idea. They leak all over the place e= ven over HTTPS. Even in fragments. >>> 3) Break the "rules" and find a way to submit sensitive data like access= tokens, session information or any other (even short term) sensitive data i= n a secure fashion. This includes POST, JSON data payloads over PUT/PATCH an= d other verbs - all over well configured HTTPS. >>> 4) If you really must submit sensitive data over GET , consider JWT/JWS/= JWE (with limited scopes/lifetimes) to provide message level confidentiality= and integrity. >>> Aloha, >>> Jim Manico >>> Manicode Security >>> https://www.manicode.com >>>=20 >>>> On 6/27/16 9:30 PM, Liyu Yi wrote: >>>> While we are working on a project with OAuth2 implementation, one quest= ion arises from our engineers. >>>> We noticed at https://tools.ietf.org/html/draft-ietf-oauth-v2-31#page-3= 0, it is specified that >>>> =20 >>>> (C) Assuming the resource owner grants access, the authorization >>>> server redirects the user-agent back to the client using the >>>> redirection URI provided earlier. The redirection URI includes= >>>> the access token in the URI fragment. >>>> =20 >>>> For my understanding, the browser keeps the URI fragment in the history= , and this introduces unexpected exposure of the access token. A user withou= t authorization for the resource can get the access token as long as he has t= he access to the browser. This can happen in a shared computer in library, o= r for an IT staff who works on other employee=E2=80=99s computer. >>>> =20 >>>> Shouldn=E2=80=99t it be more secure if we change to use a post method f= or access token, similar to the SAML does? >>>> I feel there might be something I missed here. Any advices will be appr= eciated. >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>> --=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 >=20 >=20 --Apple-Mail-749964E7-4190-4D88-AFDA-D18C5877F2E5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
HTTP POST requests are also a lot more= difficult to cache server side compared to URI's which are easier to cache.= I'm likely not explaining this well, but I believe it's a webscale concern.=

--
Jim Manico
@Manicode
On Jul 1, 2016, at 11:01 PM, Oleg Gryb <oleg_gryb@yahoo.com> wrote:

AFAIR, they were talking about cost of= this additional POST on the server side, which was not good for high volume= traffic (millions requests per day). I'll try to dig it out to find more de= tails.
=

= From: Liyu Yi <liyuyi@gmail.com>
To: John Bradley <ve7jtb@ve7jtb.com>
C= c: Oleg Gryb <oleg@gryb.info= >; Jim Manico <jim@manicode.co= m>; "oauth@ietf.org" <oauth@ietf.org>
Sent: Friday, July 1, 2016 1:42 PM
Subject: Re: [OAUTH-WG] Security conc= ern for URI fragment as Implicit grant

BTW, I do not see any significa= nt performance concerns for post. Parsing and executing the Javascript logic= for post operation will be on the client side, no extra server load is intr= oduced.

<= /div>
Plus post will remove t= he size restriction of the URL length.

-- Liyu 

On Fri= , Jul 1, 2016 at 1:35 PM, Liyu Yi <liyuyi@gmail.com> wrote:
Thanks for the great comments and advices.

I think it is a good idea for the working group to revise the frag= ment part in the spec, since there might be public available tools already i= mplemented this approach and people can end up with a solution with serious s= ecurity loopholes.

The re-append issue can be mitigate by a logic on Resou= rce Server which carefully re-writes/removes the fragment in any redirect, i= f the the redirect can not be avoided.

-- Liyu
 

On Fri, Jul 1, 2= 016 at 11:33 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
This behaviour started changing around 2011

=46rom HTTP/1.1
      f the Location value provided in a 3xx (Redirection) r= esponse does
   not have a fragment component, a use=
r agent MUST process the
   redirection as if the value inherits the fragment component of the
   URI reference used to generate the request target (i.e., the
   redirection inherits the original reference's fragment, if any).

   For example, a GET request generated for the URI reference
   "http://www.example.org/~tim" might result in a 303 (Se=
e Other)
   response containing the header field:

     Location: /People.html#tim

   which suggests that the user agent redirect to
   "http://www.example.org/People.html#tim=E2=80=
=9D

   Likewise, a=
 GET request generated for the URI reference
   "http://www.example.org/index.html#larry" m=
ight result in a 301
   (Moved Permanently) response containing the header field:

     Location: http://www.example.net/index.html

   which suggests that the user agent redirect to
   "http://www.example.net/index.html#larry", p=
reserving the original
   fragment identifier.


This blog also explores the change.
<= br clear=3D"none">

On Jul 1, 2016, at 1:05 PM, Oleg Gryb <oleg_gryb@yahoo.com> wrote:

"Browsers now re-append  fragments acr= oss 302 redirects unless they are explicitly cleared this makes fragment enc= oding less safe than it was  when originally specified" - thanks Jim. L= ooks like a good reason for vetting this flow out.
=

John,
P= lease provide more details/links about re-appending fragments. <= /div>

Thanks,
Oleg.


From: J= im Manico <jim@manicode.com= >
To:<= /b> Oleg Gryb <oleg@gryb.info>
Cc: "oauth@ietf.org" <oauth@ietf.org>; Liyu Yi <liyuyi@gmail.com>
Sent: Thursday, June 30= , 2016 10:25 PM
Subj= ect: Re: [OAUTH-WG] Security concern for URI fragment as Implicit= grant

Ole= g! Hello! Great to see you pop up here with a similar concern.
John Bradley just answered this thread with the d= etails I was looking for (thanks John, hat tip your way).

He also mentioned details about fragment leakage:

"Browsers now re-append  frag= ments across 302 redirects unless they are explicitly cleared this makes fra= gment encoding less safe than it was when originally specified"
=

Again, I'm new here but I'm grateful for t= his conversation.

Aloha,
<= div>--
Jim Manico
@Manicode

On Jul 1, 2016, at 1:24 AM, Oleg Gryb <oleg_gryb@yahoo.com> wrote:

We've discussed access tokens in U= RI back in 2010 (= https://www.ietf.org/mail-archive/web/oauth/current/msg04043.html). Ther= e were two major objectives when I was saying that it's not secure:

1. Fragment is not s= ent to a server by a browser. When I've asked if this is true for every brow= ser in the world, nobody was able to answer.
2. Replac= ing with POST would mean a significant performance impact in some high volum= e implementations (I think it was Goole folks who were saying this, but I do= n't remember now).

AFAIR, nobody was arguing about browsing history, so it's valid.
=

So, 6 years later= we're at square one with this and I hope that this time the community will b= e more successful with getting rid of secrets in URL.
=
BTW, Jim, if you can come up with o= ther scenarios when fragments can leak, please share. It'll probably help th= e community with solving this problem faster than in 6 years.

Thanks,
Oleg.


From: Jim Manico &= lt;jim@manicode.com> To: Liyu Yi= <liyuyi@gmail.com>; <= a rel=3D"nofollow" shape=3D"rect" ymailto=3D"mailto:oauth@ietf.org" target=3D= "_blank" href=3D"mailto:oauth@ietf.org">oauth@ietf.org
Sent: Wednesday, June 29,= 2016 7:30 AM
Subjec= t: Re: [OAUTH-WG] Security concern for URI fragment as Implicit g= rant

> Shouldn=E2=80=99t it be more secure if we change to use a post method for access token, similar to the SAML does?=
I say yes. But please note I'm very new at this and someone with more experience will have more to say or correct my comments.
Here are a few more details to consider.
1) OAuth is a framework and not a standard, per se. Different authorization servers will have different implementations that are not necessarily compatible with other service providers. So there is no standard to break, per se.
2) Sensitive data in a URI is a bad idea. They leak all over the place even over HTTPS. Even in fragments.
3) Break the "rules" and find a way to submit sensitive data like access tokens, session information or any other (even short term) sensitive data in a secure fashion. This includes POST, JSON data payloads over PUT/PATCH and other verbs - all over well configured HTTPS.
4) If you really must submit sensitive data over GET , consider JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level confidentiality and integrity.
Aloha,
Jim Manico
Manicode Security
https://www.manicode.com

On 6/27/16 9:30 PM, Liyu Yi wrote:
While we are working on a project with OAuth2 implementation, one question arises from our engineers.
  
(C)  Assuming the resource owner grants access, the authorization
        server redirec= ts the user-agent back to the client using the
        redirection UR= I provided earlier.  The redirection URI includes
        the access tok= en in the URI fragment.
 
For my understanding, the browser keeps the URI fragment in the history, and this introduces unexpected exposure of the access token. A user without authorization for the resource can get the access token as long as he has the access to the browser. This can happen in a shared computer in library, or for an IT staff who works on other employee=E2=80=99s computer.
 
Shouldn=E2=80=99t it be more secure if we change to use a post method for access token, similar to the SAML does?
I feel there might be something I missed here. Any advices will be appreciated.


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


--=20



<= /blockquote>

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






= --Apple-Mail-749964E7-4190-4D88-AFDA-D18C5877F2E5-- From nobody Fri Jul 1 15:13:59 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A081E12B058 for ; Fri, 1 Jul 2016 15:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NUgO8d5xz2dF for ; Fri, 1 Jul 2016 15:13:53 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d: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 BC4A712D09C for ; Fri, 1 Jul 2016 15:13:52 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id t127so224750929qkf.1 for ; Fri, 01 Jul 2016 15:13:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=K+AMdw8YLzDm78KH4BdEyH8Gq6pBUrGxLjQ5yxc8044=; b=mFhD5ne3UCcmsuY95d7qxlculiRRlexokyITTENTFyv8izEm1aTbBA5FTuw9dV26hQ 0WN1kiZCLPLF0LtWo/g3rTN/Qt9O/96/t+PdZ2zvgzALylCVLJDAypQ+BuBbYeA9QPO8 Rf8/GFEIm4+8es69vT5YcDKqQALx/Sm1pP35L0shz7j2ygz6jw9rYn58+KTvhprbzPaL +g8xIjSo+3wgTCG5/cvh9gbYTHDl3FakDtYLuBO1G2RCpoIYT/61lWE/E6chRdcj32zF HlQA0acwaB0Ho5AE2BmS9WmndD5pScDJgIAB9KjAUpRts7+3PISI6nmwFN07NkA/yl6V n8hg== 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:date :message-id:subject:from:to:cc; bh=K+AMdw8YLzDm78KH4BdEyH8Gq6pBUrGxLjQ5yxc8044=; b=SRfsR0qpvOPPw3yHGTORGodFMT8b1pXgF0Gc5/YChpoQxyjvGH/mHnX4afdQNrH+pc HlO4ic0UhSqaqXNOZs2rVHPa9cJAPJ3zT74JOqhRxu7nWtAGAdHSyqvrJcy3kaMyOwzB 9RBSkjZgBQVHavRsgwLqiQlynlAcgehs4pecq8UJ3zZfGr7tjdrWsZB1m2TTfxjRdnMq g9wDJ7+Sgt5HxJlhrIwGUnIZhRxyMBwM61zAe6bner0HYjnjYjjX+sYVMt7zI0mVYE4L zej35UWIItuoqIG4nTp2xMzuNZwC5vkf429zcNeeQEx4yqEjdc6eIZuahQE2GsbL4fBx 3A4A== X-Gm-Message-State: ALyK8tJWvl0nbA/nT4/H4bDgPam9jiR70Nb/O9Aqd448tUl4OAmWVMFZmrG0CZWE6GqiWQciKoS2WW1CHMPTvA== MIME-Version: 1.0 X-Received: by 10.129.3.17 with SMTP id 17mr339077ywd.288.1467411231793; Fri, 01 Jul 2016 15:13:51 -0700 (PDT) Received: by 10.37.69.65 with HTTP; Fri, 1 Jul 2016 15:13:51 -0700 (PDT) Received: by 10.37.69.65 with HTTP; Fri, 1 Jul 2016 15:13:51 -0700 (PDT) In-Reply-To: <71CE61B3-FEC2-46A7-AB28-B53E89A8E53F@ve7jtb.com> References: <994121658.55005.1467329084208.JavaMail.yahoo@mail.yahoo.com> <235316006.458279.1467392709447.JavaMail.yahoo@mail.yahoo.com> <6584BD74-B18F-4174-9E69-5C7B4B76F895@ve7jtb.com> <410908395.555462.1467407397629.JavaMail.yahoo@mail.yahoo.com> <8CC41328-C26D-42C0-BFDB-BF0216C7B76C@ve7jtb.com> <71CE61B3-FEC2-46A7-AB28-B53E89A8E53F@ve7jtb.com> Date: Fri, 1 Jul 2016 18:13:51 -0400 Message-ID: From: Josh Mandel To: John Bradley Content-Type: multipart/alternative; boundary=001a1142d7be35fd2e05369a4df0 Archived-At: Cc: Oleg Gryb , "" , Liyu Yi Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 22:13:58 -0000 --001a1142d7be35fd2e05369a4df0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks John! Yes, we're following the CORS based flow you've described below (though I should note that the actual redirection back to the client could be a 302, or could be a simple Web link that the user follows from an authorization page; this is up to the authorization server). Overall I don't argue that this flow is "more secure" than the implicit flow -- though I believe it does help client developers avoid some common pitfalls. (For example, clients that, through careless programming or poor understanding of the spec, fail to validate incoming "state" are still not susceptible to arbitrary token injection, which means at least they won't readily be tricked into using a token designated for an entirely different client. With poorly written implicit flow clients, this is an issue.) That said, I wasn't aiming to discuss the relative security; just wanted to make sure I knew what you meant by "won't work well". Thanks again! -Josh On Jul 1, 2016 18:02, "John Bradley" wrote: > I am making a distinction between a browser talking to a Web server that > is acting as a OAuth Client POST response mode =3D good , and a oauth cli= ent > running in the browser user agent as a Java script application (that can= =E2=80=99t > directly capture a POST response back to the server) > > So it depends on where the client is actually running. > > Are you saying that you are using a 302 redirect from the authorization > endpoint back to the server hosting the JS and then loading the JS > including the code and then using CORES to exchange the code for a AT? > > You can do that but I don=E2=80=99t think a public client like that is mo= re secure > than just using the fragment encoded response and is more work. > It also may give the server a false sense of security. > > John B. > > On Jul 1, 2016, at 5:52 PM, Josh Mandel wrote: > > I think the confusion here is that I'm not using HEART's OAuth profiles := -) > > I'm using the SMART profiles, where we do specify the use of an > authorization code grant even for browser-based public clients (in which > case, no client_secret is issued or used). I'm just trying to understand > your perspective eon why this "won't work well". Perhaps you didn't mean > this comment to refer to browser-based OAuth clients generally? > > -Josh > > On Fri, Jul 1, 2016 at 5:45 PM, John Bradley wrote: > >> I don=E2=80=99t think the post response mode is supported by heart so I = suspect >> that we are talking about different things. >> >> You are probably using the supported code flow that uses a 302 get to >> return the code to the OAuth client on the server. >> The Web server is then acting as a confidential client to exchange the >> code via a POST (different POST) with the AS token_endpoint. >> >> The Token endpoint will return a access token (AT) and optional refresh >> token (RT). >> >> The web page may be getting the server to make the OAuth calls on it=E2= =80=99s >> behalf to the Resource Server, or possibly you are passing the AT from t= he >> server back to a Java script app that is using CORES to make calls direc= tly >> to the RS without going through the Web server. >> >> Passing the AT back to the user agent from the client is not recommended= . >> >> For in browser clients where the JS is using the AT to make the calls >> directly to the RS via CORES the recommended approach is to use the >> fragment encoded response via a 302 to deliver the AT directly to the >> client (It never hits the backend Web server). >> >> However I believe In browser OAuth clients are not currently supported i= n >> HEART, so I am not quite sure what you are doing. >> >> Perhaps Justin has a better answer. >> >> John B. >> >> >> On Jul 1, 2016, at 5:33 PM, Josh Mandel wrote: >> >> John, >> >> I appreciate your response. I'm hoping you can clarify why you say that >> "HTTP POST... won't work well for... [a] single page OAuth client"? >> >> We commonly build single-page apps that act as OAuth clients for SMART >> (e.g. this sample app >> ), >> and we've had good experience with the technique. Could you elaborate? >> >> -J >> >> On Fri, Jul 1, 2016 at 5:26 PM, John Bradley wrote: >> >>> HEART only supports web server clients at the moment. That might >>> change in future to support native apps if that an be made to support t= he >>> security requirements of Heath IT. >>> >>> So the thing HTTP POST responses won=E2=80=99t work well for is a type = of in >>> browser single page OAuth client. That still needs fragment encoded >>> responses or the new post-message Java Script API approach. >>> >>> John B. >>> >>> >>> On Jul 1, 2016, at 5:16 PM, Josh Mandel wrote: >>> >>> Thanks Justin, >>> >>> To clarify: John's comment and my question were about POST. (I do >>> understand the behavior of HTTP POST and of window.postMessage; these a= re >>> totally different things.) From my perspective in SMART Health IT, we u= se >>> the OAuth 2.0 authorization code flow, including HTTP POST, in our auth= orization >>> spec even for public >>> clients, and it has worked very well for us, with about a dozen electro= nic >>> health record servers supporting this approach. That's why I was curiou= s to >>> hear John's perspective about limitations. >>> >>> -J >>> >>> On Fri, Jul 1, 2016 at 5:09 PM, Oleg Gryb wrote: >>> >>>> > POST will send things to the server, which isn=E2=80=99t desirable i= f your >>>> client is solely in the browser >>>> Why it's not desirable, assuming that we disregard performance? You ca= n >>>> generate HTTP POST from JS, e.g. through an AJAX call. What is wrong w= ith >>>> this? >>>> >>>> >>>> ------------------------------ >>>> *From:* Justin Richer >>>> *To:* Josh Mandel >>>> *Cc:* Oleg Gryb ; "" ; >>>> Liyu Yi >>>> *Sent:* Friday, July 1, 2016 2:00 PM >>>> >>>> *Subject:* Re: [OAUTH-WG] Security concern for URI fragment as >>>> Implicit grant >>>> >>>> POST will send things to the server, which isn=E2=80=99t desirable if = your >>>> client is solely in the browser. postMessage is a browser API and not = to be >>>> confused with HTTP POST. postMessage messages stay (or can stay) withi= n the >>>> browser, which is the intent here. >>>> >>>> =E2=80=94 Justin >>>> >>>> On Jul 1, 2016, at 4:56 PM, Josh Mandel wrote: >>>> >>>> John, >>>> >>>> Could you clarify what you mean by "POST doesn't really work"? Do you >>>> just mean that CORS support (e.g., http://caniuse.com/#feat=3Dcors) >>>> isn't universal, or something more? >>>> >>>> On Fri, Jul 1, 2016 at 4:51 PM, John Bradley wrote= : >>>> >>>> Yes but POST doesn't really work for in browser apps. >>>> >>>> If it is a server app it should be using the code flow with GET or POS= T >>>> as you like. >>>> >>>> If we do a post message based binding it will be targeted at in >>>> browser applications. >>>> >>>> John B. >>>> >>>> On Fri, Jul 1, 2016 at 4:42 PM, Liyu Yi wrote: >>>> >>>> BTW, I do not see any significant performance concerns for post. >>>> Parsing and executing the Javascript logic for post operation will be = on >>>> the client side, no extra server load is introduced. >>>> >>>> Plus post will remove the size restriction of the URL length. >>>> >>>> -- Liyu >>>> >>>> On Fri, Jul 1, 2016 at 1:35 PM, Liyu Yi wrote: >>>> >>>> Thanks for the great comments and advices. >>>> >>>> I think it is a good idea for the working group to revise the fragment >>>> part in the spec, since there might be public available tools already >>>> implemented this approach and people can end up with a solution with >>>> serious security loopholes. >>>> >>>> The re-append issue can be mitigate by a logic on Resource Server whic= h >>>> carefully re-writes/removes the fragment in any redirect, if the the >>>> redirect can not be avoided. >>>> >>>> -- Liyu >>>> >>>> >>>> On Fri, Jul 1, 2016 at 11:33 AM, John Bradley >>>> wrote: >>>> >>>> This behaviour started changing around 2011 >>>> >>>> From HTTP/1.1 >>>> See https://tools.ietf.org/html/rfc7231#section-7.1.2I >>>> f the Location value provided in a 3xx (Redirection) response do= es >>>> >>>> not have a fragment component, a user agent MUST process the >>>> redirection as if the value inherits the fragment component of the >>>> URI reference used to generate the request target (i.e., the >>>> redirection inherits the original reference's fragment, if any). >>>> >>>> For example, a GET request generated for the URI reference >>>> "http://www.example.org/~tim" might result in a 303 (See Other) >>>> response containing the header field: >>>> >>>> Location: /People.html#tim >>>> >>>> which suggests that the user agent redirect to >>>> "http://www.example.org/People.html#tim=E2=80=9D >>>> >>>> >>>> Likewise, a GET request generated for the URI reference >>>> "http://www.example.org/index.html#larry" might result in a 301 >>>> (Moved Permanently) response containing the header field: >>>> >>>> Location: http://www.example.net/index.html >>>> >>>> which suggests that the user agent redirect to >>>> "http://www.example.net/index.html#larry", preserving the original >>>> fragment identifier. >>>> >>>> >>>> >>>> This blog also explores the change. >>>> >>>> https://blogs.msdn.microsoft.com/ieinternals/2011/05/16/url-fragments-= and-redirects/ >>>> >>>> >>>> On Jul 1, 2016, at 1:05 PM, Oleg Gryb wrote: >>>> >>>> "Browsers now re-append fragments across 302 redirects unless they >>>> are explicitly cleared this makes fragment encoding less safe than it = was >>>> when originally specified" - thanks Jim. Looks like a good reason for >>>> vetting this flow out. >>>> >>>> John, >>>> Please provide more details/links about re-appending fragments. >>>> >>>> Thanks, >>>> Oleg. >>>> >>>> >>>> ------------------------------ >>>> *From:* Jim Manico >>>> *To:* Oleg Gryb >>>> *Cc:* "oauth@ietf.org" ; Liyu Yi >>>> *Sent:* Thursday, June 30, 2016 10:25 PM >>>> *Subject:* Re: [OAUTH-WG] Security concern for URI fragment as >>>> Implicit grant >>>> >>>> Oleg! Hello! Great to see you pop up here with a similar concern. >>>> >>>> John Bradley just answered this thread with the details I was looking >>>> for (thanks John, hat tip your way). >>>> >>>> He also mentioned details about fragment leakage: >>>> >>>> "Browsers now re-append fragments across 302 redirects unless they >>>> are explicitly cleared this makes fragment encoding less safe than it = was >>>> when originally specified" >>>> >>>> Again, I'm new here but I'm grateful for this conversation. >>>> >>>> Aloha, >>>> -- >>>> Jim Manico >>>> @Manicode >>>> >>>> On Jul 1, 2016, at 1:24 AM, Oleg Gryb wrote: >>>> >>>> We've discussed access tokens in URI back in 2010 ( >>>> https://www.ietf.org/mail-archive/web/oauth/current/msg04043.html). >>>> There were two major objectives when I was saying that it's not secure= : >>>> >>>> 1. Fragment is not sent to a server by a browser. When I've asked if >>>> this is true for every browser in the world, nobody was able to answer= . >>>> 2. Replacing with POST would mean a significant performance impact in >>>> some high volume implementations (I think it was Goole folks who were >>>> saying this, but I don't remember now). >>>> >>>> AFAIR, nobody was arguing about browsing history, so it's valid. >>>> >>>> So, 6 years later we're at square one with this and I hope that this >>>> time the community will be more successful with getting rid of secrets= in >>>> URL. >>>> >>>> BTW, Jim, if you can come up with other scenarios when fragments can >>>> leak, please share. It'll probably help the community with solving thi= s >>>> problem faster than in 6 years. >>>> >>>> Thanks, >>>> Oleg. >>>> >>>> >>>> ------------------------------ >>>> *From:* Jim Manico >>>> *To:* Liyu Yi ; oauth@ietf.org >>>> *Sent:* Wednesday, June 29, 2016 7:30 AM >>>> *Subject:* Re: [OAUTH-WG] Security concern for URI fragment as >>>> Implicit grant >>>> >>>> > Shouldn=E2=80=99t it be more secure if we change to use a post metho= d for >>>> access token, similar to the SAML does? >>>> I say yes. But please note I'm very new at this and someone with more >>>> experience will have more to say or correct my comments. >>>> Here are a few more details to consider. >>>> 1) OAuth is a framework and not a standard, per se. Different >>>> authorization servers will have different implementations that are not >>>> necessarily compatible with other service providers. So there is no >>>> standard to break, per se. >>>> 2) Sensitive data in a URI is a bad idea. They leak all over the place >>>> even over HTTPS. Even in fragments. >>>> 3) Break the "rules" and find a way to submit sensitive data like >>>> access tokens, session information or any other (even short term) sens= itive >>>> data in a secure fashion. This includes POST, JSON data payloads over >>>> PUT/PATCH and other verbs - all over well configured HTTPS. >>>> 4) If you really must submit sensitive data over GET , consider >>>> JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level >>>> confidentiality and integrity. >>>> Aloha, >>>> >>>> Jim Manico >>>> Manicode Securityhttps://www.manicode.com >>>> >>>> >>>> On 6/27/16 9:30 PM, Liyu Yi wrote: >>>> >>>> While we are working on a project with OAuth2 implementation, one >>>> question arises from our engineers. >>>> We noticed at >>>> >>>> https://tools.ietf.org/html/draft-ietf-oauth-v2-31#page-30, it is >>>> specified that >>>> >>>> (C) Assuming the resource owner grants access, the authorization >>>> server redirects the user-agent back to the client using the >>>> redirection URI provided earlier. The redirection URI include= s >>>> the access token in the URI fragment. >>>> >>>> For my understanding, the browser keeps the URI fragment in the >>>> history, and this introduces unexpected exposure of the access token. = A >>>> user without authorization for the resource can get the access token a= s >>>> long as he has the access to the browser. This can happen in a shared >>>> computer in library, or for an IT staff who works on other employee=E2= =80=99s >>>> computer. >>>> >>>> Shouldn=E2=80=99t it be more secure if we change to use a post method = for >>>> access token, similar to the SAML does? >>>> I feel there might be something I missed here. Any advices will be >>>> appreciated. >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/= oauth >>>> >>>> >>>> -- >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >> >> > > --001a1142d7be35fd2e05369a4df0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Thanks John! Yes, we're following the CORS based flow yo= u've described below (though I should note that the actual redirection = back to the client could be a 302, or could be a simple Web link that the u= ser follows from an authorization page; this is up to the authorization ser= ver).

Overall I don't argue that this flow is "more secur= e" than the implicit flow -- though I believe it does help client deve= lopers avoid some common pitfalls. (For example, clients that, through care= less programming or poor understanding of the spec, fail to validate incomi= ng "state" are still not susceptible to arbitrary token injection= , which means at least they won't readily be tricked into using a token= designated for an entirely different client. With poorly written implicit = flow clients, this is an issue.)

That said, I wasn't aiming to discuss the relative secur= ity; just wanted to make sure I knew what you meant by "won't work= well".

Thanks again!

-Josh

On Jul 1, 2016 18:02, "John Bradley" &= lt;ve7jtb@ve7jtb.com> wrote:
I am making a distinction between a browser talking to a Web = server that is acting as a OAuth Client POST response mode =3D good , and a= oauth client running in the browser user agent as a Java script applicatio= n (that can=E2=80=99t directly capture a POST response back to the server)<= div>
So it depends on where the client is actually running.

Are you saying that you are using a 302 redirect fr= om the authorization endpoint back to the server hosting the JS and then lo= ading the JS including the code and then using CORES =C2=A0to exchange the = code for a AT?

You can do that but I don=E2=80=99t= think a public client like that is more secure than just using the fragmen= t encoded response and is more work.
It also may give the server = a false sense of security.

John B.
On Jul 1, 2016, at 5:52 PM, Josh Mandel <jmandel@gmail.com> w= rote:

I think the confusion here is that I&#= 39;m not using HEART's OAuth profiles :-)

I'm us= ing the SMART profiles, where we do specify the use of an authorization cod= e grant even for browser-based public clients (in which case, no client_sec= ret is issued or used). I'm just trying to understand your perspective = eon why this "won't work well". Perhaps you didn't mean t= his comment to refer to browser-based OAuth clients generally?
=C2=A0 -Josh

On Fri, Jul 1, 2016 at 5:45 PM, John Bradley <ve7jtb@ve7jtb.= com> wrote:
I don=E2=80=99t think the post response mode is suppor= ted by heart so I suspect that we are talking about different things.
<= br>
You are probably using the supported code flow that uses a 30= 2 get to return the code to the OAuth client on the server. =C2=A0
The Web server is then acting as a confidential client to exchange the co= de via a POST (different POST) with the AS token_endpoint.

The Token endpoint will return a access token (AT) and optional re= fresh token (RT).

The web page may be getting the = server to make the OAuth calls on it=E2=80=99s behalf to the Resource Serve= r, or possibly you are passing the AT from the server back to a Java script= app that is using CORES to make calls directly to the RS without going thr= ough the Web server.

Passing the AT back to the us= er agent from the client is not recommended.=C2=A0

For in browser clients where the JS is using the AT to make the calls dire= ctly to the RS via CORES the recommended approach is to use the fragment en= coded response via a 302 to deliver the AT directly to the client (It never= hits the backend Web server).

However I believe I= n browser OAuth clients are not currently supported in HEART, so I am not q= uite sure what you are doing.

Perhaps Justin has a= better answer.

John B.


On Jul 1, 2016, at 5:33 PM= , Josh Mandel <jm= andel@gmail.com> wrote:

John,
I appreciate your response. I'm hoping you can clarify why = you say that "HTTP POST... won't work well for... [a] single page = OAuth client"?

We commonly build single-page apps t= hat act as OAuth clients for SMART (e.g. this sample app=C2=A0), and we've had good ex= perience with the technique. Could you elaborate?

= =C2=A0 -J

On F= ri, Jul 1, 2016 at 5:26 PM, John Bradley <ve7jtb@ve7jtb.com>= wrote:
HEART only supports web server clients at the moment. =C2=A0 That might = change in future to support native apps if that an be made to support the s= ecurity requirements of Heath IT.

So the thing HTTP POST respo= nses won=E2=80=99t work well for is a type of in browser single page OAuth = client.=C2=A0 That still needs fragment encoded responses or the new post-m= essage Java Script API approach.

John B.


On Jul 1,= 2016, at 5:16 PM, Josh Mandel <jmandel@gmail.com> wrote:

Thanks Justin,

To clarify: John's comment and my= question were about POST. (I do understand the behavior of HTTP POST and o= f window.postMessage; these are totally different things.) From my perspect= ive in SMART Health IT, we use the OAuth 2.0 authorization code flow, inclu= ding HTTP POST, in our authorization spec=C2=A0even for public clients,= and it has worked very well for us, with about a dozen electronic health r= ecord servers supporting this approach. That's why I was curious to hea= r John's perspective about limitations.

=C2=A0= -J

On Fri, = Jul 1, 2016 at 5:09 PM, Oleg Gryb <oleg_gryb@yahoo.com> wr= ote:
> POST will send things to the server, = which isn=E2=80=99t desirable if your client is solely in the browser
=
Why it's not desirable, assuming that we disreg= ard performance? You can generate HTTP POST from JS, e.g. through an AJAX c= all. What is wrong with this?

<= hr size=3D"1"> From: Justin = Richer <jricher@mit= .edu>
To: Josh Ma= ndel <jmandel@gma= il.com>
Cc: Oleg = Gryb <oleg@gryb.info= >; "<oau= th@ietf.org>" <oauth@ietf.org>; Liyu Yi <liyuyi@gmail.com>
Sent: Friday, July 1, 2016 2:00 PM

= Subject: Re: [OAUTH-WG] Securit= y concern for URI fragment as Implicit grant
=

POST will send things to the server, which is= n=E2=80=99t desirable if your client is solely in the browser. postMessage = is a browser API and not to be confused with HTTP POST. postMessage message= s stay (or can stay) within the browser, which is the intent here.

=C2=A0=E2=80=94 Justin

On Jul 1, 2016, at 4:56 PM, J= osh Mandel <jmandel@gmail.com> wrote:

John,

Could you clarify what yo= u mean by "POST doesn't really wo= rk"? Do you just mean that CORS support (e.g.,=C2=A0http://caniuse.com/#feat=3Dcors) isn't universal, or something mor= e?

On Fri, Jul 1, 2016 at 4:51 PM,= John Bradley <ve7jtb@ve7jtb.com> wrote:
Yes but POST doesn= 't really work for in browser apps.

I= f it is a server app it should be using the code flow with GET or POST as y= ou like.

If we do a =C2=A0post mess= age based binding it will be targeted at in browser applications.

John B.

<= div>On Fri, Jul 1, 2016 at 4:42 PM, Liyu Yi <liyuyi@gmail.com> wrote:
BTW, I do not see any significant performance concerns for post. = Parsing and executing the Javascript logic for post operation will be on th= e client side, no extra server load is introduced.

<= /div>
Plus post will remove the size restriction of the URL length.

-- Liyu=C2=A0

On Fr= i, Jul 1, 2016 at 1:35 PM, Liyu Yi <liyuyi@= gmail.com> wrote:
Thanks for the great comments and advices.

I think it is a good idea for the working group to revise the frag= ment part in the spec, since there might be public available tools already = implemented this approach and people can end up with a solution with seriou= s security loopholes.

The re-append issue= can be mitigate by a logic on Resource Server which carefully re-writes/re= moves the fragment in any redirect, if the the redirect can not be avoided.=

<= /div>
-- Liyu
=C2=A0

On Fri, Jul 1, 2016 at 11:33 AM, John Bradle= y <ve7jtb@ve7jtb.com> wrote:=
This behavi= our started changing around 2011

From HTT= P/1.1
=C2=A0 =C2=A0 =C2= =A0 f the Location value provided in a 3xx (Redirection) response does
   not have a fragment component, a user agent MUST pro=
cess the
   redirection as if the value inherits the fragment component of the
   URI reference used to generate the request target (i.e., the
   redirection inherits the original reference's fragment, if any).

   For example, a GET request generated for the URI reference
   "http://www.example.org/~tim" might result =
in a 303 (See Other)
   response containing the header field:

     Location: /People.html#tim

   which suggests that the user agent redirect to
   "http://www.example.org/People.html#tim=E2=80=9D

   L=
ikewise, a GET request generated for the URI reference
   "http://www.example.org/index.html#larry=
" might result in a 301
   (Moved Permanently) response containing the header field:

     Location: http://www.example.net/index.html

   which suggests that the user agent redirect to
   "http://www.example.net/index.html#larry=
", preserving the original
   fragment identifier.


This blog also explores the change.


On Jul 1, 2016, at 1:05 PM, Oleg Gryb <ole= g_gryb@yahoo.com> wrote:

"Browsers now re-append =C2=A0fragments across 302 redirects unle= ss they are explicitly cleared this makes fragment encoding less safe than = it was =C2=A0when originally specified" - thanks Jim. Looks like a goo= d reason for vetting this flow out.

John,
Please provide more details/links about re-ap= pending fragments.=C2=A0

Thanks,
Oleg.


=
From: Jim M= anico <jim@manicode.com>
To: Oleg Gryb <oleg@gryb.i= nfo>
Cc: "oauth@ietf.org" <oauth@ietf.org<= /a>>; Liyu Yi <liyuyi@gmail.com>
= Sent: Thursday, June 30, 20= 16 10:25 PM
Subject:= Re: [OAUTH-WG] Security concern for URI fragment as Implicit gr= ant

Oleg!= Hello! Great to see you pop up here with a similar concern.

John Bradley just answered this thread with the d= etails I was looking for (thanks John, hat tip your way).

He also mentioned details about fragment leakage:

"Browsers now re-append = =C2=A0fragments across 302 redirects unless they are explicitly cleared thi= s makes fragment encoding less safe than it was when originally specified&q= uot;

Again, I'm new here= but I'm grateful for this conversation.

<= /div>
Aloha,
--
Jim Manico
@Manicode=

On Jul 1, 2016, at 1:24 AM, Oleg G= ryb <oleg_gryb@yahoo.com> wrote:
=
We've discusse= d access tokens in URI back in 2010 (https://www.ietf.org/mail-archive/web/oauth/current/m= sg04043.html). There were two major objectives when I was saying that i= t's not secure:

1. Fragment is not sent to a server by a browser. When I've as= ked if this is true for every browser in the world, nobody was able to answ= er.
2. Replacing with POST would mean a significant p= erformance impact in some high volume implementations (I think it was Goole= folks who were saying this, but I don't remember now).

AFAIR, nobody was arguin= g about browsing history, so it's valid.

So, 6 years later we're at square one= with this and I hope that this time the community will be more successful = with getting rid of secrets in URL.

BTW, Jim, if you can come up with other scenarios = when fragments can leak, please share. It'll probably help the communit= y with solving this problem faster than in 6 years.
<= br clear=3D"none">
Thanks,
Oleg= .


<= span style=3D"font-weight:bold">From: Jim Manico <= jim@manicode.com>
To: Liyu Yi <liyuyi@gmail.com>; oauth@ietf.org
Sent: Wednesday, June 29, 2016 7:30 AM
= Subject: Re: [OAUTH-WG] Securit= y concern for URI fragment as Implicit grant

> Shouldn=E2=80=99t it be more secure if we change to use a post method for access token, similar to the SAML does?
I say yes. But please note I'm very new at this and someone wi= th more experience will have more to say or correct my comments.
Here are a few more details to consider.
1) OAuth is a framework and not a standard, per se. Different authorization servers will have different implementations that are not necessarily compatible with other service providers. So there is no standard to break, per se.
2) Sensitive data in a URI is a bad idea. They leak all over the place even over HTTPS. Even in fragments.
3) Break the "rules" and find a way to submit sensitive = data like access tokens, session information or any other (even short term) sensitive data in a secure fashion. This includes POST, JSON data payloads over PUT/PATCH and other verbs - all over well configured HTTPS.
4) If you really must submit sensitive data over GET , consider JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level confidentiality and integrity.
Aloha,
Jim Manico
Manicode Security
https://www.manicode.com

On 6/27/16 9:30 PM, Liyu Yi wrote:
While we are working on a project with OAuth2 implementation, one question arises from our engineers.
=C2=A0=C2=A0
(C)=C2=A0 Assuming the resource owner grants access, the authorization
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 server redire= cts the user-agent back to the client using the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 redirection U= RI provided earlier.=C2=A0 The redirection URI includes
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the access to= ken in the URI fragment.
=C2=A0
For my understanding, the browser keeps the URI fragment in the history, and this introduces unexpected exposure of the access token. A user without authorization for the resource can get the access token as long as he has the access to the browser. This can happen in a shared computer in library, or for an IT staff who works on other employee=E2=80=99s computer.
=C2=A0
Shouldn=E2=80=99t it be more secure if we change to use a post method for access token, similar to the SAML does?
I feel there might be something I missed here. Any advices will be appreciated.


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


--=20




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


=





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


_______________________________________________
OAuth mai= ling list
OAuth@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">ht= tps://www.ietf.org/mailman/listinfo/oauth


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



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



--001a1142d7be35fd2e05369a4df0-- From nobody Fri Jul 1 15:44:42 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5C6F12B022 for ; Fri, 1 Jul 2016 15:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.145 X-Spam-Level: X-Spam-Status: No, score=-4.145 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 uBUFyZ-bpjxS for ; Fri, 1 Jul 2016 15:44:37 -0700 (PDT) Received: from nm16.bullet.mail.bf1.yahoo.com (nm16.bullet.mail.bf1.yahoo.com [98.139.212.175]) (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 5228912B00F for ; Fri, 1 Jul 2016 15:44:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1467413076; bh=1qRuELtmFvpR+HxjvEFrl6V4fg6q/LwvyUT3aPJL88o=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=aAcPMkikn6K/mcocxiqj9bNzby35jNysuiqre2z/a09uezXjT9zPUJlomsEW7vVBkzXCL7KZu2pwtgQJneqFs/quZeA5MJR5pa/gGRKt+a+RNifVWzqUH8TU86GyH2m4RFn687zFlOHT3kIDlKd0ldmzNWiTmTY7xvGEhl37/axvx5FRjTzAanzcdL7cbz/kxun8JEVLk20LloSZrZOjK/W1Rg4OOybvXKMC1smHUlG9mODmzDksUe0ogzEBf5p3+OQaV9WvwIKOO47zZ1JKMQwEWDrbALdmKhjy9zU5//0L4yv/CxWaKDBPJxvKFq1rR5cBt6YzXY62vYkUIDiFLQ== Received: from [66.196.81.170] by nm16.bullet.mail.bf1.yahoo.com with NNFMP; 01 Jul 2016 22:44:36 -0000 Received: from [98.139.215.249] by tm16.bullet.mail.bf1.yahoo.com with NNFMP; 01 Jul 2016 22:44:36 -0000 Received: from [127.0.0.1] by omp1062.mail.bf1.yahoo.com with NNFMP; 01 Jul 2016 22:44:36 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 28617.26987.bm@omp1062.mail.bf1.yahoo.com X-YMail-OSG: Xqai.yQVM1lPjNqhEpoQ0Lb2vGq67_Kf2EPDCflYtZ9iUysIbXQj7jeZWnUusci U5lJU.MrXC.TKPsJLYldh.1N4aPRjf2FrWtOX2iiBacsYM6z2Pk.aeNJqR4hyYJNmbVWFZuL_ph7 gfAt4NqAJ16gIn7xI.B1OL56qRxcPaWoAx4BKPEuBMQ7Z0B7YDHTIM2r4hAuK7r1utiQe529lwUo eO2IV02tmUwM4GxpR4l140UgYHFT720.VOWVCp_M5hSrhcl2U_Lvh_OmUgsok67qizanD6AVOdqM WfcVrYO3ky7TeTKYoOgJ.Pm.wDz0E2eFXicuxP.pNyELNKngqujwEyD21_LlBsqWcf91k.UpVAG0 liwwOB7I_3OEfWqTCatpa8kg_NwdMv1td9tQM7dwPI04xbs3V.i04DiTNbnpkOzWbgmMXhczADn8 QTRfq2qSCDuO.st3aYMYSb11XDT93vI2QOb.ctXjUK.jk2Brj4l6_ZUOpx6FW4DqNfLaJdS9bjfr _FAoPYmowHPVKzzQZOilR9H.uosE- Received: from jws10684.mail.bf1.yahoo.com by sendmailws147.mail.bf1.yahoo.com; Fri, 01 Jul 2016 22:44:35 +0000; 1467413075.539 Date: Fri, 1 Jul 2016 22:44:35 +0000 (UTC) From: Oleg Gryb To: John Bradley , Oleg Gryb Message-ID: <2041922420.584649.1467413075182.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <65E833F7-E277-4F7D-AB1B-B5B61B91BE5B@ve7jtb.com> References: <994121658.55005.1467329084208.JavaMail.yahoo@mail.yahoo.com> <235316006.458279.1467392709447.JavaMail.yahoo@mail.yahoo.com> <6584BD74-B18F-4174-9E69-5C7B4B76F895@ve7jtb.com> <717734404.555393.1467406368492.JavaMail.yahoo@mail.yahoo.com> <65E833F7-E277-4F7D-AB1B-B5B61B91BE5B@ve7jtb.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_584648_127824622.1467413075164" Archived-At: Cc: "oauth@ietf.org" , Liyu Yi Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Oleg Gryb List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 22:44:40 -0000 ------=_Part_584648_127824622.1467413075164 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm aware about exploits related to improper redirect_url validation, which= was FB case, no qs here,=C2=A0 but I still can't understand if appending a= fragment to Location by a browser makes this exploit simpler or can lead t= o other exploits that have not been described yet. =20 From: John Bradley To: Oleg Gryb =20 Cc: "oauth@ietf.org" ; Liyu Yi Sent: Friday, July 1, 2016 2:21 PM Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit gran= t =20 If the attacker can modify the redirect URI to anything like an embedded ad= d that will do a 302 redirect then the recipient of the redirect can load J= S to extract the access token. This has happened at Facebook so many times I have lost count. =C2=A0 It is= not theoretical, it happens all the time.One reason you need to do exact r= edirect_uri matching in the AS but people are not so good at following that= and take redirects to any URI on the host in some cases. When used correctly for a real in web client it is fine. =C2=A0For a web se= rver client it introduces unnecessary risks over the code flow, or hybrid f= low using POST. Others may differ with my opinion. John B. On Jul 1, 2016, at 4:52 PM, Oleg Gryb wrote: John, Thanks, very useful. However, I'm still trying to figure out why it's dange= rous. Fragment doesn't travel to a server in this new flow either. Appendin= g it to Location header is done by the browser who needs to memorize what t= he original request was. If the original request had a fragment and the bro= wser got redirected, Location header will be appended by the browser. Are you saying that this is dangerous because the browser would *always* ne= ed to store the fragment somewhere in its memory just in case if a server d= ecides to redirect? So an attack vector here is that an imposter can try to retrieve the fragme= nt from the browser's memory somehow. Is my understanding correct? Oleg. =20 From: John Bradley To: Oleg Gryb =20 Cc: "oauth@ietf.org" ; Liyu Yi Sent: Friday, July 1, 2016 11:33 AM Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit gran= t =20 This behaviour started changing around 2011 >From HTTP/1.1See=C2=A0https://tools.ietf.org/html/rfc7231#section-7.1.2I=C2= =A0 =C2=A0 =C2=A0 f the Location value provided in a 3xx (Redirection) resp= onse does not have a fragment component, a user agent MUST process the redirection as if the value inherits the fragment component of the URI reference used to generate the request target (i.e., the redirection inherits the original reference's fragment, if any). For example, a GET request generated for the URI reference "http://www.example.org/~tim" might result in a 303 (See Other) response containing the header field: Location: /People.html#tim which suggests that the user agent redirect to "http://www.example.org/People.html#tim=E2=80=9D Likewise, a GET request generated for the URI reference "http://www.example.org/index.html#larry" might result in a 301 (Moved Permanently) response containing the header field: Location: http://www.example.net/index.html which suggests that the user agent redirect to "http://www.example.net/index.html#larry", preserving the original fragment identifier. This blog also explores the change.https://blogs.msdn.microsoft.com/ieinter= nals/2011/05/16/url-fragments-and-redirects/ On Jul 1, 2016, at 1:05 PM, Oleg Gryb wrote: "Browsers now re-append =C2=A0fragments across 302 redirects unless they ar= e explicitly cleared this makes fragment encoding less safe than it was =C2= =A0when originally specified" - thanks Jim. Looks like a good reason for ve= tting this flow out. John,Please provide more details/links about re-appending fragments.=C2=A0 Thanks,Oleg. =20 From: Jim Manico To: Oleg Gryb =20 Cc: "oauth@ietf.org" ; Liyu Yi Sent: Thursday, June 30, 2016 10:25 PM Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit gran= t =20 Oleg! Hello! Great to see you pop up here with a similar concern. John Bradley just answered this thread with the details I was looking for (= thanks John, hat tip your way). He also mentioned details about fragment leakage: "Browsers now re-append =C2=A0fragments across 302 redirects unless they ar= e explicitly cleared this makes fragment encoding less safe than it was whe= n originally specified" Again, I'm new here but I'm grateful for this conversation. Aloha,--Jim Manico@Manicode On Jul 1, 2016, at 1:24 AM, Oleg Gryb wrote: We've discussed access tokens in URI back in 2010 (https://www.ietf.org/mai= l-archive/web/oauth/current/msg04043.html). There were two major objectives= when I was saying that it's not secure: 1. Fragment is not sent to a server by a browser. When I've asked if this i= s true for every browser in the world, nobody was able to answer.2. Replaci= ng with POST would mean a significant performance impact in some high volum= e implementations (I think it was Goole folks who were saying this, but I d= on't remember now). AFAIR, nobody was arguing about browsing history, so it's valid. So, 6 years later we're at square one with this and I hope that this time t= he community will be more successful with getting rid of secrets in URL. BTW, Jim, if you can come up with other scenarios when fragments can leak, = please share. It'll probably help the community with solving this problem f= aster than in 6 years. Thanks,Oleg. =20 From: Jim Manico To: Liyu Yi ; oauth@ietf.org=20 Sent: Wednesday, June 29, 2016 7:30 AM Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit gran= t =20 > Shouldn=E2=80=99t it be more secure if we change to use a post method fo= r access token, similar to the SAML does? I say yes. But please note I'm ve= ry new at this and someone with more experience will have more to say or co= rrect my comments. Here are a few more details to consider. 1) OAuth is a framework and not a standard, per se. Different authorizati= on servers will have different implementations that are not necessarily com= patible with other service providers. So there is no standard to break, per= se. 2) Sensitive data in a URI is a bad idea. They leak all over the place ev= en over HTTPS. Even in fragments. 3) Break the "rules" and find a way to submit sensitive data like access = tokens, session information or any other (even short term) sensitive data i= n a secure fashion. This includes POST, JSON data payloads over PUT/PATCH a= nd other verbs - all over well configured HTTPS. 4) If you really must submit sensitive data over GET , consider JWT/JWS/J= WE (with limited scopes/lifetimes) to provide message level confidentiality= and integrity. Aloha, Jim Manico Manicode Security https://www.manicode.com=20 On 6/27/16 9:30 PM, Liyu Yi wrote: =20 While we are working on a project with OAuth2 implementation, one questio= n arises from our engineers. We noticed at https://tools.ietf.org/html/draf= t-ietf-oauth-v2-31#page-30, it is specified that =C2=A0=C2=A0 (C)=C2=A0 Ass= uming the resource owner grants access, the authorization =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 server redirects the user-agent back to the cli= ent using the =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 redirection URI pr= ovided earlier.=C2=A0 The redirection URI includes =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 the access token in the URI fragment. =C2=A0 For my unde= rstanding, the browser keeps the URI fragment in the history, and this intr= oduces unexpected exposure of the access token. A user without authorizati= on for the resource can get the access token as long as he has the access t= o the browser. This can happen in a shared computer in library, or for an I= T staff who works on other employee=E2=80=99s computer. =C2=A0 Shouldn=E2= =80=99t it be more secure if we change to use a post method for access toke= n, similar to the SAML does? I feel there might be something I missed here.= Any advices will be appreciated. =20 =20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 =20 --=20 =20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 =20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 =20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 =20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 ------=_Part_584648_127824622.1467413075164 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm aware about expl= oits related to improper redirect_url validation, which was FB case, no qs = here,  but I still can't understand if appending a fragment to Locatio= n by a browser makes this exploit simpler or can lead to other exploits tha= t have not been described yet.


From: John Bradley <ve7jtb@ve7jtb.com>
To: Oleg Gryb <oleg@gryb.info> <= br>Cc: "oauth@ietf.org" &l= t;oauth@ietf.org>; Liyu Yi <liyuyi@gmail.com>
Sent: Friday, July 1, 2016 = 2:21 PM
Subject: Re: [= OAUTH-WG] Security concern for URI fragment as Implicit grant
 <= /div>

If the attacker can modify the redirect URI to anything like an= embedded add that will do a 302 redirect then the recipient of the redirec= t can load JS to extract the access token.

This has happened at Facebook so many times I have lost coun= t.   It is not theoretical, it happens all the time.
One reason yo= u need to do exact redirect_uri matching in the AS but people are not so go= od at following that and take redirects to any URI on the host in some case= s.

When used correctly for a real in w= eb client it is fine.  For a web server client it introduces unnecessa= ry risks over the code flow, or hybrid flow using POST.

Others may differ with my opinion.

John B.

On Jul 1,= 2016, at 4:52 PM, Oleg Gryb <oleg_gryb@yahoo.com> wrote:
John,

Thanks, very useful. However, I'm still trying to figure out why it's dang= erous. Fragment doesn't travel to a server in this new flow either. Appendi= ng it to Location header is done by the browser who needs to memorize what = the original request was. If the original request had a fragment and the br= owser got redirected, Location header will be appended by the browser.

Are= you saying that this is dangerous because the browser would *always* need = to store the fragment somewhere in its memory just in case if a server deci= des to redirect?

So an attack vector here is that an imposter can try to r= etrieve the fragment from the browser's memory somehow. Is my understanding= correct?

=
Oleg.


<= hr class=3D"yiv4314045269" id=3D"yiv4314045269yui_3_16_0_ym19_1_14674057323= 10_4310" size=3D"1"> From: John Bradley <ve7jtb@ve7jt= b.com>
To: Oleg Gryb <oleg@gryb.info>
Cc: "oauth@ietf.org" <oauth@ietf.org>; Liyu Yi <<= a rel=3D"nofollow" shape=3D"rect" class=3D"yiv4314045269" ymailto=3D"mailto= :liyuyi@gmail.com" target=3D"_blank" href=3D"mailto:liyuyi@gmail.com">liyuy= i@gmail.com>
Se= nt: Friday, July 1, 2016 11:33 AM
Subject: Re: [OAUTH-WG] Security concern = for URI fragment as Implicit grant

This behaviour started changing around 2011

From HTTP/1.1
= See http= s://tools.ietf.org/html/rfc7231#section-7.1.2I
      f the Location value provided in a 3xx (Redirec= tion) response does
   not have a fragment component, a user agent MUST process the
   redirection as if the value inherits the fragment component of the
   URI reference used to generate the request target (i.e., the
   redirection inherits the original reference's fragment, if any).

   For example, a GET request generated for the URI reference
   "http://www.example.org/~tim"=
 might result in a 303 (See Other)
   response containing the header field:

     Location: /People.html#tim

   which suggests that the user agent redirect to
   "http://www.example.or=
g/People.html#tim=E2=80=9D

   =
Likewise, a GET request generated for the URI reference
   "http://www.example.o=
rg/index.html#larry" might result in a 301
   (Moved Permanently) response containing the header field:

     Location: http://www.exam=
ple.net/index.html

   which suggests that the user agent redirect to
   "http://www.example.n=
et/index.html#larry", preserving the original
   fragment identifier.


This blog also explores the= change.
https://blo= gs.msdn.microsoft.com/ieinternals/2011/05/16/url-fragments-and-redirects/


On Jul 1, 2016, at 1:05 PM, Oleg Gry= b <oleg_gryb@yahoo.com> wrote:

"Browsers now re-append  fragments across 302 redirects un= less they are explicitly cleared this makes fragment encoding less safe tha= n it was  when originally specified" - thanks Jim. Looks like a good r= eason for vetting this flow out.

= John,
Please provide more details/links about re-ap= pending fragments. 

Than= ks,
Oleg.


= From: Jim Manico <jim@manicode.com>
To: Oleg Gryb <oleg@gryb.in= fo>
Cc:<= /b> "oau= th@ietf.org" <oauth@ietf.org>; Liyu Yi <liyuyi@gmail.com>
Sent: Thursday,= June 30, 2016 10:25 PM
Subject: Re: [OAUTH-WG] Security concern for URI fragment as I= mplicit grant

Oleg! Hello! Great = to see you pop up here with a similar concern.

John Bradley just answered this thread with the details I was l= ooking for (thanks John, hat tip your way).

He also mentioned details about fragment leakage:

"Browsers now re-append &nb= sp;fragments across 302 redirects unless they are explicitly cleared this m= akes fragment encoding less safe than it was when originally specified"

Again, I'm new here but I'm gra= teful for this conversation.

Aloha,=
<= div class=3D"yiv4314045269" id=3D"yiv4314045269yui_3_16_0_ym19_1_1467392120= 814_3607">--
Jim Manico
@Manicode

On Jul 1, 2016, at 1:24= AM, Oleg Gryb <oleg_gryb@yahoo.com> wrote:

We've discussed access tokens i= n URI back in 2010 (https://www.ietf.org/mail-archive/web/oauth/current/msg04043.ht= ml). There were two major objectives when I was saying that it's not se= cure:

1. Fragment is not sent to a server by a bro= wser. When I've asked if this is true for every browser in the world, nobod= y was able to answer.
2. Replacing with POST wo= uld mean a significant performance impact in some high volume implementatio= ns (I think it was Goole folks who were saying this, but I don't remember n= ow).

AFAIR, nobody was arguing about browsing hist= ory, so it's valid.

So, 6 years later we're at squ= are one with this and I hope that this time the community will be more succ= essful with getting rid of secrets in URL.

BTW, Ji= m, if you can come up with other scenarios when fragments can leak, please = share. It'll probably help the community with solving this problem faster t= han in 6 years.

Thanks,
Oleg.


From: Jim Manico <jim@manicode.com>
To: Liyu Yi <liyuyi@gmail.com>; oauth@ietf.org
Sent: Wednesday, June 29, = 2016 7:30 AM
Subject: Re: [OAUTH-WG] Security c= oncern for URI fragment as Implicit grant

> Shouldn=E2=80=99t it be more secure if we c= hange to use a post method for access token, similar to the SAML does?
I say yes. But please note I'm very new at this and someone = with more experience will have more to say or correct my comments.
Here are a few more details to consider.
1) OAuth is a framework and not a standard, per se. Differen= t authorization servers will have different implementations that are not necessarily compatible with other service providers. So there is no standard to break, per se.
2) Sensitive data in a URI is a bad idea. = They leak all over the place even over HTTPS. Even in fragments.
3) Break the "rules" and find a way to sub= mit sensitive data like access tokens, session information or any other (even short term) sensitive data in a secure fashion. This includes POST, JSON data payloads over PUT/PATCH and other verbs - all over well configured HTTPS.
4) If you really must submit sensitive dat= a over GET , consider JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level confidentiality and integrity.
Aloha,
Jim Manico
Manicode Security
https://www.manic=
ode.com

=
On 6/27/16 9:30 PM, Liyu Yi wro= te:
While we= are working on a project with OAuth2 implementation, one question arises from our engineers.
We notic= ed at https://tools.iet= f.org/html/draft-ietf-oauth-v2-31#page-30, it is specified that
  
(C) = ; Assuming the resource owner grants access, the authorization
 &n= bsp;      server redirects the user-agent back to the client using the
 &n= bsp;      redirection URI provided earlier.  The redirection URI includes
 &n= bsp;      the access token in the URI fragment.
 
For my u= nderstanding, the browser keeps the URI fragment in the history, and this introduces unexpected exposure of the access token. A user without authorization for the resource can get the access token as long as he has the access to the browser. This can happen in a shared computer in library, or for an IT staff who works on other employee=E2=80=99s computer.
 
Shouldn= =E2=80=99t it be more secure if we change to use a post method for access token, similar to the SAML does?
I feel t= here might be something I missed here. Any advices will be appreciated.


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


--=20

______________________= _________________________
OAuth m= ailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



_______________________________________________
OAuth mailing list
OAuth@ietf.org
<= a rel=3D"nofollow" shape=3D"rect" class=3D"yiv4314045269" target=3D"_blank"= href=3D"https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.org/= mailman/listinfo/oauth
=


=

______________________________= _________________
OAuth mailing l= ist
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




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


------=_Part_584648_127824622.1467413075164-- From nobody Fri Jul 1 15:49:48 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8C0512D740 for ; Fri, 1 Jul 2016 15:49:46 -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 y4qohgoREYKM for ; Fri, 1 Jul 2016 15:49:43 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCA5112B065 for ; Fri, 1 Jul 2016 15:49:42 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id f89so64626453qtd.2 for ; Fri, 01 Jul 2016 15:49:42 -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=mIq/qjQNfL13PIUKwStEJPN4fggGwzqzpn70zTTE42I=; b=ZqVQMkjgsDLbxTI3Zg5iH7ATEALt0FtIhwTfJ1QM7+fGLimQaU00KzhpJw4o0Fq4yj Nv3GiEQs9zUnltzROV6T/Ss0IEqouuwbKOlMivC4SB+NVjVVq26RnCDWZOFwfOuMhG8D j6kRdGH9+c6X1cQLedlqWmw/hB6QZMvA1I+EHlUa3qb5CWtOxkiBnNWMfqJhSohBZ0H7 o5uFgpTMSP53V6ioirFnpGqpTCuh3ssjJkSGWjI8DYZHCQmQ9unF1Icz1cSYrhELlRW+ Yf/hj1TvcJ56u/SwvuOxlMyHAneysuTvI/sYQYr45Vq2/OG/4kBko7L4N1w8F9l2p6/x FW8g== 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=mIq/qjQNfL13PIUKwStEJPN4fggGwzqzpn70zTTE42I=; b=Ih1bBdWx3k9wBvodGuwKkbnrZeDTNgP19UElMHSI+fsnnBgahGDQ/YZML49/vmaE00 BoBpVBMcv/sG53oSYCiimo9njXUIKccDFlBLbVWu5ZK9LGkeHxUelIcE62V+lJu3bjik YkEjZQHNrOe9YtuSHdWYP3o8ypld9yXxM6J0ufnupQoixS2cxozaHMVAVsqilKizwrKR 0/HT/MXLyFo/y0xaR7M4Tk9SRl7gZfkA7Kn1x2B763tWOkjl5zzpS6IKEGAZDIPcPHqA RLwXIaqPtQE2IiyN1P6i1h5hXoN6mJxoRQUrKEM+Vm8tC2iqnInb1pQ31AQtU64h8Ut6 CeqQ== X-Gm-Message-State: ALyK8tI/Qz3vitHdDI20+qfl4ZCwqC2DCBMW2dPSRlPMDlPBgQ3O3RxSufu9c/I5yhCaH/Iv X-Received: by 10.200.54.110 with SMTP id n43mr1087441qtb.47.1467413381603; Fri, 01 Jul 2016 15:49:41 -0700 (PDT) Received: from [192.168.1.41] ([191.115.51.34]) by smtp.gmail.com with ESMTPSA id k63sm1834134qte.9.2016.07.01.15.49.05 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 01 Jul 2016 15:49:41 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_34FB13DA-1E4E-4889-8702-1512FF9AF5C1" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: John Bradley In-Reply-To: Date: Fri, 1 Jul 2016 18:48:35 -0400 Message-Id: <730B8A93-2537-4204-881E-039D71C5D393@ve7jtb.com> References: <994121658.55005.1467329084208.JavaMail.yahoo@mail.yahoo.com> <235316006.458279.1467392709447.JavaMail.yahoo@mail.yahoo.com> <6584BD74-B18F-4174-9E69-5C7B4B76F895@ve7jtb.com> <410908395.555462.1467407397629.JavaMail.yahoo@mail.yahoo.com> <8CC41328-C26D-42C0-BFDB-BF0216C7B76C@ve7jtb.com> <71CE61B3-FEC2-46A7-AB28-B53E89A8E53F@ve7jtb.com> To: Josh Mandel X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Oleg Gryb , "" , Liyu Yi Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 22:49:47 -0000 --Apple-Mail=_34FB13DA-1E4E-4889-8702-1512FF9AF5C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 If the in browser JS checks that it is talking to the correct AS making = a authorization request that is no worse that making a request to = exchange code via CORS. Attacks where code is stolen and replayed to = the client to impersonate the user are also possable That is the reason = for the id_token with signed nonce, as state can be manipulated in some = cases as it is not signed.=20 That is a different discussion however. John B. > On Jul 1, 2016, at 6:13 PM, Josh Mandel wrote: >=20 > Thanks John! Yes, we're following the CORS based flow you've described = below (though I should note that the actual redirection back to the = client could be a 302, or could be a simple Web link that the user = follows from an authorization page; this is up to the authorization = server). >=20 > Overall I don't argue that this flow is "more secure" than the = implicit flow -- though I believe it does help client developers avoid = some common pitfalls. (For example, clients that, through careless = programming or poor understanding of the spec, fail to validate incoming = "state" are still not susceptible to arbitrary token injection, which = means at least they won't readily be tricked into using a token = designated for an entirely different client. With poorly written = implicit flow clients, this is an issue.) >=20 > That said, I wasn't aiming to discuss the relative security; just = wanted to make sure I knew what you meant by "won't work well". >=20 > Thanks again! >=20 > -Josh >=20 > On Jul 1, 2016 18:02, "John Bradley" > wrote: > I am making a distinction between a browser talking to a Web server = that is acting as a OAuth Client POST response mode =3D good , and a = oauth client running in the browser user agent as a Java script = application (that can=E2=80=99t directly capture a POST response back to = the server) >=20 > So it depends on where the client is actually running. >=20 > Are you saying that you are using a 302 redirect from the = authorization endpoint back to the server hosting the JS and then = loading the JS including the code and then using CORES to exchange the = code for a AT? >=20 > You can do that but I don=E2=80=99t think a public client like that is = more secure than just using the fragment encoded response and is more = work. > It also may give the server a false sense of security. >=20 > John B. >> On Jul 1, 2016, at 5:52 PM, Josh Mandel > wrote: >>=20 >> I think the confusion here is that I'm not using HEART's OAuth = profiles :-) >>=20 >> I'm using the SMART profiles, where we do specify the use of an = authorization code grant even for browser-based public clients (in which = case, no client_secret is issued or used). I'm just trying to understand = your perspective eon why this "won't work well". Perhaps you didn't mean = this comment to refer to browser-based OAuth clients generally? >>=20 >> -Josh >>=20 >> On Fri, Jul 1, 2016 at 5:45 PM, John Bradley > wrote: >> I don=E2=80=99t think the post response mode is supported by heart so = I suspect that we are talking about different things. >>=20 >> You are probably using the supported code flow that uses a 302 get to = return the code to the OAuth client on the server. =20 >> The Web server is then acting as a confidential client to exchange = the code via a POST (different POST) with the AS token_endpoint. >>=20 >> The Token endpoint will return a access token (AT) and optional = refresh token (RT). >>=20 >> The web page may be getting the server to make the OAuth calls on = it=E2=80=99s behalf to the Resource Server, or possibly you are passing = the AT from the server back to a Java script app that is using CORES to = make calls directly to the RS without going through the Web server. >>=20 >> Passing the AT back to the user agent from the client is not = recommended.=20 >>=20 >> For in browser clients where the JS is using the AT to make the calls = directly to the RS via CORES the recommended approach is to use the = fragment encoded response via a 302 to deliver the AT directly to the = client (It never hits the backend Web server). >>=20 >> However I believe In browser OAuth clients are not currently = supported in HEART, so I am not quite sure what you are doing. >>=20 >> Perhaps Justin has a better answer. >>=20 >> John B. >>=20 >>=20 >>> On Jul 1, 2016, at 5:33 PM, Josh Mandel > wrote: >>>=20 >>> John, >>>=20 >>> I appreciate your response. I'm hoping you can clarify why you say = that "HTTP POST... won't work well for... [a] single page OAuth client"? >>>=20 >>> We commonly build single-page apps that act as OAuth clients for = SMART (e.g. this sample app = ), and we've had good experience with the = technique. Could you elaborate? >>>=20 >>> -J >>>=20 >>> On Fri, Jul 1, 2016 at 5:26 PM, John Bradley > wrote: >>> HEART only supports web server clients at the moment. That might = change in future to support native apps if that an be made to support = the security requirements of Heath IT. >>>=20 >>> So the thing HTTP POST responses won=E2=80=99t work well for is a = type of in browser single page OAuth client. That still needs fragment = encoded responses or the new post-message Java Script API approach. >>>=20 >>> John B. >>>=20 >>>=20 >>>> On Jul 1, 2016, at 5:16 PM, Josh Mandel > wrote: >>>>=20 >>>> Thanks Justin, >>>>=20 >>>> To clarify: John's comment and my question were about POST. (I do = understand the behavior of HTTP POST and of window.postMessage; these = are totally different things.) =46rom my perspective in SMART Health IT, = we use the OAuth 2.0 authorization code flow, including HTTP POST, in = our authorization spec = even for public clients, and it has worked very well for us, with about = a dozen electronic health record servers supporting this approach. = That's why I was curious to hear John's perspective about limitations. >>>>=20 >>>> -J >>>>=20 >>>> On Fri, Jul 1, 2016 at 5:09 PM, Oleg Gryb > wrote: >>>> > POST will send things to the server, which isn=E2=80=99t = desirable if your client is solely in the browser >>>> Why it's not desirable, assuming that we disregard performance? You = can generate HTTP POST from JS, e.g. through an AJAX call. What is wrong = with this? >>>>=20 >>>>=20 >>>> From: Justin Richer > >>>> To: Josh Mandel >=20 >>>> Cc: Oleg Gryb >; = ">" >; Liyu Yi > >>>> Sent: Friday, July 1, 2016 2:00 PM >>>>=20 >>>> Subject: Re: [OAUTH-WG] Security concern for URI fragment as = Implicit grant >>>>=20 >>>> POST will send things to the server, which isn=E2=80=99t desirable = if your client is solely in the browser. postMessage is a browser API = and not to be confused with HTTP POST. postMessage messages stay (or can = stay) within the browser, which is the intent here. >>>>=20 >>>> =E2=80=94 Justin >>>>=20 >>>>> On Jul 1, 2016, at 4:56 PM, Josh Mandel > wrote: >>>>>=20 >>>>=20 >>>> John, >>>>=20 >>>> Could you clarify what you mean by "POST doesn't really work"? Do = you just mean that CORS support (e.g., http://caniuse.com/#feat=3Dcors = ) isn't universal, or something more? >>>>=20 >>>> On Fri, Jul 1, 2016 at 4:51 PM, John Bradley > wrote: >>>> Yes but POST doesn't really work for in browser apps. >>>>=20 >>>> If it is a server app it should be using the code flow with GET or = POST as you like. >>>>=20 >>>> If we do a post message based binding it will be targeted at in = browser applications. >>>>=20 >>>> John B. >>>>=20 >>>> On Fri, Jul 1, 2016 at 4:42 PM, Liyu Yi > wrote: >>>> BTW, I do not see any significant performance concerns for post. = Parsing and executing the Javascript logic for post operation will be on = the client side, no extra server load is introduced. >>>>=20 >>>> Plus post will remove the size restriction of the URL length. >>>>=20 >>>> -- Liyu=20 >>>>=20 >>>> On Fri, Jul 1, 2016 at 1:35 PM, Liyu Yi > wrote: >>>> Thanks for the great comments and advices. >>>>=20 >>>> I think it is a good idea for the working group to revise the = fragment part in the spec, since there might be public available tools = already implemented this approach and people can end up with a solution = with serious security loopholes. >>>>=20 >>>> The re-append issue can be mitigate by a logic on Resource Server = which carefully re-writes/removes the fragment in any redirect, if the = the redirect can not be avoided. >>>>=20 >>>> -- Liyu >>>> =20 >>>>=20 >>>> On Fri, Jul 1, 2016 at 11:33 AM, John Bradley > wrote: >>>> This behaviour started changing around 2011 >>>>=20 >>>> =46rom HTTP/1.1 >>>> See https://tools.ietf.org/html/rfc7231#section-7.1.2 = I >>>> f the Location value provided in a 3xx (Redirection) response = does >>>> not have a fragment component, a user agent MUST process the >>>> redirection as if the value inherits the fragment component of = the >>>> URI reference used to generate the request target (i.e., the >>>> redirection inherits the original reference's fragment, if any). >>>>=20 >>>> For example, a GET request generated for the URI reference >>>> "http://www.example.org/~tim " = might result in a 303 (See Other) >>>> response containing the header field: >>>>=20 >>>> Location: /People.html#tim >>>>=20 >>>> which suggests that the user agent redirect to >>>> "http://www.example.org/People.html#tim = =E2=80=9D >>>>=20 >>>> Likewise, a GET request generated for the URI reference >>>> "http://www.example.org/index.html#larry = " might result in a 301 >>>> (Moved Permanently) response containing the header field: >>>>=20 >>>> Location: http://www.example.net/index.html = >>>>=20 >>>> which suggests that the user agent redirect to >>>> "http://www.example.net/index.html#larry = ", preserving the original >>>> fragment identifier. >>>>=20 >>>>=20 >>>> This blog also explores the change. >>>> = https://blogs.msdn.microsoft.com/ieinternals/2011/05/16/url-fragments-and-= redirects/ = >>>>=20 >>>>=20 >>>>> On Jul 1, 2016, at 1:05 PM, Oleg Gryb > wrote: >>>>>=20 >>>>> "Browsers now re-append fragments across 302 redirects unless = they are explicitly cleared this makes fragment encoding less safe than = it was when originally specified" - thanks Jim. Looks like a good = reason for vetting this flow out. >>>>>=20 >>>>> John, >>>>> Please provide more details/links about re-appending fragments.=20 >>>>>=20 >>>>> Thanks, >>>>> Oleg. >>>>>=20 >>>>>=20 >>>>> From: Jim Manico > >>>>> To: Oleg Gryb >=20 >>>>> Cc: "oauth@ietf.org " >; Liyu Yi > >>>>> Sent: Thursday, June 30, 2016 10:25 PM >>>>> Subject: Re: [OAUTH-WG] Security concern for URI fragment as = Implicit grant >>>>>=20 >>>>> Oleg! Hello! Great to see you pop up here with a similar concern. >>>>>=20 >>>>> John Bradley just answered this thread with the details I was = looking for (thanks John, hat tip your way). >>>>>=20 >>>>> He also mentioned details about fragment leakage: >>>>>=20 >>>>> "Browsers now re-append fragments across 302 redirects unless = they are explicitly cleared this makes fragment encoding less safe than = it was when originally specified" >>>>>=20 >>>>> Again, I'm new here but I'm grateful for this conversation. >>>>>=20 >>>>> Aloha, >>>>> -- >>>>> Jim Manico >>>>> @Manicode >>>>>=20 >>>>> On Jul 1, 2016, at 1:24 AM, Oleg Gryb > wrote: >>>>>=20 >>>>>> We've discussed access tokens in URI back in 2010 = (https://www.ietf.org/mail-archive/web/oauth/current/msg04043.html = ). = There were two major objectives when I was saying that it's not secure: >>>>>>=20 >>>>>> 1. Fragment is not sent to a server by a browser. When I've asked = if this is true for every browser in the world, nobody was able to = answer. >>>>>> 2. Replacing with POST would mean a significant performance = impact in some high volume implementations (I think it was Goole folks = who were saying this, but I don't remember now). >>>>>>=20 >>>>>> AFAIR, nobody was arguing about browsing history, so it's valid. >>>>>>=20 >>>>>> So, 6 years later we're at square one with this and I hope that = this time the community will be more successful with getting rid of = secrets in URL. >>>>>>=20 >>>>>> BTW, Jim, if you can come up with other scenarios when fragments = can leak, please share. It'll probably help the community with solving = this problem faster than in 6 years. >>>>>>=20 >>>>>> Thanks, >>>>>> Oleg. >>>>>>=20 >>>>>>=20 >>>>>> From: Jim Manico > >>>>>> To: Liyu Yi >; = oauth@ietf.org =20 >>>>>> Sent: Wednesday, June 29, 2016 7:30 AM >>>>>> Subject: Re: [OAUTH-WG] Security concern for URI fragment as = Implicit grant >>>>>>=20 >>>>>> > Shouldn=E2=80=99t it be more secure if we change to use a post = method for access token, similar to the SAML does? >>>>>> I say yes. But please note I'm very new at this and someone with = more experience will have more to say or correct my comments. >>>>>> Here are a few more details to consider. >>>>>> 1) OAuth is a framework and not a standard, per se. Different = authorization servers will have different implementations that are not = necessarily compatible with other service providers. So there is no = standard to break, per se. >>>>>> 2) Sensitive data in a URI is a bad idea. They leak all over the = place even over HTTPS. Even in fragments. >>>>>> 3) Break the "rules" and find a way to submit sensitive data like = access tokens, session information or any other (even short term) = sensitive data in a secure fashion. This includes POST, JSON data = payloads over PUT/PATCH and other verbs - all over well configured = HTTPS. >>>>>> 4) If you really must submit sensitive data over GET , consider = JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level = confidentiality and integrity. >>>>>> Aloha, >>>>>> Jim Manico >>>>>> Manicode Security >>>>>> https://www.manicode.com >>>>>> On 6/27/16 9:30 PM, Liyu Yi wrote: >>>>>>> While we are working on a project with OAuth2 implementation, = one question arises from our engineers. >>>>>>> We noticed at = https://tools.= ietf.org/html/draft-ietf-oauth-v2-31#page-30 = , it is = specified that >>>>>>> =20 >>>>>>> (C) Assuming the resource owner grants access, the = authorization >>>>>>> server redirects the user-agent back to the client using = the >>>>>>> redirection URI provided earlier. The redirection URI = includes >>>>>>> the access token in the URI fragment. >>>>>>> =20 >>>>>>> For my understanding, the browser keeps the URI fragment in the = history, and this introduces unexpected exposure of the access token. A = user without authorization for the resource can get the access token as = long as he has the access to the browser. This can happen in a shared = computer in library, or for an IT staff who works on other employee=E2=80=99= s computer. >>>>>>> =20 >>>>>>> Shouldn=E2=80=99t it be more secure if we change to use a post = method for access token, similar to the SAML does? >>>>>>> I feel there might be something I missed here. Any advices will = be appreciated. >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>=20 >>>>>> --=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth = >>>=20 >>>=20 >>=20 >>=20 >=20 --Apple-Mail=_34FB13DA-1E4E-4889-8702-1512FF9AF5C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 If the in browser JS checks that it is talking to the correct = AS making a authorization request that is no worse that making a request = to exchange code via CORS.  Attacks where code is stolen and = replayed to the client to impersonate the user are also possable That is = the reason for the id_token with signed nonce, as state can be = manipulated in some cases as it is not signed. 

That is a different discussion = however.

John = B.

On Jul 1, 2016, at 6:13 PM, = Josh Mandel <jmandel@gmail.com> wrote:

Thanks John! Yes, we're following the CORS based flow you've = described below (though I should note that the actual redirection back = to the client could be a 302, or could be a simple Web link that the = user follows from an authorization page; this is up to the authorization = server).

Overall I don't argue that this = flow is "more secure" than the implicit flow -- though I believe it does = help client developers avoid some common pitfalls. (For example, clients = that, through careless programming or poor understanding of the spec, = fail to validate incoming "state" are still not susceptible to arbitrary = token injection, which means at least they won't readily be tricked into = using a token designated for an entirely different client. With poorly = written implicit flow clients, this is an issue.)

That said, I wasn't aiming to discuss the relative security; = just wanted to make sure I knew what you meant by "won't work = well".

Thanks again!

-Josh

On Jul 1, 2016 18:02, "John Bradley" <ve7jtb@ve7jtb.com> = wrote:
I = am making a distinction between a browser talking to a Web server that = is acting as a OAuth Client POST response mode =3D good , and a oauth = client running in the browser user agent as a Java script application = (that can=E2=80=99t directly capture a POST response back to the = server)

So it = depends on where the client is actually running.

Are you saying that you are using a 302 = redirect from the authorization endpoint back to the server hosting the = JS and then loading the JS including the code and then using CORES =  to exchange the code for a AT?

You can do that but I don=E2=80=99t = think a public client like that is more secure than just using the = fragment encoded response and is more work.
It also = may give the server a false sense of security.

John B.
On Jul = 1, 2016, at 5:52 PM, Josh Mandel <jmandel@gmail.com> wrote:

I think the = confusion here is that I'm not using HEART's OAuth profiles :-)

I'm using the SMART = profiles, where we do specify the use of an authorization code grant = even for browser-based public clients (in which case, no client_secret = is issued or used). I'm just trying to understand your perspective eon = why this "won't work well". Perhaps you didn't mean this comment to = refer to browser-based OAuth clients generally?

  -Josh

On Fri, = Jul 1, 2016 at 5:45 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
I don=E2=80=99t think the post = response mode is supported by heart so I suspect that we are talking = about different things.

You are probably using the supported code flow that uses a = 302 get to return the code to the OAuth client on the server. =  
The Web server is then acting as a = confidential client to exchange the code via a POST (different POST) = with the AS token_endpoint.

The Token endpoint will return a access token (AT) and = optional refresh token (RT).

The web page may be getting the server = to make the OAuth calls on it=E2=80=99s behalf to the Resource Server, = or possibly you are passing the AT from the server back to a Java script = app that is using CORES to make calls directly to the RS without going = through the Web server.

Passing the AT back to the user agent from the client is not = recommended. 

For in browser clients where the JS is using the AT to make = the calls directly to the RS via CORES the recommended approach is to = use the fragment encoded response via a 302 to deliver the AT directly = to the client (It never hits the backend Web server).

However I believe In = browser OAuth clients are not currently supported in HEART, so I am not = quite sure what you are doing.

Perhaps Justin has a better = answer.

John = B.


On Jul = 1, 2016, at 5:33 PM, Josh Mandel <jmandel@gmail.com> wrote:

John,

I appreciate your = response. I'm hoping you can clarify why you say that "HTTP POST... = won't work well for... [a] single page OAuth client"?

We commonly build single-page apps that = act as OAuth clients for SMART (e.g. this = sample app ), and we've had good experience with the technique. = Could you elaborate?

  -J

On Fri, Jul 1, 2016 at 5:26 PM, = John Bradley <ve7jtb@ve7jtb.com> wrote:
HEART only supports web server = clients at the moment.   That might change in future to support = native apps if that an be made to support the security requirements of = Heath IT.

So the thing = HTTP POST responses won=E2=80=99t work well for is a type of in browser = single page OAuth client.  That still needs fragment encoded = responses or the new post-message Java Script API approach.

John B.


On Jul 1, 2016, at 5:16 PM, Josh Mandel = <jmandel@gmail.com> wrote:

Thanks Justin,

To clarify: John's comment and my = question were about POST. (I do understand the behavior of HTTP POST and = of window.postMessage; these are totally different things.) =46rom my = perspective in SMART Health IT, we use the OAuth 2.0 authorization code = flow, including HTTP POST, in our authorization spec even for public clients, and it = has worked very well for us, with about a dozen electronic health record = servers supporting this approach. That's why I was curious to hear = John's perspective about limitations.

  -J

On Fri, = Jul 1, 2016 at 5:09 PM, Oleg Gryb <oleg_gryb@yahoo.com> wrote:
> POST will send things to the server, which isn=E2=80=99t = desirable if your client is solely in the browser
Why it's not desirable, assuming that we = disregard performance? You can generate HTTP POST from JS, e.g. through = an AJAX call. What is wrong with this?


=
=
= From:= Justin Richer <jricher@mit.edu>
To: Josh Mandel <jmandel@gmail.com>
Cc: Oleg Gryb <oleg@gryb.info>; "<oauth@ietf.org>" <oauth@ietf.org>; Liyu Yi <liyuyi@gmail.com>
Sent: Friday, July 1, = 2016 2:00 PM

Subject:= Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant
=

POST will = send things to the server, which isn=E2=80=99t desirable if your client = is solely in the browser. postMessage is a browser API and not to be = confused with HTTP POST. postMessage messages stay (or can stay) within = the browser, which is the intent here.

 =E2=80=94 Justin

On Jul = 1, 2016, at 4:56 PM, Josh Mandel <jmandel@gmail.com> wrote:

John,

Could you = clarify what you mean by "POST= doesn't really work"? Do you just mean that CORS support (e.g., http://caniuse.com/#feat=3Dcors) isn't = universal, or something more?

On Fri, Jul 1, 2016 at 4:51 = PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
Yes but = POST doesn't really work for in browser apps.

If it is a server app it = should be using the code flow with GET or POST as you like.

If we do = a  post message based binding it will be targeted at in browser = applications.

John B.

On Fri, Jul 1, 2016 at 4:42 = PM, Liyu Yi <liyuyi@gmail.com> wrote:
BTW, I do = not see any significant performance concerns for post. Parsing and = executing the Javascript logic for post operation will be on the client = side, no extra server load is introduced.

Plus post will remove = the size restriction of the URL length.

-- = Liyu 

On Fri, Jul 1, 2016 at 1:35 = PM, Liyu Yi <liyuyi@gmail.com> wrote:
Thanks for the great comments and advices.

I think it is a good idea = for the working group to revise the fragment part in the spec, since = there might be public available tools already implemented this approach = and people can end up with a solution with serious security = loopholes.

The re-append issue can be mitigate by a logic on Resource = Server which carefully re-writes/removes the fragment in any redirect, = if the the redirect can not be avoided.

-- = Liyu
 

On Fri, Jul 1, 2016 at 11:33 = AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
This behaviour started changing around 2011

=46rom = HTTP/1.1
See https://tools.ietf.org/html/rfc7231#section-7.1.2I
    =   f the Location value provided in a 3xx (Redirection) response = does
   not have a fragment component, a user agent MUST =
process the
   redirection as if the value inherits the fragment component of the
   URI reference used to generate the request target (i.e., the
   redirection inherits the original reference's fragment, if any).

   For example, a GET request generated for the URI reference
   "http://www.example.org/~tim" might result in a 303 (See =
Other)
   response containing the header field:

     Location: /People.html#tim

   which suggests that the user agent redirect to
   "http://www.example.org/People.html#tim=E2=80=9D

   Likewise, a GET request generated for the URI =
reference
   "http://www.example.org/index.html#larry" might result in =
a 301
   (Moved Permanently) response containing the header field:

     Location: http://www.example.net/index.html

   which suggests that the user agent redirect to
   "http://www.example.net/index.html#larry", preserving the =
original
   fragment identifier.


This blog = also explores the change.
https://blogs.msdn.microsoft.com/ieinternals/2011/05/16/url-fra= gments-and-redirects/


On Jul 1, 2016, at 1:05 PM, Oleg Gryb <oleg_gryb@yahoo.com> wrote:

"Browsers now = re-append  fragments across 302 redirects unless they are = explicitly cleared this makes fragment encoding less safe than it was =  when originally specified" - thanks Jim. Looks like a good reason = for vetting this flow out.

John,
Please provide more details/links about re-appending = fragments. 

Thanks,
Oleg.


=
From: Jim Manico <jim@manicode.com>
To: = Oleg Gryb <oleg@gryb.info>
Cc: = "oauth@ietf.org" <oauth@ietf.org>; Liyu Yi <liyuyi@gmail.com>
Sent: = Thursday, June 30, 2016 10:25 PM
Subject:= Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

Oleg! Hello! = Great to see you pop up here with a similar concern.

John = Bradley just answered this thread with the details I was looking for = (thanks John, hat tip your way).

He also mentioned details about = fragment leakage:

"Browsers now = re-append  fragments across 302 redirects unless they are = explicitly cleared this makes fragment encoding less safe than it was = when originally specified"

Again, I'm new here but I'm grateful = for this conversation.

Aloha,
--
Jim Manico
@Manicode

On Jul 1, 2016, at 1:24 AM, Oleg Gryb <oleg_gryb@yahoo.com> wrote:

We've discussed access tokens in URI back in = 2010 (https://www.ietf.org/mail-archive/web/oauth/current/msg04043.ht= ml). There were two major objectives when I was saying that it's not = secure:

1. Fragment is not sent to = a server by a browser. When I've asked if this is true for every browser = in the world, nobody was able to answer.
2. Replacing with POST would mean a significant performance = impact in some high volume implementations (I think it was Goole folks = who were saying this, but I don't remember now).

AFAIR, nobody was arguing about browsing history, so it's = valid.

So, 6 years later we're at = square one with this and I hope that this time the community will be = more successful with getting rid of secrets in URL.

BTW, Jim, if you can come up with other scenarios when = fragments can leak, please share. It'll probably help the community with = solving this problem faster than in 6 years.

Thanks,
Oleg.


=
From: Jim Manico <jim@manicode.com>
To: = Liyu Yi <liyuyi@gmail.com>; oauth@ietf.org
Sent: = Wednesday, June 29, 2016 7:30 AM
Subject:= Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

> Shouldn=E2=80=99t it be more = secure if we change to use a post method for access token, similar to the SAML = does?
I say yes. But please note I'm very new at this and = someone with more experience will have more to say or correct my = comments.
Here are a few more details to consider.
1) OAuth is a framework and not a standard, per se. = Different authorization servers will have different implementations that are not necessarily compatible with other service providers. So there is no standard to break, per se.
2) Sensitive data in a URI is a bad idea. They leak = all over the place even over HTTPS. Even in fragments.
3) Break the "rules" and find a way to submit = sensitive data like access tokens, session information or any other (even short term) sensitive data in a secure fashion. This includes POST, JSON data payloads over PUT/PATCH and other verbs - all over well configured HTTPS.
4) If you really must submit sensitive data over GET = , consider JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level confidentiality and integrity.
Aloha,
Jim Manico
Manicode Security
https://www.manicode.com

On 6/27/16 9:30 PM, Liyu Yi = wrote:
While we are working on a = project with OAuth2 implementation, one question arises from our engineers.
We noticed at https://tools.ietf.org/html/draft-ietf-oauth-v2-31#page-30<= /span>, it is specified that
  
(C)  Assuming the resource = owner grants access, the authorization
        server redirects = the user-agent back to the client using the
        redirection URI = provided earlier.  The redirection URI includes
        the access token = in the URI fragment.
 
For my understanding, the = browser keeps the URI fragment in the history, and this introduces unexpected exposure of the access token. A user without authorization for the resource can get the access token as long as he has the access to the browser. This can happen in a shared computer in library, or for an IT staff who works on other employee=E2=80=99s computer.
 
Shouldn=E2=80=99t it be more = secure if we change to use a post method for access token, similar to the SAML does?
I feel there might be something = I missed here. Any advices will be appreciated.


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


--=20

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


=

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


=





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


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


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


=
=

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






= --Apple-Mail=_34FB13DA-1E4E-4889-8702-1512FF9AF5C1-- From nobody Fri Jul 1 16:07:43 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD8412B046 for ; Fri, 1 Jul 2016 16:07:42 -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 oLSIiAoTGliB for ; Fri, 1 Jul 2016 16:07:38 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5C2312B00F for ; Fri, 1 Jul 2016 16:07:37 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id u124so455627qkh.2 for ; Fri, 01 Jul 2016 16:07:37 -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=8wXm6Z7vWf2XhG+q89Yv7Rr3LCDYE4EZDi9SPmrEml8=; b=SxL1M40PzXd4T4vR7OkacOKIPSqBtDHD8vA1Kiy1wF2L5UggQpvF9cVT+fgvHQ63Qd 3zBmqmUBVTkuPrVYk9+smiz1Fa7awv5FJYul0cTtBNFBmbnBlxz6+Yhdd7UqZp49EZPr TyRCH85u/noje72v+9Qx+s9NFeGDmVFErE45iV8/xBcl8UwSaJ9gnibeqy6hAzIuIh6j /pm6UL4h3oPyX9nyFPatSiIvagU6I+VFnE4fIZy162FuTKzD6hea4/G65AywyDdsvU/K VPPdEtGx1gsEefvnbXeEOpk2tXBlBXAKP6eVTXJjgihydMUSzfsrGpch6clhz17ZII+t nteg== 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=8wXm6Z7vWf2XhG+q89Yv7Rr3LCDYE4EZDi9SPmrEml8=; b=kMFPS6WH2zf0qqWqToBux508+Vw7K02+ocT/ejD0xh0FEo0qHUdpfU/5Ev+pNp5FMu sPm3z3valZv8kNWzEiF0NS3JGCVR8GoS0Qu16pR4iGZFN1cM4XoNFkivNU+n91pxlRY3 ZWY2SpTs79KBGEQ/nWghKW/I5SlZgszG21FPV0RP7jO5bPpSmx/wGXxSPDU6XLMowKCJ 1em4XRPWE0uRr3fZL6Zp0OLgYavJV6ff09JaGTZDC8xO3Bhw7QzcQ4/AvyCBpzlj2ulR kiJwjJJhUKZ6Ykq9/c+Eedp9Zwlu6pq0iI9K1SAbA156ordLEIV3OUDfi1wxUd/fQL1r rS2w== X-Gm-Message-State: ALyK8tKePM61sWPnwe3+DZxF4dyIk6PVbZMgxdQYSFstkmFXtrAvxvdK3UDqN50ExU8h5lKA X-Received: by 10.55.103.84 with SMTP id b81mr1047006qkc.177.1467414456713; Fri, 01 Jul 2016 16:07:36 -0700 (PDT) Received: from [192.168.1.41] ([191.115.51.34]) by smtp.gmail.com with ESMTPSA id g188sm2169722qkf.7.2016.07.01.16.07.11 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 01 Jul 2016 16:07:36 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_CAC5488D-8EBB-48CC-905C-255C4F21ECB1" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: John Bradley In-Reply-To: Date: Fri, 1 Jul 2016 19:06:45 -0400 Message-Id: References: <994121658.55005.1467329084208.JavaMail.yahoo@mail.yahoo.com> <235316006.458279.1467392709447.JavaMail.yahoo@mail.yahoo.com> <6584BD74-B18F-4174-9E69-5C7B4B76F895@ve7jtb.com> <410908395.555462.1467407397629.JavaMail.yahoo@mail.yahoo.com> <8CC41328-C26D-42C0-BFDB-BF0216C7B76C@ve7jtb.com> <71CE61B3-FEC2-46A7-AB28-B53E89A8E53F@ve7jtb.com> To: Liyu Yi X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Oleg Gryb , "" Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 23:07:42 -0000 --Apple-Mail=_CAC5488D-8EBB-48CC-905C-255C4F21ECB1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I take it that Web-hosted client resource is part of the client. I think perhaps you have client and resource serve r mixed up a bit in = your diagram. Yes you could do that but it is not a great way to build the client as = it will blow away context. =20 You can do it but people generally want to start the application in the = browser first and then call out to the IdP in a iFrame. What you propose would work more or less. I don=E2=80=99t see it as a = pattern that I would necessarily recommend over the current fragment = encoding. If we mover to post message it would include API for logout and session = management, not just login. John B. > On Jul 1, 2016, at 6:43 PM, Liyu Yi wrote: >=20 > Understood there is an Authorization Code grant type; here I am more = focusing on the Implicit grant type.=20 > =20 > also when I mentioned POST, I did not mean postMessage, it is simply = the HTTP POST. Specifically it is more like this ... >=20 >=20 >=20 > 4.2 . Implicit Grant = (modified) >=20 > +----------+ > | Resource | > | Owner | > | | > +----------+ > ^ > | > (B) > +----|-----+ Client Identifier +---------------+ > | -+----(A)-- & Redirection URI --->| | > | User- | | Authorization | > | Agent -|----(B)-- User authenticates -->| Server | > | | | | > | |<---(C)- Response embedded JS -<| | > | | with Access Token +---------------+ > | | in JS content, which will be posted to = Resource Server > | | +---------------+ > | |----(D)-- JS post to RS URI --->| Web-Hosted | > | | with Access Token | Client | > | | | Resource | > | (F) |<---(E)----- RS Script --------<| | > | | with Access Token +---------------+ > +-|--------+ > | | > (A) (G) Access Token > | | > ^ v > +---------+ > | | > | Client | > | | > +---------+ >=20 >=20 >=20 > Figure 4: Implicit Grant Flow >=20 > The flow illustrated in Figure 4 includes the following steps: >=20 > (A) The client initiates the flow by directing the resource = owner's > user-agent to the authorization endpoint. The client includes > its client identifier, requested scope, local state, and a > redirection URI to which the authorization server will send = the > user-agent back once access is granted (or denied). >=20 > (B) The authorization server authenticates the resource owner (via > the user-agent) and establishes whether the resource owner > grants or denies the client's access request. >=20 > (C) Assuming the resource owner grants access, the authorization > server responds with a JavaScript logic which automatically = posts to=20 > "redirection" URI provided earlier. The JavaScript includes > the access token in the URI fragment. >=20 > (D) The user-agent does the post with the access token. Granted, =20= > user agent can actually do post without the access = token in a different iframe,=20 > then use postMessage to pass the token over, but I = do not see why get it need that compexity. >=20 >=20 > On Fri, Jul 1, 2016 at 3:13 PM, Josh Mandel > wrote: > Thanks John! Yes, we're following the CORS based flow you've described = below (though I should note that the actual redirection back to the = client could be a 302, or could be a simple Web link that the user = follows from an authorization page; this is up to the authorization = server). >=20 > Overall I don't argue that this flow is "more secure" than the = implicit flow -- though I believe it does help client developers avoid = some common pitfalls. (For example, clients that, through careless = programming or poor understanding of the spec, fail to validate incoming = "state" are still not susceptible to arbitrary token injection, which = means at least they won't readily be tricked into using a token = designated for an entirely different client. With poorly written = implicit flow clients, this is an issue.) >=20 > That said, I wasn't aiming to discuss the relative security; just = wanted to make sure I knew what you meant by "won't work well". >=20 > Thanks again! >=20 > -Josh >=20 > On Jul 1, 2016 18:02, "John Bradley" > wrote: > I am making a distinction between a browser talking to a Web server = that is acting as a OAuth Client POST response mode =3D good , and a = oauth client running in the browser user agent as a Java script = application (that can=E2=80=99t directly capture a POST response back to = the server) >=20 > So it depends on where the client is actually running. >=20 > Are you saying that you are using a 302 redirect from the = authorization endpoint back to the server hosting the JS and then = loading the JS including the code and then using CORES to exchange the = code for a AT? >=20 > You can do that but I don=E2=80=99t think a public client like that is = more secure than just using the fragment encoded response and is more = work. > It also may give the server a false sense of security. >=20 > John B. >> On Jul 1, 2016, at 5:52 PM, Josh Mandel > wrote: >>=20 >> I think the confusion here is that I'm not using HEART's OAuth = profiles :-) >>=20 >> I'm using the SMART profiles, where we do specify the use of an = authorization code grant even for browser-based public clients (in which = case, no client_secret is issued or used). I'm just trying to understand = your perspective eon why this "won't work well". Perhaps you didn't mean = this comment to refer to browser-based OAuth clients generally? >>=20 >> -Josh >>=20 >> On Fri, Jul 1, 2016 at 5:45 PM, John Bradley > wrote: >> I don=E2=80=99t think the post response mode is supported by heart so = I suspect that we are talking about different things. >>=20 >> You are probably using the supported code flow that uses a 302 get to = return the code to the OAuth client on the server. =20 >> The Web server is then acting as a confidential client to exchange = the code via a POST (different POST) with the AS token_endpoint. >>=20 >> The Token endpoint will return a access token (AT) and optional = refresh token (RT). >>=20 >> The web page may be getting the server to make the OAuth calls on = it=E2=80=99s behalf to the Resource Server, or possibly you are passing = the AT from the server back to a Java script app that is using CORES to = make calls directly to the RS without going through the Web server. >>=20 >> Passing the AT back to the user agent from the client is not = recommended.=20 >>=20 >> For in browser clients where the JS is using the AT to make the calls = directly to the RS via CORES the recommended approach is to use the = fragment encoded response via a 302 to deliver the AT directly to the = client (It never hits the backend Web server). >>=20 >> However I believe In browser OAuth clients are not currently = supported in HEART, so I am not quite sure what you are doing. >>=20 >> Perhaps Justin has a better answer. >>=20 >> John B. >>=20 >>=20 >>> On Jul 1, 2016, at 5:33 PM, Josh Mandel > wrote: >>>=20 >>> John, >>>=20 >>> I appreciate your response. I'm hoping you can clarify why you say = that "HTTP POST... won't work well for... [a] single page OAuth client"? >>>=20 >>> We commonly build single-page apps that act as OAuth clients for = SMART (e.g. this sample app = ), and we've had good experience with the = technique. Could you elaborate? >>>=20 >>> -J >>>=20 >>> On Fri, Jul 1, 2016 at 5:26 PM, John Bradley > wrote: >>> HEART only supports web server clients at the moment. That might = change in future to support native apps if that an be made to support = the security requirements of Heath IT. >>>=20 >>> So the thing HTTP POST responses won=E2=80=99t work well for is a = type of in browser single page OAuth client. That still needs fragment = encoded responses or the new post-message Java Script API approach. >>>=20 >>> John B. >>>=20 >>>=20 >>>> On Jul 1, 2016, at 5:16 PM, Josh Mandel > wrote: >>>>=20 >>>> Thanks Justin, >>>>=20 >>>> To clarify: John's comment and my question were about POST. (I do = understand the behavior of HTTP POST and of window.postMessage; these = are totally different things.) =46rom my perspective in SMART Health IT, = we use the OAuth 2.0 authorization code flow, including HTTP POST, in = our authorization spec = even for public clients, and it has worked very well for us, with about = a dozen electronic health record servers supporting this approach. = That's why I was curious to hear John's perspective about limitations. >>>>=20 >>>> -J >>>>=20 >>>> On Fri, Jul 1, 2016 at 5:09 PM, Oleg Gryb > wrote: >>>> > POST will send things to the server, which isn=E2=80=99t = desirable if your client is solely in the browser >>>> Why it's not desirable, assuming that we disregard performance? You = can generate HTTP POST from JS, e.g. through an AJAX call. What is wrong = with this? >>>>=20 >>>>=20 >>>> From: Justin Richer > >>>> To: Josh Mandel >=20 >>>> Cc: Oleg Gryb >; = ">" >; Liyu Yi > >>>> Sent: Friday, July 1, 2016 2:00 PM >>>>=20 >>>> Subject: Re: [OAUTH-WG] Security concern for URI fragment as = Implicit grant >>>>=20 >>>> POST will send things to the server, which isn=E2=80=99t desirable = if your client is solely in the browser. postMessage is a browser API = and not to be confused with HTTP POST. postMessage messages stay (or can = stay) within the browser, which is the intent here. >>>>=20 >>>> =E2=80=94 Justin >>>>=20 >>>>> On Jul 1, 2016, at 4:56 PM, Josh Mandel > wrote: >>>>>=20 >>>>=20 >>>> John, >>>>=20 >>>> Could you clarify what you mean by "POST doesn't really work"? Do = you just mean that CORS support (e.g., http://caniuse.com/#feat=3Dcors = ) isn't universal, or something more? >>>>=20 >>>> On Fri, Jul 1, 2016 at 4:51 PM, John Bradley > wrote: >>>> Yes but POST doesn't really work for in browser apps. >>>>=20 >>>> If it is a server app it should be using the code flow with GET or = POST as you like. >>>>=20 >>>> If we do a post message based binding it will be targeted at in = browser applications. >>>>=20 >>>> John B. >>>>=20 >>>> On Fri, Jul 1, 2016 at 4:42 PM, Liyu Yi > wrote: >>>> BTW, I do not see any significant performance concerns for post. = Parsing and executing the Javascript logic for post operation will be on = the client side, no extra server load is introduced. >>>>=20 >>>> Plus post will remove the size restriction of the URL length. >>>>=20 >>>> -- Liyu=20 >>>>=20 >>>> On Fri, Jul 1, 2016 at 1:35 PM, Liyu Yi > wrote: >>>> Thanks for the great comments and advices. >>>>=20 >>>> I think it is a good idea for the working group to revise the = fragment part in the spec, since there might be public available tools = already implemented this approach and people can end up with a solution = with serious security loopholes. >>>>=20 >>>> The re-append issue can be mitigate by a logic on Resource Server = which carefully re-writes/removes the fragment in any redirect, if the = the redirect can not be avoided. >>>>=20 >>>> -- Liyu >>>> =20 >>>>=20 >>>> On Fri, Jul 1, 2016 at 11:33 AM, John Bradley > wrote: >>>> This behaviour started changing around 2011 >>>>=20 >>>> =46rom HTTP/1.1 >>>> See https://tools.ietf.org/html/rfc7231#section-7.1.2 = I >>>> f the Location value provided in a 3xx (Redirection) response = does >>>> not have a fragment component, a user agent MUST process the >>>> redirection as if the value inherits the fragment component of = the >>>> URI reference used to generate the request target (i.e., the >>>> redirection inherits the original reference's fragment, if any). >>>>=20 >>>> For example, a GET request generated for the URI reference >>>> "http://www.example.org/~tim " = might result in a 303 (See Other) >>>> response containing the header field: >>>>=20 >>>> Location: /People.html#tim >>>>=20 >>>> which suggests that the user agent redirect to >>>> "http://www.example.org/People.html#tim = =E2=80=9D >>>>=20 >>>> Likewise, a GET request generated for the URI reference >>>> "http://www.example.org/index.html#larry = " might result in a 301 >>>> (Moved Permanently) response containing the header field: >>>>=20 >>>> Location: http://www.example.net/index.html = >>>>=20 >>>> which suggests that the user agent redirect to >>>> "http://www.example.net/index.html#larry = ", preserving the original >>>> fragment identifier. >>>>=20 >>>>=20 >>>> This blog also explores the change. >>>> = https://blogs.msdn.microsoft.com/ieinternals/2011/05/16/url-fragments-and-= redirects/ = >>>>=20 >>>>=20 >>>>> On Jul 1, 2016, at 1:05 PM, Oleg Gryb > wrote: >>>>>=20 >>>>> "Browsers now re-append fragments across 302 redirects unless = they are explicitly cleared this makes fragment encoding less safe than = it was when originally specified" - thanks Jim. Looks like a good = reason for vetting this flow out. >>>>>=20 >>>>> John, >>>>> Please provide more details/links about re-appending fragments.=20 >>>>>=20 >>>>> Thanks, >>>>> Oleg. >>>>>=20 >>>>>=20 >>>>> From: Jim Manico > >>>>> To: Oleg Gryb >=20 >>>>> Cc: "oauth@ietf.org " >; Liyu Yi > >>>>> Sent: Thursday, June 30, 2016 10:25 PM >>>>> Subject: Re: [OAUTH-WG] Security concern for URI fragment as = Implicit grant >>>>>=20 >>>>> Oleg! Hello! Great to see you pop up here with a similar concern. >>>>>=20 >>>>> John Bradley just answered this thread with the details I was = looking for (thanks John, hat tip your way). >>>>>=20 >>>>> He also mentioned details about fragment leakage: >>>>>=20 >>>>> "Browsers now re-append fragments across 302 redirects unless = they are explicitly cleared this makes fragment encoding less safe than = it was when originally specified" >>>>>=20 >>>>> Again, I'm new here but I'm grateful for this conversation. >>>>>=20 >>>>> Aloha, >>>>> -- >>>>> Jim Manico >>>>> @Manicode >>>>>=20 >>>>> On Jul 1, 2016, at 1:24 AM, Oleg Gryb > wrote: >>>>>=20 >>>>>> We've discussed access tokens in URI back in 2010 = (https://www.ietf.org/mail-archive/web/oauth/current/msg04043.html = ). = There were two major objectives when I was saying that it's not secure: >>>>>>=20 >>>>>> 1. Fragment is not sent to a server by a browser. When I've asked = if this is true for every browser in the world, nobody was able to = answer. >>>>>> 2. Replacing with POST would mean a significant performance = impact in some high volume implementations (I think it was Goole folks = who were saying this, but I don't remember now). >>>>>>=20 >>>>>> AFAIR, nobody was arguing about browsing history, so it's valid. >>>>>>=20 >>>>>> So, 6 years later we're at square one with this and I hope that = this time the community will be more successful with getting rid of = secrets in URL. >>>>>>=20 >>>>>> BTW, Jim, if you can come up with other scenarios when fragments = can leak, please share. It'll probably help the community with solving = this problem faster than in 6 years. >>>>>>=20 >>>>>> Thanks, >>>>>> Oleg. >>>>>>=20 >>>>>>=20 >>>>>> From: Jim Manico > >>>>>> To: Liyu Yi >; = oauth@ietf.org =20 >>>>>> Sent: Wednesday, June 29, 2016 7:30 AM >>>>>> Subject: Re: [OAUTH-WG] Security concern for URI fragment as = Implicit grant >>>>>>=20 >>>>>> > Shouldn=E2=80=99t it be more secure if we change to use a post = method for access token, similar to the SAML does? >>>>>> I say yes. But please note I'm very new at this and someone with = more experience will have more to say or correct my comments. >>>>>> Here are a few more details to consider. >>>>>> 1) OAuth is a framework and not a standard, per se. Different = authorization servers will have different implementations that are not = necessarily compatible with other service providers. So there is no = standard to break, per se. >>>>>> 2) Sensitive data in a URI is a bad idea. They leak all over the = place even over HTTPS. Even in fragments. >>>>>> 3) Break the "rules" and find a way to submit sensitive data like = access tokens, session information or any other (even short term) = sensitive data in a secure fashion. This includes POST, JSON data = payloads over PUT/PATCH and other verbs - all over well configured = HTTPS. >>>>>> 4) If you really must submit sensitive data over GET , consider = JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level = confidentiality and integrity. >>>>>> Aloha, >>>>>> Jim Manico >>>>>> Manicode Security >>>>>> https://www.manicode.com >>>>>> On 6/27/16 9:30 PM, Liyu Yi wrote: >>>>>>> While we are working on a project with OAuth2 implementation, = one question arises from our engineers. >>>>>>> We noticed at = https://tools.= ietf.org/html/draft-ietf-oauth-v2-31#page-30 = , it is = specified that >>>>>>> =20 >>>>>>> (C) Assuming the resource owner grants access, the = authorization >>>>>>> server redirects the user-agent back to the client using = the >>>>>>> redirection URI provided earlier. The redirection URI = includes >>>>>>> the access token in the URI fragment. >>>>>>> =20 >>>>>>> For my understanding, the browser keeps the URI fragment in the = history, and this introduces unexpected exposure of the access token. A = user without authorization for the resource can get the access token as = long as he has the access to the browser. This can happen in a shared = computer in library, or for an IT staff who works on other employee=E2=80=99= s computer. >>>>>>> =20 >>>>>>> Shouldn=E2=80=99t it be more secure if we change to use a post = method for access token, similar to the SAML does? >>>>>>> I feel there might be something I missed here. Any advices will = be appreciated. >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>=20 >>>>>> --=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth = >>>=20 >>>=20 >>=20 >>=20 >=20 >=20 --Apple-Mail=_CAC5488D-8EBB-48CC-905C-255C4F21ECB1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I take it that Web-hosted client resource is part of the = client.

I think = perhaps you have client and resource serve r mixed up a bit in your = diagram.

Yes = you could do that but it is not a great way to build the client as it = will blow away context.  
You can do it but = people generally want to start the application in the browser first and = then call out to the IdP  in a iFrame.

What you propose would work more or = less.  I don=E2=80=99t see it as a pattern that I would necessarily = recommend over the current fragment encoding.

If we mover to post message it would = include API  for logout and session management, not just = login.

John = B.


On = Jul 1, 2016, at 6:43 PM, Liyu Yi <liyuyi@gmail.com> wrote:

Understood there is an Authorization Code = grant type; here I am more focusing on the Implicit grant = type. 
  
also = when I mentioned POST, I did not mean postMessage, it is simply the HTTP = POST. Specifically it is more like this ...



4.2.  Implicit Grant =
(modified)


     +----------+
     | Resource |
     |  Owner   |
     |          |
     +----------+
          ^
          |
         (B)
     +----|-----+          Client Identifier     +---------------+
     |         -+----(A)-- & Redirection URI --->|               =
|
     |  User-   |                                | Authorization |
     |  Agent  -|----(B)-- User authenticates -->|     Server    |
     |          |                                |               |
     |          |<---(C)- Response embedded JS -<|               |
     |          |          with Access Token     +---------------+
     |          |            in JS content, which will be posted to =
Resource Server
     |          |                                +---------------+
     |          |----(D)-- JS post to RS URI --->|   Web-Hosted  |
     |          |         with Access Token      |     Client    |
     |          |                                |    Resource   |
     |     (F)  |<---(E)----- RS Script --------<|               |
     |          |         with Access Token      +---------------+
     +-|--------+
       |    |
      (A)  (G) Access Token
       |    |
       ^    v
     +---------+
     |         |
     |  Client |
     |         |
     +---------+



                       Figure 4: Implicit Grant Flow


   The flow illustrated in Figure 4 includes the =
following steps:

   (A)  The client initiates the flow by directing the resource owner's
        user-agent to the authorization endpoint.  The client includes
        its client identifier, requested scope, local state, and a
        redirection URI to which the authorization server will send the
        user-agent back once access is granted (or denied).

   (B)  The authorization server authenticates the resource owner (via
        the user-agent) and establishes whether the resource owner
        grants or denies the client's access request.

   (C)  Assuming the resource owner grants access, the authorization
        server responds with a JavaScript logic which automatically =
posts to=20
        "redirection" URI provided earlier.  The JavaScript includes
        the access token in the URI fragment.

   (D)  The user-agent does the post with the access token. Granted, =
 
   =
               user agent can actually do post without the access token  =
in a different iframe, 
                  then use postMessage to pass the token =
over, but I do not see why get it need that compexity.


On Fri, = Jul 1, 2016 at 3:13 PM, Josh Mandel <jmandel@gmail.com> wrote:

Thanks John! Yes, we're following the CORS based flow you've = described below (though I should note that the actual redirection back = to the client could be a 302, or could be a simple Web link that the = user follows from an authorization page; this is up to the authorization = server).

Overall I don't argue that this = flow is "more secure" than the implicit flow -- though I believe it does = help client developers avoid some common pitfalls. (For example, clients = that, through careless programming or poor understanding of the spec, = fail to validate incoming "state" are still not susceptible to arbitrary = token injection, which means at least they won't readily be tricked into = using a token designated for an entirely different client. With poorly = written implicit flow clients, this is an issue.)

That said, I wasn't aiming to discuss the relative security; = just wanted to make sure I knew what you meant by "won't work = well".

Thanks again!

-Josh

=
On Jul 1, 2016 18:02, "John Bradley" <ve7jtb@ve7jtb.com> wrote:
I am making a distinction = between a browser talking to a Web server that is acting as a OAuth = Client POST response mode =3D good , and a oauth client running in the = browser user agent as a Java script application (that can=E2=80=99t = directly capture a POST response back to the server)

So it depends on where the client is = actually running.

Are you saying that you are using a 302 redirect from the = authorization endpoint back to the server hosting the JS and then = loading the JS including the code and then using CORES  to exchange = the code for a AT?

You can do that but I don=E2=80=99t think a public client = like that is more secure than just using the fragment encoded response = and is more work.
It also may give the server a = false sense of security.

John B.
On Jul 1, 2016, at 5:52 PM, Josh Mandel = <jmandel@gmail.com> wrote:

I think the confusion here is = that I'm not using HEART's OAuth profiles :-)

I'm using the SMART profiles, where we = do specify the use of an authorization code grant even for browser-based = public clients (in which case, no client_secret is issued or used). I'm = just trying to understand your perspective eon why this "won't work = well". Perhaps you didn't mean this comment to refer to browser-based = OAuth clients generally?

  -Josh

On Fri, Jul 1, 2016 at 5:45 PM, = John Bradley <ve7jtb@ve7jtb.com> wrote:
I don=E2=80=99t think the post = response mode is supported by heart so I suspect that we are talking = about different things.

You are probably using the supported code flow that uses a = 302 get to return the code to the OAuth client on the server. =  
The Web server is then acting as a = confidential client to exchange the code via a POST (different POST) = with the AS token_endpoint.

The Token endpoint will return a access token (AT) and = optional refresh token (RT).

The web page may be getting the server = to make the OAuth calls on it=E2=80=99s behalf to the Resource Server, = or possibly you are passing the AT from the server back to a Java script = app that is using CORES to make calls directly to the RS without going = through the Web server.

Passing the AT back to the user agent from the client is not = recommended. 

For in browser clients where the JS is using the AT to make = the calls directly to the RS via CORES the recommended approach is to = use the fragment encoded response via a 302 to deliver the AT directly = to the client (It never hits the backend Web server).

However I believe In = browser OAuth clients are not currently supported in HEART, so I am not = quite sure what you are doing.

Perhaps Justin has a better = answer.

John = B.


On Jul = 1, 2016, at 5:33 PM, Josh Mandel <jmandel@gmail.com> wrote:

John,

I appreciate your = response. I'm hoping you can clarify why you say that "HTTP POST... = won't work well for... [a] single page OAuth client"?

We commonly build single-page apps that = act as OAuth clients for SMART (e.g. this = sample app ), and we've had good experience with the technique. = Could you elaborate?

  -J

On Fri, Jul 1, 2016 at 5:26 PM, = John Bradley <ve7jtb@ve7jtb.com> wrote:
HEART only supports web server = clients at the moment.   That might change in future to support = native apps if that an be made to support the security requirements of = Heath IT.

So the thing = HTTP POST responses won=E2=80=99t work well for is a type of in browser = single page OAuth client.  That still needs fragment encoded = responses or the new post-message Java Script API approach.

John B.


On Jul 1, 2016, at 5:16 PM, Josh Mandel = <jmandel@gmail.com> wrote:

Thanks Justin,

To clarify: John's comment and my = question were about POST. (I do understand the behavior of HTTP POST and = of window.postMessage; these are totally different things.) =46rom my = perspective in SMART Health IT, we use the OAuth 2.0 authorization code = flow, including HTTP POST, in our authorization spec even for public clients, and it = has worked very well for us, with about a dozen electronic health record = servers supporting this approach. That's why I was curious to hear = John's perspective about limitations.

  -J

On Fri, = Jul 1, 2016 at 5:09 PM, Oleg Gryb <oleg_gryb@yahoo.com> wrote:
> POST will send things to the server, which isn=E2=80=99t = desirable if your client is solely in the browser
Why it's not desirable, assuming that we = disregard performance? You can generate HTTP POST from JS, e.g. through = an AJAX call. What is wrong with this?


=
=
= From:= Justin Richer <jricher@mit.edu>
To: Josh Mandel <jmandel@gmail.com>
Cc: Oleg Gryb <oleg@gryb.info>; "<oauth@ietf.org>" <oauth@ietf.org>; Liyu Yi <liyuyi@gmail.com>
Sent: Friday, July 1, = 2016 2:00 PM

Subject:= Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant
=

POST will = send things to the server, which isn=E2=80=99t desirable if your client = is solely in the browser. postMessage is a browser API and not to be = confused with HTTP POST. postMessage messages stay (or can stay) within = the browser, which is the intent here.

 =E2=80=94 Justin

On Jul = 1, 2016, at 4:56 PM, Josh Mandel <jmandel@gmail.com> wrote:

John,

Could you = clarify what you mean by "POST= doesn't really work"? Do you just mean that CORS support (e.g., http://caniuse.com/#feat=3Dcors) isn't = universal, or something more?

On Fri, Jul 1, 2016 at 4:51 = PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
Yes but = POST doesn't really work for in browser apps.

If it is a server app it = should be using the code flow with GET or POST as you like.

If we do = a  post message based binding it will be targeted at in browser = applications.

John B.

On Fri, Jul 1, 2016 at 4:42 = PM, Liyu Yi <liyuyi@gmail.com> wrote:
BTW, I do = not see any significant performance concerns for post. Parsing and = executing the Javascript logic for post operation will be on the client = side, no extra server load is introduced.

Plus post will remove = the size restriction of the URL length.

-- = Liyu 

On Fri, Jul 1, 2016 at 1:35 = PM, Liyu Yi <liyuyi@gmail.com> wrote:
Thanks for the great comments and advices.

I think it is a good idea = for the working group to revise the fragment part in the spec, since = there might be public available tools already implemented this approach = and people can end up with a solution with serious security = loopholes.

The re-append issue can be mitigate by a logic on Resource = Server which carefully re-writes/removes the fragment in any redirect, = if the the redirect can not be avoided.

-- = Liyu
 

On Fri, Jul 1, 2016 at 11:33 = AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
This behaviour started changing around 2011

=46rom = HTTP/1.1
See https://tools.ietf.org/html/rfc7231#section-7.1.2I
    =   f the Location value provided in a 3xx (Redirection) response = does
   not have a fragment component, a user agent MUST =
process the
   redirection as if the value inherits the fragment component of the
   URI reference used to generate the request target (i.e., the
   redirection inherits the original reference's fragment, if any).

   For example, a GET request generated for the URI reference
   "http://www.example.org/~tim" might result in a 303 (See =
Other)
   response containing the header field:

     Location: /People.html#tim

   which suggests that the user agent redirect to
   "http://www.example.org/People.html#tim=E2=80=9D

   Likewise, a GET request generated for the URI =
reference
   "http://www.example.org/index.html#larry" might result in =
a 301
   (Moved Permanently) response containing the header field:

     Location: http://www.example.net/index.html

   which suggests that the user agent redirect to
   "http://www.example.net/index.html#larry", preserving the =
original
   fragment identifier.


This blog = also explores the change.
https://blogs.msdn.microsoft.com/ieinternals/2011/05/16/url-fra= gments-and-redirects/


On Jul 1, 2016, at 1:05 PM, Oleg Gryb <oleg_gryb@yahoo.com> wrote:

"Browsers now = re-append  fragments across 302 redirects unless they are = explicitly cleared this makes fragment encoding less safe than it was =  when originally specified" - thanks Jim. Looks like a good reason = for vetting this flow out.

John,
Please provide more details/links about re-appending = fragments. 

Thanks,
Oleg.


=
From: Jim Manico <jim@manicode.com>
To: = Oleg Gryb <oleg@gryb.info>
Cc: = "oauth@ietf.org" <oauth@ietf.org>; Liyu Yi <liyuyi@gmail.com>
Sent: = Thursday, June 30, 2016 10:25 PM
Subject:= Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

Oleg! Hello! = Great to see you pop up here with a similar concern.

John = Bradley just answered this thread with the details I was looking for = (thanks John, hat tip your way).

He also mentioned details about = fragment leakage:

"Browsers now = re-append  fragments across 302 redirects unless they are = explicitly cleared this makes fragment encoding less safe than it was = when originally specified"

Again, I'm new here but I'm grateful = for this conversation.

Aloha,
--
Jim Manico
@Manicode

On Jul 1, 2016, at 1:24 AM, Oleg Gryb <oleg_gryb@yahoo.com> wrote:

We've discussed access tokens in URI back in = 2010 (https://www.ietf.org/mail-archive/web/oauth/current/msg04043.ht= ml). There were two major objectives when I was saying that it's not = secure:

1. Fragment is not sent to = a server by a browser. When I've asked if this is true for every browser = in the world, nobody was able to answer.
2. Replacing with POST would mean a significant performance = impact in some high volume implementations (I think it was Goole folks = who were saying this, but I don't remember now).

AFAIR, nobody was arguing about browsing history, so it's = valid.

So, 6 years later we're at = square one with this and I hope that this time the community will be = more successful with getting rid of secrets in URL.

BTW, Jim, if you can come up with other scenarios when = fragments can leak, please share. It'll probably help the community with = solving this problem faster than in 6 years.

Thanks,
Oleg.


=
From: Jim Manico <jim@manicode.com>
To: = Liyu Yi <liyuyi@gmail.com>; oauth@ietf.org
Sent: = Wednesday, June 29, 2016 7:30 AM
Subject:= Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

> Shouldn=E2=80=99t it be more = secure if we change to use a post method for access token, similar to the SAML = does?
I say yes. But please note I'm very new at this and = someone with more experience will have more to say or correct my = comments.
Here are a few more details to consider.
1) OAuth is a framework and not a standard, per se. = Different authorization servers will have different implementations that are not necessarily compatible with other service providers. So there is no standard to break, per se.
2) Sensitive data in a URI is a bad idea. They leak = all over the place even over HTTPS. Even in fragments.
3) Break the "rules" and find a way to submit = sensitive data like access tokens, session information or any other (even short term) sensitive data in a secure fashion. This includes POST, JSON data payloads over PUT/PATCH and other verbs - all over well configured HTTPS.
4) If you really must submit sensitive data over GET = , consider JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level confidentiality and integrity.
Aloha,
Jim Manico
Manicode Security
https://www.manicode.com

On 6/27/16 9:30 PM, Liyu Yi = wrote:
While we are working on a = project with OAuth2 implementation, one question arises from our engineers.
We noticed at https://tools.ietf.org/html/draft-ietf-oauth-v2-31#page-30<= /span>, it is specified that
  
(C)  Assuming the resource = owner grants access, the authorization
        server redirects = the user-agent back to the client using the
        redirection URI = provided earlier.  The redirection URI includes
        the access token = in the URI fragment.
 
For my understanding, the = browser keeps the URI fragment in the history, and this introduces unexpected exposure of the access token. A user without authorization for the resource can get the access token as long as he has the access to the browser. This can happen in a shared computer in library, or for an IT staff who works on other employee=E2=80=99s computer.
 
Shouldn=E2=80=99t it be more = secure if we change to use a post method for access token, similar to the SAML does?
I feel there might be something = I missed here. Any advices will be appreciated.


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


--=20

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


=

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


=





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


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


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


=
=

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







= --Apple-Mail=_CAC5488D-8EBB-48CC-905C-255C4F21ECB1-- From nobody Fri Jul 1 17:18:36 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FEC912D73E for ; Fri, 1 Jul 2016 17:18:35 -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 ysRE21IL9rSg for ; Fri, 1 Jul 2016 17:18:30 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::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 0E77312B01B for ; Fri, 1 Jul 2016 17:18:29 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id e3so25581070qkd.0 for ; Fri, 01 Jul 2016 17:18:29 -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=wmmGap2FqLZ6PPJg6x9F9v86CQCleQIGD90Z/w+8ng0=; b=yc1Jx/TqZzdax4gHtFkud7QKpye0HJ5kP1/FiOFJqFfSjvztHPgbjlNPUPwBlyxcEa iQhGXpdhn42xnCracHi1zCHmgDr+TEOF9G/V4QXMWMVeV2TteUUOG599+YN278/uN8pz HEFBAajUq0iEDmLrxYRkUz9MBsoXSkjKDBlqoSSai8CJRC0YpK39Xd6I/vVLZeRcE83+ sKfi9QP8Cgd9qeGNqixU7zmS20xH1leEq3bS9ZKTq0I5ukkQaP2Pt925TCNB1JtsaXAV 4ZPzmiySiwqr3jrMZmlb7stnXhmHllVdJ+X4JxSJ0pWW6UOLeqOvCT2stT7mMKz6j0dK Jxsw== 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=wmmGap2FqLZ6PPJg6x9F9v86CQCleQIGD90Z/w+8ng0=; b=c15V1lH/Jx7GUxnDIq8eVG89T/AEGS2MkrY9m549BSF3jBG3RruNtOkeHcw0+BAKH8 54lozwVSXlM2flYgJWvq8GXHAAKsvdBFQAi4Dd4apxQt1vC6WalLaPdINWmjhX5O6GwN OFK4A3QeQjM9o7GDx42X3jiD53I4sibrjheTNTuppRshF1nJx+EGGLqjmYrqmLo9gbKa r2KqyonjmWsUllG5xP5f6+oiVSEL8YhGhd7pGxuk+yIMJCE513g/uRRkacemJ6hVdJoF L4YgIxad5rNZf5z7whiLDvVrOhXS8DBc8jNuTpmDY8zaduIsXfuNVU5wqGXUKI4GwG3E eC1g== X-Gm-Message-State: ALyK8tIBrALpSglikcRqrV4JiQiBnFpEhkOnP7+6+vddLutm9fuSd1i7I1XRT31EJs+AKkqe X-Received: by 10.233.232.12 with SMTP id a12mr1373563qkg.25.1467418708791; Fri, 01 Jul 2016 17:18:28 -0700 (PDT) Received: from [192.168.8.102] ([181.202.103.243]) by smtp.gmail.com with ESMTPSA id w17sm2241904qtc.47.2016.07.01.17.18.26 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 01 Jul 2016 17:18:28 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_D08A956B-130F-433E-B2FD-CE91622D8F0F" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: John Bradley In-Reply-To: Date: Fri, 1 Jul 2016 20:18:24 -0400 Message-Id: References: <994121658.55005.1467329084208.JavaMail.yahoo@mail.yahoo.com> <235316006.458279.1467392709447.JavaMail.yahoo@mail.yahoo.com> <6584BD74-B18F-4174-9E69-5C7B4B76F895@ve7jtb.com> <410908395.555462.1467407397629.JavaMail.yahoo@mail.yahoo.com> <8CC41328-C26D-42C0-BFDB-BF0216C7B76C@ve7jtb.com> <71CE61B3-FEC2-46A7-AB28-B53E89A8E53F@ve7jtb.com> To: Liyu Yi X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Oleg Gryb , "" Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2016 00:18:35 -0000 --Apple-Mail=_D08A956B-130F-433E-B2FD-CE91622D8F0F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 No not if it is a GET back to the same URI that loaded the JS and it is = cashed. At least that was the design by Facebook, Google and other at = the time. John B. > On Jul 1, 2016, at 7:26 PM, Liyu Yi wrote: >=20 > John, >=20 > I am a little bit confused :) > Are you talking about a SPA type of client application and concerning = the POST will reload the browser DOM from the RS domain? If that is the = case, even the current spec using a redirect with fragment in URL will = have the same behavior, right? =20 >=20 > On Fri, Jul 1, 2016 at 4:06 PM, John Bradley > wrote: > I take it that Web-hosted client resource is part of the client. >=20 > I think perhaps you have client and resource serve r mixed up a bit in = your diagram. >=20 > Yes you could do that but it is not a great way to build the client as = it will blow away context. =20 > You can do it but people generally want to start the application in = the browser first and then call out to the IdP in a iFrame. >=20 > What you propose would work more or less. I don=E2=80=99t see it as a = pattern that I would necessarily recommend over the current fragment = encoding. >=20 > If we mover to post message it would include API for logout and = session management, not just login. >=20 > John B. >=20 >=20 >> On Jul 1, 2016, at 6:43 PM, Liyu Yi > wrote: >>=20 >> Understood there is an Authorization Code grant type; here I am more = focusing on the Implicit grant type.=20 >> =20 >> also when I mentioned POST, I did not mean postMessage, it is simply = the HTTP POST. Specifically it is more like this ... >>=20 >>=20 >>=20 >> 4.2 . Implicit = Grant (modified) >>=20 >> +----------+ >> | Resource | >> | Owner | >> | | >> +----------+ >> ^ >> | >> (B) >> +----|-----+ Client Identifier +---------------+ >> | -+----(A)-- & Redirection URI --->| | >> | User- | | Authorization | >> | Agent -|----(B)-- User authenticates -->| Server | >> | | | | >> | |<---(C)- Response embedded JS -<| | >> | | with Access Token +---------------+ >> | | in JS content, which will be posted to = Resource Server >> | | +---------------+ >> | |----(D)-- JS post to RS URI --->| Web-Hosted | >> | | with Access Token | Client | >> | | | Resource | >> | (F) |<---(E)----- RS Script --------<| | >> | | with Access Token +---------------+ >> +-|--------+ >> | | >> (A) (G) Access Token >> | | >> ^ v >> +---------+ >> | | >> | Client | >> | | >> +---------+ >>=20 >>=20 >>=20 >> Figure 4: Implicit Grant Flow >>=20 >> The flow illustrated in Figure 4 includes the following steps: >>=20 >> (A) The client initiates the flow by directing the resource = owner's >> user-agent to the authorization endpoint. The client = includes >> its client identifier, requested scope, local state, and a >> redirection URI to which the authorization server will send = the >> user-agent back once access is granted (or denied). >>=20 >> (B) The authorization server authenticates the resource owner = (via >> the user-agent) and establishes whether the resource owner >> grants or denies the client's access request. >>=20 >> (C) Assuming the resource owner grants access, the authorization >> server responds with a JavaScript logic which automatically = posts to=20 >> "redirection" URI provided earlier. The JavaScript includes >> the access token in the URI fragment. >>=20 >> (D) The user-agent does the post with the access token. Granted, =20= >> user agent can actually do post without the access = token in a different iframe,=20 >> then use postMessage to pass the token over, but I = do not see why get it need that compexity. >>=20 >>=20 >> On Fri, Jul 1, 2016 at 3:13 PM, Josh Mandel > wrote: >> Thanks John! Yes, we're following the CORS based flow you've = described below (though I should note that the actual redirection back = to the client could be a 302, or could be a simple Web link that the = user follows from an authorization page; this is up to the authorization = server).=20 >>=20 >> Overall I don't argue that this flow is "more secure" than the = implicit flow -- though I believe it does help client developers avoid = some common pitfalls. (For example, clients that, through careless = programming or poor understanding of the spec, fail to validate incoming = "state" are still not susceptible to arbitrary token injection, which = means at least they won't readily be tricked into using a token = designated for an entirely different client. With poorly written = implicit flow clients, this is an issue.) >>=20 >> That said, I wasn't aiming to discuss the relative security; just = wanted to make sure I knew what you meant by "won't work well". >>=20 >> Thanks again! >>=20 >> -Josh >>=20 >> On Jul 1, 2016 18:02, "John Bradley" > wrote: >> I am making a distinction between a browser talking to a Web server = that is acting as a OAuth Client POST response mode =3D good , and a = oauth client running in the browser user agent as a Java script = application (that can=E2=80=99t directly capture a POST response back to = the server) >>=20 >> So it depends on where the client is actually running. >>=20 >> Are you saying that you are using a 302 redirect from the = authorization endpoint back to the server hosting the JS and then = loading the JS including the code and then using CORES to exchange the = code for a AT? >>=20 >> You can do that but I don=E2=80=99t think a public client like that = is more secure than just using the fragment encoded response and is more = work. >> It also may give the server a false sense of security. >>=20 >> John B. >>> On Jul 1, 2016, at 5:52 PM, Josh Mandel > wrote: >>>=20 >>> I think the confusion here is that I'm not using HEART's OAuth = profiles :-) >>>=20 >>> I'm using the SMART profiles, where we do specify the use of an = authorization code grant even for browser-based public clients (in which = case, no client_secret is issued or used). I'm just trying to understand = your perspective eon why this "won't work well". Perhaps you didn't mean = this comment to refer to browser-based OAuth clients generally? >>>=20 >>> -Josh >>>=20 >>> On Fri, Jul 1, 2016 at 5:45 PM, John Bradley > wrote: >>> I don=E2=80=99t think the post response mode is supported by heart = so I suspect that we are talking about different things. >>>=20 >>> You are probably using the supported code flow that uses a 302 get = to return the code to the OAuth client on the server. =20 >>> The Web server is then acting as a confidential client to exchange = the code via a POST (different POST) with the AS token_endpoint. >>>=20 >>> The Token endpoint will return a access token (AT) and optional = refresh token (RT). >>>=20 >>> The web page may be getting the server to make the OAuth calls on = it=E2=80=99s behalf to the Resource Server, or possibly you are passing = the AT from the server back to a Java script app that is using CORES to = make calls directly to the RS without going through the Web server. >>>=20 >>> Passing the AT back to the user agent from the client is not = recommended.=20 >>>=20 >>> For in browser clients where the JS is using the AT to make the = calls directly to the RS via CORES the recommended approach is to use = the fragment encoded response via a 302 to deliver the AT directly to = the client (It never hits the backend Web server). >>>=20 >>> However I believe In browser OAuth clients are not currently = supported in HEART, so I am not quite sure what you are doing. >>>=20 >>> Perhaps Justin has a better answer. >>>=20 >>> John B. >>>=20 >>>=20 >>>> On Jul 1, 2016, at 5:33 PM, Josh Mandel > wrote: >>>>=20 >>>> John, >>>>=20 >>>> I appreciate your response. I'm hoping you can clarify why you say = that "HTTP POST... won't work well for... [a] single page OAuth client"? >>>>=20 >>>> We commonly build single-page apps that act as OAuth clients for = SMART (e.g. this sample app = ), and we've had good experience with the = technique. Could you elaborate? >>>>=20 >>>> -J >>>>=20 >>>> On Fri, Jul 1, 2016 at 5:26 PM, John Bradley > wrote: >>>> HEART only supports web server clients at the moment. That might = change in future to support native apps if that an be made to support = the security requirements of Heath IT. >>>>=20 >>>> So the thing HTTP POST responses won=E2=80=99t work well for is a = type of in browser single page OAuth client. That still needs fragment = encoded responses or the new post-message Java Script API approach. >>>>=20 >>>> John B. >>>>=20 >>>>=20 >>>>> On Jul 1, 2016, at 5:16 PM, Josh Mandel > wrote: >>>>>=20 >>>>> Thanks Justin, >>>>>=20 >>>>> To clarify: John's comment and my question were about POST. (I do = understand the behavior of HTTP POST and of window.postMessage; these = are totally different things.) =46rom my perspective in SMART Health IT, = we use the OAuth 2.0 authorization code flow, including HTTP POST, in = our authorization spec = even for public clients, and it has worked very well for us, with about = a dozen electronic health record servers supporting this approach. = That's why I was curious to hear John's perspective about limitations. >>>>>=20 >>>>> -J >>>>>=20 >>>>> On Fri, Jul 1, 2016 at 5:09 PM, Oleg Gryb > wrote: >>>>> > POST will send things to the server, which isn=E2=80=99t = desirable if your client is solely in the browser >>>>> Why it's not desirable, assuming that we disregard performance? = You can generate HTTP POST from JS, e.g. through an AJAX call. What is = wrong with this? >>>>>=20 >>>>>=20 >>>>> From: Justin Richer > >>>>> To: Josh Mandel >=20 >>>>> Cc: Oleg Gryb >; = ">" >; Liyu Yi > >>>>> Sent: Friday, July 1, 2016 2:00 PM >>>>>=20 >>>>> Subject: Re: [OAUTH-WG] Security concern for URI fragment as = Implicit grant >>>>>=20 >>>>> POST will send things to the server, which isn=E2=80=99t desirable = if your client is solely in the browser. postMessage is a browser API = and not to be confused with HTTP POST. postMessage messages stay (or can = stay) within the browser, which is the intent here. >>>>>=20 >>>>> =E2=80=94 Justin >>>>>=20 >>>>>> On Jul 1, 2016, at 4:56 PM, Josh Mandel > wrote: >>>>>>=20 >>>>>=20 >>>>> John, >>>>>=20 >>>>> Could you clarify what you mean by "POST doesn't really work"? Do = you just mean that CORS support (e.g., http://caniuse.com/#feat=3Dcors = ) isn't universal, or something more? >>>>>=20 >>>>> On Fri, Jul 1, 2016 at 4:51 PM, John Bradley > wrote: >>>>> Yes but POST doesn't really work for in browser apps. >>>>>=20 >>>>> If it is a server app it should be using the code flow with GET or = POST as you like. >>>>>=20 >>>>> If we do a post message based binding it will be targeted at in = browser applications. >>>>>=20 >>>>> John B. >>>>>=20 >>>>> On Fri, Jul 1, 2016 at 4:42 PM, Liyu Yi > wrote: >>>>> BTW, I do not see any significant performance concerns for post. = Parsing and executing the Javascript logic for post operation will be on = the client side, no extra server load is introduced. >>>>>=20 >>>>> Plus post will remove the size restriction of the URL length. >>>>>=20 >>>>> -- Liyu=20 >>>>>=20 >>>>> On Fri, Jul 1, 2016 at 1:35 PM, Liyu Yi > wrote: >>>>> Thanks for the great comments and advices. >>>>>=20 >>>>> I think it is a good idea for the working group to revise the = fragment part in the spec, since there might be public available tools = already implemented this approach and people can end up with a solution = with serious security loopholes. >>>>>=20 >>>>> The re-append issue can be mitigate by a logic on Resource Server = which carefully re-writes/removes the fragment in any redirect, if the = the redirect can not be avoided. >>>>>=20 >>>>> -- Liyu >>>>> =20 >>>>>=20 >>>>> On Fri, Jul 1, 2016 at 11:33 AM, John Bradley > wrote: >>>>> This behaviour started changing around 2011 >>>>>=20 >>>>> =46rom HTTP/1.1 >>>>> See https://tools.ietf.org/html/rfc7231#section-7.1.2 = I >>>>> f the Location value provided in a 3xx (Redirection) = response does >>>>> not have a fragment component, a user agent MUST process the >>>>> redirection as if the value inherits the fragment component of = the >>>>> URI reference used to generate the request target (i.e., the >>>>> redirection inherits the original reference's fragment, if = any). >>>>>=20 >>>>> For example, a GET request generated for the URI reference >>>>> "http://www.example.org/~tim " = might result in a 303 (See Other) >>>>> response containing the header field: >>>>>=20 >>>>> Location: /People.html#tim >>>>>=20 >>>>> which suggests that the user agent redirect to >>>>> "http://www.example.org/People.html#tim = =E2=80=9D >>>>>=20 >>>>> Likewise, a GET request generated for the URI reference >>>>> "http://www.example.org/index.html#larry = " might result in a 301 >>>>> (Moved Permanently) response containing the header field: >>>>>=20 >>>>> Location: http://www.example.net/index.html = >>>>>=20 >>>>> which suggests that the user agent redirect to >>>>> "http://www.example.net/index.html#larry = ", preserving the original >>>>> fragment identifier. >>>>>=20 >>>>>=20 >>>>> This blog also explores the change. >>>>> = https://blogs.msdn.microsoft.com/ieinternals/2011/05/16/url-fragments-and-= redirects/ = >>>>>=20 >>>>>=20 >>>>>> On Jul 1, 2016, at 1:05 PM, Oleg Gryb > wrote: >>>>>>=20 >>>>>> "Browsers now re-append fragments across 302 redirects unless = they are explicitly cleared this makes fragment encoding less safe than = it was when originally specified" - thanks Jim. Looks like a good = reason for vetting this flow out. >>>>>>=20 >>>>>> John, >>>>>> Please provide more details/links about re-appending fragments.=20= >>>>>>=20 >>>>>> Thanks, >>>>>> Oleg. >>>>>>=20 >>>>>>=20 >>>>>> From: Jim Manico > >>>>>> To: Oleg Gryb >=20 >>>>>> Cc: "oauth@ietf.org " >; Liyu Yi > >>>>>> Sent: Thursday, June 30, 2016 10:25 PM >>>>>> Subject: Re: [OAUTH-WG] Security concern for URI fragment as = Implicit grant >>>>>>=20 >>>>>> Oleg! Hello! Great to see you pop up here with a similar concern. >>>>>>=20 >>>>>> John Bradley just answered this thread with the details I was = looking for (thanks John, hat tip your way). >>>>>>=20 >>>>>> He also mentioned details about fragment leakage: >>>>>>=20 >>>>>> "Browsers now re-append fragments across 302 redirects unless = they are explicitly cleared this makes fragment encoding less safe than = it was when originally specified" >>>>>>=20 >>>>>> Again, I'm new here but I'm grateful for this conversation. >>>>>>=20 >>>>>> Aloha, >>>>>> -- >>>>>> Jim Manico >>>>>> @Manicode >>>>>>=20 >>>>>> On Jul 1, 2016, at 1:24 AM, Oleg Gryb > wrote: >>>>>>=20 >>>>>>> We've discussed access tokens in URI back in 2010 = (https://www.ietf.org/mail-archive/web/oauth/current/msg04043.html = ). = There were two major objectives when I was saying that it's not secure: >>>>>>>=20 >>>>>>> 1. Fragment is not sent to a server by a browser. When I've = asked if this is true for every browser in the world, nobody was able to = answer. >>>>>>> 2. Replacing with POST would mean a significant performance = impact in some high volume implementations (I think it was Goole folks = who were saying this, but I don't remember now). >>>>>>>=20 >>>>>>> AFAIR, nobody was arguing about browsing history, so it's valid. >>>>>>>=20 >>>>>>> So, 6 years later we're at square one with this and I hope that = this time the community will be more successful with getting rid of = secrets in URL. >>>>>>>=20 >>>>>>> BTW, Jim, if you can come up with other scenarios when fragments = can leak, please share. It'll probably help the community with solving = this problem faster than in 6 years. >>>>>>>=20 >>>>>>> Thanks, >>>>>>> Oleg. >>>>>>>=20 >>>>>>>=20 >>>>>>> From: Jim Manico > >>>>>>> To: Liyu Yi >; = oauth@ietf.org =20 >>>>>>> Sent: Wednesday, June 29, 2016 7:30 AM >>>>>>> Subject: Re: [OAUTH-WG] Security concern for URI fragment as = Implicit grant >>>>>>>=20 >>>>>>> > Shouldn=E2=80=99t it be more secure if we change to use a post = method for access token, similar to the SAML does? >>>>>>> I say yes. But please note I'm very new at this and someone with = more experience will have more to say or correct my comments. >>>>>>> Here are a few more details to consider. >>>>>>> 1) OAuth is a framework and not a standard, per se. Different = authorization servers will have different implementations that are not = necessarily compatible with other service providers. So there is no = standard to break, per se. >>>>>>> 2) Sensitive data in a URI is a bad idea. They leak all over the = place even over HTTPS. Even in fragments. >>>>>>> 3) Break the "rules" and find a way to submit sensitive data = like access tokens, session information or any other (even short term) = sensitive data in a secure fashion. This includes POST, JSON data = payloads over PUT/PATCH and other verbs - all over well configured = HTTPS. >>>>>>> 4) If you really must submit sensitive data over GET , consider = JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level = confidentiality and integrity. >>>>>>> Aloha, >>>>>>> Jim Manico >>>>>>> Manicode Security >>>>>>> https://www.manicode.com >>>>>>> On 6/27/16 9:30 PM, Liyu Yi wrote: >>>>>>>> While we are working on a project with OAuth2 implementation, = one question arises from our engineers. >>>>>>>> We noticed at = https://tools.= ietf.org/html/draft-ietf-oauth-v2-31#page-30 = , it is = specified that >>>>>>>> =20 >>>>>>>> (C) Assuming the resource owner grants access, the = authorization >>>>>>>> server redirects the user-agent back to the client = using the >>>>>>>> redirection URI provided earlier. The redirection URI = includes >>>>>>>> the access token in the URI fragment. >>>>>>>> =20 >>>>>>>> For my understanding, the browser keeps the URI fragment in the = history, and this introduces unexpected exposure of the access token. A = user without authorization for the resource can get the access token as = long as he has the access to the browser. This can happen in a shared = computer in library, or for an IT staff who works on other employee=E2=80=99= s computer. >>>>>>>> =20 >>>>>>>> Shouldn=E2=80=99t it be more secure if we change to use a post = method for access token, similar to the SAML does? >>>>>>>> I feel there might be something I missed here. Any advices will = be appreciated. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>>=20 >>>>>>> --=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >>=20 >=20 >=20 --Apple-Mail=_D08A956B-130F-433E-B2FD-CE91622D8F0F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 No not if it is a GET back to the same URI that loaded the JS = and it is cashed.   At least that was the design by Facebook, = Google and other at the time.

John B.

On Jul 1, 2016, at 7:26 PM, = Liyu Yi <liyuyi@gmail.com> wrote:

John,

I = am a little bit confused :)
Are you talking about a = SPA type of client application and concerning the POST will reload the = browser DOM from the RS domain? If that is the case, even the current = spec using a redirect with fragment in URL will have the same behavior, = right?  

On Fri, Jul 1, 2016 at 4:06 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
I take it that Web-hosted = client resource is part of the client.

I think perhaps you have client and = resource serve r mixed up a bit in your diagram.

Yes you could do that but it is not a = great way to build the client as it will blow away context. =  
You can do it but people generally want to = start the application in the browser first and then call out to the IdP =  in a iFrame.

What you propose would work more or less.  I don=E2=80=99t= see it as a pattern that I would necessarily recommend over the current = fragment encoding.

If we mover to post message it would include API  for = logout and session management, not just login.

John B.


On Jul 1, 2016, at 6:43 PM, Liyu Yi <liyuyi@gmail.com> wrote:

Understood there = is an Authorization Code grant type; here I am more focusing on the = Implicit grant type. 
  
also when I mentioned POST, I did not mean postMessage, it is = simply the HTTP POST. Specifically it is more like this ...



4.2.  =
Implicit Grant (modified)



     +----------+
     | Resource |
     |  Owner   |
     |          |
     +----------+
          ^
          |
         (B)
     +----|-----+          Client Identifier     +---------------+
     |         -+----(A)-- & Redirection URI --->|               =
|
     |  User-   |                                | Authorization |
     |  Agent  -|----(B)-- User authenticates -->|     Server    |
     |          |                                |               |
     |          |<---(C)- Response embedded JS -<|               |
     |          |          with Access Token     +---------------+
     |          |            in JS content, which will be posted to =
Resource Server
     |          |                                +---------------+
     |          |----(D)-- JS post to RS URI --->|   Web-Hosted  |
     |          |         with Access Token      |     Client    |
     |          |                                |    Resource   |
     |     (F)  |<---(E)----- RS Script --------<|               |
     |          |         with Access Token      +---------------+
     +-|--------+
       |    |
      (A)  (G) Access Token
       |    |
       ^    v
     +---------+
     |         |
     |  Client |
     |         |
     +---------+



                       Figure 4: Implicit Grant Flow


   The flow illustrated in Figure 4 includes the following =
steps:

   (A)  The client initiates the flow by directing the resource owner's
        user-agent to the authorization endpoint.  The client includes
        its client identifier, requested scope, local state, and a
        redirection URI to which the authorization server will send the
        user-agent back once access is granted (or denied).

   (B)  The authorization server authenticates the resource owner (via
        the user-agent) and establishes whether the resource owner
        grants or denies the client's access request.

   (C)  Assuming the resource owner grants access, the authorization
        server responds with a JavaScript logic which automatically =
posts to=20
        "redirection" URI provided earlier.  The JavaScript includes
        the access token in the URI fragment.

   (D)  The user-agent does the post with the access token. Granted, =
 
   =
               user agent can actually do post without the access token  =
in a different iframe, 
   =
               then use postMessage to pass the token over, but I do not =
see why get it need that compexity.

On Fri, Jul 1, 2016 at 3:13 PM, = Josh Mandel <jmandel@gmail.com> wrote:

Thanks John! Yes, we're following the CORS based flow you've = described below (though I should note that the actual redirection back = to the client could be a 302, or could be a simple Web link that the = user follows from an authorization page; this is up to the authorization = server).

Overall I don't argue that this = flow is "more secure" than the implicit flow -- though I believe it does = help client developers avoid some common pitfalls. (For example, clients = that, through careless programming or poor understanding of the spec, = fail to validate incoming "state" are still not susceptible to arbitrary = token injection, which means at least they won't readily be tricked into = using a token designated for an entirely different client. With poorly = written implicit flow clients, this is an issue.)

That said, I wasn't aiming to discuss the relative security; = just wanted to make sure I knew what you meant by "won't work = well".

Thanks again!

-Josh

On Jul 1, 2016 18:02, "John Bradley" <ve7jtb@ve7jtb.com> wrote:
I am making a distinction = between a browser talking to a Web server that is acting as a OAuth = Client POST response mode =3D good , and a oauth client running in the = browser user agent as a Java script application (that can=E2=80=99t = directly capture a POST response back to the server)

So it depends on where the client is = actually running.

Are you saying that you are using a 302 redirect from the = authorization endpoint back to the server hosting the JS and then = loading the JS including the code and then using CORES  to exchange = the code for a AT?

You can do that but I don=E2=80=99t think a public client = like that is more secure than just using the fragment encoded response = and is more work.
It also may give the server a = false sense of security.

John B.
On Jul 1, 2016, at 5:52 PM, Josh Mandel = <jmandel@gmail.com> wrote:

I think the confusion here is = that I'm not using HEART's OAuth profiles :-)

I'm using the SMART profiles, where we = do specify the use of an authorization code grant even for browser-based = public clients (in which case, no client_secret is issued or used). I'm = just trying to understand your perspective eon why this "won't work = well". Perhaps you didn't mean this comment to refer to browser-based = OAuth clients generally?

  -Josh

On Fri, Jul 1, 2016 at 5:45 PM, = John Bradley <ve7jtb@ve7jtb.com> wrote:
I don=E2=80=99t think the post = response mode is supported by heart so I suspect that we are talking = about different things.

You are probably using the supported code flow that uses a = 302 get to return the code to the OAuth client on the server. =  
The Web server is then acting as a = confidential client to exchange the code via a POST (different POST) = with the AS token_endpoint.

The Token endpoint will return a access token (AT) and = optional refresh token (RT).

The web page may be getting the server = to make the OAuth calls on it=E2=80=99s behalf to the Resource Server, = or possibly you are passing the AT from the server back to a Java script = app that is using CORES to make calls directly to the RS without going = through the Web server.

Passing the AT back to the user agent from the client is not = recommended. 

For in browser clients where the JS is using the AT to make = the calls directly to the RS via CORES the recommended approach is to = use the fragment encoded response via a 302 to deliver the AT directly = to the client (It never hits the backend Web server).

However I believe In = browser OAuth clients are not currently supported in HEART, so I am not = quite sure what you are doing.

Perhaps Justin has a better = answer.

John = B.


On Jul = 1, 2016, at 5:33 PM, Josh Mandel <jmandel@gmail.com> wrote:

John,

I appreciate your = response. I'm hoping you can clarify why you say that "HTTP POST... = won't work well for... [a] single page OAuth client"?

We commonly build single-page apps that = act as OAuth clients for SMART (e.g. this = sample app ), and we've had good experience with the technique. = Could you elaborate?

  -J

On Fri, Jul 1, 2016 at 5:26 PM, = John Bradley <ve7jtb@ve7jtb.com> wrote:
HEART only supports web server = clients at the moment.   That might change in future to support = native apps if that an be made to support the security requirements of = Heath IT.

So the thing = HTTP POST responses won=E2=80=99t work well for is a type of in browser = single page OAuth client.  That still needs fragment encoded = responses or the new post-message Java Script API approach.

John B.


On Jul 1, 2016, at 5:16 PM, Josh Mandel = <jmandel@gmail.com> wrote:

Thanks Justin,

To clarify: John's comment and my = question were about POST. (I do understand the behavior of HTTP POST and = of window.postMessage; these are totally different things.) =46rom my = perspective in SMART Health IT, we use the OAuth 2.0 authorization code = flow, including HTTP POST, in our authorization spec even for public clients, and it = has worked very well for us, with about a dozen electronic health record = servers supporting this approach. That's why I was curious to hear = John's perspective about limitations.

  -J

On Fri, = Jul 1, 2016 at 5:09 PM, Oleg Gryb <oleg_gryb@yahoo.com> wrote:
> POST will send things to the server, which isn=E2=80=99t = desirable if your client is solely in the browser
Why it's not desirable, assuming that we = disregard performance? You can generate HTTP POST from JS, e.g. through = an AJAX call. What is wrong with this?


=
=
= From:= Justin Richer <jricher@mit.edu>
To: Josh Mandel <jmandel@gmail.com>
Cc: Oleg Gryb <oleg@gryb.info>; "<oauth@ietf.org>" <oauth@ietf.org>; Liyu Yi <liyuyi@gmail.com>
Sent: Friday, July 1, = 2016 2:00 PM

Subject:= Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant
=

POST will = send things to the server, which isn=E2=80=99t desirable if your client = is solely in the browser. postMessage is a browser API and not to be = confused with HTTP POST. postMessage messages stay (or can stay) within = the browser, which is the intent here.

 =E2=80=94 Justin

On Jul = 1, 2016, at 4:56 PM, Josh Mandel <jmandel@gmail.com> wrote:

John,

Could you = clarify what you mean by "POST= doesn't really work"? Do you just mean that CORS support (e.g., http://caniuse.com/#feat=3Dcors) isn't = universal, or something more?

On Fri, Jul 1, 2016 at 4:51 = PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
Yes but = POST doesn't really work for in browser apps.

If it is a server app it = should be using the code flow with GET or POST as you like.

If we do = a  post message based binding it will be targeted at in browser = applications.

John B.

On Fri, Jul 1, 2016 at 4:42 = PM, Liyu Yi <liyuyi@gmail.com> wrote:
BTW, I do = not see any significant performance concerns for post. Parsing and = executing the Javascript logic for post operation will be on the client = side, no extra server load is introduced.

Plus post will remove = the size restriction of the URL length.

-- = Liyu 

On Fri, Jul 1, 2016 at 1:35 = PM, Liyu Yi <liyuyi@gmail.com> wrote:
Thanks for the great comments and advices.

I think it is a good idea = for the working group to revise the fragment part in the spec, since = there might be public available tools already implemented this approach = and people can end up with a solution with serious security = loopholes.

The re-append issue can be mitigate by a logic on Resource = Server which carefully re-writes/removes the fragment in any redirect, = if the the redirect can not be avoided.

-- = Liyu
 

On Fri, Jul 1, 2016 at 11:33 = AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
This behaviour started changing around 2011

=46rom = HTTP/1.1
See https://tools.ietf.org/html/rfc7231#section-7.1.2I
    =   f the Location value provided in a 3xx (Redirection) response = does
   not have a fragment component, a user agent MUST =
process the
   redirection as if the value inherits the fragment component of the
   URI reference used to generate the request target (i.e., the
   redirection inherits the original reference's fragment, if any).

   For example, a GET request generated for the URI reference
   "http://www.example.org/~tim" might result in a 303 (See =
Other)
   response containing the header field:

     Location: /People.html#tim

   which suggests that the user agent redirect to
   "http://www.example.org/People.html#tim=E2=80=9D

   Likewise, a GET request generated for the URI =
reference
   "http://www.example.org/index.html#larry" might result in =
a 301
   (Moved Permanently) response containing the header field:

     Location: http://www.example.net/index.html

   which suggests that the user agent redirect to
   "http://www.example.net/index.html#larry", preserving the =
original
   fragment identifier.


This blog = also explores the change.
https://blogs.msdn.microsoft.com/ieinternals/2011/05/16/url-fra= gments-and-redirects/


On Jul 1, 2016, at 1:05 PM, Oleg Gryb <oleg_gryb@yahoo.com> wrote:

"Browsers now = re-append  fragments across 302 redirects unless they are = explicitly cleared this makes fragment encoding less safe than it was =  when originally specified" - thanks Jim. Looks like a good reason = for vetting this flow out.

John,
Please provide more details/links about re-appending = fragments. 

Thanks,
Oleg.


=
From: Jim Manico <jim@manicode.com>
To: = Oleg Gryb <oleg@gryb.info>
Cc: = "oauth@ietf.org" <oauth@ietf.org>; Liyu Yi <liyuyi@gmail.com>
Sent: = Thursday, June 30, 2016 10:25 PM
Subject:= Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

Oleg! Hello! = Great to see you pop up here with a similar concern.

John = Bradley just answered this thread with the details I was looking for = (thanks John, hat tip your way).

He also mentioned details about = fragment leakage:

"Browsers now = re-append  fragments across 302 redirects unless they are = explicitly cleared this makes fragment encoding less safe than it was = when originally specified"

Again, I'm new here but I'm grateful = for this conversation.

Aloha,
--
Jim Manico
@Manicode

On Jul 1, 2016, at 1:24 AM, Oleg Gryb <oleg_gryb@yahoo.com> wrote:

We've discussed access tokens in URI back in = 2010 (https://www.ietf.org/mail-archive/web/oauth/current/msg04043.ht= ml). There were two major objectives when I was saying that it's not = secure:

1. Fragment is not sent to = a server by a browser. When I've asked if this is true for every browser = in the world, nobody was able to answer.
2. Replacing with POST would mean a significant performance = impact in some high volume implementations (I think it was Goole folks = who were saying this, but I don't remember now).

AFAIR, nobody was arguing about browsing history, so it's = valid.

So, 6 years later we're at = square one with this and I hope that this time the community will be = more successful with getting rid of secrets in URL.

BTW, Jim, if you can come up with other scenarios when = fragments can leak, please share. It'll probably help the community with = solving this problem faster than in 6 years.

Thanks,
Oleg.


=
From: Jim Manico <jim@manicode.com>
To: = Liyu Yi <liyuyi@gmail.com>; oauth@ietf.org
Sent: = Wednesday, June 29, 2016 7:30 AM
Subject:= Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

> Shouldn=E2=80=99t it be more = secure if we change to use a post method for access token, similar to the SAML = does?
I say yes. But please note I'm very new at this and = someone with more experience will have more to say or correct my = comments.
Here are a few more details to consider.
1) OAuth is a framework and not a standard, per se. = Different authorization servers will have different implementations that are not necessarily compatible with other service providers. So there is no standard to break, per se.
2) Sensitive data in a URI is a bad idea. They leak = all over the place even over HTTPS. Even in fragments.
3) Break the "rules" and find a way to submit = sensitive data like access tokens, session information or any other (even short term) sensitive data in a secure fashion. This includes POST, JSON data payloads over PUT/PATCH and other verbs - all over well configured HTTPS.
4) If you really must submit sensitive data over GET = , consider JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level confidentiality and integrity.
Aloha,
Jim Manico
Manicode Security
https://www.manicode.com

On 6/27/16 9:30 PM, Liyu Yi = wrote:
While we are working on a = project with OAuth2 implementation, one question arises from our engineers.
We noticed at https://tools.ietf.org/html/draft-ietf-oauth-v2-31#page-30<= /span>, it is specified that
  
(C)  Assuming the resource = owner grants access, the authorization
        server redirects = the user-agent back to the client using the
        redirection URI = provided earlier.  The redirection URI includes
        the access token = in the URI fragment.
 
For my understanding, the = browser keeps the URI fragment in the history, and this introduces unexpected exposure of the access token. A user without authorization for the resource can get the access token as long as he has the access to the browser. This can happen in a shared computer in library, or for an IT staff who works on other employee=E2=80=99s computer.
 
Shouldn=E2=80=99t it be more = secure if we change to use a post method for access token, similar to the SAML does?
I feel there might be something = I missed here. Any advices will be appreciated.


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


--=20

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


=

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


=





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


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


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


=
=

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









= --Apple-Mail=_D08A956B-130F-433E-B2FD-CE91622D8F0F-- From nobody Fri Jul 1 17:39:39 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5B812D097 for ; Fri, 1 Jul 2016 17:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.034 X-Spam-Level: X-Spam-Status: No, score=-3.034 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=yahoo.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 TqHYD8A_MNWe for ; Fri, 1 Jul 2016 17:39:34 -0700 (PDT) Received: from nm13-vm0.bullet.mail.bf1.yahoo.com (nm13-vm0.bullet.mail.bf1.yahoo.com [98.139.213.79]) (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 B57AD12B05F for ; Fri, 1 Jul 2016 17:39:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1467419972; bh=kl/rrWbKT51xvE8K7CyYdX5326tbDJdlSOr3KcnGSBw=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=WsbIjokM+qv26WIx/PvYDjRBDHzxxbgmtxrnHG2+rKkhGyL6TJd9JLA2tInzav6LQmH6NAvX5fPxdSrFML8M1BOSrJRFjGdWWa2LSD6IJJaCym7hJMh+9YFEVsDl2vK53bjw0+9pjNEfZbdf1cZdezAxiphCSKJ5mHfAJmkLi2Pcj9XiXUONwlx8js9h7ujpA8UGW9l1b1kfLx8FGQH4e9HdqTD7lav9EjSTUC4yW2vntkypOU2y3hSyk3L6pKbiYulf4Hr0Mujlo7lvICZmbdPxM0/vNx076YlAs4l+rgaS3Q4RxI/hNoKpBdHCQsrNTjcA6jsRTWDfzWJRSEJDeg== Received: from [66.196.81.173] by nm13.bullet.mail.bf1.yahoo.com with NNFMP; 02 Jul 2016 00:39:32 -0000 Received: from [98.139.212.247] by tm19.bullet.mail.bf1.yahoo.com with NNFMP; 02 Jul 2016 00:39:32 -0000 Received: from [127.0.0.1] by omp1056.mail.bf1.yahoo.com with NNFMP; 02 Jul 2016 00:39:32 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 720302.94560.bm@omp1056.mail.bf1.yahoo.com X-YMail-OSG: OUvJ5VUVM1ndW2vPC908bDNSHzhBUbrisLzx7rMMekobcOnlrfPQE4XUiWFCZnJ R7vdzBwON256_N6cI0SpKe4g7hLxrhuKAVLba5Wx7oyLjLFb7worZd5.us1qHVmqJuICa0SaTYcy .u_W87xax.Srw6xSyugYfzS9moIBVbmz4eNf7cY3x8MZJfUZ7L8Lw73d7V_nK840cYkIXMMtovHE XLURRHgLHdP1jUJa4p9SDfz0cmOUPWG7djpkcDEPMoa3VtMPnJqqZ.vKxv_pL4905Sms.Usf._2Y 2N1V7A2pgkvKOptEcGjOB9S8BnS5lKn476fCdQyJkxgzlrpQzPp7UM19CA9lgezYkgUUty24fbDk hTeq95cHiiuTxxFOpaIkURAFoohjuLNVWdIdvvHGoXe5Cs43c76HUC7K9c6NLcX4aowJdQt6uRyN OP9.cE2wLPzx_alHsVrvcsPd6nVLT35QEE.YyqOF.Gqkauj17.6h4DTvd_LPn8q_MHOgxGFmG3jV tP0NRaqD0IXpU.EcP736eHWHrJMg8z13zF9XyuIo- Received: from jws106175.mail.bf1.yahoo.com by sendmailws137.mail.bf1.yahoo.com; Sat, 02 Jul 2016 00:39:32 +0000; 1467419972.234 Date: Sat, 2 Jul 2016 00:39:31 +0000 (UTC) From: Oleg Gryb To: John Bradley , Liyu Yi Message-ID: <560704570.608692.1467419971908.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: <994121658.55005.1467329084208.JavaMail.yahoo@mail.yahoo.com> <235316006.458279.1467392709447.JavaMail.yahoo@mail.yahoo.com> <6584BD74-B18F-4174-9E69-5C7B4B76F895@ve7jtb.com> <410908395.555462.1467407397629.JavaMail.yahoo@mail.yahoo.com> <8CC41328-C26D-42C0-BFDB-BF0216C7B76C@ve7jtb.com> <71CE61B3-FEC2-46A7-AB28-B53E89A8E53F@ve7jtb.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_608691_1985465874.1467419971885" Archived-At: Cc: Oleg Gryb , "" Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Oleg Gryb List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2016 00:39:38 -0000 ------=_Part_608691_1985465874.1467419971885 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think, the intention was not to share AT with the web-hosted client resou= rce. As you can see in the original flow the latter never receives the AT, = it simply provides code that can get AT from a fragment and some UI. In the= modified flow AT is sent to the web-hosted client resource, which makes se= curity worse in my view, because you have your AT exposed in two places now= - in the User Agent *and* in the web-hosted client resource. =20 From: John Bradley To: Liyu Yi =20 Cc: Oleg Gryb ; "" Sent: Friday, July 1, 2016 4:06 PM Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit gran= t =20 I take it that Web-hosted client resource is part of the client. I think perhaps you have client and resource serve r mixed up a bit in your= diagram. Yes you could do that but it is not a great way to build the client as it w= ill blow away context. =C2=A0You can do it but people generally want to sta= rt the application in the browser first and then call out to the IdP =C2=A0= in a iFrame. What you propose would work more or less. =C2=A0I don=E2=80=99t see it as a= pattern that I would necessarily recommend over the current fragment encod= ing. If we mover to post message it would include API =C2=A0for logout and sessi= on management, not just login. John B. On Jul 1, 2016, at 6:43 PM, Liyu Yi wrote: Understood there is an Authorization Code grant type; here I am more focusi= ng on the Implicit grant type.=C2=A0=C2=A0=C2=A0also when I mentioned POST,= I did not mean postMessage, it is simply the HTTP POST. Specifically it is= more like this ... 4.2. Implicit Grant (modified) +----------+ | Resource | | Owner | | | +----------+ ^ | (B) +----|-----+ Client Identifier +---------------+ | -+----(A)-- & Redirection URI --->| | | User- | | Authorization | | Agent -|----(B)-- User authenticates -->| Server | | | | | | |<---(C)- Response embedded JS -<| | | | with Access Token +---------------+ | | in JS content, which will be posted to Resourc= e Server | | +---------------+ | |----(D)-- JS post to RS URI --->| Web-Hosted | | | with Access Token | Client | | | | Resource | | (F) |<---(E)----- RS Script --------<| | | | with Access Token +---------------+ +-|--------+ | | (A) (G) Access Token | | ^ v +---------+ | | | Client | | | +---------+ Figure 4: Implicit Grant Flow The flow illustrated in Figure 4 includes the following steps: (A) The client initiates the flow by directing the resource owner's user-agent to the authorization endpoint. The client includes its client identifier, requested scope, local state, and a redirection URI to which the authorization server will send the user-agent back once access is granted (or denied). (B) The authorization server authenticates the resource owner (via the user-agent) and establishes whether the resource owner grants or denies the client's access request. (C) Assuming the resource owner grants access, the authorization server responds with a JavaScript logic which automatically posts t= o=20 "redirection" URI provided earlier. The JavaScript includes the access token in the URI fragment. (D) The user-agent does the post with the access token. Granted, = user agent can actually do post without the access token in a= different iframe, then use postMessage to pass the token= over, but I do not see why get it need that compexity. On Fri, Jul 1, 2016 at 3:13 PM, Josh Mandel wrote: Thanks John! Yes, we're following the CORS based flow you've described belo= w (though I should note that the actual redirection back to the client coul= d be a 302, or could be a simple Web link that the user follows from an aut= horization page; this is up to the authorization server). Overall I don't a= rgue that this flow is "more secure" than the implicit flow -- though I bel= ieve it does help client developers avoid some common pitfalls. (For exampl= e, clients that, through careless programming or poor understanding of the = spec, fail to validate incoming "state" are still not susceptible to arbitr= ary token injection, which means at least they won't readily be tricked int= o using a token designated for an entirely different client. With poorly wr= itten implicit flow clients, this is an issue.) That said, I wasn't aiming = to discuss the relative security; just wanted to make sure I knew what you = meant by "won't work well".Thanks again! -JoshOn Jul 1, 2016 18:02, "John B= radley" wrote: I am making a distinction between a browser talking to a Web server that is= acting as a OAuth Client POST response mode =3D good , and a oauth client = running in the browser user agent as a Java script application (that can=E2= =80=99t directly capture a POST response back to the server) So it depends on where the client is actually running. Are you saying that you are using a 302 redirect from the authorization end= point back to the server hosting the JS and then loading the JS including t= he code and then using CORES =C2=A0to exchange the code for a AT? You can do that but I don=E2=80=99t think a public client like that is more= secure than just using the fragment encoded response and is more work.It a= lso may give the server a false sense of security. John B. On Jul 1, 2016, at 5:52 PM, Josh Mandel wrote: I think the confusion here is that I'm not using HEART's OAuth profiles :-) I'm using the SMART profiles, where we do specify the use of an authorizati= on code grant even for browser-based public clients (in which case, no clie= nt_secret is issued or used). I'm just trying to understand your perspectiv= e eon why this "won't work well". Perhaps you didn't mean this comment to r= efer to browser-based OAuth clients generally? =C2=A0 -Josh On Fri, Jul 1, 2016 at 5:45 PM, John Bradley wrote: I don=E2=80=99t think the post response mode is supported by heart so I sus= pect that we are talking about different things. You are probably using the supported code flow that uses a 302 get to retur= n the code to the OAuth client on the server. =C2=A0The Web server is then = acting as a confidential client to exchange the code via a POST (different = POST) with the AS token_endpoint. The Token endpoint will return a access token (AT) and optional refresh tok= en (RT). The web page may be getting the server to make the OAuth calls on it=E2=80= =99s behalf to the Resource Server, or possibly you are passing the AT from= the server back to a Java script app that is using CORES to make calls dir= ectly to the RS without going through the Web server. Passing the AT back to the user agent from the client is not recommended.= =C2=A0 For in browser clients where the JS is using the AT to make the calls direc= tly to the RS via CORES the recommended approach is to use the fragment enc= oded response via a 302 to deliver the AT directly to the client (It never = hits the backend Web server). However I believe In browser OAuth clients are not currently supported in H= EART, so I am not quite sure what you are doing. Perhaps Justin has a better answer. John B. On Jul 1, 2016, at 5:33 PM, Josh Mandel wrote: John, I appreciate your response. I'm hoping you can clarify why you say that "HT= TP POST... won't work well for... [a] single page OAuth client"? We commonly build single-page apps that act as OAuth clients for SMART (e.g= . this sample app=C2=A0), and we've had good experience with the technique.= Could you elaborate? =C2=A0 -J On Fri, Jul 1, 2016 at 5:26 PM, John Bradley wrote: HEART only supports web server clients at the moment. =C2=A0 That might cha= nge in future to support native apps if that an be made to support the secu= rity requirements of Heath IT. So the thing HTTP POST responses won=E2=80=99t work well for is a type of i= n browser single page OAuth client.=C2=A0 That still needs fragment encoded= responses or the new post-message Java Script API approach. John B. On Jul 1, 2016, at 5:16 PM, Josh Mandel wrote: Thanks Justin, To clarify: John's comment and my question were about POST. (I do understan= d the behavior of HTTP POST and of window.postMessage; these are totally di= fferent things.) From my perspective in SMART Health IT, we use the OAuth 2= .0 authorization code flow, including HTTP POST, in our authorization spec= =C2=A0even for public clients, and it has worked very well for us, with abo= ut a dozen electronic health record servers supporting this approach. That'= s why I was curious to hear John's perspective about limitations. =C2=A0 -J On Fri, Jul 1, 2016 at 5:09 PM, Oleg Gryb wrote: > POST will send things to the server, which isn=E2=80=99t desirable if you= r client is solely in the browserWhy it's not desirable, assuming that we d= isregard performance? You can generate HTTP POST from JS, e.g. through an A= JAX call. What is wrong with this? =20 From: Justin Richer To: Josh Mandel =20 Cc: Oleg Gryb ; "" ; Liyu Y= i Sent: Friday, July 1, 2016 2:00 PM Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit gran= t =20 POST will send things to the server, which isn=E2=80=99t desirable if your = client is solely in the browser. postMessage is a browser API and not to be= confused with HTTP POST. postMessage messages stay (or can stay) within th= e browser, which is the intent here. =C2=A0=E2=80=94 Justin On Jul 1, 2016, at 4:56 PM, Josh Mandel wrote: John, Could you clarify what you mean by "POST doesn't really work"? Do you just = mean that CORS support (e.g.,=C2=A0http://caniuse.com/#feat=3Dcors) isn't u= niversal, or something more? On Fri, Jul 1, 2016 at 4:51 PM, John Bradley wrote: Yes but POST doesn't really work for in browser apps. If it is a server app it should be using the code flow with GET or POST as = you like. If we do a =C2=A0post message based binding it will be targeted at in brows= er applications. John B. On Fri, Jul 1, 2016 at 4:42 PM, Liyu Yi wrote: BTW, I do not see any significant performance concerns for post. Parsing an= d executing the Javascript logic for post operation will be on the client s= ide, no extra server load is introduced. Plus post will remove the size restriction of the URL length. -- Liyu=C2=A0 On Fri, Jul 1, 2016 at 1:35 PM, Liyu Yi wrote: Thanks for the great comments and advices. I think it is a good idea for the working group to revise the fragment part= in the spec, since there might be public available tools already implement= ed this approach and people can end up with a solution with serious securit= y loopholes. The re-append issue can be mitigate by a logic on Resource Server which car= efully re-writes/removes the fragment in any redirect, if the the redirect = can not be avoided. -- Liyu=C2=A0 On Fri, Jul 1, 2016 at 11:33 AM, John Bradley wrote: This behaviour started changing around 2011 >From HTTP/1.1See=C2=A0https://tools.ietf.org/html/rfc7231#section-7.1.2I=C2= =A0 =C2=A0 =C2=A0 f the Location value provided in a 3xx (Redirection) resp= onse does not have a fragment component, a user agent MUST process the redirection as if the value inherits the fragment component of the URI reference used to generate the request target (i.e., the redirection inherits the original reference's fragment, if any). For example, a GET request generated for the URI reference "http://www.example.org/~tim" might result in a 303 (See Other) response containing the header field: Location: /People.html#tim which suggests that the user agent redirect to "http://www.example.org/People.html#tim=E2=80=9D Likewise, a GET request generated for the URI reference "http://www.example.org/index.html#larry" might result in a 301 (Moved Permanently) response containing the header field: Location: http://www.example.net/index.html which suggests that the user agent redirect to "http://www.example.net/index.html#larry", preserving the original fragment identifier. This blog also explores the change.https://blogs.msdn.microsoft.com/ieinter= nals/2011/05/16/url-fragments-and-redirects/ On Jul 1, 2016, at 1:05 PM, Oleg Gryb wrote: "Browsers now re-append =C2=A0fragments across 302 redirects unless they ar= e explicitly cleared this makes fragment encoding less safe than it was =C2= =A0when originally specified" - thanks Jim. Looks like a good reason for ve= tting this flow out. John,Please provide more details/links about re-appending fragments.=C2=A0 Thanks,Oleg. =20 From: Jim Manico To: Oleg Gryb =20 Cc: "oauth@ietf.org" ; Liyu Yi Sent: Thursday, June 30, 2016 10:25 PM Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit gran= t =20 Oleg! Hello! Great to see you pop up here with a similar concern. John Bradley just answered this thread with the details I was looking for (= thanks John, hat tip your way). He also mentioned details about fragment leakage: "Browsers now re-append =C2=A0fragments across 302 redirects unless they ar= e explicitly cleared this makes fragment encoding less safe than it was whe= n originally specified" Again, I'm new here but I'm grateful for this conversation. Aloha,--Jim Manico@Manicode On Jul 1, 2016, at 1:24 AM, Oleg Gryb wrote: We've discussed access tokens in URI back in 2010 (https://www.ietf.org/mai= l-archive/web/oauth/current/msg04043.html). There were two major objectives= when I was saying that it's not secure: 1. Fragment is not sent to a server by a browser. When I've asked if this i= s true for every browser in the world, nobody was able to answer.2. Replaci= ng with POST would mean a significant performance impact in some high volum= e implementations (I think it was Goole folks who were saying this, but I d= on't remember now). AFAIR, nobody was arguing about browsing history, so it's valid. So, 6 years later we're at square one with this and I hope that this time t= he community will be more successful with getting rid of secrets in URL. BTW, Jim, if you can come up with other scenarios when fragments can leak, = please share. It'll probably help the community with solving this problem f= aster than in 6 years. Thanks,Oleg. =20 From: Jim Manico To: Liyu Yi ; oauth@ietf.org=20 Sent: Wednesday, June 29, 2016 7:30 AM Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit gran= t =20 > Shouldn=E2=80=99t it be more secure if we change to use a post method fo= r access token, similar to the SAML does? I say yes. But please note I'm ve= ry new at this and someone with more experience will have more to say or co= rrect my comments. Here are a few more details to consider. 1) OAuth is a framework and not a standard, per se. Different authorizati= on servers will have different implementations that are not necessarily com= patible with other service providers. So there is no standard to break, per= se. 2) Sensitive data in a URI is a bad idea. They leak all over the place ev= en over HTTPS. Even in fragments. 3) Break the "rules" and find a way to submit sensitive data like access = tokens, session information or any other (even short term) sensitive data i= n a secure fashion. This includes POST, JSON data payloads over PUT/PATCH a= nd other verbs - all over well configured HTTPS. 4) If you really must submit sensitive data over GET , consider JWT/JWS/J= WE (with limited scopes/lifetimes) to provide message level confidentiality= and integrity. Aloha, Jim Manico Manicode Security https://www.manicode.com=20 On 6/27/16 9:30 PM, Liyu Yi wrote: =20 While we are working on a project with OAuth2 implementation, one questio= n arises from our engineers. We noticed at https://tools.ietf.org/html/draf= t-ietf-oauth-v2-31#page-30, it is specified that =C2=A0=C2=A0 (C)=C2=A0 Ass= uming the resource owner grants access, the authorization =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 server redirects the user-agent back to the cli= ent using the =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 redirection URI pr= ovided earlier.=C2=A0 The redirection URI includes =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 the access token in the URI fragment. =C2=A0 For my unde= rstanding, the browser keeps the URI fragment in the history, and this intr= oduces unexpected exposure of the access token. A user without authorizati= on for the resource can get the access token as long as he has the access t= o the browser. This can happen in a shared computer in library, or for an I= T staff who works on other employee=E2=80=99s computer. =C2=A0 Shouldn=E2= =80=99t it be more secure if we change to use a post method for access toke= n, similar to the SAML does? I feel there might be something I missed here.= Any advices will be appreciated. =20 =20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 =20 --=20 =20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 =20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 =20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 =20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 ------=_Part_608691_1985465874.1467419971885 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think, the intention was not to share AT with the web-= hosted client resource. As you can see in the original flow the latter neve= r receives the AT, it simply provides code that can get AT from a fragment = and some UI. In the modified flow AT is sent to the web-hosted client resou= rce, which makes security worse in my view, because you have your AT expose= d in two places now - in the User Agent *and* in the web-hosted client reso= urce.



= From: John Bradley <ve7jtb@ve7jtb.com>
To: Liyu Yi <liyuyi@gmail.com> Cc: Oleg G= ryb <oleg@gryb.info>; "<oauth@ietf.org>" <oauth@ietf.org>=
Sent: Friday, July 1,= 2016 4:06 PM
Subject:= Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

I take it that Web-hosted client resource is part of the = client.

I think perhaps you h= ave client and resource serve r mixed up a bit in your diagram.

Yes you could do that but it is = not a great way to build the client as it will blow away context.  
You can do it but people generally want to start the application in the b= rowser first and then call out to the IdP  in a iFrame.

What you propose would work more or = less.  I don=E2=80=99t see it as a pattern that I would necessarily re= commend over the current fragment encoding.

If we mover to post mess= age it would include API  for logout and session management, not just = login.

John B.


On Jul 1, 2016, at 6:43 PM, Liyu Yi <liyuyi@gmail.com= > wrote:

Understood there is an Aut= horization Code grant type; here I am more focusing on the Implicit grant t= ype. 
  
also when I mentioned POST, I did not mean postMessage, = it is simply the HTTP POST. Specifically it is more like this ...

<= br clear=3D"none" class=3D"yiv6067780691">

4.2. Implicit Grant (modified)

     +------=
----+
     | Resource |
     |  Owner   |
     |          |
     +----------+
          ^
          |
         (B)
     +----|-----+          Client Identifier     +---------------+
     |         -+----(A)-- & Redirection URI --->|               |
     |  User-   |                                | Authorization |
     |  Agent  -|----(B)-- User authenticates -->|     Server    |
     |          |                                |               |
     |          |<---(C)- Response embedded JS -<|               |
     |          |          with Access Token     +---------------+
     |          |            in JS content, which will be posted to Resourc=
e Server
     |          |                                +---------------+
     |          |----(D)-- JS post to RS URI --->|   Web-Hosted  |
     |          |         with Access Token      |     Client    |
     |          |                                |    Resource   |
     |     (F)  |<---(E)----- RS Script --------<|               |
     |          |         with Access Token      +---------------+
     +-|--------+
       |    |
      (A)  (G) Access Token
       |    |
       ^    v
     +---------+
     |         |
     |  Client |
     |         |
     +---------+



                       Figure 4: Implicit Grant Flow


   The flow illustrated in Figure 4 includes the fo=
llowing steps:

   (A)  The client initiates the flow by directing the resource owner's
        user-agent to the authorization endpoint.  The client includes
        its client identifier, requested scope, local state, and a
        redirection URI to which the authorization server will send the
        user-agent back once access is granted (or denied).

   (B)  The authorization server authenticates the resource owner (via
        the user-agent) and establishes whether the resource owner
        grants or denies the client's access request.

   (C)  Assuming the resource owner grants access, the authorization
        server responds with a JavaScript logic which automatically posts t=
o=20
        "redirection" URI provided earlier.  The JavaScript includes
        the access token in the URI fragment.

   (D)  The user-agent does the post with the access token. Granted,  
                 =
 user agent can actually do post without the access token  in a different iframe,


On Fri, Jul 1, 2016 at 3:13 PM, Josh Mandel <= span class=3D"yiv6067780691" dir=3D"ltr"><jmandel@gmail.com>= wrote:
Thanks John! Y= es, we're following the CORS based flow you've described below (though I sh= ould note that the actual redirection back to the client could be a 302, or= could be a simple Web link that the user follows from an authorization pag= e; this is up to the authorization server).
Overall I don't argue that this flow is "more secure" than = the implicit flow -- though I believe it does help client developers avoid = some common pitfalls. (For example, clients that, through careless programm= ing or poor understanding of the spec, fail to validate incoming "state" ar= e still not susceptible to arbitrary token injection, which means at least = they won't readily be tricked into using a token designated for an entirely= different client. With poorly written implicit flow clients, this is an is= sue.)
That said, I wasn't ai= ming to discuss the relative security; just wanted to make sure I knew what= you meant by "won't work well".
Thanks again!
-Josh
On Jul 1, 2016 18:02, "John Bradley= " <ve7jtb@ve7jtb.com> wrote:
I am making a distinction between a brow= ser talking to a Web server that is acting as a OAuth Client POST response = mode =3D good , and a oauth client running in the browser user agent as a J= ava script application (that can=E2=80=99t directly capture a POST response= back to the server)

So it depends on wher= e the client is actually running.

Are = you saying that you are using a 302 redirect from the authorization endpoin= t back to the server hosting the JS and then loading the JS including the c= ode and then using CORES  to exchange the code for a AT?

You can do that but I don=E2=80=99t think a public = client like that is more secure than just using the fragment encoded respon= se and is more work.
It also may give the= server a false sense of security.

Joh= n B.
On Jul 1, 2016, at 5:52 PM, Josh Mandel <jmandel@gmail.com> w= rote:

I think the confusion here= is that I'm not using HEART's OAuth profiles :-)

I'm using the SMART profiles, where we do specify the use of an autho= rization code grant even for browser-based public clients (in which case, n= o client_secret is issued or used). I'm just trying to understand your pers= pective eon why this "won't work well". Perhaps you didn't mean this commen= t to refer to browser-based OAuth clients generally?

  -Josh
On Fri, Jul 1, 2016 at 5:45 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
I don=E2=80=99t t= hink the post response mode is supported by heart so I suspect that we are = talking about different things.

You are prob= ably using the supported code flow that uses a 302 get to return the code t= o the OAuth client on the server.  
= The Web server is then acting as a confidential client to exchange the code= via a POST (different POST) with the AS token_endpoint.

The Token endpoint will return a access token (AT) and o= ptional refresh token (RT).

The web pa= ge may be getting the server to make the OAuth calls on it=E2=80=99s behalf= to the Resource Server, or possibly you are passing the AT from the server= back to a Java script app that is using CORES to make calls directly to th= e RS without going through the Web server.

Passing the AT back to the user agent from the client is not recommend= ed. 

For in browser clients where= the JS is using the AT to make the calls directly to the RS via CORES the = recommended approach is to use the fragment encoded response via a 302 to d= eliver the AT directly to the client (It never hits the backend Web server)= .

However I believe In browser OAuth c= lients are not currently supported in HEART, so I am not quite sure what yo= u are doing.

Perhaps Justin has a bett= er answer.

John B.

On Jul 1, 2016, at 5:33 PM, Josh Mandel <jmandel@gmail.com> wro= te:

John,

I appreciate your response. I'm hoping you can clarify why you say= that "HTTP POST... won't work well for... [a] single page OAuth client"?
We commonly build single-page apps that act a= s OAuth clients for SMART (e.g. this s= ample app ), and we've had good experience with the technique. Cou= ld you elaborate?

  -J
<= br clear=3D"none" class=3D"yiv6067780691">
On Fri, Jul 1, 2016 at 5:26 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
HEART only suppo= rts web server clients at the moment.   That might change in future to= support native apps if that an be made to support the security requirement= s of Heath IT.

So the thing HTTP POST responses wo= n=E2=80=99t work well for is a type of in browser single page OAuth client.=   That still needs fragment encoded responses or the new post-message = Java Script API approach.

John B.


On Jul 1, 2016, at 5:16 PM, Josh Mandel <jmandel@gmail.= com> wrote:

Thanks Justin= ,

To clarify: John's comment and my question= were about POST. (I do understand the behavior of HTTP POST and of window.= postMessage; these are totally different things.) From my perspective in SM= ART Health IT, we use the OAuth 2.0 authorization code flow, including HTTP= POST, in our autho= rization spec even for public clients, and it has worked very well= for us, with about a dozen electronic health record servers supporting thi= s approach. That's why I was curious to hear John's perspective about limit= ations.

  -J

On Fri, Jul 1, 2016 at 5:09 PM, Oleg Gryb = <oleg_gryb@yahoo.com>= wrote:
> POST will send things to the server, = which isn=E2=80=99t desirable if your client is solely in the browser
=
Why it's not desirable, assuming t= hat we disregard performance? You can generate HTTP POST from JS, e.g. thro= ugh an AJAX call. What is wrong with this?
=


From: Justin Richer &l= t;jric= her@mit.edu>
To= : Josh Mandel <jmandel@gmail.com>
Cc: Oleg Gryb <oleg@gryb.info>;= "<oa= uth@ietf.org>" <oauth@ietf.org>; Liyu Yi <liyuyi@gmail.com><= br clear=3D"none" class=3D"yiv6067780691"> Sent: Frida= y, July 1, 2016 2:00 PM

Subject:= Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant
POST will send things to the server, which isn=E2=80= =99t desirable if your client is solely in the browser. postMessage is a br= owser API and not to be confused with HTTP POST. postMessage messages stay = (or can stay) within the browser, which is the intent here.

 =E2=80=94 Justin

<= div class=3D"yiv6067780691">On Jul 1, 2016, at 4:56 PM, Josh Mandel <jmand= el@gmail.com> wrote:

John,

Could you clarif= y what you mean by "POST doesn't really work"? Do you just mean that CORS support (e.g.,&nbs= p;http://caniuse.com/#feat=3Dcor= s) isn't universal, or something more?

On Fri, Jul 1, 2016 at 4:51 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
Yes but POST doesn't really work for in browser = apps.

If it is a server app it should be usi= ng the code flow with GET or POST as you like.

If we do a  post message based binding it will be targeted at= in browser applications.

John B.

On Fri, Jul 1, 2016 at 4:42 PM, Liyu Yi <liyuyi@gmail.com> wro= te:
BTW, I do not see any signifi= cant performance concerns for post. Parsing and executing the Javascript lo= gic for post operation will be on the client side, no extra server load is = introduced.

Plus post will remove the size r= estriction of the URL length.

-- Liyu 

On Fri, Jul 1, 2016 at 1:35 PM= , Liyu Yi <liyuyi@gmail.com>= ; wrote:
Thanks for the great comments and advices.

I think it i= s a good idea for the working group to revise the fragment part in the spec= , since there might be public available tools already implemented this appr= oach and people can end up with a solution with serious security loopholes.=

The re-append issue can be mitigate by a lo= gic on Resource Server which carefully re-writes/removes the fragment in an= y redirect, if the the redirect can not be avoided.
<= div class=3D"yiv6067780691">
-- Liyu
 

On Fri, Jul 1, 2016 at 11:33 A= M, John Bradley <ve7jtb@ve7jtb.c= om> wrote:
This behaviour started changing around 2011

From HTTP/1.1
See https://tools.ietf.o= rg/html/rfc7231#section-7.1.2I
      f th= e Location value provided in a 3xx (Redirection) response does
= 
   not have a fragment component, a us=
er agent MUST process the
   redirection as if the value inherits the fragment component of the
   URI reference used to generate the request target (i.e., the
   redirection inherits the original reference's fragment, if any).

   For example, a GET request generated for the URI reference
   "http://www.example.org/~tim"=
 might result in a 303 (See Other)
   response containing the header field:

     Location: /People.html#tim

   which suggests that the user agent redirect to
   "http://www.example.or=
g/People.html#tim=E2=80=9D
   Likewise, a GET request generated =
for the URI reference
   "http://www.example.o=
rg/index.html#larry" might result in a 301
   (Moved Permanently) response containing the header field:

     Location: http://www.exam=
ple.net/index.html

   which suggests that the user agent redirect to
   "http://www.example.n=
et/index.html#larry", preserving the original
   fragment identifier.


This blog also explores the = change.
https://blog= s.msdn.microsoft.com/ieinternals/2011/05/16/url-fragments-and-redirects/



=
"Browsers now re-append  fragments across 302 redirects unless they a= re explicitly cleared this makes fragment encoding less safe than it was &n= bsp;when originally specified" - thanks Jim. Looks like a good reason for v= etting this flow out.

John,
Please provide mo= re details/links about re-appending fragments. 

Thanks,
Oleg.


From: Jim Manico <jim@manicode.com>
To: O= leg Gryb <oleg@gryb.info>
Cc: "oauth@ietf.org" <oauth@ietf.org>; Liyu Yi <liyuyi@gmail.= com>
Sent: Thursday, June 30, 2016 10:25 PM
Subject: Re: [OAUTH-WG] Security concern for U= RI fragment as Implicit grant
<= /div>

Oleg! Hello! Great to see you pop up here with a similar con= cern.

John Bradley just answered this = thread with the details I was looking for (thanks John, hat tip your way).<= /div>

He also mentioned details about fragme= nt leakage:

"Browsers now re-append  fragments across 302 redirects unless the= y are explicitly cleared this makes fragment encoding less safe than it was= when originally specified"

Aga= in, I'm new here but I'm grateful for this conversation.

Aloha,
--
Jim Manico
@Manicode

On Jul = 1, 2016, at 1:24 AM, Oleg Gryb <oleg_gryb@yahoo.com> wrote:

= We've discussed access tokens in URI back in 2010 (https://www.iet= f.org/mail-archive/web/oauth/current/msg04043.html). There were two maj= or objectives when I was saying that it's not secure:

<= div class=3D"yiv6067780691" dir=3D"ltr">1. Fragment is not sent to a server= by a browser. When I've asked if this is true for every browser in the wor= ld, nobody was able to answer.
2. Replacing with POST would mean a significant performance impact in som= e high volume implementations (I think it was Goole folks who were saying t= his, but I don't remember now).

AFAIR, nobody was arguing about browsing history, so it's= valid.

So, 6 = years later we're at square one with this and I hope that this time the com= munity will be more successful with getting rid of secrets in URL.

BTW, Jim, if you can c= ome up with other scenarios when fragments can leak, please share. It'll pr= obably help the community with solving this problem faster than in 6 years.=

Thanks,
=
Oleg.


= From: Jim Manico <jim@manicode.com>
To: Liyu Yi <liyuyi@gma= il.com>; oauth@ietf.org
Sent: Wednesday, June 29, 2016 7:30 AM
Subject: Re: [OAUTH-WG] Securi= ty concern for URI fragment as Implicit grant

> Shouldn= =E2=80=99t it be more secure if we change to use a post method for access token, similar to the SAML does?
I say yes. But please note I'm very new at= this and someone with more experience will have more to say or correct my comments.
Here are a few more details to consider.
1) OAuth is a framework and not a standard= , per se. Different authorization servers will have different implementations that are not necessarily compatible with other service providers. So there is no standard to break, per se.
2) Sensitive data in a URI is a bad idea. = They leak all over the place even over HTTPS. Even in fragments.
3) Break the "rules" and find a way to sub= mit sensitive data like access tokens, session information or any other (even short term) sensitive data in a secure fashion. This includes POST, JSON data payloads over PUT/PATCH and other verbs - all over well configured HTTPS.
4) If you really must submit sensitive dat= a over GET , consider JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level confidentiality and integrity.
Aloha,
Jim Manico
Manicode Security
https://www.manicode.com

On 6/27/16 9:= 30 PM, Liyu Yi wrote:
While we= are working on a project with OAuth2 implementation, one question arises from our engineers.
We notic= ed at https://tools.ietf.org/html/draft-ietf= -oauth-v2-31#page-30, it is specified that
  
(C) = ; Assuming the resource owner grants access, the authorization
 &n= bsp;      server redirects the user-agent back to the client using the
 &n= bsp;      redirection URI provided earlier.  The redirection URI includes
 &n= bsp;      the access token in the URI fragment.
 
For my u= nderstanding, the browser keeps the URI fragment in the history, and this introduces unexpected exposure of the access token. A user without authorization for the resource can get the access token as long as he has the access to the browser. This can happen in a shared computer in library, or for an IT staff who works on other employee=E2=80=99s computer.
 
Shouldn= =E2=80=99t it be more secure if we change to use a post method for access token, similar to the SAML does?
I feel t= here might be something I missed here. Any advices will be appreciated.


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


--=20

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


<= /div>

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


<= /div>




<= /div>
________________________________= _______________
OAuth mailing list
OAuth@ie= tf.org
https://www.ietf.org= /mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
OAuth@i= etf.org
https://www.ietf.org/mailman/listinfo/oau= th


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



_______________________________________________
OAuth mailing list
OAuth@i= etf.org
https://www.ietf.org/mailman/listinfo/oau= th
<= br clear=3D"none" class=3D"yiv6067780691">

<= /div>

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

------=_Part_608691_1985465874.1467419971885-- From nobody Fri Jul 1 17:54:08 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0923C12B059 for ; Fri, 1 Jul 2016 17:54:07 -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 2CayMmeCDL8X for ; Fri, 1 Jul 2016 17:54:02 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1848C12B019 for ; Fri, 1 Jul 2016 17:54:01 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id e3so25975327qkd.0 for ; Fri, 01 Jul 2016 17:54:01 -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=u8XUp6hbIlIV1ZsrqMJesgrZ/orbOXoHJ+2C4A/mWUc=; b=Qd0yXdcvYj1tkdTvPT0hpBjC9KbfI99JXhzVZKjQjtA9G008W8Fyj80cealZcr/Lx0 v26ej5TzqcQaZa8FtYZF2veDLi6EW7bgxhNO8nt34sPNwY81dlSPpYgk1zqEQlmwcxlT 4UkicejQ52iJFQqaW6WxC0ut3Zss7MFMALZEX1Xw0KB7IEtEzY56nMPSMD3zUGpsLILN J+lCsjmwZrnd/BTWuFtgygnBPAQTE1cQiLDPIrWbh/jhzSTmuOV8I300uCPSv23q4b8S gBb59P6quHOffzPYOLo/3AKr6Y426iGYpEzdzbf1au6IRoIP6RSTR1P7wnnV1AcksBf5 IVoA== 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=u8XUp6hbIlIV1ZsrqMJesgrZ/orbOXoHJ+2C4A/mWUc=; b=g8dJ6dKHr4mF4yAXO+A33ZokpN1wBadTAKBh2GA8mt5lj4DtZxvnNdG6cW7tHQeQ9h XQnmuQP3q4Dg1usppnvOpeCEikFnI44nS7+DCWrkMVDby4HVemtuRBmHn6u9GYEtFZsj mSKmhKw9M3GktWXaSs8uYkpM23AcHJ3oMY7/S4oAfIzEfUdwLmsU6vhXqBkULOTt91Vj X/UTRPup0U/RyXfR8oPUyWPBd0H3oWC/aVm05fZajy3QzipLLHlDc963Q2XwXiwkbvFF MvRh3UOcpAWar77jJR4YNJb7knXn6IhMo1pZvkaOYGr47hq0+62KmkJQVlejcG5MuVfM IZmA== X-Gm-Message-State: ALyK8tJFILyCw+1Oi9NoyTQCQcoiGm39EArX3Yh0ct4rXrJol0eKI2AF4ctzMTSNUBcxxo0Q X-Received: by 10.55.182.131 with SMTP id g125mr1410179qkf.171.1467420840883; Fri, 01 Jul 2016 17:54:00 -0700 (PDT) Received: from [192.168.8.102] ([181.202.103.243]) by smtp.gmail.com with ESMTPSA id h68sm2353218qkc.37.2016.07.01.17.53.58 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 01 Jul 2016 17:54:00 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_9B3FD9E0-ED0A-4EF7-AD42-A01106395419" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: John Bradley In-Reply-To: <560704570.608692.1467419971908.JavaMail.yahoo@mail.yahoo.com> Date: Fri, 1 Jul 2016 20:53:56 -0400 Message-Id: <50E491F2-E08F-40A7-B9DE-AB50CB647C04@ve7jtb.com> References: <994121658.55005.1467329084208.JavaMail.yahoo@mail.yahoo.com> <235316006.458279.1467392709447.JavaMail.yahoo@mail.yahoo.com> <6584BD74-B18F-4174-9E69-5C7B4B76F895@ve7jtb.com> <410908395.555462.1467407397629.JavaMail.yahoo@mail.yahoo.com> <8CC41328-C26D-42C0-BFDB-BF0216C7B76C@ve7jtb.com> <71CE61B3-FEC2-46A7-AB28-B53E89A8E53F@ve7jtb.com> <560704570.608692.1467419971908.JavaMail.yahoo@mail.yahoo.com> To: Oleg Gryb X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "" , Liyu Yi Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2016 00:54:07 -0000 --Apple-Mail=_9B3FD9E0-ED0A-4EF7-AD42-A01106395419 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 yes > On Jul 1, 2016, at 8:39 PM, Oleg Gryb wrote: >=20 > I think, the intention was not to share AT with the web-hosted client = resource. As you can see in the original flow the latter never receives = the AT, it simply provides code that can get AT from a fragment and some = UI. In the modified flow AT is sent to the web-hosted client resource, = which makes security worse in my view, because you have your AT exposed = in two places now - in the User Agent *and* in the web-hosted client = resource. >=20 >=20 >=20 > From: John Bradley > To: Liyu Yi =20 > Cc: Oleg Gryb ; "" > Sent: Friday, July 1, 2016 4:06 PM > Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit = grant >=20 > I take it that Web-hosted client resource is part of the client. >=20 > I think perhaps you have client and resource serve r mixed up a bit in = your diagram. >=20 > Yes you could do that but it is not a great way to build the client as = it will blow away context. =20 > You can do it but people generally want to start the application in = the browser first and then call out to the IdP in a iFrame. >=20 > What you propose would work more or less. I don=E2=80=99t see it as a = pattern that I would necessarily recommend over the current fragment = encoding. >=20 > If we mover to post message it would include API for logout and = session management, not just login. >=20 > John B. >=20 >=20 >> On Jul 1, 2016, at 6:43 PM, Liyu Yi > wrote: >>=20 >> Understood there is an Authorization Code grant type; here I am more = focusing on the Implicit grant type.=20 >> =20 >> also when I mentioned POST, I did not mean postMessage, it is simply = the HTTP POST. Specifically it is more like this ... >>=20 >>=20 >>=20 >> 4.2 . Implicit Grant = (modified) >> +----------+ >> | Resource | >> | Owner | >> | | >> +----------+ >> ^ >> | >> (B) >> +----|-----+ Client Identifier +---------------+ >> | -+----(A)-- & Redirection URI --->| | >> | User- | | Authorization | >> | Agent -|----(B)-- User authenticates -->| Server | >> | | | | >> | |<---(C)- Response embedded JS -<| | >> | | with Access Token +---------------+ >> | | in JS content, which will be posted to = Resource Server >> | | +---------------+ >> | |----(D)-- JS post to RS URI --->| Web-Hosted | >> | | with Access Token | Client | >> | | | Resource | >> | (F) |<---(E)----- RS Script --------<| | >> | | with Access Token +---------------+ >> +-|--------+ >> | | >> (A) (G) Access Token >> | | >> ^ v >> +---------+ >> | | >> | Client | >> | | >> +---------+ >>=20 >>=20 >>=20 >> Figure 4: Implicit Grant Flow >>=20 >> The flow illustrated in Figure 4 includes the following steps: >>=20 >> (A) The client initiates the flow by directing the resource = owner's >> user-agent to the authorization endpoint. The client = includes >> its client identifier, requested scope, local state, and a >> redirection URI to which the authorization server will send = the >> user-agent back once access is granted (or denied). >>=20 >> (B) The authorization server authenticates the resource owner = (via >> the user-agent) and establishes whether the resource owner >> grants or denies the client's access request. >>=20 >> (C) Assuming the resource owner grants access, the authorization >> server responds with a JavaScript logic which automatically = posts to=20 >> "redirection" URI provided earlier. The JavaScript includes >> the access token in the URI fragment. >>=20 >> (D) The user-agent does the post with the access token. Granted, =20= >> user agent can actually do post without the access = token in a different iframe,=20 >> then use postMessage to pass the token over, but I = do not see why get it need that compexity. >>=20 >>=20 >> On Fri, Jul 1, 2016 at 3:13 PM, Josh Mandel > wrote: >> Thanks John! Yes, we're following the CORS based flow you've = described below (though I should note that the actual redirection back = to the client could be a 302, or could be a simple Web link that the = user follows from an authorization page; this is up to the authorization = server). >> Overall I don't argue that this flow is "more secure" than the = implicit flow -- though I believe it does help client developers avoid = some common pitfalls. (For example, clients that, through careless = programming or poor understanding of the spec, fail to validate incoming = "state" are still not susceptible to arbitrary token injection, which = means at least they won't readily be tricked into using a token = designated for an entirely different client. With poorly written = implicit flow clients, this is an issue.) >> That said, I wasn't aiming to discuss the relative security; just = wanted to make sure I knew what you meant by "won't work well". >> Thanks again! >> -Josh >> On Jul 1, 2016 18:02, "John Bradley" > wrote: >> I am making a distinction between a browser talking to a Web server = that is acting as a OAuth Client POST response mode =3D good , and a = oauth client running in the browser user agent as a Java script = application (that can=E2=80=99t directly capture a POST response back to = the server) >>=20 >> So it depends on where the client is actually running. >>=20 >> Are you saying that you are using a 302 redirect from the = authorization endpoint back to the server hosting the JS and then = loading the JS including the code and then using CORES to exchange the = code for a AT? >>=20 >> You can do that but I don=E2=80=99t think a public client like that = is more secure than just using the fragment encoded response and is more = work. >> It also may give the server a false sense of security. >>=20 >> John B. >>> On Jul 1, 2016, at 5:52 PM, Josh Mandel > wrote: >>>=20 >>> I think the confusion here is that I'm not using HEART's OAuth = profiles :-) >>>=20 >>> I'm using the SMART profiles, where we do specify the use of an = authorization code grant even for browser-based public clients (in which = case, no client_secret is issued or used). I'm just trying to understand = your perspective eon why this "won't work well". Perhaps you didn't mean = this comment to refer to browser-based OAuth clients generally? >>>=20 >>> -Josh >>>=20 >>> On Fri, Jul 1, 2016 at 5:45 PM, John Bradley > wrote: >>> I don=E2=80=99t think the post response mode is supported by heart = so I suspect that we are talking about different things. >>>=20 >>> You are probably using the supported code flow that uses a 302 get = to return the code to the OAuth client on the server. =20 >>> The Web server is then acting as a confidential client to exchange = the code via a POST (different POST) with the AS token_endpoint. >>>=20 >>> The Token endpoint will return a access token (AT) and optional = refresh token (RT). >>>=20 >>> The web page may be getting the server to make the OAuth calls on = it=E2=80=99s behalf to the Resource Server, or possibly you are passing = the AT from the server back to a Java script app that is using CORES to = make calls directly to the RS without going through the Web server. >>>=20 >>> Passing the AT back to the user agent from the client is not = recommended.=20 >>>=20 >>> For in browser clients where the JS is using the AT to make the = calls directly to the RS via CORES the recommended approach is to use = the fragment encoded response via a 302 to deliver the AT directly to = the client (It never hits the backend Web server). >>>=20 >>> However I believe In browser OAuth clients are not currently = supported in HEART, so I am not quite sure what you are doing. >>>=20 >>> Perhaps Justin has a better answer. >>>=20 >>> John B. >>>=20 >>>=20 >>>> On Jul 1, 2016, at 5:33 PM, Josh Mandel > wrote: >>>>=20 >>>> John, >>>>=20 >>>> I appreciate your response. I'm hoping you can clarify why you say = that "HTTP POST... won't work well for... [a] single page OAuth client"? >>>>=20 >>>> We commonly build single-page apps that act as OAuth clients for = SMART (e.g. this sample app = ), and we've had good experience with the = technique. Could you elaborate? >>>>=20 >>>> -J >>>>=20 >>>> On Fri, Jul 1, 2016 at 5:26 PM, John Bradley > wrote: >>>> HEART only supports web server clients at the moment. That might = change in future to support native apps if that an be made to support = the security requirements of Heath IT. >>>>=20 >>>> So the thing HTTP POST responses won=E2=80=99t work well for is a = type of in browser single page OAuth client. That still needs fragment = encoded responses or the new post-message Java Script API approach. >>>>=20 >>>> John B. >>>>=20 >>>>=20 >>>>> On Jul 1, 2016, at 5:16 PM, Josh Mandel > wrote: >>>>>=20 >>>>> Thanks Justin, >>>>>=20 >>>>> To clarify: John's comment and my question were about POST. (I do = understand the behavior of HTTP POST and of window.postMessage; these = are totally different things.) =46rom my perspective in SMART Health IT, = we use the OAuth 2.0 authorization code flow, including HTTP POST, in = our authorization spec = even for public clients, and it has worked very well for us, with about = a dozen electronic health record servers supporting this approach. = That's why I was curious to hear John's perspective about limitations. >>>>>=20 >>>>> -J >>>>>=20 >>>>> On Fri, Jul 1, 2016 at 5:09 PM, Oleg Gryb > wrote: >>>>> > POST will send things to the server, which isn=E2=80=99t = desirable if your client is solely in the browser >>>>> Why it's not desirable, assuming that we disregard performance? = You can generate HTTP POST from JS, e.g. through an AJAX call. What is = wrong with this? >>>>>=20 >>>>>=20 >>>>> From: Justin Richer > >>>>> To: Josh Mandel >=20 >>>>> Cc: Oleg Gryb >; = ">" >; Liyu Yi > >>>>> Sent: Friday, July 1, 2016 2:00 PM >>>>>=20 >>>>> Subject: Re: [OAUTH-WG] Security concern for URI fragment as = Implicit grant >>>>>=20 >>>>> POST will send things to the server, which isn=E2=80=99t desirable = if your client is solely in the browser. postMessage is a browser API = and not to be confused with HTTP POST. postMessage messages stay (or can = stay) within the browser, which is the intent here. >>>>>=20 >>>>> =E2=80=94 Justin >>>>>=20 >>>>>> On Jul 1, 2016, at 4:56 PM, Josh Mandel > wrote: >>>>>>=20 >>>>>=20 >>>>> John, >>>>>=20 >>>>> Could you clarify what you mean by "POST doesn't really work"? Do = you just mean that CORS support (e.g., http://caniuse.com/#feat=3Dcors = ) isn't universal, or something more? >>>>>=20 >>>>> On Fri, Jul 1, 2016 at 4:51 PM, John Bradley > wrote: >>>>> Yes but POST doesn't really work for in browser apps. >>>>>=20 >>>>> If it is a server app it should be using the code flow with GET or = POST as you like. >>>>>=20 >>>>> If we do a post message based binding it will be targeted at in = browser applications. >>>>>=20 >>>>> John B. >>>>>=20 >>>>> On Fri, Jul 1, 2016 at 4:42 PM, Liyu Yi > wrote: >>>>> BTW, I do not see any significant performance concerns for post. = Parsing and executing the Javascript logic for post operation will be on = the client side, no extra server load is introduced. >>>>>=20 >>>>> Plus post will remove the size restriction of the URL length. >>>>>=20 >>>>> -- Liyu=20 >>>>>=20 >>>>> On Fri, Jul 1, 2016 at 1:35 PM, Liyu Yi > wrote: >>>>> Thanks for the great comments and advices. >>>>>=20 >>>>> I think it is a good idea for the working group to revise the = fragment part in the spec, since there might be public available tools = already implemented this approach and people can end up with a solution = with serious security loopholes. >>>>>=20 >>>>> The re-append issue can be mitigate by a logic on Resource Server = which carefully re-writes/removes the fragment in any redirect, if the = the redirect can not be avoided. >>>>>=20 >>>>> -- Liyu >>>>> =20 >>>>>=20 >>>>> On Fri, Jul 1, 2016 at 11:33 AM, John Bradley > wrote: >>>>> This behaviour started changing around 2011 >>>>>=20 >>>>> =46rom HTTP/1.1 >>>>> See https://tools.ietf.org/html/rfc7231#section-7.1.2 = I >>>>> f the Location value provided in a 3xx (Redirection) = response does >>>>> not have a fragment component, a user agent MUST process the >>>>> redirection as if the value inherits the fragment component of = the >>>>> URI reference used to generate the request target (i.e., the >>>>> redirection inherits the original reference's fragment, if = any). >>>>>=20 >>>>> For example, a GET request generated for the URI reference >>>>> "http://www.example.org/~tim " = might result in a 303 (See Other) >>>>> response containing the header field: >>>>>=20 >>>>> Location: /People.html#tim >>>>>=20 >>>>> which suggests that the user agent redirect to >>>>> "http://www.example.org/People.html#tim = =E2=80=9D >>>>>=20 >>>>> Likewise, a GET request generated for the URI reference >>>>> "http://www.example.org/index.html#larry = " might result in a 301 >>>>> (Moved Permanently) response containing the header field: >>>>>=20 >>>>> Location: http://www.example.net/index.html = >>>>>=20 >>>>> which suggests that the user agent redirect to >>>>> "http://www.example.net/index.html#larry = ", preserving the original >>>>> fragment identifier. >>>>>=20 >>>>>=20 >>>>> This blog also explores the change. >>>>> = https://blogs.msdn.microsoft.com/ieinternals/2011/05/16/url-fragments-and-= redirects/ = >>>>>=20 >>>>>=20 >>>>>> On Jul 1, 2016, at 1:05 PM, Oleg Gryb > wrote: >>>>>>=20 >>>>>> "Browsers now re-append fragments across 302 redirects unless = they are explicitly cleared this makes fragment encoding less safe than = it was when originally specified" - thanks Jim. Looks like a good = reason for vetting this flow out. >>>>>>=20 >>>>>> John, >>>>>> Please provide more details/links about re-appending fragments.=20= >>>>>>=20 >>>>>> Thanks, >>>>>> Oleg. >>>>>>=20 >>>>>>=20 >>>>>> From: Jim Manico > >>>>>> To: Oleg Gryb >=20 >>>>>> Cc: "oauth@ietf.org " >; Liyu Yi > >>>>>> Sent: Thursday, June 30, 2016 10:25 PM >>>>>> Subject: Re: [OAUTH-WG] Security concern for URI fragment as = Implicit grant >>>>>>=20 >>>>>> Oleg! Hello! Great to see you pop up here with a similar concern. >>>>>>=20 >>>>>> John Bradley just answered this thread with the details I was = looking for (thanks John, hat tip your way). >>>>>>=20 >>>>>> He also mentioned details about fragment leakage: >>>>>>=20 >>>>>> "Browsers now re-append fragments across 302 redirects unless = they are explicitly cleared this makes fragment encoding less safe than = it was when originally specified" >>>>>>=20 >>>>>> Again, I'm new here but I'm grateful for this conversation. >>>>>>=20 >>>>>> Aloha, >>>>>> -- >>>>>> Jim Manico >>>>>> @Manicode >>>>>>=20 >>>>>> On Jul 1, 2016, at 1:24 AM, Oleg Gryb > wrote: >>>>>>=20 >>>>>>> We've discussed access tokens in URI back in 2010 = (https://www.ietf.org/mail-archive/web/oauth/current/msg04043.html = ). = There were two major objectives when I was saying that it's not secure: >>>>>>>=20 >>>>>>> 1. Fragment is not sent to a server by a browser. When I've = asked if this is true for every browser in the world, nobody was able to = answer. >>>>>>> 2. Replacing with POST would mean a significant performance = impact in some high volume implementations (I think it was Goole folks = who were saying this, but I don't remember now). >>>>>>>=20 >>>>>>> AFAIR, nobody was arguing about browsing history, so it's valid. >>>>>>>=20 >>>>>>> So, 6 years later we're at square one with this and I hope that = this time the community will be more successful with getting rid of = secrets in URL. >>>>>>>=20 >>>>>>> BTW, Jim, if you can come up with other scenarios when fragments = can leak, please share. It'll probably help the community with solving = this problem faster than in 6 years. >>>>>>>=20 >>>>>>> Thanks, >>>>>>> Oleg. >>>>>>>=20 >>>>>>>=20 >>>>>>> From: Jim Manico > >>>>>>> To: Liyu Yi >; = oauth@ietf.org =20 >>>>>>> Sent: Wednesday, June 29, 2016 7:30 AM >>>>>>> Subject: Re: [OAUTH-WG] Security concern for URI fragment as = Implicit grant >>>>>>>=20 >>>>>>> > Shouldn=E2=80=99t it be more secure if we change to use a post = method for access token, similar to the SAML does? >>>>>>> I say yes. But please note I'm very new at this and someone with = more experience will have more to say or correct my comments. >>>>>>> Here are a few more details to consider. >>>>>>> 1) OAuth is a framework and not a standard, per se. Different = authorization servers will have different implementations that are not = necessarily compatible with other service providers. So there is no = standard to break, per se. >>>>>>> 2) Sensitive data in a URI is a bad idea. They leak all over the = place even over HTTPS. Even in fragments. >>>>>>> 3) Break the "rules" and find a way to submit sensitive data = like access tokens, session information or any other (even short term) = sensitive data in a secure fashion. This includes POST, JSON data = payloads over PUT/PATCH and other verbs - all over well configured = HTTPS. >>>>>>> 4) If you really must submit sensitive data over GET , consider = JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level = confidentiality and integrity. >>>>>>> Aloha, >>>>>>> Jim Manico >>>>>>> Manicode Security >>>>>>> https://www.manicode.com >>>>>>> On 6/27/16 9:30 PM, Liyu Yi wrote: >>>>>>>> While we are working on a project with OAuth2 implementation, = one question arises from our engineers. >>>>>>>> We noticed at = https://tools.= ietf.org/html/draft-ietf-oauth-v2-31#page-30 = , it is = specified that >>>>>>>> =20 >>>>>>>> (C) Assuming the resource owner grants access, the = authorization >>>>>>>> server redirects the user-agent back to the client = using the >>>>>>>> redirection URI provided earlier. The redirection URI = includes >>>>>>>> the access token in the URI fragment. >>>>>>>> =20 >>>>>>>> For my understanding, the browser keeps the URI fragment in the = history, and this introduces unexpected exposure of the access token. A = user without authorization for the resource can get the access token as = long as he has the access to the browser. This can happen in a shared = computer in library, or for an IT staff who works on other employee=E2=80=99= s computer. >>>>>>>> =20 >>>>>>>> Shouldn=E2=80=99t it be more secure if we change to use a post = method for access token, similar to the SAML does? >>>>>>>> I feel there might be something I missed here. Any advices will = be appreciated. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>>=20 >>>>>>> --=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >>=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 --Apple-Mail=_9B3FD9E0-ED0A-4EF7-AD42-A01106395419 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 yes
On Jul 1, 2016, at 8:39 PM, Oleg Gryb <oleg_gryb@yahoo.com>= wrote:

I= think, the intention was not to share AT with the web-hosted client = resource. As you can see in the original flow the latter never receives = the AT, it simply provides code that can get AT from a fragment and some = UI. In the modified flow AT is sent to the web-hosted client resource, = which makes security worse in my view, because you have your AT exposed = in two places now - in the User Agent *and* in the web-hosted client = resource.



=
= From: John Bradley <ve7jtb@ve7jtb.com>
To: Liyu Yi <liyuyi@gmail.com>
Cc: Oleg Gryb <oleg@gryb.info>; "<oauth@ietf.org>" <oauth@ietf.org>
Sent: Friday, July 1, = 2016 4:06 PM
Subject: Re: [OAUTH-WG] Security concern = for URI fragment as Implicit grant
I take it that = Web-hosted client resource is part of the client.

I think perhaps you have = client and resource serve r mixed up a bit in your diagram.

Yes you could do that but = it is not a great way to build the client as it will blow away context. =  
You can do it but people = generally want to start the application in the browser first and then = call out to the IdP  in a iFrame.

What you propose would work = more or less.  I don=E2=80=99t see it as a pattern that I would = necessarily recommend over the current fragment encoding.

If we mover to post message = it would include API  for logout and session management, not just = login.

John B.


On Jul 1, 2016, at 6:43 PM, Liyu Yi <liyuyi@gmail.com> = wrote:

Understood there is an Authorization Code grant = type; here I am more focusing on the Implicit grant = type. 
  
also when I mentioned POST, I did not mean = postMessage, it is simply the HTTP POST. Specifically it is more like = this ...



<=
/span>

4.2. Implicit Grant (modified)

     +----------+
     | Resource |
     |  Owner   |
     |          |
     +----------+
          ^
          |
         (B)
     +----|-----+          Client Identifier     +---------------+
     |         -+----(A)-- & Redirection URI --->|               =
|
     |  User-   |                                | Authorization |
     |  Agent  -|----(B)-- User authenticates -->|     Server    |
     |          |                                |               |
     |          |<---(C)- Response embedded JS -<|               |
     |          |          with Access Token     +---------------+
     |          |            in JS content, which will be posted to =
Resource Server
     |          |                                +---------------+
     |          |----(D)-- JS post to RS URI --->|   Web-Hosted  |
     |          |         with Access Token      |     Client    |
     |          |                                |    Resource   |
     |     (F)  |<---(E)----- RS Script --------<|               |
     |          |         with Access Token      +---------------+
     +-|--------+
       |    |
      (A)  (G) Access Token
       |    |
       ^    v
     +---------+
     |         |
     |  Client |
     |         |
     +---------+



                       Figure 4: Implicit Grant Flow


   The =
flow illustrated in Figure 4 includes the following steps:

   (A)  The client initiates the flow by directing the resource owner's
        user-agent to the authorization endpoint.  The client includes
        its client identifier, requested scope, local state, and a
        redirection URI to which the authorization server will send the
        user-agent back once access is granted (or denied).

   (B)  The authorization server authenticates the resource owner (via
        the user-agent) and establishes whether the resource owner
        grants or denies the client's access request.

   (C)  Assuming the resource owner grants access, the authorization
        server responds with a JavaScript logic which automatically =
posts to=20
        "redirection" URI provided earlier.  The JavaScript includes
        the access token in the URI fragment.

   (D)  The user-agent does the post with the access token. Granted, =
 =

                  user agent can actually do post without =
the access token  in a =
different iframe, 
                  then use postMessage to pass the token =
over, but I do not see why get it need that compexity.


On Fri, = Jul 1, 2016 at 3:13 PM, Josh Mandel <jmandel@gmail.com> = wrote:
Thanks John! Yes, we're following = the CORS based flow you've described below (though I should note that = the actual redirection back to the client could be a 302, or could be a = simple Web link that the user follows from an authorization page; this = is up to the authorization server).
Overall I don't argue that this flow is "more secure" than = the implicit flow -- though I believe it does help client developers = avoid some common pitfalls. (For example, clients that, through careless = programming or poor understanding of the spec, fail to validate incoming = "state" are still not susceptible to arbitrary token injection, which = means at least they won't readily be tricked into using a token = designated for an entirely different client. With poorly written = implicit flow clients, this is an issue.)
That said, I wasn't aiming to = discuss the relative security; just wanted to make sure I knew what you = meant by "won't work well".
Thanks again!
-Josh
On Jul 1, 2016 18:02, "John = Bradley" <ve7jtb@ve7jtb.com> wrote:
I am making a = distinction between a browser talking to a Web server that is acting as = a OAuth Client POST response mode =3D good , and a oauth client running = in the browser user agent as a Java script application (that can=E2=80=99t= directly capture a POST response back to the server)

So it depends = on where the client is actually running.

Are you = saying that you are using a 302 redirect from the authorization endpoint = back to the server hosting the JS and then loading the JS including the = code and then using CORES  to exchange the code for a AT?

You can do = that but I don=E2=80=99t think a public client like that is more secure = than just using the fragment encoded response and is more = work.
It also may give the server a = false sense of security.

John B.
On = Jul 1, 2016, at 5:52 PM, Josh Mandel <jmandel@gmail.com> = wrote:

I think = the confusion here is that I'm not using HEART's OAuth profiles :-)

I'm using the = SMART profiles, where we do specify the use of an authorization code = grant even for browser-based public clients (in which case, no = client_secret is issued or used). I'm just trying to understand your = perspective eon why this "won't work well". Perhaps you didn't mean this = comment to refer to browser-based OAuth clients generally?

  = -Josh

On Fri, = Jul 1, 2016 at 5:45 PM, John Bradley <ve7jtb@ve7jtb.com> = wrote:
I don=E2=80=99t = think the post response mode is supported by heart so I suspect that we = are talking about different things.

You are probably using the supported code flow = that uses a 302 get to return the code to the OAuth client on the = server.  
The Web server is then = acting as a confidential client to exchange the code via a POST = (different POST) with the AS token_endpoint.

The Token = endpoint will return a access token (AT) and optional refresh token = (RT).

The web page = may be getting the server to make the OAuth calls on it=E2=80=99s behalf = to the Resource Server, or possibly you are passing the AT from the = server back to a Java script app that is using CORES to make calls = directly to the RS without going through the Web server.

Passing the = AT back to the user agent from the client is not = recommended. 

For in = browser clients where the JS is using the AT to make the calls directly = to the RS via CORES the recommended approach is to use the fragment = encoded response via a 302 to deliver the AT directly to the client (It = never hits the backend Web server).

However I believe In browser OAuth clients are = not currently supported in HEART, so I am not quite sure what you are = doing.

Perhaps = Justin has a better answer.

John B.


On Jul 1, 2016, at 5:33 PM, = Josh Mandel <jmandel@gmail.com> = wrote:

John,
I appreciate = your response. I'm hoping you can clarify why you say that "HTTP POST... = won't work well for... [a] single page OAuth client"?

We commonly = build single-page apps that act as OAuth clients for SMART (e.g. this sample app ), and = we've had good experience with the technique. Could you = elaborate?

  -J

On Fri, = Jul 1, 2016 at 5:26 PM, John Bradley <ve7jtb@ve7jtb.com> = wrote:
HEART only = supports web server clients at the moment.   That might change in = future to support native apps if that an be made to support the security = requirements of Heath IT.

So the thing HTTP = POST responses won=E2=80=99t work well for is a type of in browser = single page OAuth client.  That still needs fragment encoded = responses or the new post-message Java Script API approach.

John = B.


On Jul 1, 2016, at 5:16 PM, = Josh Mandel <jmandel@gmail.com> = wrote:

Thanks = Justin,

To clarify: = John's comment and my question were about POST. (I do understand the = behavior of HTTP POST and of window.postMessage; these are totally = different things.) =46rom my perspective in SMART Health IT, we use the = OAuth 2.0 authorization code flow, including HTTP POST, in our authorization = spec even for public clients, and it has worked very well for = us, with about a dozen electronic health record servers supporting this = approach. That's why I was curious to hear John's perspective about = limitations.

  = -J

On Fri, = Jul 1, 2016 at 5:09 PM, Oleg Gryb <oleg_gryb@yahoo.com> = wrote:
> POST = will send things to the server, which isn=E2=80=99t desirable if your = client is solely in the browser
Why it's not desirable, assuming that we disregard = performance? You can generate HTTP POST from JS, e.g. through an AJAX = call. What is wrong with this?


=
From: Justin Richer <jricher@mit.edu>
To: Josh = Mandel <jmandel@gmail.com>
Cc: Oleg = Gryb <oleg@gryb.info>; "<oauth@ietf.org>" <oauth@ietf.org>; Liyu Yi <liyuyi@gmail.com>
Sent: = Friday, July 1, 2016 2:00 PM

Subject: Re: [OAUTH-WG] Security = concern for URI fragment as Implicit grant

POST will send = things to the server, which isn=E2=80=99t desirable if your client is = solely in the browser. postMessage is a browser API and not to be = confused with HTTP POST. postMessage messages stay (or can stay) within = the browser, which is the intent here.

 =E2=80=94 Justin

On = Jul 1, 2016, at 4:56 PM, Josh Mandel <jmandel@gmail.com> = wrote:

John,

Could you clarify what you mean by "POST doesn't really = work"? Do you just mean that CORS support (e.g., http://caniuse.com/#feat=3Dcors) isn't universal, or something more?

On Fri, Jul 1, 2016 at 4:51 PM, John Bradley = <ve7jtb@ve7jtb.com> = wrote:
Yes = but POST doesn't really work for in browser apps.

If it is a = server app it should be using the code flow with GET or POST as you = like.

If we do a =  post message based binding it will be targeted at in browser = applications.

John = B.

On Fri, Jul 1, 2016 = at 4:42 PM, Liyu Yi <liyuyi@gmail.com> = wrote:
BTW, I = do not see any significant performance concerns for post. Parsing and = executing the Javascript logic for post operation will be on the client = side, no extra server load is introduced.

Plus post will remove the size restriction of = the URL length.

-- = Liyu 

On Fri, Jul 1, 2016 = at 1:35 PM, Liyu Yi <liyuyi@gmail.com> = wrote:
Thanks for the great comments and = advices.

I think it is a good idea for the working = group to revise the fragment part in the spec, since there might be = public available tools already implemented this approach and people can = end up with a solution with serious security loopholes.

The re-append = issue can be mitigate by a logic on Resource Server which carefully = re-writes/removes the fragment in any redirect, if the the redirect can = not be avoided.

-- Liyu
 

On Fri, Jul 1, 2016 at 11:33 AM, John Bradley = <ve7jtb@ve7jtb.com> = wrote:
This behaviour started changing around = 2011

=46rom = HTTP/1.1
See https://tools.i= etf.org/html/rfc7231#section-7.1.2I
      f the Location value = provided in a 3xx (Redirection) response does
   not have a fragment component, a user agent MUST process the
   redirection as if the value inherits the fragment component of the
   URI reference used to generate the request target (i.e., the
   redirection inherits the original reference's fragment, if any).

   For example, a GET request generated for the URI reference
   "http://www.example.org/~tim" =
might result in a 303 (See Other)
   response containing the header field:

     Location: /People.html#tim

   which suggests that the user agent redirect to
   "http://www.example.org/Peo=
ple.html#tim=E2=80=9D

   Likewise, a GET request generated for the URI reference
   "http://www.example.org/in=
dex.html#larry" might result in a 301
   (Moved Permanently) response containing the header field:

     Location: http://www.example.net/index.ht=
ml

   which suggests that the user agent redirect to
   "http://www.example.net/in=
dex.html#larry", preserving the original
   fragment identifier.


This blog also explores the change.
https://blogs.msdn.microsoft.com/ieinternals/2011/05/1= 6/url-fragments-and-redirects/


On Jul 1, 2016, at 1:05 PM, = Oleg Gryb <oleg_gryb@yahoo.com> = wrote:

"Browsers now re-append  fragments across = 302 redirects unless they are explicitly cleared this makes fragment = encoding less safe than it was  when originally specified" - thanks = Jim. Looks like a good reason for vetting this flow out.

John,
Please = provide more details/links about re-appending = fragments. 

Thanks,
Oleg.

=
From: Jim Manico <jim@manicode.com>
To: Oleg = Gryb <oleg@gryb.info>
Cc: "oauth@ietf.org" <oauth@ietf.org>; = Liyu Yi <liyuyi@gmail.com>
Sent: = Thursday, June 30, 2016 10:25 PM
Subject: = Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

Oleg! Hello! Great to see you pop up here with a = similar concern.

John Bradley = just answered this thread with the details I was looking for (thanks = John, hat tip your way).

He also mentioned details about fragment = leakage:

"Browsers now re-append  fragments across = 302 redirects unless they are explicitly cleared this makes fragment = encoding less safe than it was when originally = specified"

Again, I'm = new here but I'm grateful for this conversation.

Aloha,
--
Jim = Manico
@Manicode

On Jul 1, 2016, at 1:24 AM, Oleg Gryb <oleg_gryb@yahoo.com> = wrote:

We've discussed access tokens = in URI back in 2010 (https://www.ietf.org/mail-archive/web/oauth/current/msg04043.html). = There were two major objectives when I was saying that it's not = secure:

1. = Fragment is not sent to a server by a browser. When I've asked if this = is true for every browser in the world, nobody was able to = answer.
2. Replacing with = POST would mean a significant performance impact in some high volume = implementations (I think it was Goole folks who were saying this, but I = don't remember now).

AFAIR, nobody was arguing about browsing history, so it's = valid.

So,= 6 years later we're at square one with this and I hope that this time = the community will be more successful with getting rid of secrets in = URL.

BTW, Jim, if you can come up with other scenarios when = fragments can leak, please share. It'll probably help the community with = solving this problem faster than in 6 years.

Thanks,
Oleg.


=
From: Jim Manico <jim@manicode.com>
To: Liyu = Yi <liyuyi@gmail.com>; oauth@ietf.org
Sent: = Wednesday, June 29, 2016 7:30 AM
Subject: = Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

> Shouldn=E2=80=99t it be more secure if we change = to use a post method for access token, similar to the SAML = does?
I say yes. But please note I'm very new = at this and someone with more experience will have more to say or correct my = comments.
Here are a few more details to = consider.
1) OAuth is a framework and not a = standard, per se. Different authorization servers will have different implementations that are not necessarily compatible with other service providers. So there is no standard to break, per se.
2) Sensitive data in a URI is a bad = idea. They leak all over the place even over HTTPS. Even in fragments.
3) Break the "rules" and find a way to = submit sensitive data like access tokens, session information or any other (even short term) sensitive data in a secure fashion. This includes POST, JSON data payloads over PUT/PATCH and other verbs - all over well configured HTTPS.
4) If you really must submit sensitive = data over GET , consider JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level confidentiality and integrity.
Aloha,
Jim Manico
Manicode Security
https://www.manicode.com

On 6/27/16 = 9:30 PM, Liyu Yi wrote:
While = we are working on a project with OAuth2 implementation, one question arises from our engineers.
We = noticed at https:= //tools.ietf.org/html/draft-ietf-oauth-v2-31#page-30, it is specified that
  
(C)  Assuming the resource owner grants access, the authorization
        = server redirects the user-agent back to the client using the
        = redirection URI provided earlier.  The redirection URI includes
        the = access token in the URI fragment.
 
For = my understanding, the browser keeps the URI fragment in the history, and this introduces unexpected exposure of the access token. A user without authorization for the resource can get the access token as long as he has the access to the browser. This can happen in a shared computer in library, or for an IT staff who works on other employee=E2=80=99s computer.
 
Shouldn=E2=80=99t it be more secure if we change to use a post method for access token, similar to the SAML does?
I = feel there might be something I missed here. Any advices will be appreciated.


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


--=20

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


=
=

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


=
=





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


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


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


=
=

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

<= br clear=3D"none" class=3D"yiv6067780691">






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


= =
= --Apple-Mail=_9B3FD9E0-ED0A-4EF7-AD42-A01106395419-- From nobody Fri Jul 1 18:15:01 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59A6B12B043 for ; Fri, 1 Jul 2016 18:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.034 X-Spam-Level: X-Spam-Status: No, score=-3.034 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=yahoo.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 X7DRt1PEgCrc for ; Fri, 1 Jul 2016 18:14:56 -0700 (PDT) Received: from nm18-vm0.bullet.mail.bf1.yahoo.com (nm18-vm0.bullet.mail.bf1.yahoo.com [98.139.213.138]) (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 041F912B019 for ; Fri, 1 Jul 2016 18:14:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1467422095; bh=rku1UZRkU8bIOLhdFhstZpHeeKWf2qT+g/dvw9aTdyQ=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=ILCzWZ38ZPDyk40YG5No6zIweC9MgAFEw5FLsPokB6ShX8BBm027tPZalVTkJnhBwkqvInfYAtZX1Qmh0QVmjziCj4NImnBmhEdKuUbQaTXwaFWHSAHgah4oqav/tiPsKAljfIwmMTYlOFFmBsSpzMVOTuRXH/2cgxocZ2kjurgg/EmJwjaX6FZiDsCA7sYL4XciDSsFAvyFJIQ+hKTz/CtRKhSRLsaVBhJEoMktq3S3lsxvDc+rHNaJQbBijLfF6VV8Y2j266wiKD9ESWWMQVzKc+KZGW0H+5dl+Pu7UtPomAGbzGAmLgU8PUaeoeU4ZMRtj6SU4B816+mIEJ05KQ== Received: from [98.139.170.181] by nm18.bullet.mail.bf1.yahoo.com with NNFMP; 02 Jul 2016 01:14:55 -0000 Received: from [98.139.212.217] by tm24.bullet.mail.bf1.yahoo.com with NNFMP; 02 Jul 2016 01:14:54 -0000 Received: from [127.0.0.1] by omp1026.mail.bf1.yahoo.com with NNFMP; 02 Jul 2016 01:14:54 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 891088.69493.bm@omp1026.mail.bf1.yahoo.com X-YMail-OSG: P5ZS17EVM1mJWdHkUcLyNPSupsgHODapGWHnE4z2_eMemCEFyYr9Cm60cSpZvdw 5VM0zd3OUFnquVWbUm5BEMQsYtB7aqrakgQU.mWD3FbLLwdwaoUGLWyKpLTml5vba83IVYYslo8K Ig1GYYLpOIrv0lTKF7_SLefgAyY5wKi.nXWZ3m26aJEDdBIs.N_3L1AwGPD46rNc3wrHWmnuw0tH qBOge2h.qRdiohDwfafFnVQgSmOakUAZfHQ.6lm7yUVUFoMyNPcP5kV.vAzC5rt9fhUyHyBnMRe7 L.74Yk9kuu0s_FANB2uKFfmY9TOhBn49Bj6oRb9d3Jh9R8ASmiGcd_p5CSPt8YYw3lbNUVAZfPzV 7yiBpEXw7r2D6zv8ypsvgqg95HBoPWf_SE4AtQa0.OgvL0oiLvufN3wCavjGRVnAOtTHqMakogux _k3UQwwDy4zKNpPsx_lHhsSJc0oeJxmZE_NIeSt5.qLgQzCgn4sYddpj6I1drreJaOtpWchjeOz9 MWVmjxSSkggsmOA8S1PxMD9ABpU_QdNP5T12U4zTgukDFAQRpYvJ9BQeEsiOFwBXx7Eho9hxg.47 PlOxw3reMjyN_YLZCgjY6ckyRPwiwHtpVfgq.Rs9hfNb8._MVg6RfXPfcPsUWbw_QuA-- Received: from jws10680.mail.bf1.yahoo.com by sendmailws163.mail.bf1.yahoo.com; Sat, 02 Jul 2016 01:14:54 +0000; 1467422094.394 Date: Sat, 2 Jul 2016 01:14:53 +0000 (UTC) From: Oleg Gryb To: Liyu Yi , John Bradley Message-ID: <597554829.619782.1467422094020.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: <994121658.55005.1467329084208.JavaMail.yahoo@mail.yahoo.com> <235316006.458279.1467392709447.JavaMail.yahoo@mail.yahoo.com> <6584BD74-B18F-4174-9E69-5C7B4B76F895@ve7jtb.com> <410908395.555462.1467407397629.JavaMail.yahoo@mail.yahoo.com> <8CC41328-C26D-42C0-BFDB-BF0216C7B76C@ve7jtb.com> <71CE61B3-FEC2-46A7-AB28-B53E89A8E53F@ve7jtb.com> <560704570.608692.1467419971908.JavaMail.yahoo@mail.yahoo.com> <50E491F2-E08F-40A7-B9DE-AB50CB647C04@ve7jtb.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_619779_711122837.1467422093987" Archived-At: Cc: Oleg Gryb , "" Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Oleg Gryb List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2016 01:15:00 -0000 ------=_Part_619779_711122837.1467422093987 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable As John has already pointed out - you're confusing RS with the=C2=A0web-hos= ted client resource. =20 From: Liyu Yi To: John Bradley =20 Cc: Oleg Gryb ; "" Sent: Friday, July 1, 2016 6:11 PM Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit gran= t =20 I would say AT is supposed to be consumed by the Resource Server. Although = the original spec does not show how AT is used by the client, but the AT wi= ll be sent out, most likely by the browser directly, or in a rare case if t= he client application has another channel, indirectly. The fact is that the AT is not sent in the 1st GET request does leave the R= S JavaScript a chance to choose the right method, say an ajax POST. But AT = is NOT =C2=A0a secrete to RS. On Fri, Jul 1, 2016 at 5:53 PM, John Bradley wrote: yes On Jul 1, 2016, at 8:39 PM, Oleg Gryb wrote: I think, the intention was not to share AT with the web-hosted client resou= rce. As you can see in the original flow the latter never receives the AT, = it simply provides code that can get AT from a fragment and some UI. In the= modified flow AT is sent to the web-hosted client resource, which makes se= curity worse in my view, because you have your AT exposed in two places now= - in the User Agent *and* in the web-hosted client resource. =20 From: John Bradley To: Liyu Yi =20 Cc: Oleg Gryb ; "" Sent: Friday, July 1, 2016 4:06 PM Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit gran= t =20 I take it that Web-hosted client resource is part of the client. I think perhaps you have client and resource serve r mixed up a bit in your= diagram. Yes you could do that but it is not a great way to build the client as it w= ill blow away context. =C2=A0You can do it but people generally want to sta= rt the application in the browser first and then call out to the IdP =C2=A0= in a iFrame. What you propose would work more or less.=C2=A0 I don=E2=80=99t see it as a= pattern that I would necessarily recommend over the current fragment encod= ing. If we mover to post message it would include API =C2=A0for logout and sessi= on management, not just login. John B. On Jul 1, 2016, at 6:43 PM, Liyu Yi wrote: Understood there is an Authorization Code grant type; here I am more focusi= ng on the Implicit grant type.=C2=A0=C2=A0=C2=A0also when I mentioned POST,= I did not mean postMessage, it is simply the HTTP POST. Specifically it is= more like this ... 4.2. Implicit Grant (modified) +----------+ | Resource | | Owner | | | +----------+ ^ | (B) +----|-----+ Client Identifier +---------------+ | -+----(A)-- & Redirection URI --->| | | User- | | Authorization | | Agent -|----(B)-- User authenticates -->| Server | | | | | | |<---(C)- Response embedded JS -<| | | | with Access Token +---------------+ | | in JS content, which will be posted to Resourc= e Server | | +---------------+ | |----(D)-- JS post to RS URI --->| Web-Hosted | | | with Access Token | Client | | | | Resource | | (F) |<---(E)----- RS Script --------<| | | | with Access Token +---------------+ +-|--------+ | | (A) (G) Access Token | | ^ v +---------+ | | | Client | | | +---------+ Figure 4: Implicit Grant Flow The flow illustrated in Figure 4 includes the following steps: (A) The client initiates the flow by directing the resource owner's user-agent to the authorization endpoint. The client includes its client identifier, requested scope, local state, and a redirection URI to which the authorization server will send the user-agent back once access is granted (or denied). (B) The authorization server authenticates the resource owner (via the user-agent) and establishes whether the resource owner grants or denies the client's access request. (C) Assuming the resource owner grants access, the authorization server responds with a JavaScript logic which automatically posts t= o=20 "redirection" URI provided earlier. The JavaScript includes the access token in the URI fragment. (D) The user-agent does the post with the access token. Granted, = user agent can actually do post without the access token in a= different iframe, then use postMessage to pass the token= over, but I do not see why get it need that compexity. On Fri, Jul 1, 2016 at 3:13 PM, Josh Mandel wrote: Thanks John! Yes, we're following the CORS based flow you've described belo= w (though I should note that the actual redirection back to the client coul= d be a 302, or could be a simple Web link that the user follows from an aut= horization page; this is up to the authorization server). Overall I don't a= rgue that this flow is "more secure" than the implicit flow -- though I bel= ieve it does help client developers avoid some common pitfalls. (For exampl= e, clients that, through careless programming or poor understanding of the = spec, fail to validate incoming "state" are still not susceptible to arbitr= ary token injection, which means at least they won't readily be tricked int= o using a token designated for an entirely different client. With poorly wr= itten implicit flow clients, this is an issue.) That said, I wasn't aiming = to discuss the relative security; just wanted to make sure I knew what you = meant by "won't work well".Thanks again! -JoshOn Jul 1, 2016 18:02, "John B= radley" wrote: I am making a distinction between a browser talking to a Web server that is= acting as a OAuth Client POST response mode =3D good , and a oauth client = running in the browser user agent as a Java script application (that can=E2= =80=99t directly capture a POST response back to the server) So it depends on where the client is actually running. Are you saying that you are using a 302 redirect from the authorization end= point back to the server hosting the JS and then loading the JS including t= he code and then using CORES =C2=A0to exchange the code for a AT? You can do that but I don=E2=80=99t think a public client like that is more= secure than just using the fragment encoded response and is more work.It a= lso may give the server a false sense of security. John B. On Jul 1, 2016, at 5:52 PM, Josh Mandel wrote: I think the confusion here is that I'm not using HEART's OAuth profiles :-) I'm using the SMART profiles, where we do specify the use of an authorizati= on code grant even for browser-based public clients (in which case, no clie= nt_secret is issued or used). I'm just trying to understand your perspectiv= e eon why this "won't work well". Perhaps you didn't mean this comment to r= efer to browser-based OAuth clients generally? =C2=A0 -Josh On Fri, Jul 1, 2016 at 5:45 PM, John Bradley wrote: I don=E2=80=99t think the post response mode is supported by heart so I sus= pect that we are talking about different things. You are probably using the supported code flow that uses a 302 get to retur= n the code to the OAuth client on the server. =C2=A0The Web server is then = acting as a confidential client to exchange the code via a POST (different = POST) with the AS token_endpoint. The Token endpoint will return a access token (AT) and optional refresh tok= en (RT). The web page may be getting the server to make the OAuth calls on it=E2=80= =99s behalf to the Resource Server, or possibly you are passing the AT from= the server back to a Java script app that is using CORES to make calls dir= ectly to the RS without going through the Web server. Passing the AT back to the user agent from the client is not recommended.= =C2=A0 For in browser clients where the JS is using the AT to make the calls direc= tly to the RS via CORES the recommended approach is to use the fragment enc= oded response via a 302 to deliver the AT directly to the client (It never = hits the backend Web server). However I believe In browser OAuth clients are not currently supported in H= EART, so I am not quite sure what you are doing. Perhaps Justin has a better answer. John B. On Jul 1, 2016, at 5:33 PM, Josh Mandel wrote: John, I appreciate your response. I'm hoping you can clarify why you say that "HT= TP POST... won't work well for... [a] single page OAuth client"? We commonly build single-page apps that act as OAuth clients for SMART (e.g= . this sample app=C2=A0), and we've had good experience with the technique.= Could you elaborate? =C2=A0 -J On Fri, Jul 1, 2016 at 5:26 PM, John Bradley wrote: HEART only supports web server clients at the moment. =C2=A0 That might cha= nge in future to support native apps if that an be made to support the secu= rity requirements of Heath IT. So the thing HTTP POST responses won=E2=80=99t work well for is a type of i= n browser single page OAuth client.=C2=A0 That still needs fragment encoded= responses or the new post-message Java Script API approach. John B. On Jul 1, 2016, at 5:16 PM, Josh Mandel wrote: Thanks Justin, To clarify: John's comment and my question were about POST. (I do understan= d the behavior of HTTP POST and of window.postMessage; these are totally di= fferent things.) From my perspective in SMART Health IT, we use the OAuth 2= .0 authorization code flow, including HTTP POST, in our authorization spec= =C2=A0even for public clients, and it has worked very well for us, with abo= ut a dozen electronic health record servers supporting this approach. That'= s why I was curious to hear John's perspective about limitations. =C2=A0 -J On Fri, Jul 1, 2016 at 5:09 PM, Oleg Gryb wrote: > POST will send things to the server, which isn=E2=80=99t desirable if you= r client is solely in the browserWhy it's not desirable, assuming that we d= isregard performance? You can generate HTTP POST from JS, e.g. through an A= JAX call. What is wrong with this? =20 From: Justin Richer To: Josh Mandel =20 Cc: Oleg Gryb ; "" ; Liyu Y= i Sent: Friday, July 1, 2016 2:00 PM Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit gran= t =20 POST will send things to the server, which isn=E2=80=99t desirable if your = client is solely in the browser. postMessage is a browser API and not to be= confused with HTTP POST. postMessage messages stay (or can stay) within th= e browser, which is the intent here. =C2=A0=E2=80=94 Justin On Jul 1, 2016, at 4:56 PM, Josh Mandel wrote: John, Could you clarify what you mean by "POST doesn't really work"? Do you just = mean that CORS support (e.g.,=C2=A0http://caniuse.com/#feat=3Dcors) isn't u= niversal, or something more? On Fri, Jul 1, 2016 at 4:51 PM, John Bradley wrote: Yes but POST doesn't really work for in browser apps. If it is a server app it should be using the code flow with GET or POST as = you like. If we do a =C2=A0post message based binding it will be targeted at in brows= er applications. John B. On Fri, Jul 1, 2016 at 4:42 PM, Liyu Yi wrote: BTW, I do not see any significant performance concerns for post. Parsing an= d executing the Javascript logic for post operation will be on the client s= ide, no extra server load is introduced. Plus post will remove the size restriction of the URL length. -- Liyu=C2=A0 On Fri, Jul 1, 2016 at 1:35 PM, Liyu Yi wrote: Thanks for the great comments and advices. I think it is a good idea for the working group to revise the fragment part= in the spec, since there might be public available tools already implement= ed this approach and people can end up with a solution with serious securit= y loopholes. The re-append issue can be mitigate by a logic on Resource Server which car= efully re-writes/removes the fragment in any redirect, if the the redirect = can not be avoided. -- Liyu=C2=A0 On Fri, Jul 1, 2016 at 11:33 AM, John Bradley wrote: This behaviour started changing around 2011 >From HTTP/1.1See=C2=A0https://tools.ietf.org/html/rfc7231#section-7.1.2I=C2= =A0 =C2=A0 =C2=A0 f the Location value provided in a 3xx (Redirection) resp= onse does not have a fragment component, a user agent MUST process the redirection as if the value inherits the fragment component of the URI reference used to generate the request target (i.e., the redirection inherits the original reference's fragment, if any). For example, a GET request generated for the URI reference "http://www.example.org/~tim" might result in a 303 (See Other) response containing the header field: Location: /People.html#tim which suggests that the user agent redirect to "http://www.example.org/People.html#tim=E2=80=9D Likewise, a GET request generated for the URI reference "http://www.example.org/index.html#larry" might result in a 301 (Moved Permanently) response containing the header field: Location: http://www.example.net/index.html which suggests that the user agent redirect to "http://www.example.net/index.html#larry", preserving the original fragment identifier. This blog also explores the change.https://blogs.msdn.microsoft.com/ieinter= nals/2011/05/16/url-fragments-and-redirects/ On Jul 1, 2016, at 1:05 PM, Oleg Gryb wrote: "Browsers now re-append =C2=A0fragments across 302 redirects unless they ar= e explicitly cleared this makes fragment encoding less safe than it was =C2= =A0when originally specified" - thanks Jim. Looks like a good reason for ve= tting this flow out. John,Please provide more details/links about re-appending fragments.=C2=A0 Thanks,Oleg. =20 From: Jim Manico To: Oleg Gryb =20 Cc: "oauth@ietf.org" ; Liyu Yi Sent: Thursday, June 30, 2016 10:25 PM Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit gran= t =20 Oleg! Hello! Great to see you pop up here with a similar concern. John Bradley just answered this thread with the details I was looking for (= thanks John, hat tip your way). He also mentioned details about fragment leakage: "Browsers now re-append =C2=A0fragments across 302 redirects unless they ar= e explicitly cleared this makes fragment encoding less safe than it was whe= n originally specified" Again, I'm new here but I'm grateful for this conversation. Aloha,--Jim Manico@Manicode On Jul 1, 2016, at 1:24 AM, Oleg Gryb wrote: We've discussed access tokens in URI back in 2010 (https://www.ietf.org/mai= l-archive/web/oauth/current/msg04043.html). There were two major objectives= when I was saying that it's not secure: 1. Fragment is not sent to a server by a browser. When I've asked if this i= s true for every browser in the world, nobody was able to answer.2. Replaci= ng with POST would mean a significant performance impact in some high volum= e implementations (I think it was Goole folks who were saying this, but I d= on't remember now). AFAIR, nobody was arguing about browsing history, so it's valid. So, 6 years later we're at square one with this and I hope that this time t= he community will be more successful with getting rid of secrets in URL. BTW, Jim, if you can come up with other scenarios when fragments can leak, = please share. It'll probably help the community with solving this problem f= aster than in 6 years. Thanks,Oleg. =20 From: Jim Manico To: Liyu Yi ; oauth@ietf.org=20 Sent: Wednesday, June 29, 2016 7:30 AM Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit gran= t =20 > Shouldn=E2=80=99t it be more secure if we change to use a post method fo= r access token, similar to the SAML does? I say yes. But please note I'm ve= ry new at this and someone with more experience will have more to say or co= rrect my comments. Here are a few more details to consider. 1) OAuth is a framework and not a standard, per se. Different authorizati= on servers will have different implementations that are not necessarily com= patible with other service providers. So there is no standard to break, per= se. 2) Sensitive data in a URI is a bad idea. They leak all over the place ev= en over HTTPS. Even in fragments. 3) Break the "rules" and find a way to submit sensitive data like access = tokens, session information or any other (even short term) sensitive data i= n a secure fashion. This includes POST, JSON data payloads over PUT/PATCH a= nd other verbs - all over well configured HTTPS. 4) If you really must submit sensitive data over GET , consider JWT/JWS/J= WE (with limited scopes/lifetimes) to provide message level confidentiality= and integrity. Aloha, Jim Manico Manicode Security https://www.manicode.com=20 On 6/27/16 9:30 PM, Liyu Yi wrote: =20 While we are working on a project with OAuth2 implementation, one questio= n arises from our engineers. We noticed at https://tools.ietf.org/html/draf= t-ietf-oauth-v2-31#page-30, it is specified that =C2=A0=C2=A0 (C)=C2=A0 Ass= uming the resource owner grants access, the authorization =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 server redirects the user-agent back to the cli= ent using the =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 redirection URI pr= ovided earlier.=C2=A0 The redirection URI includes =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 the access token in the URI fragment. =C2=A0 For my unde= rstanding, the browser keeps the URI fragment in the history, and this intr= oduces unexpected exposure of the access token. A user without authorizati= on for the resource can get the access token as long as he has the access t= o the browser. This can happen in a shared computer in library, or for an I= T staff who works on other employee=E2=80=99s computer. =C2=A0 Shouldn=E2= =80=99t it be more secure if we change to use a post method for access toke= n, similar to the SAML does? I feel there might be something I missed here.= Any advices will be appreciated. =20 =20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 =20 --=20 =20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 =20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 =20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 =20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 =20 =20 ------=_Part_619779_711122837.1467422093987 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As John has already pointed out - you're confusing RS wit= h the web-hosted client resource.


From:= Liyu Yi <liyuyi@gmail.com>
To: John Bradley <ve7jtb@ve7jtb.com>
Cc: Oleg Gryb <oleg@gryb.info>; "&= lt;oauth@ietf.org>" <oauth@ietf.org>
Sent: Friday, July 1, 2016 6:11 PM
Subject: Re: [OAUTH-WG] Security conce= rn for URI fragment as Implicit grant

I would say AT is suppose= d to be consumed by the Resource Server. Although the original spec does no= t show how AT is used by the client, but the AT will be sent out, most like= ly by the browser directly, or in a rare case if the client application has= another channel, indirectly.

The fact is that the AT is not sent in the 1st GET request does leave t= he RS JavaScript a chance to choose the right method, say an ajax POST. But= AT is NOT  a secrete to RS.




On Fri, Jul 1, 2016 at 5:53 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
yes

On Jul 1, 2016, at 8:39 PM, Oleg Gryb <oleg_gryb@yahoo.com>= wrote:

I think, the intention was not to share AT with t= he web-hosted client resource. As you can see in the original flow the latt= er never receives the AT, it simply provides code that can get AT from a fr= agment and some UI. In the modified flow AT is sent to the web-hosted clien= t resource, which makes security worse in my view, because you have your AT= exposed in two places now - in the User Agent *and* in the web-hosted clie= nt resource.

<= /div>


From: John Bradley <ve7jtb@ve7jtb.com> To: Liyu Y= i <liyuyi@gmail.com&g= t;
Cc: O= leg Gryb <oleg@gryb.info&= gt;; "<oauth@ietf.org>= " <oauth@ietf.org>
Sent: Frida= y, July 1, 2016 4:06 PM
Subject: Re: [OAUTH-WG] Security concern for URI fragment a= s Implicit grant

I take it that Web-hosted client resource is part of the client.
I think perhaps you have client and resource ser= ve r mixed up a bit in your diagram.

Yes you could do that but it is not a great way to build the client as it= will blow away context.  
You can do it but people generall= y want to start the application in the browser first and then call out to t= he IdP  in a iFrame.

What you = propose would work more or less.  I don=E2=80=99t see it as a pattern = that I would necessarily recommend over the current fragment encoding.

If we mover to post message it would in= clude API  for logout and session management, not just login.

John B.

=

On Jul 1, = 2016, at 6:43 PM, Liyu Yi <liyuyi@gmail.com> wrote:

Understood there is an Authorization Code grant type; here I am m= ore focusing on the Implicit grant type. 
  
=
also when I mentioned POST, I did not mean postMessage, it is simply t= he HTTP POST. Specifically it is more like this ...



4.2.  Implicit Grant (modified)



     +=
----------+
     | Resource |
     |  Owner   |
     |          |
     +----------+
          ^
          |
         (B)
     +----|-----+          Client Identifier     +---------------+
     |         -+----(A)-- & Redirection URI --->|               |
     |  User-   |                                | Authorization |
     |  Agent  -|----(B)-- User authenticates -->|     Server    |
     |          |                                |               |
     |          |<---(C)- Response embedded JS -<|               |
     |          |          with Access Token     +---------------+
     |          |            in JS content, which will be posted to Resourc=
e Server
     |          |                                +---------------+
     |          |----(D)-- JS post to RS URI --->|   Web-Hosted  |
     |          |         with Access Token      |     Client    |
     |          |                                |    Resource   |
     |     (F)  |<---(E)----- RS Script --------<|               |
     |          |         with Access Token      +---------------+
     +-|--------+
       |    |
      (A)  (G) Access Token
       |    |
       ^    v
     +---------+
     |         |
     |  Client |
     |         |
     +---------+



                       Figure 4: Implicit Grant Flow


=
   The flow illustrated in Figure 4 includes the following steps:

   (A)  The client initiates the flow by directing the resource owner's
        user-agent to the authorization endpoint.  The client includes
        its client identifier, requested scope, local state, and a
        redirection URI to which the authorization server will send the
        user-agent back once access is granted (or denied).

   (B)  The authorization server authenticates the resource owner (via
        the user-agent) and establishes whether the resource owner
        grants or denies the client's access request.

   (C)  Assuming the resource owner grants access, the authorization
        server responds with a JavaScript logic which automatically posts t=
o=20
        "redirection" URI provided earlier.  The JavaScript includes
        the access token in the URI fragment.

   (D)  The user-agent does the post with the access token. Granted,  
=

              =
    user agent can actually do post without the access token  in a different=
 iframe, 
                  then use postMessage to pass the token over, but =
I do not see why get it need that compexity.


On Fri, Jul 1, 2016 at 3:13 PM, J= osh Mandel <jmandel@gmail.com> wrote:
=
Thanks John! Yes, we're following the CORS based flow you'= ve described below (though I should note that the actual redirection back t= o the client could be a 302, or could be a simple Web link that the user fo= llows from an authorization page; this is up to the authorization server). =
Overall I don't argue that this flow is "more secure= " than the implicit flow -- though I believe it does help client developers= avoid some common pitfalls. (For example, clients that, through careless p= rogramming or poor understanding of the spec, fail to validate incoming "st= ate" are still not susceptible to arbitrary token injection, which means at= least they won't readily be tricked into using a token designated for an e= ntirely different client. With poorly written implicit flow clients, this i= s an issue.)
That said, I wasn't aiming to discuss t= he relative security; just wanted to make sure I knew what you meant by "wo= n't work well".
Thanks again!
-Josh
On Jul 1, 2016 18:02, "John Bradley" <ve7jtb@ve7jtb.com> wrote:
I am making a distinction betwee= n a browser talking to a Web server that is acting as a OAuth Client POST r= esponse mode =3D good , and a oauth client running in the browser user agen= t as a Java script application (that can=E2=80=99t directly capture a POST = response back to the server)

So it depend= s on where the client is actually running.

Are you saying that you are using a 302 redirect from the authoriza= tion endpoint back to the server hosting the JS and then loading the JS inc= luding the code and then using CORES  to exchange the code for a AT?

You can do that but I don=E2=80=99t = think a public client like that is more secure than just using the fragment= encoded response and is more work.
It also may give the server a= false sense of security.

John B.
On Jul 1, 2016, at 5:5= 2 PM, Josh Mandel <jman= del@gmail.com> wrote:

= I think the confusion here is that I'm not using HEART's OAuth profiles :-)=

I'm using the SMART profiles, where we d= o specify the use of an authorization code grant even for browser-based pub= lic clients (in which case, no client_secret is issued or used). I'm just t= rying to understand your perspective eon why this "won't work well". Perhap= s you didn't mean this comment to refer to browser-based OAuth clients gene= rally?

  -Josh

On Fri, Jul 1, 2016 at 5:45 PM, John Bradley <ve7jtb@ve7jtb= .com> wrote:
I don=E2=80=99t think the post response mode is supported = by heart so I suspect that we are talking about different things.

You are probably using the supported code flow tha= t uses a 302 get to return the code to the OAuth client on the server. &nbs= p;
The Web server is then acting as a confidential client to exch= ange the code via a POST (different POST) with the AS token_endpoint.
=

The Token endpoint will return a access = token (AT) and optional refresh token (RT).

The web page may be getting the server to make the OAuth calls on = it=E2=80=99s behalf to the Resource Server, or possibly you are passing the= AT from the server back to a Java script app that is using CORES to make c= alls directly to the RS without going through the Web server.
Passing the AT back to the user agent from the c= lient is not recommended. 

For= in browser clients where the JS is using the AT to make the calls directly= to the RS via CORES the recommended approach is to use the fragment encode= d response via a 302 to deliver the AT directly to the client (It never hit= s the backend Web server).

However = I believe In browser OAuth clients are not currently supported in HEART, so= I am not quite sure what you are doing.

Perhaps Justin has a better answer.

John B.


On Jul 1, 2016, at 5:33 PM, J= osh Mandel <jmandel@gma= il.com> wrote:

John,
I appreciate your response. I'm hoping you= can clarify why you say that "HTTP POST... won't work well for... [a] sing= le page OAuth client"?

We commonly build = single-page apps that act as OAuth clients for SMART (e.g. thi= s sample app ), and we've had good experience with the technique. = Could you elaborate?

  -J

On Fri, Jul 1, 2016 at 5:26 PM, = John Bradley <ve7jtb@ve7jtb.com> wrote:
HEART only supports web server clien= ts at the moment.   That might change in future to support native apps= if that an be made to support the security requirements of Heath IT.
<= br clear=3D"none">
So the thing HTTP POST responses won=E2=80=99t work = well for is a type of in browser single page OAuth client.  That still= needs fragment encoded responses or the new post-message Java Script API a= pproach.

John B.


On Jul 1, 2016, at 5:16 PM, Josh Mandel <jmandel@gmail.com> wrote:

Thanks Justin,

To clarify: John's comment and my question were about POST. (I do u= nderstand the behavior of HTTP POST and of window.postMessage; these are to= tally different things.) From my perspective in SMART Health IT, we use the= OAuth 2.0 authorization code flow, including HTTP POST, in our authorization spec even for public clients, a= nd it has worked very well for us, with about a dozen electronic health rec= ord servers supporting this approach. That's why I was curious to hear John= 's perspective about limitations.

&= nbsp; -J

On Fri, Jul 1, 2016 at 5:09 PM, = Oleg Gryb <oleg_gryb@yahoo.com> wrote:
> POST = will send things to the server, which isn=E2=80=99t desirable if your clien= t is solely in the browser
Why it's not desirable, as= suming that we disregard performance? You can generate HTTP POST from JS, e= .g. through an AJAX call. What is wrong with this?
=


From: Justin Richer <jr= icher@mit.edu>
To: Josh Mandel <jmandel@gmail.com>
Cc: Oleg Gryb <oleg@gryb.info>; "<oauth@ietf.org>" <oauth@ietf.org>; Liyu Yi <liyuyi@gmail.com>
Sent: Friday, July 1, 2016 2:00 PM
<= br clear=3D"none"> Subject:= Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

POST will send things to the server, which isn=E2=80=99t desirable if your= client is solely in the browser. postMessage is a browser API and not to b= e confused with HTTP POST. postMessage messages stay (or can stay) within t= he browser, which is the intent here.

&nb= sp;=E2=80=94 Justin

On Jul 1, 2016, at 4:56 PM, Josh Mandel <jmandel@gmail.com> wrote:

John,

Could you clarify wh= at you mean by "POST doesn't really work"= ? Do you just mean that CORS support (e.g., http:/= /caniuse.com/#feat=3Dcors) isn't universal, or something more?

On Fri, Jul 1, 2016 at 4:51 PM, John Bradl= ey <v= e7jtb@ve7jtb.com> wrote:
Yes but POST doesn't really work for in browser apps.

If it is a server app it should be using the code fl= ow with GET or POST as you like.

If= we do a  post message based binding it will be targeted at in browser= applications.

John B.
<= div>
On Fri, Jul 1, 2016 at 4:42 PM, Liyu Yi <liyuyi@gmail.= com> wrote:
BTW,= I do not see any significant performance concerns for post. Parsing and ex= ecuting the Javascript logic for post operation will be on the client side,= no extra server load is introduced.

Plus= post will remove the size restriction of the URL length.

-- Liyu&= nbsp;

On Fri, Jul 1, 2016= at 1:35 PM, Liyu Yi <liyuyi@gmail.com> wrote:
Thanks for the great comments and advices.

I think it is a good idea for the working g= roup to revise the fragment part in the spec, since there might be public a= vailable tools already implemented this approach and people can end up with= a solution with serious security loopholes.

<= div>The re-append issue can be mitigate by a logic on Resource Server which= carefully re-writes/removes the fragment in any redirect, if the the redir= ect can not be avoided.

-- Liyu
 
<= /div>

On Fri, Jul 1, 2016 a= t 11:33 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
This behaviour started c= hanging around 2011

From HTTP/1.1
See https://tools.ietf.org/htm= l/rfc7231#section-7.1.2I
      f the Loc= ation value provided in a 3xx (Redirection) response does
   not have a fragment component, a user agent MUST process the
   redirection as if the value inherits the fragment component of the
   URI reference used to generate the request target (i.e., the
   redirection inherits the original reference's fragment, if any).

   For example, a GET request generated for the URI reference
   "http://www.example.org/~tim" might result in a 303 (=
See Other)
   response containing the header field:

     Location: /People.html#tim

   which suggests that the user agent redirect to
   "http://www.example.org/People.html#tim=E2=
=80=9D

   Like=
wise, a GET request generated for the URI reference
   "http://www.example.org/index.html#larry"=
 might result in a 301
   (Moved Permanently) response containing the header field:

     Location: http://www.example.net/index.html

   which suggests that the user agent redirect to
   "http://www.example.net/index.html#larry"=
, preserving the original
   fragment identifier.


This blog also explores the change.


On Jul 1, 2016, at 1:05 PM, Oleg Gryb <oleg_gryb@yahoo.com> wrote:
"Browsers now re-append  fragments across = 302 redirects unless they are explicitly cleared this makes fragment encodi= ng less safe than it was  when originally specified" - thanks Jim. Loo= ks like a good reason for vetting this flow out.
<= div dir=3D"ltr">
John,
Please provide more details/link= s about re-appending fragments. 
Thanks,
Oleg.


=
From: Jim Manico <jim@manicode.com>
To: Oleg Gryb <oleg@gryb.info>
Cc: "oauth@ietf.org" <oauth@i= etf.org>; Liyu Yi <liyuyi@gmail.com>
Sent: Thursday, June 30, 2016 10:25 PM
= Subject: Re: [OAUTH-WG] Se= curity concern for URI fragment as Implicit grant

Oleg! Hello! Great to see you pop = up here with a similar concern.

Joh= n Bradley just answered this thread with the details I was looking for (tha= nks John, hat tip your way).

He als= o mentioned details about fragment leakage:

"Browsers now re-append  fragments across 302 redirects= unless they are explicitly cleared this makes fragment encoding less safe = than it was when originally specified"

=
Again, I'm new here but I'm grateful for this conversation.

Aloha,
--
Jim = Manico
@Manicode

On Jul 1= , 2016, at 1:24 AM, Oleg Gryb <oleg_gryb@yahoo.com> wrote:

We've discussed access tokens in URI back in= 2010 (https://= www.ietf.org/mail-archive/web/oauth/current/msg04043.html). There were = two major objectives when I was saying that it's not secure:

1. Fragment is not sent = to a server by a browser. When I've asked if this is true for every browser= in the world, nobody was able to answer.
2. Replacin= g with POST would mean a significant performance impact in some high volume= implementations (I think it was Goole folks who were saying this, but I do= n't remember now).

AFAIR, nobody was arguing about browsing history, so it's valid.

So, 6 years = later we're at square one with this and I hope that this time the community= will be more successful with getting rid of secrets in URL.

BTW, Jim, if you can com= e up with other scenarios when fragments can leak, please share. It'll prob= ably help the community with solving this problem faster than in 6 years.

Thanks,
Oleg.


From:= Jim Manico <j= im@manicode.com>
To: Liyu Yi <liyuyi@gmail.com>; oauth@ietf.org
Sent: Wednesday, June 29, 2016 7:30 AM
<= span style=3D"font-weight:bold;">Subject: Re: [OAUTH-WG] Securit= y concern for URI fragment as Implicit grant

> Shouldn=E2=80=99t it be more secure if we change to use a post method for access token, similar to the SAML does?
I say yes. But please note I'm very new at this and someone with more experience will have more to say or correct my comments.
Here are a few more details to consider.
1) OAuth is a framework and not a standard, per se. Different authorization servers will have different implementations that are not necessarily compatible with other service providers. So there is no standard to break, per se.
2) Sensitive data in a URI is a bad idea. They leak all over the place even over HTTPS. Even in fragments.
3) Break the "rules" and find a way to submit sensitive data like access tokens, session information or any other (even short term) sensitive data in a secure fashion. This includes POST, JSON data payloads over PUT/PATCH and other verbs - all over well configured HTTPS.
4) If you really must submit sensitive data over GET , consider JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level confidentiality and integrity.
Aloha,
Jim Manico
Manicode Security
https://www.manicode.com

On 6/27/16 9:30 PM, Liyu Yi wrote:
While we are working on a project with OAuth2 implementation, one question arises from our engineers.
  
(C)  Assuming the resource owner grants access, the authorization
        server redire= cts the user-agent back to the client using the
        redirection U= RI provided earlier.  The redirection URI includes
        the access to= ken in the URI fragment.
 
For my understanding, the browser keeps the URI fragment in the history, and this introduces unexpected exposure of the access token. A user without authorization for the resource can get the access token as long as he has the access to the browser. This can happen in a shared computer in library, or for an IT staff who works on other employee=E2=80=99s computer.
 
Shouldn=E2=80=99t it be more secure if we change to use a post method for access token, similar to the SAML does?
I feel there might be something I missed here. Any advices will be appreciated.


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


--=20



=

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



<= /div>




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


_______________________________________________
OAuth mai= ling list
OAut= h@ietf.org
https://ww= w.ietf.org/mailman/listinfo/oauth

=

_________________________________= ______________
OAuth mailing list
OAuth@ietf.org
= https://www.ietf.org/mailman/listinfo/oauth<= /a>


=
_______________________________________________
OAuth mai= ling list
OAut= h@ietf.org
https://ww= w.ietf.org/mailman/listinfo/oauth
=

<= br clear=3D"none">






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




<= br> ------=_Part_619779_711122837.1467422093987-- From nobody Fri Jul 1 18:43:48 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC5612B056 for ; Fri, 1 Jul 2016 18:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.015 X-Spam-Level: X-Spam-Status: No, score=-3.015 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=yahoo.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 iYknyEOvI7tF for ; Fri, 1 Jul 2016 18:43:42 -0700 (PDT) Received: from nm41-vm4.bullet.mail.bf1.yahoo.com (nm41-vm4.bullet.mail.bf1.yahoo.com [216.109.114.159]) (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 A775412B019 for ; Fri, 1 Jul 2016 18:43:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1467423820; bh=UAwO1bRPVxplnc4IuFYr+ADGbnkatOLEc9RCOPgWNAw=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=n2VTGb3nzuf12HvXQdZ7wa5zV5oalUCWZDC8uahYahQnN5vAVagRnzvG4c3lOckO9fmBI8Njlw7uhKLf//Jm3AL+Q7JciLPahT1ktp8JXj0mi8bY4uQYLfRuMApCzaarTB9eC7E2mrcFaQK0/Iaac6g3zrTAoZRFndOP4LI0SxeNDDTac7oK9U7UwqcEglJ0V8cFDNy6FZzFZWRi/nkLoCz8Lrz0uwbvRa6prFANmbGHvyoQC96h934W0qJCeXtV6sbYcFfA/gcYjiGuBSG+hLS3QZjaJDtEuaLo1V1oYrxnnauk49IEZ6elRvdvqGlXt8NWueHIJOKKbAHjK3IgFw== Received: from [98.139.214.32] by nm41.bullet.mail.bf1.yahoo.com with NNFMP; 02 Jul 2016 01:43:40 -0000 Received: from [98.139.212.238] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 02 Jul 2016 01:43:40 -0000 Received: from [127.0.0.1] by omp1047.mail.bf1.yahoo.com with NNFMP; 02 Jul 2016 01:43:40 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 635969.50585.bm@omp1047.mail.bf1.yahoo.com X-YMail-OSG: 5v6iACQVM1kZ3_TCpMc3p__YCo.6WAQ4X5eU0hyQkGJcr13bG8U.auTp5glpWQC 3HHOh50PXQDdrU0tlRzdr1k_QuNvS.TIXgLuiu3L9cyGTvkPHQfUQ3ru2NWmfyTGO9G1c2QP3IW0 i6KY2Q5D7w5SXyUliqzXxV29uLV8snLc80crl20cJ_unyPw8YbdDq0k6z42SmRNvh1AW8LIpK1Q_ IKttmkS5wYgwLrnmKD7uexaaIMv_RPdILBnMeQgOhWtqon_qPplwWoQqNFCn505F66NwGhpavo1d WGbSJMuOWu7yoMNiuQEiRUp3e9Edi7hw_DBkXaR33RT_Nmq_eRRIu._TEtZN318JaGh7t_LKZG4q 6OfiKIOLy0gAl3UQwMZiCLTVteVu94VZeNmUzENt81i32vxwSRV6luWBW0zzyVfrF0SRARqJ.wo3 mwpQufUpXi1B5yvTQgwLv3m4ia_usNXFMInYwhSrI_1m7taQhQZs1qLDczel4qTFQpO_1t.gn5J8 Lis1a56Xh8TUbDjIbbKxsPM4_dPRJrNgqWm8IpCY- Received: from jws106206.mail.bf1.yahoo.com by sendmailws148.mail.bf1.yahoo.com; Sat, 02 Jul 2016 01:43:38 +0000; 1467423818.341 Date: Sat, 2 Jul 2016 01:43:33 +0000 (UTC) From: Oleg Gryb To: Liyu Yi , Oleg Gryb Message-ID: <466439908.635338.1467423813225.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: <994121658.55005.1467329084208.JavaMail.yahoo@mail.yahoo.com> <235316006.458279.1467392709447.JavaMail.yahoo@mail.yahoo.com> <6584BD74-B18F-4174-9E69-5C7B4B76F895@ve7jtb.com> <410908395.555462.1467407397629.JavaMail.yahoo@mail.yahoo.com> <8CC41328-C26D-42C0-BFDB-BF0216C7B76C@ve7jtb.com> <71CE61B3-FEC2-46A7-AB28-B53E89A8E53F@ve7jtb.com> <560704570.608692.1467419971908.JavaMail.yahoo@mail.yahoo.com> <50E491F2-E08F-40A7-B9DE-AB50CB647C04@ve7jtb.com> <597554829.619782.1467422094020.JavaMail.yahoo@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_635337_104073063.1467423813188" Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Oleg Gryb List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2016 01:43:46 -0000 ------=_Part_635337_104073063.1467423813188 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable You know, I've tried to solve this problem 6 years ago and I failed, but I'= m glad that community is looking to this again and I hope that John and oth= ers will eventually come up with something better than what we have now. If I come up with a sane idea, I'll definitely share. =20 =20 From: Liyu Yi To: Oleg Gryb =20 Cc: John Bradley ; "" Sent: Friday, July 1, 2016 6:37 PM Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit gran= t =20 John and Oleg, good point. I missed that. So in this case the "web-hosted c= lient resource" is a party different from the RS and is also different from= AS and is not supposed to access to AT. But I guess this "web-hosted clien= t resource" must be trusted, since its JS has access the the AT on the brow= ser side anyways. Maybe the secure way is to let the AS return an HTML with embedded JS and A= T. It does make the AS do more work, but it cuts out the need of "web-hoste= d client resource". Comments? -- Liyu On Fri, Jul 1, 2016 at 6:14 PM, Oleg Gryb wrote: As John has already pointed out - you're confusing RS with the=C2=A0web-hos= ted client resource. =20 From: Liyu Yi To: John Bradley =20 Cc: Oleg Gryb ; "" Sent: Friday, July 1, 2016 6:11 PM Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit gran= t =20 I would say AT is supposed to be consumed by the Resource Server. Although = the original spec does not show how AT is used by the client, but the AT wi= ll be sent out, most likely by the browser directly, or in a rare case if t= he client application has another channel, indirectly. The fact is that the AT is not sent in the 1st GET request does leave the R= S JavaScript a chance to choose the right method, say an ajax POST. But AT = is NOT =C2=A0a secrete to RS. On Fri, Jul 1, 2016 at 5:53 PM, John Bradley wrote: yes On Jul 1, 2016, at 8:39 PM, Oleg Gryb wrote: I think, the intention was not to share AT with the web-hosted client resou= rce. As you can see in the original flow the latter never receives the AT, = it simply provides code that can get AT from a fragment and some UI. In the= modified flow AT is sent to the web-hosted client resource, which makes se= curity worse in my view, because you have your AT exposed in two places now= - in the User Agent *and* in the web-hosted client resource. =20 From: John Bradley To: Liyu Yi =20 Cc: Oleg Gryb ; "" Sent: Friday, July 1, 2016 4:06 PM Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit gran= t =20 I take it that Web-hosted client resource is part of the client. I think perhaps you have client and resource serve r mixed up a bit in your= diagram. Yes you could do that but it is not a great way to build the client as it w= ill blow away context. =C2=A0You can do it but people generally want to sta= rt the application in the browser first and then call out to the IdP =C2=A0= in a iFrame. What you propose would work more or less.=C2=A0 I don=E2=80=99t see it as a= pattern that I would necessarily recommend over the current fragment encod= ing. If we mover to post message it would include API =C2=A0for logout and sessi= on management, not just login. John B. On Jul 1, 2016, at 6:43 PM, Liyu Yi wrote: Understood there is an Authorization Code grant type; here I am more focusi= ng on the Implicit grant type.=C2=A0=C2=A0=C2=A0also when I mentioned POST,= I did not mean postMessage, it is simply the HTTP POST. Specifically it is= more like this ... 4.2. Implicit Grant (modified) +----------+ | Resource | | Owner | | | +----------+ ^ | (B) +----|-----+ Client Identifier +---------------+ | -+----(A)-- & Redirection URI --->| | | User- | | Authorization | | Agent -|----(B)-- User authenticates -->| Server | | | | | | |<---(C)- Response embedded JS -<| | | | with Access Token +---------------+ | | in JS content, which will be posted to Resourc= e Server | | +---------------+ | |----(D)-- JS post to RS URI --->| Web-Hosted | | | with Access Token | Client | | | | Resource | | (F) |<---(E)----- RS Script --------<| | | | with Access Token +---------------+ +-|--------+ | | (A) (G) Access Token | | ^ v +---------+ | | | Client | | | +---------+ Figure 4: Implicit Grant Flow The flow illustrated in Figure 4 includes the following steps: (A) The client initiates the flow by directing the resource owner's user-agent to the authorization endpoint. The client includes its client identifier, requested scope, local state, and a redirection URI to which the authorization server will send the user-agent back once access is granted (or denied). (B) The authorization server authenticates the resource owner (via the user-agent) and establishes whether the resource owner grants or denies the client's access request. (C) Assuming the resource owner grants access, the authorization server responds with a JavaScript logic which automatically posts t= o=20 "redirection" URI provided earlier. The JavaScript includes the access token in the URI fragment. (D) The user-agent does the post with the access token. Granted, = user agent can actually do post without the access token in a= different iframe, then use postMessage to pass the token= over, but I do not see why get it need that compexity. On Fri, Jul 1, 2016 at 3:13 PM, Josh Mandel wrote: Thanks John! Yes, we're following the CORS based flow you've described belo= w (though I should note that the actual redirection back to the client coul= d be a 302, or could be a simple Web link that the user follows from an aut= horization page; this is up to the authorization server). Overall I don't a= rgue that this flow is "more secure" than the implicit flow -- though I bel= ieve it does help client developers avoid some common pitfalls. (For exampl= e, clients that, through careless programming or poor understanding of the = spec, fail to validate incoming "state" are still not susceptible to arbitr= ary token injection, which means at least they won't readily be tricked int= o using a token designated for an entirely different client. With poorly wr= itten implicit flow clients, this is an issue.) That said, I wasn't aiming = to discuss the relative security; just wanted to make sure I knew what you = meant by "won't work well".Thanks again! -JoshOn Jul 1, 2016 18:02, "John B= radley" wrote: I am making a distinction between a browser talking to a Web server that is= acting as a OAuth Client POST response mode =3D good , and a oauth client = running in the browser user agent as a Java script application (that can=E2= =80=99t directly capture a POST response back to the server) So it depends on where the client is actually running. Are you saying that you are using a 302 redirect from the authorization end= point back to the server hosting the JS and then loading the JS including t= he code and then using CORES =C2=A0to exchange the code for a AT? You can do that but I don=E2=80=99t think a public client like that is more= secure than just using the fragment encoded response and is more work.It a= lso may give the server a false sense of security. John B. On Jul 1, 2016, at 5:52 PM, Josh Mandel wrote: I think the confusion here is that I'm not using HEART's OAuth profiles :-) I'm using the SMART profiles, where we do specify the use of an authorizati= on code grant even for browser-based public clients (in which case, no clie= nt_secret is issued or used). I'm just trying to understand your perspectiv= e eon why this "won't work well". Perhaps you didn't mean this comment to r= efer to browser-based OAuth clients generally? =C2=A0 -Josh On Fri, Jul 1, 2016 at 5:45 PM, John Bradley wrote: I don=E2=80=99t think the post response mode is supported by heart so I sus= pect that we are talking about different things. You are probably using the supported code flow that uses a 302 get to retur= n the code to the OAuth client on the server. =C2=A0The Web server is then = acting as a confidential client to exchange the code via a POST (different = POST) with the AS token_endpoint. The Token endpoint will return a access token (AT) and optional refresh tok= en (RT). The web page may be getting the server to make the OAuth calls on it=E2=80= =99s behalf to the Resource Server, or possibly you are passing the AT from= the server back to a Java script app that is using CORES to make calls dir= ectly to the RS without going through the Web server. Passing the AT back to the user agent from the client is not recommended.= =C2=A0 For in browser clients where the JS is using the AT to make the calls direc= tly to the RS via CORES the recommended approach is to use the fragment enc= oded response via a 302 to deliver the AT directly to the client (It never = hits the backend Web server). However I believe In browser OAuth clients are not currently supported in H= EART, so I am not quite sure what you are doing. Perhaps Justin has a better answer. John B. On Jul 1, 2016, at 5:33 PM, Josh Mandel wrote: John, I appreciate your response. I'm hoping you can clarify why you say that "HT= TP POST... won't work well for... [a] single page OAuth client"? We commonly build single-page apps that act as OAuth clients for SMART (e.g= . this sample app=C2=A0), and we've had good experience with the technique.= Could you elaborate? =C2=A0 -J On Fri, Jul 1, 2016 at 5:26 PM, John Bradley wrote: HEART only supports web server clients at the moment. =C2=A0 That might cha= nge in future to support native apps if that an be made to support the secu= rity requirements of Heath IT. So the thing HTTP POST responses won=E2=80=99t work well for is a type of i= n browser single page OAuth client.=C2=A0 That still needs fragment encoded= responses or the new post-message Java Script API approach. John B. On Jul 1, 2016, at 5:16 PM, Josh Mandel wrote: Thanks Justin, To clarify: John's comment and my question were about POST. (I do understan= d the behavior of HTTP POST and of window.postMessage; these are totally di= fferent things.) From my perspective in SMART Health IT, we use the OAuth 2= .0 authorization code flow, including HTTP POST, in our authorization spec= =C2=A0even for public clients, and it has worked very well for us, with abo= ut a dozen electronic health record servers supporting this approach. That'= s why I was curious to hear John's perspective about limitations. =C2=A0 -J On Fri, Jul 1, 2016 at 5:09 PM, Oleg Gryb wrote: > POST will send things to the server, which isn=E2=80=99t desirable if you= r client is solely in the browserWhy it's not desirable, assuming that we d= isregard performance? You can generate HTTP POST from JS, e.g. through an A= JAX call. What is wrong with this? =20 From: Justin Richer To: Josh Mandel =20 Cc: Oleg Gryb ; "" ; Liyu Y= i Sent: Friday, July 1, 2016 2:00 PM Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit gran= t =20 POST will send things to the server, which isn=E2=80=99t desirable if your = client is solely in the browser. postMessage is a browser API and not to be= confused with HTTP POST. postMessage messages stay (or can stay) within th= e browser, which is the intent here. =C2=A0=E2=80=94 Justin On Jul 1, 2016, at 4:56 PM, Josh Mandel wrote: John, Could you clarify what you mean by "POST doesn't really work"? Do you just = mean that CORS support (e.g.,=C2=A0http://caniuse.com/#feat=3Dcors) isn't u= niversal, or something more? On Fri, Jul 1, 2016 at 4:51 PM, John Bradley wrote: Yes but POST doesn't really work for in browser apps. If it is a server app it should be using the code flow with GET or POST as = you like. If we do a =C2=A0post message based binding it will be targeted at in brows= er applications. John B. On Fri, Jul 1, 2016 at 4:42 PM, Liyu Yi wrote: BTW, I do not see any significant performance concerns for post. Parsing an= d executing the Javascript logic for post operation will be on the client s= ide, no extra server load is introduced. Plus post will remove the size restriction of the URL length. -- Liyu=C2=A0 On Fri, Jul 1, 2016 at 1:35 PM, Liyu Yi wrote: Thanks for the great comments and advices. I think it is a good idea for the working group to revise the fragment part= in the spec, since there might be public available tools already implement= ed this approach and people can end up with a solution with serious securit= y loopholes. The re-append issue can be mitigate by a logic on Resource Server which car= efully re-writes/removes the fragment in any redirect, if the the redirect = can not be avoided. -- Liyu=C2=A0 On Fri, Jul 1, 2016 at 11:33 AM, John Bradley wrote: This behaviour started changing around 2011 >From HTTP/1.1See=C2=A0https://tools.ietf.org/html/rfc7231#section-7.1.2I=C2= =A0 =C2=A0 =C2=A0 f the Location value provided in a 3xx (Redirection) resp= onse does not have a fragment component, a user agent MUST process the redirection as if the value inherits the fragment component of the URI reference used to generate the request target (i.e., the redirection inherits the original reference's fragment, if any). For example, a GET request generated for the URI reference "http://www.example.org/~tim" might result in a 303 (See Other) response containing the header field: Location: /People.html#tim which suggests that the user agent redirect to "http://www.example.org/People.html#tim=E2=80=9D Likewise, a GET request generated for the URI reference "http://www.example.org/index.html#larry" might result in a 301 (Moved Permanently) response containing the header field: Location: http://www.example.net/index.html which suggests that the user agent redirect to "http://www.example.net/index.html#larry", preserving the original fragment identifier. This blog also explores the change.https://blogs.msdn.microsoft.com/ieinter= nals/2011/05/16/url-fragments-and-redirects/ On Jul 1, 2016, at 1:05 PM, Oleg Gryb wrote: "Browsers now re-append =C2=A0fragments across 302 redirects unless they ar= e explicitly cleared this makes fragment encoding less safe than it was =C2= =A0when originally specified" - thanks Jim. Looks like a good reason for ve= tting this flow out. John,Please provide more details/links about re-appending fragments.=C2=A0 Thanks,Oleg. =20 From: Jim Manico To: Oleg Gryb =20 Cc: "oauth@ietf.org" ; Liyu Yi Sent: Thursday, June 30, 2016 10:25 PM Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit gran= t =20 Oleg! Hello! Great to see you pop up here with a similar concern. John Bradley just answered this thread with the details I was looking for (= thanks John, hat tip your way). He also mentioned details about fragment leakage: "Browsers now re-append =C2=A0fragments across 302 redirects unless they ar= e explicitly cleared this makes fragment encoding less safe than it was whe= n originally specified" Again, I'm new here but I'm grateful for this conversation. Aloha,--Jim Manico@Manicode On Jul 1, 2016, at 1:24 AM, Oleg Gryb wrote: We've discussed access tokens in URI back in 2010 (https://www.ietf.org/mai= l-archive/web/oauth/current/msg04043.html). There were two major objectives= when I was saying that it's not secure: 1. Fragment is not sent to a server by a browser. When I've asked if this i= s true for every browser in the world, nobody was able to answer.2. Replaci= ng with POST would mean a significant performance impact in some high volum= e implementations (I think it was Goole folks who were saying this, but I d= on't remember now). AFAIR, nobody was arguing about browsing history, so it's valid. So, 6 years later we're at square one with this and I hope that this time t= he community will be more successful with getting rid of secrets in URL. BTW, Jim, if you can come up with other scenarios when fragments can leak, = please share. It'll probably help the community with solving this problem f= aster than in 6 years. Thanks,Oleg. =20 From: Jim Manico To: Liyu Yi ; oauth@ietf.org=20 Sent: Wednesday, June 29, 2016 7:30 AM Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit gran= t =20 > Shouldn=E2=80=99t it be more secure if we change to use a post method fo= r access token, similar to the SAML does? I say yes. But please note I'm ve= ry new at this and someone with more experience will have more to say or co= rrect my comments. Here are a few more details to consider. 1) OAuth is a framework and not a standard, per se. Different authorizati= on servers will have different implementations that are not necessarily com= patible with other service providers. So there is no standard to break, per= se. 2) Sensitive data in a URI is a bad idea. They leak all over the place ev= en over HTTPS. Even in fragments. 3) Break the "rules" and find a way to submit sensitive data like access = tokens, session information or any other (even short term) sensitive data i= n a secure fashion. This includes POST, JSON data payloads over PUT/PATCH a= nd other verbs - all over well configured HTTPS. 4) If you really must submit sensitive data over GET , consider JWT/JWS/J= WE (with limited scopes/lifetimes) to provide message level confidentiality= and integrity. Aloha, Jim Manico Manicode Security https://www.manicode.com=20 On 6/27/16 9:30 PM, Liyu Yi wrote: =20 While we are working on a project with OAuth2 implementation, one questio= n arises from our engineers. We noticed at https://tools.ietf.org/html/draf= t-ietf-oauth-v2-31#page-30, it is specified that =C2=A0=C2=A0 (C)=C2=A0 Ass= uming the resource owner grants access, the authorization =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 server redirects the user-agent back to the cli= ent using the =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 redirection URI pr= ovided earlier.=C2=A0 The redirection URI includes =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 the access token in the URI fragment. =C2=A0 For my unde= rstanding, the browser keeps the URI fragment in the history, and this intr= oduces unexpected exposure of the access token. A user without authorizati= on for the resource can get the access token as long as he has the access t= o the browser. This can happen in a shared computer in library, or for an I= T staff who works on other employee=E2=80=99s computer. =C2=A0 Shouldn=E2= =80=99t it be more secure if we change to use a post method for access toke= n, similar to the SAML does? I feel there might be something I missed here.= Any advices will be appreciated. =20 =20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 =20 --=20 =20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 =20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 =20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 =20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 =20 =20 =20 =20 ------=_Part_635337_104073063.1467423813188 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable




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








------=_Part_635337_104073063.1467423813188-- From nobody Fri Jul 1 22:28:16 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A34B12B027 for ; Fri, 1 Jul 2016 22:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 u2HYXdPzAUos for ; Fri, 1 Jul 2016 22:28:09 -0700 (PDT) Received: from nm45-vm8.bullet.mail.bf1.yahoo.com (nm45-vm8.bullet.mail.bf1.yahoo.com [216.109.115.79]) (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 D0A0512B013 for ; Fri, 1 Jul 2016 22:28:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1467437287; bh=B3pIaeLjj2SjiUkUfUClU02oKNwKcII39xq6Q70aaJg=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=mSCwco6mHy9allKwJQf0VSZh62pDSXIGZFk6HczbuA4jUb2o+Gda3G8AvCxzYcNu7SKCZDtMlFnRvMusw62c36YkcZqNv3Xj6ZaNmf1nfg6BmlF9+A/yFToBF1IoBH1OZCAHnOxDM/ZmKLhK9Kd3skFOpep4tambGMEnpoqgKQpwZcb6BgqXW+qoth3XPfpLtrVAgKE5o936OSLSA1dCF6JuR6Nztt/IHIDTKCbVudBHAbqiuGOuqZ1g/Ro+8cUHsAIRm5fZQRbdsIPKrc+++UFzDVG8MnbW8FszYciUsvAFuq4ZdsFhH8zeGvbScMBmZrtIpTIWYv+s9g+PPvX4mw== Received: from [98.139.170.181] by nm45.bullet.mail.bf1.yahoo.com with NNFMP; 02 Jul 2016 05:28:07 -0000 Received: from [98.139.212.251] by tm24.bullet.mail.bf1.yahoo.com with NNFMP; 02 Jul 2016 05:28:07 -0000 Received: from [127.0.0.1] by omp1060.mail.bf1.yahoo.com with NNFMP; 02 Jul 2016 05:28:07 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 717591.42663.bm@omp1060.mail.bf1.yahoo.com X-YMail-OSG: bBOElmgVM1nfoV4d8lYlPO7cMG3oJcNv.3m5JWehlhBOFA1EiYqd87KJKpich66 ZXCOCVK5wRjL_LffgsPP7mwGwdSlD4Hhbnd2rncbO2QEfZDY8gJpIA8aryXwTTSVfF9BP3vZAnDX dMr7MmtxaUphH99Vsbg7NzVrz7yypyTIA9BHTSLzRVj9mnXseupgEGH9dGZ4P5s4L_K3sGxESxlr _06_0UucQqkwtOgJS_7b3rKiK4EpaDaaloXVcmpIZLg8_w2qmhbVivnvlBRuhR_QDwSEJ8OCt3_I .1DfFLkkbMcd0gB93tOM7t6KAsObTz8v.lFTn3w1nCxVv.WO_O38nDG45KeyN9B8nmpoZaWm9TEQ GpZ1V13UwU02Ah53LXa3p6t5vdHSVrdMBnNunjYTJIpX7C3m5MEoSU.knkwJY.fod5BKKm873Z1L eExQ8cIw6RFHV0daB.8C7zmCtRVxPqyMnllTDQAVRcmFpUuPeYvA1sI945xs1mS4_ZH9iSCojxRn rmLEpiPAPf4dgE9dbW9AHM3QiZjokr1EZRzLNH1E- Received: from jws106111.mail.bf1.yahoo.com by sendmailws147.mail.bf1.yahoo.com; Sat, 02 Jul 2016 05:28:07 +0000; 1467437287.210 Date: Sat, 2 Jul 2016 05:26:03 +0000 (UTC) From: Oleg Gryb To: Liyu Yi , John Bradley Message-ID: <1621133370.675710.1467437163975.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <466439908.635338.1467423813225.JavaMail.yahoo@mail.yahoo.com> References: <994121658.55005.1467329084208.JavaMail.yahoo@mail.yahoo.com> <235316006.458279.1467392709447.JavaMail.yahoo@mail.yahoo.com> <6584BD74-B18F-4174-9E69-5C7B4B76F895@ve7jtb.com> <410908395.555462.1467407397629.JavaMail.yahoo@mail.yahoo.com> <8CC41328-C26D-42C0-BFDB-BF0216C7B76C@ve7jtb.com> <71CE61B3-FEC2-46A7-AB28-B53E89A8E53F@ve7jtb.com> <560704570.608692.1467419971908.JavaMail.yahoo@mail.yahoo.com> <50E491F2-E08F-40A7-B9DE-AB50CB647C04@ve7jtb.com> <597554829.619782.1467422094020.JavaMail.yahoo@mail.yahoo.com> <466439908.635338.1467423813225.JavaMail.yahoo@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_675709_1165922022.1467437163934" Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Oleg Gryb List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2016 05:28:14 -0000 ------=_Part_675709_1165922022.1467437163934 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Here is actually some idea. John, please let me know if there is anything w= rong with this. 1. At step "C" Auth Server instead of serving a redirect will return a payl= oad in a response with a JS =C2=A0called on page load that will do the redi= rect. Something like below where I use JsRender, but it can be any HTML renderer = implemented in JS
Template returned from the web hosted client resource should include someth= ing like this:
=C2=A0 =C2=A0=C2=A0 =C2=A0... other params if needed
=C2=A0 The generated page will be rendered in a browser with all params including = access token provided in hidden fields. Security risk here is the same - user agent has access to AT, but it's the = same risk as in the original flow. The benefit - no secrets in URI. =20 From: Oleg Gryb To: Liyu Yi ; Oleg Gryb =20 Cc: "" Sent: Friday, July 1, 2016 6:43 PM Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit gran= t =20 You know, I've tried to solve this problem 6 years ago and I failed, but I'= m glad that community is looking to this again and I hope that John and oth= ers will eventually come up with something better than what we have now. If I come up with a sane idea, I'll definitely share. =20 =20 From: Liyu Yi To: Oleg Gryb =20 Cc: John Bradley ; "" Sent: Friday, July 1, 2016 6:37 PM Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit gran= t =20 John and Oleg, good point. I missed that. So in this case the "web-hosted c= lient resource" is a party different from the RS and is also different from= AS and is not supposed to access to AT. But I guess this "web-hosted clien= t resource" must be trusted, since its JS has access the the AT on the brow= ser side anyways. Maybe the secure way is to let the AS return an HTML with embedded JS and A= T. It does make the AS do more work, but it cuts out the need of "web-hoste= d client resource". Comments? -- Liyu On Fri, Jul 1, 2016 at 6:14 PM, Oleg Gryb wrote: As John has already pointed out - you're confusing RS with the=C2=A0web-hos= ted client resource. =20 From: Liyu Yi To: John Bradley =20 Cc: Oleg Gryb ; "" Sent: Friday, July 1, 2016 6:11 PM Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit gran= t =20 I would say AT is supposed to be consumed by the Resource Server. Although = the original spec does not show how AT is used by the client, but the AT wi= ll be sent out, most likely by the browser directly, or in a rare case if t= he client application has another channel, indirectly. The fact is that the AT is not sent in the 1st GET request does leave the R= S JavaScript a chance to choose the right method, say an ajax POST. But AT = is NOT =C2=A0a secrete to RS. On Fri, Jul 1, 2016 at 5:53 PM, John Bradley wrote: yes On Jul 1, 2016, at 8:39 PM, Oleg Gryb wrote: I think, the intention was not to share AT with the web-hosted client resou= rce. As you can see in the original flow the latter never receives the AT, = it simply provides code that can get AT from a fragment and some UI. In the= modified flow AT is sent to the web-hosted client resource, which makes se= curity worse in my view, because you have your AT exposed in two places now= - in the User Agent *and* in the web-hosted client resource. =20 From: John Bradley To: Liyu Yi =20 Cc: Oleg Gryb ; "" Sent: Friday, July 1, 2016 4:06 PM Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit gran= t =20 I take it that Web-hosted client resource is part of the client. I think perhaps you have client and resource serve r mixed up a bit in your= diagram. Yes you could do that but it is not a great way to build the client as it w= ill blow away context. =C2=A0You can do it but people generally want to sta= rt the application in the browser first and then call out to the IdP =C2=A0= in a iFrame. What you propose would work more or less.=C2=A0 I don=E2=80=99t see it as a= pattern that I would necessarily recommend over the current fragment encod= ing. If we mover to post message it would include API =C2=A0for logout and sessi= on management, not just login. John B. On Jul 1, 2016, at 6:43 PM, Liyu Yi wrote: Understood there is an Authorization Code grant type; here I am more focusi= ng on the Implicit grant type.=C2=A0=C2=A0=C2=A0also when I mentioned POST,= I did not mean postMessage, it is simply the HTTP POST. Specifically it is= more like this ... 4.2. Implicit Grant (modified) +----------+ | Resource | | Owner | | | +----------+ ^ | (B) +----|-----+ Client Identifier +---------------+ | -+----(A)-- & Redirection URI --->| | | User- | | Authorization | | Agent -|----(B)-- User authenticates -->| Server | | | | | | |<---(C)- Response embedded JS -<| | | | with Access Token +---------------+ | | in JS content, which will be posted to Resourc= e Server | | +---------------+ | |----(D)-- JS post to RS URI --->| Web-Hosted | | | with Access Token | Client | | | | Resource | | (F) |<---(E)----- RS Script --------<| | | | with Access Token +---------------+ +-|--------+ | | (A) (G) Access Token | | ^ v +---------+ | | | Client | | | +---------+ Figure 4: Implicit Grant Flow The flow illustrated in Figure 4 includes the following steps: (A) The client initiates the flow by directing the resource owner's user-agent to the authorization endpoint. The client includes its client identifier, requested scope, local state, and a redirection URI to which the authorization server will send the user-agent back once access is granted (or denied). (B) The authorization server authenticates the resource owner (via the user-agent) and establishes whether the resource owner grants or denies the client's access request. (C) Assuming the resource owner grants access, the authorization server responds with a JavaScript logic which automatically posts t= o=20 "redirection" URI provided earlier. The JavaScript includes the access token in the URI fragment. (D) The user-agent does the post with the access token. Granted, = user agent can actually do post without the access token in a= different iframe, then use postMessage to pass the token= over, but I do not see why get it need that compexity. On Fri, Jul 1, 2016 at 3:13 PM, Josh Mandel wrote: Thanks John! Yes, we're following the CORS based flow you've described belo= w (though I should note that the actual redirection back to the client coul= d be a 302, or could be a simple Web link that the user follows from an aut= horization page; this is up to the authorization server). Overall I don't a= rgue that this flow is "more secure" than the implicit flow -- though I bel= ieve it does help client developers avoid some common pitfalls. (For exampl= e, clients that, through careless programming or poor understanding of the = spec, fail to validate incoming "state" are still not susceptible to arbitr= ary token injection, which means at least they won't readily be tricked int= o using a token designated for an entirely different client. With poorly wr= itten implicit flow clients, this is an issue.) That said, I wasn't aiming = to discuss the relative security; just wanted to make sure I knew what you = meant by "won't work well".Thanks again! -JoshOn Jul 1, 2016 18:02, "John B= radley" wrote: I am making a distinction between a browser talking to a Web server that is= acting as a OAuth Client POST response mode =3D good , and a oauth client = running in the browser user agent as a Java script application (that can=E2= =80=99t directly capture a POST response back to the server) So it depends on where the client is actually running. Are you saying that you are using a 302 redirect from the authorization end= point back to the server hosting the JS and then loading the JS including t= he code and then using CORES =C2=A0to exchange the code for a AT? You can do that but I don=E2=80=99t think a public client like that is more= secure than just using the fragment encoded response and is more work.It a= lso may give the server a false sense of security. John B. On Jul 1, 2016, at 5:52 PM, Josh Mandel wrote: I think the confusion here is that I'm not using HEART's OAuth profiles :-) I'm using the SMART profiles, where we do specify the use of an authorizati= on code grant even for browser-based public clients (in which case, no clie= nt_secret is issued or used). I'm just trying to understand your perspectiv= e eon why this "won't work well". Perhaps you didn't mean this comment to r= efer to browser-based OAuth clients generally? =C2=A0 -Josh On Fri, Jul 1, 2016 at 5:45 PM, John Bradley wrote: I don=E2=80=99t think the post response mode is supported by heart so I sus= pect that we are talking about different things. You are probably using the supported code flow that uses a 302 get to retur= n the code to the OAuth client on the server. =C2=A0The Web server is then = acting as a confidential client to exchange the code via a POST (different = POST) with the AS token_endpoint. The Token endpoint will return a access token (AT) and optional refresh tok= en (RT). The web page may be getting the server to make the OAuth calls on it=E2=80= =99s behalf to the Resource Server, or possibly you are passing the AT from= the server back to a Java script app that is using CORES to make calls dir= ectly to the RS without going through the Web server. Passing the AT back to the user agent from the client is not recommended.= =C2=A0 For in browser clients where the JS is using the AT to make the calls direc= tly to the RS via CORES the recommended approach is to use the fragment enc= oded response via a 302 to deliver the AT directly to the client (It never = hits the backend Web server). However I believe In browser OAuth clients are not currently supported in H= EART, so I am not quite sure what you are doing. Perhaps Justin has a better answer. John B. On Jul 1, 2016, at 5:33 PM, Josh Mandel wrote: John, I appreciate your response. I'm hoping you can clarify why you say that "HT= TP POST... won't work well for... [a] single page OAuth client"? We commonly build single-page apps that act as OAuth clients for SMART (e.g= . this sample app=C2=A0), and we've had good experience with the technique.= Could you elaborate? =C2=A0 -J On Fri, Jul 1, 2016 at 5:26 PM, John Bradley wrote: HEART only supports web server clients at the moment. =C2=A0 That might cha= nge in future to support native apps if that an be made to support the secu= rity requirements of Heath IT. So the thing HTTP POST responses won=E2=80=99t work well for is a type of i= n browser single page OAuth client.=C2=A0 That still needs fragment encoded= responses or the new post-message Java Script API approach. John B. On Jul 1, 2016, at 5:16 PM, Josh Mandel wrote: Thanks Justin, To clarify: John's comment and my question were about POST. (I do understan= d the behavior of HTTP POST and of window.postMessage; these are totally di= fferent things.) From my perspective in SMART Health IT, we use the OAuth 2= .0 authorization code flow, including HTTP POST, in our authorization spec= =C2=A0even for public clients, and it has worked very well for us, with abo= ut a dozen electronic health record servers supporting this approach. That'= s why I was curious to hear John's perspective about limitations. =C2=A0 -J On Fri, Jul 1, 2016 at 5:09 PM, Oleg Gryb wrote: > POST will send things to the server, which isn=E2=80=99t desirable if you= r client is solely in the browserWhy it's not desirable, assuming that we d= isregard performance? You can generate HTTP POST from JS, e.g. through an A= JAX call. What is wrong with this? =20 From: Justin Richer To: Josh Mandel =20 Cc: Oleg Gryb ; "" ; Liyu Y= i Sent: Friday, July 1, 2016 2:00 PM Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit gran= t =20 POST will send things to the server, which isn=E2=80=99t desirable if your = client is solely in the browser. postMessage is a browser API and not to be= confused with HTTP POST. postMessage messages stay (or can stay) within th= e browser, which is the intent here. =C2=A0=E2=80=94 Justin On Jul 1, 2016, at 4:56 PM, Josh Mandel wrote: John, Could you clarify what you mean by "POST doesn't really work"? Do you just = mean that CORS support (e.g.,=C2=A0http://caniuse.com/#feat=3Dcors) isn't u= niversal, or something more? On Fri, Jul 1, 2016 at 4:51 PM, John Bradley wrote: Yes but POST doesn't really work for in browser apps. If it is a server app it should be using the code flow with GET or POST as = you like. If we do a =C2=A0post message based binding it will be targeted at in brows= er applications. John B. On Fri, Jul 1, 2016 at 4:42 PM, Liyu Yi wrote: BTW, I do not see any significant performance concerns for post. Parsing an= d executing the Javascript logic for post operation will be on the client s= ide, no extra server load is introduced. Plus post will remove the size restriction of the URL length. -- Liyu=C2=A0 On Fri, Jul 1, 2016 at 1:35 PM, Liyu Yi wrote: Thanks for the great comments and advices. I think it is a good idea for the working group to revise the fragment part= in the spec, since there might be public available tools already implement= ed this approach and people can end up with a solution with serious securit= y loopholes. The re-append issue can be mitigate by a logic on Resource Server which car= efully re-writes/removes the fragment in any redirect, if the the redirect = can not be avoided. -- Liyu=C2=A0 On Fri, Jul 1, 2016 at 11:33 AM, John Bradley wrote: This behaviour started changing around 2011 >From HTTP/1.1See=C2=A0https://tools.ietf.org/html/rfc7231#section-7.1.2I=C2= =A0 =C2=A0 =C2=A0 f the Location value provided in a 3xx (Redirection) resp= onse does not have a fragment component, a user agent MUST process the redirection as if the value inherits the fragment component of the URI reference used to generate the request target (i.e., the redirection inherits the original reference's fragment, if any). For example, a GET request generated for the URI reference "http://www.example.org/~tim" might result in a 303 (See Other) response containing the header field: Location: /People.html#tim which suggests that the user agent redirect to "http://www.example.org/People.html#tim=E2=80=9D Likewise, a GET request generated for the URI reference "http://www.example.org/index.html#larry" might result in a 301 (Moved Permanently) response containing the header field: Location: http://www.example.net/index.html which suggests that the user agent redirect to "http://www.example.net/index.html#larry", preserving the original fragment identifier. This blog also explores the change.https://blogs.msdn.microsoft.com/ieinter= nals/2011/05/16/url-fragments-and-redirects/ On Jul 1, 2016, at 1:05 PM, Oleg Gryb wrote: "Browsers now re-append =C2=A0fragments across 302 redirects unless they ar= e explicitly cleared this makes fragment encoding less safe than it was =C2= =A0when originally specified" - thanks Jim. Looks like a good reason for ve= tting this flow out. John,Please provide more details/links about re-appending fragments.=C2=A0 Thanks,Oleg. =20 From: Jim Manico To: Oleg Gryb =20 Cc: "oauth@ietf.org" ; Liyu Yi Sent: Thursday, June 30, 2016 10:25 PM Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit gran= t =20 Oleg! Hello! Great to see you pop up here with a similar concern. John Bradley just answered this thread with the details I was looking for (= thanks John, hat tip your way). He also mentioned details about fragment leakage: "Browsers now re-append =C2=A0fragments across 302 redirects unless they ar= e explicitly cleared this makes fragment encoding less safe than it was whe= n originally specified" Again, I'm new here but I'm grateful for this conversation. Aloha,--Jim Manico@Manicode On Jul 1, 2016, at 1:24 AM, Oleg Gryb wrote: We've discussed access tokens in URI back in 2010 (https://www.ietf.org/mai= l-archive/web/oauth/current/msg04043.html). There were two major objectives= when I was saying that it's not secure: 1. Fragment is not sent to a server by a browser. When I've asked if this i= s true for every browser in the world, nobody was able to answer.2. Replaci= ng with POST would mean a significant performance impact in some high volum= e implementations (I think it was Goole folks who were saying this, but I d= on't remember now). AFAIR, nobody was arguing about browsing history, so it's valid. So, 6 years later we're at square one with this and I hope that this time t= he community will be more successful with getting rid of secrets in URL. BTW, Jim, if you can come up with other scenarios when fragments can leak, = please share. It'll probably help the community with solving this problem f= aster than in 6 years. Thanks,Oleg. =20 From: Jim Manico To: Liyu Yi ; oauth@ietf.org=20 Sent: Wednesday, June 29, 2016 7:30 AM Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit gran= t =20 > Shouldn=E2=80=99t it be more secure if we change to use a post method fo= r access token, similar to the SAML does? I say yes. But please note I'm ve= ry new at this and someone with more experience will have more to say or co= rrect my comments. Here are a few more details to consider. 1) OAuth is a framework and not a standard, per se. Different authorizati= on servers will have different implementations that are not necessarily com= patible with other service providers. So there is no standard to break, per= se. 2) Sensitive data in a URI is a bad idea. They leak all over the place ev= en over HTTPS. Even in fragments. 3) Break the "rules" and find a way to submit sensitive data like access = tokens, session information or any other (even short term) sensitive data i= n a secure fashion. This includes POST, JSON data payloads over PUT/PATCH a= nd other verbs - all over well configured HTTPS. 4) If you really must submit sensitive data over GET , consider JWT/JWS/J= WE (with limited scopes/lifetimes) to provide message level confidentiality= and integrity. Aloha, Jim Manico Manicode Security https://www.manicode.com=20 On 6/27/16 9:30 PM, Liyu Yi wrote: =20 While we are working on a project with OAuth2 implementation, one questio= n arises from our engineers. We noticed at https://tools.ietf.org/html/draf= t-ietf-oauth-v2-31#page-30, it is specified that =C2=A0=C2=A0 (C)=C2=A0 Ass= uming the resource owner grants access, the authorization =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 server redirects the user-agent back to the cli= ent using the =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 redirection URI pr= ovided earlier.=C2=A0 The redirection URI includes =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 the access token in the URI fragment. =C2=A0 For my unde= rstanding, the browser keeps the URI fragment in the history, and this intr= oduces unexpected exposure of the access token. A user without authorizati= on for the resource can get the access token as long as he has the access t= o the browser. This can happen in a shared computer in library, or for an I= T staff who works on other employee=E2=80=99s computer. =C2=A0 Shouldn=E2= =80=99t it be more secure if we change to use a post method for access toke= n, similar to the SAML does? I feel there might be something I missed here.= Any advices will be appreciated. =20 =20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 =20 --=20 =20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 =20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 =20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 =20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 =20 =20 =20 =20 =20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 ------=_Part_675709_1165922022.1467437163934 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Here is actually some idea. John, please let me know if there is anythi= ng wrong with this.

1. At step= "C" Auth Server instead of serving a redirect will return a payload in a r= esponse with a JS  called on page load that will do the redirect.
=
Something like below = where I use JsRender, but it can be any HTML renderer implemented in JS

=
<scr= ipt>
= function doRedirect() {
var redirect_uri =3D "yyyy"; // we got it from AS
var data =3D [
  &nb= sp; "access_token": "xxxxx", // we got it from AS
    ....    =                     &nbs= p;          // other params if needed
]
$.get(redirect_uri, functi= on(response) { 
=09var script =3D document.createElement('scri= pt');
=09script.setAttribute('type', 'text/x-jsrender');
=09script.id =3D 'template';
=09script.innerHTML =3D response;
<= div dir=3D"ltr" id=3D"yui_3_16_0_ym19_1_1467429671506_16377">
=09var template =3D $.templates= (script);
=09var html =3D template.render(data);
=09$("#res= ult").html(html);
});
</script>

<body onload=3D'= doRedirect()'>
<div id=3D"result"></div>
</body>

Template returned from the web h= osted client resource should include something like this:

<form id=3D'token'>
  &nb= sp;<input type=3D'hidden' value=3D'{{:access_token}}'>
   ... othe= r params if needed
</form> 

The generated page will be rende= red in a browser with all params including access token provided in hidden = fields.
<= br>
Secur= ity risk here is the same - user agent has access to AT, but it's the same = risk as in the original flow. The benefit - no secrets in URI.




From: Oleg Gryb <oleg_gryb@yahoo.com>
To: Liyu Yi <liyuyi@gmail.com>; Oleg Gryb &l= t;oleg@gryb.info>
Cc: "<oauth@ietf.org>" <oauth@ietf.org>
Sent: Friday, July 1, 2016 6:43 PM
Subject: Re: [OAUTH-WG] Security = concern for URI fragment as Implicit grant

You k= now, I've tried to solve this problem 6 years ago and I failed, but I'm gla= d that community is looking to this again and I hope that John and others w= ill eventually come up with something better than what we have now.

If I come up with a sane idea, I'll definitely share.


From: Liyu Yi <liyuyi@gmail.com>
To: Oleg Gryb &l= t;oleg@gryb.info>
Cc: John Bradley <ve7jtb@ve7jtb.com>; "<oauth@ietf.or= g>" <oauth@ietf.org>
Sent: Friday, July 1, 2016 6:37 PM
= Subject: Re: [OAUTH-WG] Security concern for URI fragment as= Implicit grant

John and Oleg, good point. I missed that. So in= this case the "web-hosted client resource" is a party different from the R= S and is also different from AS and is not supposed to access to AT. But I = guess this "web-hosted client resource" must be trusted, since its JS has a= ccess the the AT on the browser side anyways.

Maybe the se= cure way is to let the AS return an HTML with embedded JS and AT. It does m= ake the AS do more work, but it cuts out the need of "web-hosted client res= ource".

Comments?

-- Liyu

On Fri, Jul 1= , 2016 at 6:14 PM, Oleg Gryb <oleg_gryb@yahoo.com> wrote:
As John has already pointed out -= you're confusing RS with the web-hosted client resource.
=


From: Liyu Yi <liyuyi@gmail.com>
To: John Bradley <ve7jtb@ve7jtb.com>
Cc: Oleg= Gryb <oleg@gryb.info>= ; "<oauth@ietf.org>" &= lt;oauth@ietf.org>
Sent: F= riday, July 1, 2016 6:11 PM

Subject: Re: [OAUTH= -WG] Security concern for URI fragment as Implicit grant
=

I would say AT is supposed to be consumed = by the Resource Server. Although the original spec does not show how AT is = used by the client, but the AT will be sent out, most likely by the browser= directly, or in a rare case if the client application has another channel,= indirectly.

The fact is that the AT is n= ot sent in the 1st GET request does leave the RS JavaScript a chance to cho= ose the right method, say an ajax POST. But AT is NOT  a secrete to RS= .



On Fri, Jul 1= , 2016 at 5:53 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
yes
On Jul 1, 2016, at 8:3= 9 PM, Oleg Gryb <ol= eg_gryb@yahoo.com> wrote:

I think, the intention w= as not to share AT with the web-hosted client resource. As you can see in t= he original flow the latter never receives the AT, it simply provides code = that can get AT from a fragment and some UI. In the modified flow AT is sen= t to the web-hosted client resource, which makes security worse in my view,= because you have your AT exposed in two places now - in the User Agent *an= d* in the web-hosted client resource.


=
From: John Bradley <ve7jtb@ve7jtb.com>
= To: Liyu Yi <liyuyi@gmail.com>
Cc: Oleg Gryb <oleg@gryb.info>; "<oauth@ietf.org>" <oauth@ietf.org>
= Sent: Friday, July 1, 2016 4:0= 6 PM
Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

I take it that W= eb-hosted client resource is part of the client.

I think perhaps you have client and resource serve r mixed up a bit= in your diagram.

Yes you could do = that but it is not a great way to build the client as it will blow away con= text.  
You can do it but people generally want to start the= application in the browser first and then call out to the IdP  in a i= Frame.

What you propose would work = more or less.  I don=E2=80=99t see it as a pattern that I would necess= arily recommend over the current fragment encoding.

If we mover to post message it would include API  for= logout and session management, not just login.

John B.


On Jul 1, 2016, at 6:43 PM, L= iyu Yi <liyuyi@gmail.com<= /a>> wrote:

Understoo= d there is an Authorization Code grant type; here I am more focusing on the= Implicit grant type. 
  
also when I me= ntioned POST, I did not mean postMessage, it is simply the HTTP POST. Speci= fically it is more like this ...



4.2. Implicit Grant (modified)

     +=
----------+
     | Resource |
     |  Owner   |
     |          |
     +----------+
          ^
          |
         (B)
     +----|-----+          Client Identifier     +---------------+
     |         -+----(A)-- & Redirection URI --->|               |
     |  User-   |                                | Authorization |
     |  Agent  -|----(B)-- User authenticates -->|     Server    |
     |          |                                |               |
     |          |<---(C)- Response embedded JS -<|               |
     |          |          with Access Token     +---------------+
     |          |            in JS content, which will be posted to Resourc=
e Server
     |          |                                +---------------+
     |          |----(D)-- JS post to RS URI --->|   Web-Hosted  |
     |          |         with Access Token      |     Client    |
     |          |                                |    Resource   |
     |     (F)  |<---(E)----- RS Script --------<|               |
     |          |         with Access Token      +---------------+
     +-|--------+
       |    |
      (A)  (G) Access Token
       |    |
       ^    v
     +---------+
     |         |
     |  Client |
     |         |
     +---------+



                       Figure 4: Implicit Grant Flow


=
   The flow illustrated in Figure 4 includes the following steps:

   (A)  The client initiates the flow by directing the resource owner's
        user-agent to the authorization endpoint.  The client includes
        its client identifier, requested scope, local state, and a
        redirection URI to which the authorization server will send the
        user-agent back once access is granted (or denied).

   (B)  The authorization server authenticates the resource owner (via
        the user-agent) and establishes whether the resource owner
        grants or denies the client's access request.

   (C)  Assuming the resource owner grants access, the authorization
        server responds with a JavaScript logic which automatically posts t=
o=20
        "redirection" URI provided earlier.  The JavaScript includes
        the access token in the URI fragment.

   (D)  The user-agent does the post with the access token. Granted,
= 
              =
    user agent can actually do post without the access token  in a different=
 iframe, 
                  then use postMessage to pass the token over, but =
I do not see why get it need that compexity.


On Fri, Jul 1, 2016 at 3:13 PM, J= osh Mandel <jmandel@gmail.com> wrote:
=
Thanks John! Yes, we're following the CORS based flow you'= ve described below (though I should note that the actual redirection back t= o the client could be a 302, or could be a simple Web link that the user fo= llows from an authorization page; this is up to the authorization server). =
Overall I don't argue that this flow is "more secure= " than the implicit flow -- though I believe it does help client developers= avoid some common pitfalls. (For example, clients that, through careless p= rogramming or poor understanding of the spec, fail to validate incoming "st= ate" are still not susceptible to arbitrary token injection, which means at= least they won't readily be tricked into using a token designated for an e= ntirely different client. With poorly written implicit flow clients, this i= s an issue.)
That said, I wasn't aiming to discuss t= he relative security; just wanted to make sure I knew what you meant by "wo= n't work well".
Thanks again!
-Josh
On Jul 1, 2016 18:02, "John Bradley" <ve7jtb@ve7jtb.com> wrote:
I am making a distinction betwee= n a browser talking to a Web server that is acting as a OAuth Client POST r= esponse mode =3D good , and a oauth client running in the browser user agen= t as a Java script application (that can=E2=80=99t directly capture a POST = response back to the server)

So it depend= s on where the client is actually running.

Are you saying that you are using a 302 redirect from the authoriza= tion endpoint back to the server hosting the JS and then loading the JS inc= luding the code and then using CORES  to exchange the code for a AT?

You can do that but I don=E2=80=99t = think a public client like that is more secure than just using the fragment= encoded response and is more work.
It also may give the server a= false sense of security.

John B.
On Jul 1, 2016, at 5:5= 2 PM, Josh Mandel <jman= del@gmail.com> wrote:

= I think the confusion here is that I'm not using HEART's OAuth profiles :-)=

I'm using the SMART profiles, where we d= o specify the use of an authorization code grant even for browser-based pub= lic clients (in which case, no client_secret is issued or used). I'm just t= rying to understand your perspective eon why this "won't work well". Perhap= s you didn't mean this comment to refer to browser-based OAuth clients gene= rally?

  -Josh

On Fri, Jul 1, 2016 at 5:45 PM, John Bradley <ve7jtb@ve7jtb= .com> wrote:
I don=E2=80=99t think the post response mode is supported = by heart so I suspect that we are talking about different things.

You are probably using the supported code flow tha= t uses a 302 get to return the code to the OAuth client on the server. &nbs= p;
The Web server is then acting as a confidential client to exch= ange the code via a POST (different POST) with the AS token_endpoint.
=

The Token endpoint will return a access = token (AT) and optional refresh token (RT).

The web page may be getting the server to make the OAuth calls on = it=E2=80=99s behalf to the Resource Server, or possibly you are passing the= AT from the server back to a Java script app that is using CORES to make c= alls directly to the RS without going through the Web server.
Passing the AT back to the user agent from the c= lient is not recommended. 

For= in browser clients where the JS is using the AT to make the calls directly= to the RS via CORES the recommended approach is to use the fragment encode= d response via a 302 to deliver the AT directly to the client (It never hit= s the backend Web server).

However = I believe In browser OAuth clients are not currently supported in HEART, so= I am not quite sure what you are doing.

Perhaps Justin has a better answer.

John B.


On Jul 1, 2016, at 5:33 PM, J= osh Mandel <jmandel@gma= il.com> wrote:

John,
I appreciate your response. I'm hoping you= can clarify why you say that "HTTP POST... won't work well for... [a] sing= le page OAuth client"?

We commonly build = single-page apps that act as OAuth clients for SMART (e.g. thi= s sample app ), and we've had good experience with the technique. = Could you elaborate?

  -J

On Fri, Jul 1, 2016 at 5:26 PM, = John Bradley <ve7jtb@ve7jtb.com> wrote:
HEART only supports web server clien= ts at the moment.   That might change in future to support native apps= if that an be made to support the security requirements of Heath IT.
<= br clear=3D"none">
So the thing HTTP POST responses won=E2=80=99t work = well for is a type of in browser single page OAuth client.  That still= needs fragment encoded responses or the new post-message Java Script API a= pproach.

John B.


On Jul 1, 2016, at 5:16 PM, Josh Mandel <jmandel@gmail.com> wrote:

Thanks Justin,

To clarify: John's comment and my question were about POST. (I do u= nderstand the behavior of HTTP POST and of window.postMessage; these are to= tally different things.) From my perspective in SMART Health IT, we use the= OAuth 2.0 authorization code flow, including HTTP POST, in our authorization spec even for public clients, a= nd it has worked very well for us, with about a dozen electronic health rec= ord servers supporting this approach. That's why I was curious to hear John= 's perspective about limitations.

&= nbsp; -J

On Fri, Jul 1, 2016 at 5:09 PM, = Oleg Gryb <oleg_gryb@yahoo.com> wrote:
> POST = will send things to the server, which isn=E2=80=99t desirable if your clien= t is solely in the browser
Why it's not desirable, as= suming that we disregard performance? You can generate HTTP POST from JS, e= .g. through an AJAX call. What is wrong with this?
=


From: Justin Richer <jr= icher@mit.edu>
To: Josh Mandel <jmandel@gmail.com>
Cc: Oleg Gryb <oleg@gryb.info>; "<oauth@ietf.org>" <oauth@ietf.org>; Liyu Yi <liyuyi@gmail.com>
Sent: Friday, July 1, 2016 2:00 PM
<= br clear=3D"none"> Subject:= Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

POST will send things to the server, which isn=E2=80=99t desirable if your= client is solely in the browser. postMessage is a browser API and not to b= e confused with HTTP POST. postMessage messages stay (or can stay) within t= he browser, which is the intent here.

&nb= sp;=E2=80=94 Justin

On Jul 1, 2016, at 4:56 PM, Josh Mandel <jmandel@gmail.com> wrote:

John,

Could you clarify wh= at you mean by "POST doesn't really work"= ? Do you just mean that CORS support (e.g., http:/= /caniuse.com/#feat=3Dcors) isn't universal, or something more?

On Fri, Jul 1, 2016 at 4:51 PM, John Bradl= ey <v= e7jtb@ve7jtb.com> wrote:
Yes but POST doesn't really work for in browser apps.

If it is a server app it should be using the code fl= ow with GET or POST as you like.

If= we do a  post message based binding it will be targeted at in browser= applications.

John B.
<= div>
On Fri, Jul 1, 2016 at 4:42 PM, Liyu Yi <liyuyi@gmail.= com> wrote:
BTW,= I do not see any significant performance concerns for post. Parsing and ex= ecuting the Javascript logic for post operation will be on the client side,= no extra server load is introduced.

Plus= post will remove the size restriction of the URL length.

-- Liyu&= nbsp;

On Fri, Jul 1, 2016= at 1:35 PM, Liyu Yi <liyuyi@gmail.com> wrote:
Thanks for the great comments and advices.

I think it is a good idea for the working g= roup to revise the fragment part in the spec, since there might be public a= vailable tools already implemented this approach and people can end up with= a solution with serious security loopholes.

<= div>The re-append issue can be mitigate by a logic on Resource Server which= carefully re-writes/removes the fragment in any redirect, if the the redir= ect can not be avoided.

-- Liyu
 
<= /div>

On Fri, Jul 1, 2016 a= t 11:33 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
This behaviour started c= hanging around 2011

From HTTP/1.1
See https://tools.ietf.org/htm= l/rfc7231#section-7.1.2I
      f the Loc= ation value provided in a 3xx (Redirection) response does
   not have a fragment component, a user agent MUST process the
   redirection as if the value inherits the fragment component of the
   URI reference used to generate the request target (i.e., the
   redirection inherits the original reference's fragment, if any).

   For example, a GET request generated for the URI reference
   "http://www.example.org/~tim" might result in a 303 (=
See Other)
   response containing the header field:

     Location: /People.html#tim

   which suggests that the user agent redirect to
   "http://www.example.org/People.html#tim=E2=
=80=9D

   Like=
wise, a GET request generated for the URI reference
   "http://www.example.org/index.html#larry"=
 might result in a 301
   (Moved Permanently) response containing the header field:

     Location: http://www.example.net/index.html

   which suggests that the user agent redirect to
   "http://www.example.net/index.html#larry"=
, preserving the original
   fragment identifier.


This blog also explores the change.


On Jul 1, 2016, at 1:05 PM, Oleg Gryb <oleg_gryb@yahoo.com> wrote:
"Browsers now re-append  fragments across = 302 redirects unless they are explicitly cleared this makes fragment encodi= ng less safe than it was  when originally specified" - thanks Jim. Loo= ks like a good reason for vetting this flow out.
<= div dir=3D"ltr">
John,
Please provide more details/link= s about re-appending fragments. 
Thanks,
Oleg.


=
From: Jim Manico <jim@manicode.com>
To: Oleg Gryb <oleg@gryb.info>
Cc: "oauth@ietf.org" <oauth@i= etf.org>; Liyu Yi <liyuyi@gmail.com>
Sent: Thursday, June 30, 2016 10:25 PM
= Subject: Re: [OAUTH-WG] Se= curity concern for URI fragment as Implicit grant

Oleg! Hello! Great to see you pop = up here with a similar concern.

Joh= n Bradley just answered this thread with the details I was looking for (tha= nks John, hat tip your way).

He als= o mentioned details about fragment leakage:

"Browsers now re-append  fragments across 302 redirects= unless they are explicitly cleared this makes fragment encoding less safe = than it was when originally specified"

=
Again, I'm new here but I'm grateful for this conversation.

Aloha,
--
Jim = Manico
@Manicode

On Jul 1= , 2016, at 1:24 AM, Oleg Gryb <oleg_gryb@yahoo.com> wrote:

We've discussed access tokens in URI back in= 2010 (https://= www.ietf.org/mail-archive/web/oauth/current/msg04043.html). There were = two major objectives when I was saying that it's not secure:

1. Fragment is not sent = to a server by a browser. When I've asked if this is true for every browser= in the world, nobody was able to answer.
2. Replacin= g with POST would mean a significant performance impact in some high volume= implementations (I think it was Goole folks who were saying this, but I do= n't remember now).

AFAIR, nobody was arguing about browsing history, so it's valid.

So, 6 years = later we're at square one with this and I hope that this time the community= will be more successful with getting rid of secrets in URL.

BTW, Jim, if you can com= e up with other scenarios when fragments can leak, please share. It'll prob= ably help the community with solving this problem faster than in 6 years.

Thanks,
Oleg.


From:= Jim Manico <j= im@manicode.com>
To: Liyu Yi <liyuyi@gmail.com>; oauth@ietf.org
Sent: Wednesday, June 29, 2016 7:30 AM
<= span style=3D"font-weight:bold;">Subject: Re: [OAUTH-WG] Securit= y concern for URI fragment as Implicit grant

> Shouldn=E2=80=99t it be more secure if we change to use a post method for access token, similar to the SAML does?
I say yes. But please note I'm very new at this and someone with more experience will have more to say or correct my comments.
Here are a few more details to consider.
1) OAuth is a framework and not a standard, per se. Different authorization servers will have different implementations that are not necessarily compatible with other service providers. So there is no standard to break, per se.
2) Sensitive data in a URI is a bad idea. They leak all over the place even over HTTPS. Even in fragments.
3) Break the "rules" and find a way to submit sensitive data like access tokens, session information or any other (even short term) sensitive data in a secure fashion. This includes POST, JSON data payloads over PUT/PATCH and other verbs - all over well configured HTTPS.
4) If you really must submit sensitive data over GET , consider JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level confidentiality and integrity.
Aloha,
Jim Manico
Manicode Security
https://www.manicode.com

On 6/27/16 9:30 PM, Liyu Yi wrote:
While we are working on a project with OAuth2 implementation, one question arises from our engineers.
  
(C)  Assuming the resource owner grants access, the authorization
        server redire= cts the user-agent back to the client using the
        redirection U= RI provided earlier.  The redirection URI includes
        the access to= ken in the URI fragment.
 
For my understanding, the browser keeps the URI fragment in the history, and this introduces unexpected exposure of the access token. A user without authorization for the resource can get the access token as long as he has the access to the browser. This can happen in a shared computer in library, or for an IT staff who works on other employee=E2=80=99s computer.
 
Shouldn=E2=80=99t it be more secure if we change to use a post method for access token, similar to the SAML does?
I feel there might be something I missed here. Any advices will be appreciated.


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


--=20



=

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



<= /div>




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


_______________________________________________
OAuth mai= ling list
OAut= h@ietf.org
https://ww= w.ietf.org/mailman/listinfo/oauth

=

_________________________________= ______________
OAuth mailing list
OAuth@ietf.org
= https://www.ietf.org/mailman/listinfo/oauth<= /a>


=
_______________________________________________
OAuth mai= ling list
OAut= h@ietf.org
https://ww= w.ietf.org/mailman/listinfo/oauth
=

<= br clear=3D"none">






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









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


------=_Part_675709_1165922022.1467437163934-- From nobody Sat Jul 2 18:22:53 2016 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C52312D097; Sat, 2 Jul 2016 18:22:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160703012247.14866.81674.idtracker@ietfa.amsl.com> Date: Sat, 02 Jul 2016 18:22:47 -0700 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-native-apps-02.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2016 01:22:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol of the IETF. Title : OAuth 2.0 for Native Apps Authors : William Denniss John Bradley Filename : draft-ietf-oauth-native-apps-02.txt Pages : 16 Date : 2016-07-02 Abstract: OAuth 2.0 authorization requests from native apps should only be made through external user-agents, primarily the system browser. This specification details the security and usability reasons why this is the case, and how native apps and authorization servers can implement this best practice. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-native-apps/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-oauth-native-apps-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-native-apps-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 4 19:32:40 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCA3912B063 for ; Mon, 4 Jul 2016 19:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Zij23SbBLoGC for ; Mon, 4 Jul 2016 19:32:37 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0133.outbound.protection.outlook.com [104.47.34.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6661C12B04B for ; Mon, 4 Jul 2016 19:32: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=/7gzXKFft7PUCh9e3knyZOzfz6wUfv3OXmmbYvQONKo=; b=DQ6ZPaa6RwizbtlqlVl7I2DK0eL4lwQvkPCZX3Q+6W+BaCbFLI+Tr+Wo8SOuaESpZ0MkHex2L5mv2fHoj9ibUXMABtOceftJTMCHESO5J5JztI0luTaft1LtX9pW0Ikr0zhpYQG/b97Xq50RPVsrcHxfqFPakwEZQY9MSxQ6GoY= 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.523.12; Tue, 5 Jul 2016 02:32:35 +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.0523.028; Tue, 5 Jul 2016 02:32:35 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: Token Binding for Access Tokens, Refresh Tokens, and ID Tokens Thread-Index: AdHWXIEv5fjJPXp1SGC8eaL/01WjRg== Date: Tue, 5 Jul 2016 02: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: [50.47.93.19] x-ms-office365-filtering-correlation-id: 45117bbd-a51a-42e7-2214-08d3a47ca00c x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1645; 6:S61GvDTTm/2ZcaYsp5bo/nAC9ZZFOxvgGIYqYLTCUnvw9ZdG1bwADY8IFxVMez147Tr9RKj35KXrblrrUp4WeDcUPpZvvuIW26TiHhoonsx0qmLukIJt/AUMcd+PNnKhts33W9ZG6Qdhu1LfrGoCfX1N7gIRL9EiraTTMxJrjr8puZ4OXyT3OrgSyFak17Bwp8Qe6E9VLJBi9lL/ClB8/6LVJdAW1nkrr/fuk1OH6EyXFlbbttIKljQ6kvAyYb/cdv5DKHZ9z0xh2MNcRZNqEZdh0cMBK9xnhF4nhz2gpyp2Og7UN7PCeCKxC9ujHAt0QJVXTpdsCXwK2IQVdFc5oQ==; 5:GsZ2owK7ecDtdKCVJkowFr3WJ3dCA+0gmUKnJP5CS/C7+7DChAbWiSk3l18WS3vBZRv+5CvowFqDMLxXpSTc6xlW/G0Zkhz6sIMlT/bGdD+UQ3B63/vx+TfISyMsNvdwxDMplqcgssbGY0nOUB8+Uw==; 24:6pvE72lpDFOwdFIz5zC7tgsV4rFh++G2/hKj6UxgRYz1Gn2hI5F6KYPuUeDXEDEPfB5Mt0KqAm1gmUEj5FpvUD0K5YIYSW1U5pnqSOP5Zu0=; 7:RISAPf0Su3aQ/BsDK4qyyTipZE3OkUePXsFmWNrZowPs1X62kX+2uoehS3uDZF5R9jLMOD1xUoaCkVCdeUWTAF0DT0llACPk5+yLL2rLwZowX9jD3+kLipaLptG8yZKbKqZJXXnE+2b4RmpuLZ//9b/maHJ30vAVpGqIH52hifIFoG7KPhAX2rEaEyA+xHmEVZT95Ipm/tdAOtunZx+qJiYe5miBzlSL68HcIGjdNTi2CBbkHhLgqtgaouMWfbgI x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1645; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(31418570063057)(21748063052155)(21532816269658); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:SN1PR0301MB1645; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1645; x-forefront-prvs: 0994F5E0C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(209900001)(189002)(199003)(15975445007)(7906003)(92566002)(77096005)(74316002)(5003600100003)(7696003)(7736002)(2906002)(2900100001)(790700001)(6116002)(3846002)(102836003)(9686002)(586003)(7846002)(450100001)(5002640100001)(76576001)(110136002)(189998001)(8676002)(5640700001)(81166006)(107886002)(5630700001)(81156014)(1730700003)(101416001)(10290500002)(10400500002)(5005710100001)(97736004)(66066001)(19580395003)(54356999)(19625215002)(229853001)(87936001)(122556002)(8990500004)(33656002)(99286002)(68736007)(19617315012)(3280700002)(16236675004)(10090500001)(50986999)(3660700001)(86612001)(8936002)(105586002)(2351001)(86362001)(11100500001)(2501003)(19300405004)(106356001)(6606295002); 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_SN1PR0301MB1645A77E280D29D7617590BBF5390SN1PR0301MB1645_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jul 2016 02:32:35.5329 (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: [OAUTH-WG] Token Binding for Access Tokens, Refresh Tokens, and ID Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 02:32:40 -0000 --_000_SN1PR0301MB1645A77E280D29D7617590BBF5390SN1PR0301MB1645_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Two new related specifications define syntax and semantics for applying Tok= en Binding to OAuth Access Tokens and Refresh Tokens and to OpenID Connect = ID Tokens. draft-jones-oauth-token-binding contains the OAuth portions. openid-connect-t= oken-bound-authentication-1_0 contains the OpenID Connect portions. These are being submitted now to hopefully enable end-to-end implementation= s and interop testing of Token Bound Access Tokens, Refresh Tokens, and ID = Tokens across multiple platforms before the Token Binding specifications ar= e finalized. The OAuth specification is available at: * http://tools.ietf.org/html/draft-jones-oauth-token-binding-00 (HTML= ized text plus links to other formats) * http://self-issued.info/docs/draft-jones-oauth-token-binding-00.htm= l (HTML) The OpenID Connect specification is available at: * http://self-issued.info/docs/openid-connect-token-bound-authenticat= ion-1_0-00.html (HTML) * http://self-issued.info/docs/openid-connect-token-bound-authenticat= ion-1_0-00.txt (Text) * http://self-issued.info/docs/openid-connect-token-bound-authenticat= ion-1_0-00.xml (XML Source) Thanks to Andrei Popov, Yordan Rouskov, John Bradley, and Brian Campbell fo= r reviews of earlier versions of these specifications and to Dirk Balfanz a= nd William Denniss for some earlier discussions providing input to these sp= ecifications. -- Mike P.S. This note was also posted at http://self-issued.info/?p=3D1577 and as= @selfissued. --_000_SN1PR0301MB1645A77E280D29D7617590BBF5390SN1PR0301MB1645_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Two new related specifications define syntax and sem= antics for applying Token Binding to OAuth Access Tokens and Refresh Tokens= and to OpenID Connect ID Tokens.  draf= t-jones-oauth-token-binding contains the OAuth portions.  openid-connect-token-bound-authentication-1_0 contains the OpenID Conne= ct portions.

 

These are being submitted now to hopefully enable en= d-to-end implementations and interop testing of Token Bound Access Tokens, = Refresh Tokens, and ID Tokens across multiple platforms before the Token Bi= nding specifications are finalized.

 

The OAuth specification is available at:<= /p>

·       http://tools.ietf.org/html/draft-jones-oauth-= token-binding-00 (HTMLized text plus links to other formats)=

·       http://self-issued.info/docs/draft-jon= es-oauth-token-binding-00.html (HTML)

 

The OpenID Connect specification is available at:

·       http://self-issued.info/= docs/openid-connect-token-bound-authentication-1_0-00.html (HTML)<= /o:p>

·       http://self-issued.info/d= ocs/openid-connect-token-bound-authentication-1_0-00.txt (Text)

·       http://self-issued.info/d= ocs/openid-connect-token-bound-authentication-1_0-00.xml (XML Source)

 

Thanks to Andrei Popov, Yordan Rouskov, John Bradley= , and Brian Campbell for reviews of earlier versions of these specification= s and to Dirk Balfanz and William Denniss for some earlier discussions prov= iding input to these specifications.

 

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

 

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

--_000_SN1PR0301MB1645A77E280D29D7617590BBF5390SN1PR0301MB1645_-- From nobody Tue Jul 5 11:16:28 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 733C412D533 for ; Tue, 5 Jul 2016 11:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.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 IU0YOHckGnNd for ; Tue, 5 Jul 2016 11:16:25 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4928212D12B for ; Tue, 5 Jul 2016 11:16:25 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id h190so90185011ith.1 for ; Tue, 05 Jul 2016 11:16:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:from:date:message-id:subject:to; bh=ElDnVLOF51DhpOnnVLcOsP3+lI0zDqKb/VBAw9wun4c=; b=fN0bVWmQL4dcptTNXxh+s+SUB+hH9OsCLJxlSmb6tYiv6UoLoJkxlHO2k85IIOMOaF Bk2ZxYcxichXpK4ghvBnFVF3XiGRZnMd5yHW0KCdfbppRG7dgUbojSGOPyp68ZvQNdVp KDQvmLe1blXVu+Ym8fJjjBK672Q87LeYa9JMg= 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=ElDnVLOF51DhpOnnVLcOsP3+lI0zDqKb/VBAw9wun4c=; b=GFl3/y37EWkpZNKKywxZAkydJM2uUMlk57V/l2RSHaMk4WX9gvMwtt39fVP6gi7db7 bPU+2QEx2VFhaNukOt13jBFFHGiVuw2Sx6B5cEclCFoNuQwcLaJ02juzeM48qrGJvFnQ 36l26o4qz0EFC7vORdNMO8hMUfrSg8kw8npOvc2cB62e7NIaK1gjWXhmFz3qqa+OQL5F Ery6Z3CySjFw7PxKX2wA9hwpxeU7oX+BsXSG9LRSWNRI6v6U8ZtClB4x0iqtUMOZiDkI cndqN5EDPoPGqTXtmyw7QAHEuYMelIepbAAt9K6zR5RY5qrN1ShFvNuw/zbS7bw8stkp YQdw== X-Gm-Message-State: ALyK8tJ8rnsaPxrxPKWuS9x3bBDjjPFsTsA3aN6wscobMYbU/owoCJF9wPgiGo4PbS/SYVQYhpIkS/d/FSgjt7R8 X-Received: by 10.36.84.79 with SMTP id t76mr15652060ita.63.1467742584243; Tue, 05 Jul 2016 11:16:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.28.149 with HTTP; Tue, 5 Jul 2016 11:15:54 -0700 (PDT) From: Brian Campbell Date: Tue, 5 Jul 2016 12:15:54 -0600 Message-ID: To: oauth Content-Type: multipart/alternative; boundary=001a1135293a5b1f7d0536e77325 Archived-At: Subject: [OAUTH-WG] RT treatment in Token Exchange X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 18:16:27 -0000 --001a1135293a5b1f7d0536e77325 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I gave a short presentation about OAuth 2.0 Token Exchange at a recent identity conference, which seemed well received and a lot of folks expressed their support for it and a desire to see support for it in offerings out in the wild. However, I did get some feedback from Vittorio Bertocci of Microsoft that he felt that the language around issuing refresh tokens was overly restrictive based on real world deployment experience they have with a token exchange like interaction that they are currently offering. He described it as follows: "To summarize our main use case: we use [a token exchange like protocol] for achieving user impersonation thru tiers, or delegation for confidential clients which do not have any web UX. Those cases do call for the ability of the middle tier to access the resource also when the original credential is no longer valid (e.g. there is no longer any user entertaining an active session with the middle tier). Think of a hypothetical new feature of the Uber mobile app, which can monitor your Exchange calendar and book a ride whenever a suitable slot opens up within a certain time range. The Uber app would call an Uber-owned middle tier, in form of Web API, and the Web API would itself be a client of the Exchange API. Given that the Uber API doesn=E2=80=99t offer any brow= ser ready surface, as it is meant to be accessed only via oauth2 bearer token, the [token exchange] is the only way through which it can obtain a token for the Exchange API; and the scenario definitely call for offline access, as the uber API should be able to monitor the Exchange calendar of the user even if the user closed the app on his/her phone." While the current text in the draft allows for this kind of thing, it stigmatizes it somewhat with a "NOT RECOMMENDED" on sending an RT in the response. So the proposal here is to make refresh tokens OPTIONAL and change the accompanying text in sec 2.2.1 to the following: refresh_token OPTIONAL. A refresh token will typically not be issued when the the exchange is of one temporary credential (the subject_token) for a different temporary credential (the issued token) for use in some other context. A refresh token can be issued in cases where the client of the token exchange needs the ability to access a resource even when the original credential is no longer valid (e.g. user-not-present or offline scenarios where there is no longer any user entertaining an active session with the client). Profiles or deployments of this specification should clearly document the conditions under which a client should expect a refresh token in response to "urn:ietf:params:oauth:grant- type:token-exchange" grant type requests. I plan to make the aforementioned change and get a new draft published with that and some other updates later this week before the Internet Draft submission cut-off on Friday. --001a1135293a5b1f7d0536e77325 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I gave a short presentation about OAuth 2.0 Token Exchange at a rece= nt identity conference, which seemed well received and a lot of folks expre= ssed their support for it and a desire to see support for it in offerings o= ut in the wild.

However, I did get some feedback from Vittori= o Bertocci of Microsoft that he felt that the language around issuing refre= sh tokens was overly restrictive based on real world deployment experience = they have with a token exchange like interaction that they are currently of= fering. He described it as follows:

= "To summarize our main use case: we use [a token exchange like protoco= l] for achieving user impersonation thru tiers, or delegation for confident= ial clients which do not have any web UX.

Those cases do call for th= e ability of the middle tier to access the resource also when the original = credential is no longer valid (e.g. there is no longer any user entertainin= g an active session with the middle tier).

Think of a hypothetical n= ew feature of the Uber mobile app, which can monitor your Exchange calendar= and book a ride whenever a suitable slot opens up within a certain time ra= nge. The Uber app would call an Uber-owned middle tier, in form of Web API,= and the Web API would itself be a client of the Exchange API. Given that t= he Uber API doesn=E2=80=99t offer any browser ready surface, as it is meant= to be accessed only via oauth2 bearer token, the [token exchange] is the = only way through which it can obtain a token for the Exchange API; and the = scenario definitely call for offline access, as the uber API should be able= to monitor the Exchange calendar of the user even if the user closed the a= pp on his/her phone."

While the current text in the= draft allows for this kind of thing, it stigmatizes it somewhat with a &qu= ot;NOT RECOMMENDED" on sending an RT in the response. So the proposal = here is to make refresh tokens OPTIONAL and change the accompanying text in= sec 2.2.1 to the following:

=C2=A0=C2=A0 refresh_token=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OPTIONAL.=C2=A0 A refresh token will typica= lly not be issued when the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the exchange i= s of one temporary credential (the subject_token)
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 for a different temporary credential (the issued token) for use i= n
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 some other context.=C2=A0 A refresh tok= en can be issued in cases where
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the clien= t of the token exchange needs the ability to access a
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 resource even when the original credential is no longer valid<= br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (e.g. user-not-present or offline scenari= os where there is no
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 longer any user ente= rtaining an active session with the client).
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Profiles or deployments of this specification should clearly
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 document the conditions under which a client shoul= d expect a
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 refresh token in response to &= quot;urn:ietf:params:oauth:grant-
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 type:to= ken-exchange" grant type requests.

I plan to make th= e aforementioned change and get a new draft published with that and some ot= her updates later this week before the Internet Draft submission cut-off on= Friday.
=C2=A0



--001a1135293a5b1f7d0536e77325-- From nobody Tue Jul 5 15:47:08 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6018812D115 for ; Tue, 5 Jul 2016 15:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 w5AAX0eSZ5Wb for ; Tue, 5 Jul 2016 15:47:02 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0096.outbound.protection.outlook.com [104.47.38.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DFB112B02F for ; Tue, 5 Jul 2016 15:47:02 -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=lB1TuecyX0TqYHexiD9AAbccMgFVCwFo5Udv9Q7Ms6k=; b=dPBzBS3UD4NTNrjZx10LsWqcqPwG/xqKv4H2qDEdBX8UueUoB1uCnCEhbt+ewHXvm6qu6OaPmWrawjDMAgRV6opBf6yBv5jPAwVAbd2xF4YqYfXMZTMiDPyhCc8UyszwmxrDkDY1vyRchUaKKeuAunX1XaH6YDfKyCioQdoOu3E= Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (10.161.207.22) by BN3PR0301MB1235.namprd03.prod.outlook.com (10.161.207.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.523.12; Tue, 5 Jul 2016 22:47:00 +0000 Received: from BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) by BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) with mapi id 15.01.0534.015; Tue, 5 Jul 2016 22:47:00 +0000 From: Anthony Nadalin To: Brian Campbell , oauth Thread-Topic: [OAUTH-WG] RT treatment in Token Exchange Thread-Index: AQHR1uldKJ4PVJsse0mpXwafM2g71aAKW8uQ Date: Tue, 5 Jul 2016 22:47:00 +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=tonynad@microsoft.com; x-originating-ip: [2001:4898:80e8::4cb] x-ms-office365-filtering-correlation-id: b63d6336-7cb7-4aea-e1de-08d3a52646d7 x-microsoft-exchange-diagnostics: 1; BN3PR0301MB1235; 6:gRccuoETQg7WzSPjsTdPIOGMkSqMkG1YOwhcfnPrTcPJu2zHaMEa0lHGLeQJv5wPEdPwHGBpdsuaW+qf6PoFQwkavEN5vD+73aJ8jPy7e7N0+2+7cB4hRKk0PO3xn2/jNqNebz15uWI8EEgODqRtsVIaqHCEUGJ1VaefWivoL50IJkKwLQAnOfpNRL+Sra/6B0B4ahx+KwVE7Tj9xRRkJbKd/Yxc70tLgZXVlDGoGUWNcvJYCzZnA56dtQakCVtjZJ8KJciMxl12Mn5IieVBHWkCNJf9tBAd1sthZjpkyAPImQKDfLvS37NCw4Xocl55zwwQVedYbi3kxipnHXQV3A==; 5:mdTC4JndwYAzevH9zcTUheklxL1csfMXoELAEJI0x4BIzznG20oqeC6YPUbXT/M+TGtENcw2KQKalHtoeO3OpOZ+DbWFTQJbAQg/y32FPDbaK9Qnn+TwgdJOE1s+P5VmsyIz4qsYQKqlQOe4aXmG8w==; 24:eg/PZlYCWVV/ItiG1o+ZZXREVAb5zDbIGAe0V3sXB2wi6dt7h77lRPfrnejoUuWu4MARHsUk4oySbbqDObOT620hdp54sWaM2b9KJQ6/Si4=; 7:rQ5oVmV+0zpZ7G4taopFgiLLIAPZdJorVpRILnESt48KhbE0uSaBfKFLug5MDGQYpmu/Lr1EjjphIbQpu8RheTmcGvOnMbu2rDbtJS/Ry2LA/cL1lb11IQfq+SEASMIrbj9cqWOOksZdOdmenn02A0Zvw1vEyJutSosB1M3eyf3sxS4IkCUIOIAU8dRzNdoKWuQDMZhuN4mWQtxza1teQdr2UjiUf9FFF7HH12zYPNM19PRj2kxcuuJpmNK9mjUc x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1235; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(189930954265078)(219752817060721)(178636050973902)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BN3PR0301MB1235; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1235; x-forefront-prvs: 0994F5E0C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(377454003)(107964003)(199003)(189002)(97736004)(50986999)(86612001)(2906002)(7846002)(2950100001)(8990500004)(101416001)(19300405004)(76176999)(2900100001)(54356999)(107886002)(68736007)(5001770100001)(99286002)(7736002)(3660700001)(11100500001)(5003600100003)(8676002)(586003)(5005710100001)(81156014)(81166006)(7696003)(74316002)(16236675004)(5002640100001)(19580405001)(19580395003)(87936001)(10290500002)(10400500002)(33656002)(76576001)(19625215002)(19609705001)(3280700002)(106356001)(102836003)(7906003)(10090500001)(105586002)(106116001)(77096005)(86362001)(92566002)(561944003)(122556002)(19617315012)(189998001)(9686002)(790700001)(6116002)(15975445007)(8936002)(3826002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1235; H:BN3PR0301MB1234.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_BN3PR0301MB1234260DD22E6B6F1DDA59CCA6390BN3PR0301MB1234_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jul 2016 22:47:00.3153 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1235 Archived-At: Subject: Re: [OAUTH-WG] RT treatment in Token Exchange X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 22:47:06 -0000 --_000_BN3PR0301MB1234260DD22E6B6F1DDA59CCA6390BN3PR0301MB1234_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U28gSSB0aGluayB0aGUgcHJvcG9zZWQgd29yZGluZyBpcyBzdGlsbCB0b28gc3BlY2lmaWMgYW5k IGxpbWl0cyB0aGUgdXNlIGNhc2UgLCBJIGFsc28gZG9u4oCZdCB1bmRlcnN0YW5kIHRoZSB1c2Fn ZSBvZiDigJxjcmVkZW50aWFs4oCdIGluIHlvdXIgZGVzY3JpcHRpb24gYXMgdGhpcyBkb2VzIG5v dCBoYXZlIHRvIGJlIGEgY3JlZGVudGlhbC4gU28gc3VnZ2VzdCB0aGF0IHRoaXMgYmUgc2ltcGxl IGFuZCBpZiB5b3Ugd2FudCB5b3UgY2FuIGV4cGxhaW4gaW4gdGhlIHNlY3VyaXR5IGNvbnNpZGVy YXRpb25zIHNlY3Rpb24gd2h5IG9uZSBtYXkgbm90IHdhbnQgdG8gcmV0dXJuIGEgcmVmcmVzaF90 b2tlbg0KDQpPUFRJT05BTC4gIFRoZSByZWZyZXNoX3Rva2VuIGZvciB0aGUgaXNzdWVkIHRva2Vu IGluIHRoZSB0b2tlbl9leGNoYW5nZSByZXF1ZXN0DQoNCmFjY2Vzc190b2tlbiAocmVzcG9uc2Up LCB0aGlzIGRvZXMgbm90IGhhdmUgdG8gYmUgYW4gYWNjZXNzX3Rva2VuIHNvIHRoaXMgaXMgYSBi YWQgbmFtZQ0KDQoNCkFsc28gaXTigJlzIHVuY2xlYXIgd2h5IHRoZSBzdWJqZWN0X3Rva2VuIGlz IHJlcXVpcmVkLCBpcyBpdCBiZWluZyBzdWdnZXN0ZWQgdGhhdCB0aGUgc3ViamVjdF90b2tlbiBp cyBhbHNvIGJlaW5nIHVzZWQgYXMgYW4gYWNjZXNzX3Rva2VuID8gVGhlIGFjdG9yX3Rva2VuIGlm IHNwZWNpZmllZCBjb3VsZCBhbHNvIGJlIHRoZSBzdWJqZWN0X3Rva2VuDQoNClRoZSB0ZXJtIOKA nHNlY3VyaXR5X3Rva2Vu4oCdIEkgYXNzdW1lIGlzIG5vdCBsaW1pdGVkIHRvIGFjY2Vzc190b2tl biBzaW5jZSB0aGVyZSBpcyBhIHN1YmplY3RfdG9rZW5fdHlwZS4NCg0Kd2FudF9jb21wb3NpdGUg aXMgbm90IHJlYWxseSB0aGUgZWZmZWN0IHdlIGFyZSBsb29raW5nIGZvciBzaW5jZSBpdCBwcm92 aWRlcyBmb3IgYSBzaW5nbGUgdG9rZW4sIHRoZSB1c2UgY2FzZSB3ZSBoYXZlIGlzIHdoZXJlIHlv dSB3YW50IHRoZSBhYmlsaXR5IHRvIHVzZSB0aGUgc3ViamVjdF90b2tlbiBhbmQgdGhlIGFjdG9y X3Rva2VuIGluIGNvbWJpbmF0aW9uIGFuZCBub3QgYXMgYSBjb21wb3NpdGUgb2Ygb25seSB0aGUg Y2xhaW1zLg0KDQpGcm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBCcmlhbiBDYW1wYmVsbA0KU2VudDogVHVlc2RheSwgSnVseSA1LCAyMDE2IDEx OjE2IEFNDQpUbzogb2F1dGggPG9hdXRoQGlldGYub3JnPg0KU3ViamVjdDogW09BVVRILVdHXSBS VCB0cmVhdG1lbnQgaW4gVG9rZW4gRXhjaGFuZ2UNCg0KSSBnYXZlIGEgc2hvcnQgcHJlc2VudGF0 aW9uIGFib3V0IE9BdXRoIDIuMCBUb2tlbiBFeGNoYW5nZTxodHRwczovL25hMDEuc2FmZWxpbmtz LnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNhJTJmJTJmd3d3LnNsaWRlc2hhcmUu bmV0JTJmYnJpYW5kYXZpZGNhbXBiZWxsJTJmb2F1dGgtMjAtdG9rZW4tZXhjaGFuZ2UtYW4tc3Rz LWZvci10aGUtcmVzdC1vZi11cyZkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNv bSU3YzM2ZGE5ZDQ5OWJlMzQ3NjI3NDBhMDhkM2E1MDA3ZTMxJTdjNzJmOTg4YmY4NmYxNDFhZjkx YWIyZDdjZDAxMWRiNDclN2MxJnNkYXRhPTVhNUNhN3BIRVNtZ3pxMzZCbUpEdFFIJTJmNTY0UVRi azFKUXpGTmZhc25KVSUzZD4gYXQgYSByZWNlbnQgaWRlbnRpdHkgY29uZmVyZW5jZSwgd2hpY2gg c2VlbWVkIHdlbGwgcmVjZWl2ZWQgYW5kIGEgbG90IG9mIGZvbGtzIGV4cHJlc3NlZCB0aGVpciBz dXBwb3J0IGZvciBpdCBhbmQgYSBkZXNpcmUgdG8gc2VlIHN1cHBvcnQgZm9yIGl0IGluIG9mZmVy aW5ncyBvdXQgaW4gdGhlIHdpbGQuDQpIb3dldmVyLCBJIGRpZCBnZXQgc29tZSBmZWVkYmFjayBm cm9tIFZpdHRvcmlvIEJlcnRvY2NpIG9mIE1pY3Jvc29mdCB0aGF0IGhlIGZlbHQgdGhhdCB0aGUg bGFuZ3VhZ2UgYXJvdW5kIGlzc3VpbmcgcmVmcmVzaCB0b2tlbnMgd2FzIG92ZXJseSByZXN0cmlj dGl2ZSBiYXNlZCBvbiByZWFsIHdvcmxkIGRlcGxveW1lbnQgZXhwZXJpZW5jZSB0aGV5IGhhdmUg d2l0aCBhIHRva2VuIGV4Y2hhbmdlIGxpa2UgaW50ZXJhY3Rpb24gdGhhdCB0aGV5IGFyZSBjdXJy ZW50bHkgb2ZmZXJpbmcuIEhlIGRlc2NyaWJlZCBpdCBhcyBmb2xsb3dzOg0KIlRvIHN1bW1hcml6 ZSBvdXIgbWFpbiB1c2UgY2FzZTogd2UgdXNlIFthIHRva2VuIGV4Y2hhbmdlIGxpa2UgcHJvdG9j b2xdIGZvciBhY2hpZXZpbmcgdXNlciBpbXBlcnNvbmF0aW9uIHRocnUgdGllcnMsIG9yIGRlbGVn YXRpb24gZm9yIGNvbmZpZGVudGlhbCBjbGllbnRzIHdoaWNoIGRvIG5vdCBoYXZlIGFueSB3ZWIg VVguDQoNClRob3NlIGNhc2VzIGRvIGNhbGwgZm9yIHRoZSBhYmlsaXR5IG9mIHRoZSBtaWRkbGUg dGllciB0byBhY2Nlc3MgdGhlIHJlc291cmNlIGFsc28gd2hlbiB0aGUgb3JpZ2luYWwgY3JlZGVu dGlhbCBpcyBubyBsb25nZXIgdmFsaWQgKGUuZy4gdGhlcmUgaXMgbm8gbG9uZ2VyIGFueSB1c2Vy IGVudGVydGFpbmluZyBhbiBhY3RpdmUgc2Vzc2lvbiB3aXRoIHRoZSBtaWRkbGUgdGllcikuDQoN ClRoaW5rIG9mIGEgaHlwb3RoZXRpY2FsIG5ldyBmZWF0dXJlIG9mIHRoZSBVYmVyIG1vYmlsZSBh cHAsIHdoaWNoIGNhbiBtb25pdG9yIHlvdXIgRXhjaGFuZ2UgY2FsZW5kYXIgYW5kIGJvb2sgYSBy aWRlIHdoZW5ldmVyIGEgc3VpdGFibGUgc2xvdCBvcGVucyB1cCB3aXRoaW4gYSBjZXJ0YWluIHRp bWUgcmFuZ2UuIFRoZSBVYmVyIGFwcCB3b3VsZCBjYWxsIGFuIFViZXItb3duZWQgbWlkZGxlIHRp ZXIsIGluIGZvcm0gb2YgV2ViIEFQSSwgYW5kIHRoZSBXZWIgQVBJIHdvdWxkIGl0c2VsZiBiZSBh IGNsaWVudCBvZiB0aGUgRXhjaGFuZ2UgQVBJLiBHaXZlbiB0aGF0IHRoZSBVYmVyIEFQSSBkb2Vz buKAmXQgb2ZmZXIgYW55IGJyb3dzZXIgcmVhZHkgc3VyZmFjZSwgYXMgaXQgaXMgbWVhbnQgdG8g YmUgYWNjZXNzZWQgb25seSB2aWEgb2F1dGgyIGJlYXJlciB0b2tlbiwgdGhlIFt0b2tlbiBleGNo YW5nZV0gaXMgdGhlIG9ubHkgd2F5IHRocm91Z2ggd2hpY2ggaXQgY2FuIG9idGFpbiBhIHRva2Vu IGZvciB0aGUgRXhjaGFuZ2UgQVBJOyBhbmQgdGhlIHNjZW5hcmlvIGRlZmluaXRlbHkgY2FsbCBm b3Igb2ZmbGluZSBhY2Nlc3MsIGFzIHRoZSB1YmVyIEFQSSBzaG91bGQgYmUgYWJsZSB0byBtb25p dG9yIHRoZSBFeGNoYW5nZSBjYWxlbmRhciBvZiB0aGUgdXNlciBldmVuIGlmIHRoZSB1c2VyIGNs b3NlZCB0aGUgYXBwIG9uIGhpcy9oZXIgcGhvbmUuIg0KDQpXaGlsZSB0aGUgY3VycmVudCB0ZXh0 IGluIHRoZSBkcmFmdCBhbGxvd3MgZm9yIHRoaXMga2luZCBvZiB0aGluZywgaXQgc3RpZ21hdGl6 ZXMgaXQgc29tZXdoYXQgd2l0aCBhICJOT1QgUkVDT01NRU5ERUQiIG9uIHNlbmRpbmcgYW4gUlQg aW4gdGhlIHJlc3BvbnNlLiBTbyB0aGUgcHJvcG9zYWwgaGVyZSBpcyB0byBtYWtlIHJlZnJlc2gg dG9rZW5zIE9QVElPTkFMIGFuZCBjaGFuZ2UgdGhlIGFjY29tcGFueWluZyB0ZXh0IGluIHNlYyAy LjIuMSB0byB0aGUgZm9sbG93aW5nOg0KDQogICByZWZyZXNoX3Rva2VuDQogICAgICBPUFRJT05B TC4gIEEgcmVmcmVzaCB0b2tlbiB3aWxsIHR5cGljYWxseSBub3QgYmUgaXNzdWVkIHdoZW4gdGhl DQogICAgICB0aGUgZXhjaGFuZ2UgaXMgb2Ygb25lIHRlbXBvcmFyeSBjcmVkZW50aWFsICh0aGUg c3ViamVjdF90b2tlbikNCiAgICAgIGZvciBhIGRpZmZlcmVudCB0ZW1wb3JhcnkgY3JlZGVudGlh bCAodGhlIGlzc3VlZCB0b2tlbikgZm9yIHVzZSBpbg0KICAgICAgc29tZSBvdGhlciBjb250ZXh0 LiAgQSByZWZyZXNoIHRva2VuIGNhbiBiZSBpc3N1ZWQgaW4gY2FzZXMgd2hlcmUNCiAgICAgIHRo ZSBjbGllbnQgb2YgdGhlIHRva2VuIGV4Y2hhbmdlIG5lZWRzIHRoZSBhYmlsaXR5IHRvIGFjY2Vz cyBhDQogICAgICByZXNvdXJjZSBldmVuIHdoZW4gdGhlIG9yaWdpbmFsIGNyZWRlbnRpYWwgaXMg bm8gbG9uZ2VyIHZhbGlkDQogICAgICAoZS5nLiB1c2VyLW5vdC1wcmVzZW50IG9yIG9mZmxpbmUg c2NlbmFyaW9zIHdoZXJlIHRoZXJlIGlzIG5vDQogICAgICBsb25nZXIgYW55IHVzZXIgZW50ZXJ0 YWluaW5nIGFuIGFjdGl2ZSBzZXNzaW9uIHdpdGggdGhlIGNsaWVudCkuDQogICAgICBQcm9maWxl cyBvciBkZXBsb3ltZW50cyBvZiB0aGlzIHNwZWNpZmljYXRpb24gc2hvdWxkIGNsZWFybHkNCiAg ICAgIGRvY3VtZW50IHRoZSBjb25kaXRpb25zIHVuZGVyIHdoaWNoIGEgY2xpZW50IHNob3VsZCBl eHBlY3QgYQ0KICAgICAgcmVmcmVzaCB0b2tlbiBpbiByZXNwb25zZSB0byAidXJuOmlldGY6cGFy YW1zOm9hdXRoOmdyYW50LQ0KICAgICAgdHlwZTp0b2tlbi1leGNoYW5nZSIgZ3JhbnQgdHlwZSBy ZXF1ZXN0cy4NCkkgcGxhbiB0byBtYWtlIHRoZSBhZm9yZW1lbnRpb25lZCBjaGFuZ2UgYW5kIGdl dCBhIG5ldyBkcmFmdCBwdWJsaXNoZWQgd2l0aCB0aGF0IGFuZCBzb21lIG90aGVyIHVwZGF0ZXMg bGF0ZXIgdGhpcyB3ZWVrIGJlZm9yZSB0aGUgSW50ZXJuZXQgRHJhZnQgc3VibWlzc2lvbiBjdXQt b2ZmIG9uIEZyaWRheS4NCg0KDQoNCg== --_000_BN3PR0301MB1234260DD22E6B6F1DDA59CCA6390BN3PR0301MB1234_ 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 CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlNvIEkgdGhpbmsgdGhlIHByb3Bvc2VkIHdvcmRpbmcgaXMg c3RpbGwgdG9vIHNwZWNpZmljIGFuZCBsaW1pdHMgdGhlIHVzZSBjYXNlICwgSSBhbHNvIGRvbuKA mXQgdW5kZXJzdGFuZCB0aGUgdXNhZ2Ugb2Yg4oCcY3JlZGVudGlhbOKAnSBpbiB5b3VyIGRlc2Ny aXB0aW9uIGFzIHRoaXMgZG9lcyBub3QgaGF2ZQ0KIHRvIGJlIGEgY3JlZGVudGlhbC4gU28gc3Vn Z2VzdCB0aGF0IHRoaXMgYmUgc2ltcGxlIGFuZCBpZiB5b3Ugd2FudCB5b3UgY2FuIGV4cGxhaW4g aW4gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gd2h5IG9uZSBtYXkgbm90IHdh bnQgdG8gcmV0dXJuIGEgcmVmcmVzaF90b2tlbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T1BUSU9OQUwuJm5ic3A7IFRoZSByZWZyZXNoX3Rva2VuIGZvciB0aGUgaXNzdWVkIHRva2Vu IGluIHRoZSB0b2tlbl9leGNoYW5nZSByZXF1ZXN0PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hY2Nlc3NfdG9r ZW4gKHJlc3BvbnNlKSwgdGhpcyBkb2VzIG5vdCBoYXZlIHRvIGJlIGFuIGFjY2Vzc190b2tlbiBz byB0aGlzIGlzIGEgYmFkIG5hbWU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbHNvIGl04oCZcyB1bmNsZWFyIHdoeSB0 aGUgc3ViamVjdF90b2tlbiBpcyByZXF1aXJlZCwgaXMgaXQgYmVpbmcgc3VnZ2VzdGVkIHRoYXQg dGhlIHN1YmplY3RfdG9rZW4gaXMgYWxzbyBiZWluZyB1c2VkIGFzIGFuIGFjY2Vzc190b2tlbiA/ IFRoZSBhY3Rvcl90b2tlbiBpZiBzcGVjaWZpZWQgY291bGQgYWxzbyBiZSB0aGUgc3ViamVjdF90 b2tlbg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSB0ZXJtIOKAnHNlY3VyaXR5X3Rva2Vu 4oCdIEkgYXNzdW1lIGlzIG5vdCBsaW1pdGVkIHRvIGFjY2Vzc190b2tlbiBzaW5jZSB0aGVyZSBp cyBhIHN1YmplY3RfdG9rZW5fdHlwZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+d2FudF9jb21w b3NpdGUgaXMgbm90IHJlYWxseSB0aGUgZWZmZWN0IHdlIGFyZSBsb29raW5nIGZvciBzaW5jZSBp dCBwcm92aWRlcyBmb3IgYSBzaW5nbGUgdG9rZW4sIHRoZSB1c2UgY2FzZSB3ZSBoYXZlIGlzIHdo ZXJlIHlvdSB3YW50IHRoZSBhYmlsaXR5IHRvIHVzZSB0aGUgc3ViamVjdF90b2tlbiBhbmQgdGhl IGFjdG9yX3Rva2VuIGluIGNvbWJpbmF0aW9uIGFuZCBub3QgYXMgYSBjb21wb3NpdGUgb2Ygb25s eQ0KIHRoZSBjbGFpbXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBu YW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9hPjwvcD4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3Nl Ij48L3NwYW4+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNA aWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkJyaWFuIENhbXBiZWxsPGJyPg0KPGI+U2Vu dDo8L2I+IFR1ZXNkYXksIEp1bHkgNSwgMjAxNiAxMToxNiBBTTxicj4NCjxiPlRvOjwvYj4gb2F1 dGggJmx0O29hdXRoQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBbT0FVVEgtV0dd IFJUIHRyZWF0bWVudCBpbiBUb2tlbiBFeGNoYW5nZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5J IGdhdmUgYSA8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9v ay5jb20vP3VybD1odHRwJTNhJTJmJTJmd3d3LnNsaWRlc2hhcmUubmV0JTJmYnJpYW5kYXZpZGNh bXBiZWxsJTJmb2F1dGgtMjAtdG9rZW4tZXhjaGFuZ2UtYW4tc3RzLWZvci10aGUtcmVzdC1vZi11 cyZhbXA7ZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2MzNmRhOWQ0OTli ZTM0NzYyNzQwYTA4ZDNhNTAwN2UzMSU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3 JTdjMSZhbXA7c2RhdGE9NWE1Q2E3cEhFU21nenEzNkJtSkR0UUglMmY1NjRRVGJrMUpRekZOZmFz bkpVJTNkIiB0YXJnZXQ9Il9ibGFuayI+DQpzaG9ydCBwcmVzZW50YXRpb24gYWJvdXQgT0F1dGgg Mi4wIFRva2VuIEV4Y2hhbmdlPC9hPiBhdCBhIHJlY2VudCBpZGVudGl0eSBjb25mZXJlbmNlLCB3 aGljaCBzZWVtZWQgd2VsbCByZWNlaXZlZCBhbmQgYSBsb3Qgb2YgZm9sa3MgZXhwcmVzc2VkIHRo ZWlyIHN1cHBvcnQgZm9yIGl0IGFuZCBhIGRlc2lyZSB0byBzZWUgc3VwcG9ydCBmb3IgaXQgaW4g b2ZmZXJpbmdzIG91dCBpbiB0aGUgd2lsZC4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkhvd2V2ZXIsIEkg ZGlkIGdldCBzb21lIGZlZWRiYWNrIGZyb20gVml0dG9yaW8gQmVydG9jY2kgb2YgTWljcm9zb2Z0 IHRoYXQgaGUgZmVsdCB0aGF0IHRoZSBsYW5ndWFnZSBhcm91bmQgaXNzdWluZyByZWZyZXNoIHRv a2VucyB3YXMgb3Zlcmx5IHJlc3RyaWN0aXZlIGJhc2VkIG9uIHJlYWwgd29ybGQgZGVwbG95bWVu dCBleHBlcmllbmNlIHRoZXkgaGF2ZSB3aXRoDQogYSB0b2tlbiBleGNoYW5nZSBsaWtlIGludGVy YWN0aW9uIHRoYXQgdGhleSBhcmUgY3VycmVudGx5IG9mZmVyaW5nLiBIZSBkZXNjcmliZWQgaXQg YXMgZm9sbG93czo8bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjMwLjBw dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mcXVvdDtUbyBzdW1tYXJpemUgb3VyIG1haW4gdXNl IGNhc2U6IHdlIHVzZSBbYSB0b2tlbiBleGNoYW5nZSBsaWtlIHByb3RvY29sXSBmb3IgYWNoaWV2 aW5nIHVzZXIgaW1wZXJzb25hdGlvbiB0aHJ1IHRpZXJzLCBvciBkZWxlZ2F0aW9uIGZvciBjb25m aWRlbnRpYWwgY2xpZW50cyB3aGljaCBkbyBub3QgaGF2ZSBhbnkgd2ViIFVYLjxicj4NCjxicj4N ClRob3NlIGNhc2VzIGRvIGNhbGwgZm9yIHRoZSBhYmlsaXR5IG9mIHRoZSBtaWRkbGUgdGllciB0 byBhY2Nlc3MgdGhlIHJlc291cmNlIGFsc28gd2hlbiB0aGUgb3JpZ2luYWwgY3JlZGVudGlhbCBp cyBubyBsb25nZXIgdmFsaWQgKGUuZy4gdGhlcmUgaXMgbm8gbG9uZ2VyIGFueSB1c2VyIGVudGVy dGFpbmluZyBhbiBhY3RpdmUgc2Vzc2lvbiB3aXRoIHRoZSBtaWRkbGUgdGllcikuPGJyPg0KPGJy Pg0KVGhpbmsgb2YgYSBoeXBvdGhldGljYWwgbmV3IGZlYXR1cmUgb2YgdGhlIFViZXIgbW9iaWxl IGFwcCwgd2hpY2ggY2FuIG1vbml0b3IgeW91ciBFeGNoYW5nZSBjYWxlbmRhciBhbmQgYm9vayBh IHJpZGUgd2hlbmV2ZXIgYSBzdWl0YWJsZSBzbG90IG9wZW5zIHVwIHdpdGhpbiBhIGNlcnRhaW4g dGltZSByYW5nZS4gVGhlIFViZXIgYXBwIHdvdWxkIGNhbGwgYW4gVWJlci1vd25lZCBtaWRkbGUg dGllciwgaW4gZm9ybSBvZiBXZWIgQVBJLCBhbmQgdGhlDQogV2ViIEFQSSB3b3VsZCBpdHNlbGYg YmUgYSBjbGllbnQgb2YgdGhlIEV4Y2hhbmdlIEFQSS4gR2l2ZW4gdGhhdCB0aGUgVWJlciBBUEkg ZG9lc27igJl0IG9mZmVyIGFueSBicm93c2VyIHJlYWR5IHN1cmZhY2UsIGFzIGl0IGlzIG1lYW50 IHRvIGJlIGFjY2Vzc2VkIG9ubHkgdmlhIG9hdXRoMiBiZWFyZXIgdG9rZW4sIHRoZSBbdG9rZW4g ZXhjaGFuZ2VdIGlzIHRoZSBvbmx5IHdheSB0aHJvdWdoIHdoaWNoIGl0IGNhbiBvYnRhaW4gYSB0 b2tlbiBmb3INCiB0aGUgRXhjaGFuZ2UgQVBJOyBhbmQgdGhlIHNjZW5hcmlvIGRlZmluaXRlbHkg Y2FsbCBmb3Igb2ZmbGluZSBhY2Nlc3MsIGFzIHRoZSB1YmVyIEFQSSBzaG91bGQgYmUgYWJsZSB0 byBtb25pdG9yIHRoZSBFeGNoYW5nZSBjYWxlbmRhciBvZiB0aGUgdXNlciBldmVuIGlmIHRoZSB1 c2VyIGNsb3NlZCB0aGUgYXBwIG9uIGhpcy9oZXIgcGhvbmUuJnF1b3Q7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGlsZSB0aGUgY3VycmVudCB0ZXh0IGluIHRoZSBk cmFmdCBhbGxvd3MgZm9yIHRoaXMga2luZCBvZiB0aGluZywgaXQgc3RpZ21hdGl6ZXMgaXQgc29t ZXdoYXQgd2l0aCBhICZxdW90O05PVCBSRUNPTU1FTkRFRCZxdW90OyBvbiBzZW5kaW5nIGFuIFJU IGluIHRoZSByZXNwb25zZS4gU28gdGhlIHByb3Bvc2FsIGhlcmUgaXMgdG8gbWFrZSByZWZyZXNo IHRva2VucyBPUFRJT05BTCBhbmQgY2hhbmdlIHRoZSBhY2NvbXBhbnlpbmcNCiB0ZXh0IGluIHNl YyAyLjIuMSB0byB0aGUgZm9sbG93aW5nOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCiZu YnNwOyZuYnNwOyByZWZyZXNoX3Rva2VuPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IE9QVElPTkFMLiZuYnNwOyBBIHJlZnJlc2ggdG9rZW4gd2lsbCB0eXBpY2FsbHkgbm90IGJl IGlzc3VlZCB3aGVuIHRoZTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGUg ZXhjaGFuZ2UgaXMgb2Ygb25lIHRlbXBvcmFyeSBjcmVkZW50aWFsICh0aGUgc3ViamVjdF90b2tl bik8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZm9yIGEgZGlmZmVyZW50IHRl bXBvcmFyeSBjcmVkZW50aWFsICh0aGUgaXNzdWVkIHRva2VuKSBmb3IgdXNlIGluPGJyPg0KJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNvbWUgb3RoZXIgY29udGV4dC4mbmJzcDsgQSBy ZWZyZXNoIHRva2VuIGNhbiBiZSBpc3N1ZWQgaW4gY2FzZXMgd2hlcmU8YnI+DQombmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhlIGNsaWVudCBvZiB0aGUgdG9rZW4gZXhjaGFuZ2UgbmVl ZHMgdGhlIGFiaWxpdHkgdG8gYWNjZXNzIGE8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgcmVzb3VyY2UgZXZlbiB3aGVuIHRoZSBvcmlnaW5hbCBjcmVkZW50aWFsIGlzIG5vIGxv bmdlciB2YWxpZDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAoZS5nLiB1c2Vy LW5vdC1wcmVzZW50IG9yIG9mZmxpbmUgc2NlbmFyaW9zIHdoZXJlIHRoZXJlIGlzIG5vPGJyPg0K Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGxvbmdlciBhbnkgdXNlciBlbnRlcnRhaW5p bmcgYW4gYWN0aXZlIHNlc3Npb24gd2l0aCB0aGUgY2xpZW50KS48YnI+DQombmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgUHJvZmlsZXMgb3IgZGVwbG95bWVudHMgb2YgdGhpcyBzcGVjaWZp Y2F0aW9uIHNob3VsZCBjbGVhcmx5PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGRvY3VtZW50IHRoZSBjb25kaXRpb25zIHVuZGVyIHdoaWNoIGEgY2xpZW50IHNob3VsZCBleHBl Y3QgYTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyByZWZyZXNoIHRva2VuIGlu IHJlc3BvbnNlIHRvICZxdW90O3VybjppZXRmOnBhcmFtczpvYXV0aDpncmFudC08YnI+DQombmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdHlwZTp0b2tlbi1leGNoYW5nZSZxdW90OyBncmFu dCB0eXBlIHJlcXVlc3RzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5JIHBsYW4gdG8gbWFrZSB0 aGUgYWZvcmVtZW50aW9uZWQgY2hhbmdlIGFuZCBnZXQgYSBuZXcgZHJhZnQgcHVibGlzaGVkIHdp dGggdGhhdCBhbmQgc29tZSBvdGhlciB1cGRhdGVzIGxhdGVyIHRoaXMgd2VlayBiZWZvcmUgdGhl IEludGVybmV0IERyYWZ0IHN1Ym1pc3Npb24gY3V0LW9mZiBvbiBGcmlkYXkuPGJyPg0KJm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BN3PR0301MB1234260DD22E6B6F1DDA59CCA6390BN3PR0301MB1234_-- From nobody Tue Jul 5 16:54:08 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7FEB12B02F for ; Tue, 5 Jul 2016 16:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, 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 x86ruk777Jio for ; Tue, 5 Jul 2016 16:54:04 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDFF812B00D for ; Tue, 5 Jul 2016 16:54:04 -0700 (PDT) X-AuditID: 1209190f-12bff700000055f5-35-577c489b04a1 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 61.4B.22005.B984C775; Tue, 5 Jul 2016 19:54:03 -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 u65Ns2LZ005294; Tue, 5 Jul 2016 19:54:03 -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 u65Ns101015600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 5 Jul 2016 19:54:02 -0400 To: Brian Campbell , oauth References: From: Justin Richer Message-ID: <84134533-68dd-cdcc-47f3-d07adecfa269@mit.edu> Date: Tue, 5 Jul 2016 19:53:56 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------019CAFA061D84C94DC05E5A4" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJIsWRmVeSWpSXmKPExsUixG6nojvboybcoOmFpsXq/zcZLU6+fcXm wOSxZMlPJo+7Ry+yBDBFcdmkpOZklqUW6dslcGUcO9jDWPDDq+L0jJ/MDYwvTbsYOTkkBEwk Jk/5z9zFyMUhJNDGJNH/fTcbhLOBUeLb3C4WCOcWk8Ttv3tYQFqEBcwkpjUsZgOxRQTcJW4c msYOYgsJBEh0r33GCGKzCahKTF/TwgRi8wpYSVz9dxvMZhFQkXjWvBHMFhWIkWi8fZgdokZQ 4uTMJ2DzOQUCJa797ASLMwuESbz884hpAiPfLCRls5CkIGxbiTtzdzND2PISzVtnQ9m6Eou2 rWBHFl/AyLaKUTYlt0o3NzEzpzg1Wbc4OTEvL7VI10QvN7NELzWldBMjKIQ5Jfl3MM5p8D7E KMDBqMTDO+F5dbgQa2JZcWXuIUZJDiYlUV6Wb0AhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIrwf nWrChXhTEiurUovyYVLSHCxK4ryMDAwMQgLpiSWp2ampBalFMFkZDg4lCV5+d6BGwaLU9NSK tMycEoQ0EwcnyHAeoOExIDW8xQWJucWZ6RD5U4yKUuK8XCAJAZBERmkeXC8oxSS8PWz6ilEc 6BVhXg+QKh5geoLrfgU0mAlo8E+XapDBJYkIKakGxur+1PbsgqhJh0ouLs095u5ZXpTwS/TO 7PQdh8L/JLyZcL5n8+OAm8c6rz/iDthu+uq99IY1/evm1G4/y6ObGHgxZvv2hr5NubeqL81f +cR6v+7XOdPuVSpwcYu3Rj07fs+kXJfpcaDJzAlB0z8k3Nvf36jrz+myRMSgdfl6fvXHMVqv bi4OeqnEUpyRaKjFXFScCAARcwcsDAMAAA== Archived-At: Subject: Re: [OAUTH-WG] RT treatment in Token Exchange X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 23:54:07 -0000 This is a multi-part message in MIME format. --------------019CAFA061D84C94DC05E5A4 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit +1 to the proposed wording change. It's clear and allows for use cases where your inputs aren't as replayable as you might otherwise expect. -- Justin On 7/5/2016 2:15 PM, Brian Campbell wrote: > I gave a short presentation about OAuth 2.0 Token Exchange > > at a recent identity conference, which seemed well received and a lot > of folks expressed their support for it and a desire to see support > for it in offerings out in the wild. > > However, I did get some feedback from Vittorio Bertocci of Microsoft > that he felt that the language around issuing refresh tokens was > overly restrictive based on real world deployment experience they have > with a token exchange like interaction that they are currently > offering. He described it as follows: > > "To summarize our main use case: we use [a token exchange like > protocol] for achieving user impersonation thru tiers, or delegation > for confidential clients which do not have any web UX. > > Those cases do call for the ability of the middle tier to access the > resource also when the original credential is no longer valid (e.g. > there is no longer any user entertaining an active session with the > middle tier). > > Think of a hypothetical new feature of the Uber mobile app, which can > monitor your Exchange calendar and book a ride whenever a suitable > slot opens up within a certain time range. The Uber app would call an > Uber-owned middle tier, in form of Web API, and the Web API would > itself be a client of the Exchange API. Given that the Uber API > doesn’t offer any browser ready surface, as it is meant to be accessed > only via oauth2 bearer token, the [token exchange] is the only way > through which it can obtain a token for the Exchange API; and the > scenario definitely call for offline access, as the uber API should be > able to monitor the Exchange calendar of the user even if the user > closed the app on his/her phone." > > While the current text in the draft allows for this kind of thing, it > stigmatizes it somewhat with a "NOT RECOMMENDED" on sending an RT in > the response. So the proposal here is to make refresh tokens OPTIONAL > and change the accompanying text in sec 2.2.1 to the following: > > refresh_token > OPTIONAL. A refresh token will typically not be issued when the > the exchange is of one temporary credential (the subject_token) > for a different temporary credential (the issued token) for use in > some other context. A refresh token can be issued in cases where > the client of the token exchange needs the ability to access a > resource even when the original credential is no longer valid > (e.g. user-not-present or offline scenarios where there is no > longer any user entertaining an active session with the client). > Profiles or deployments of this specification should clearly > document the conditions under which a client should expect a > refresh token in response to "urn:ietf:params:oauth:grant- > type:token-exchange" grant type requests. > > I plan to make the aforementioned change and get a new draft published > with that and some other updates later this week before the Internet > Draft submission cut-off on Friday. > > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------019CAFA061D84C94DC05E5A4 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

+1 to the proposed wording change. It's clear and allows for use cases where your inputs aren't as replayable as you might otherwise expect.

 -- Justin


On 7/5/2016 2:15 PM, Brian Campbell wrote:
I gave a short presentation about OAuth 2.0 Token Exchange at a recent identity conference, which seemed well received and a lot of folks expressed their support for it and a desire to see support for it in offerings out in the wild.

However, I did get some feedback from Vittorio Bertocci of Microsoft that he felt that the language around issuing refresh tokens was overly restrictive based on real world deployment experience they have with a token exchange like interaction that they are currently offering. He described it as follows:

"To summarize our main use case: we use [a token exchange like protocol] for achieving user impersonation thru tiers, or delegation for confidential clients which do not have any web UX.

Those cases do call for the ability of the middle tier to access the resource also when the original credential is no longer valid (e.g. there is no longer any user entertaining an active session with the middle tier).

Think of a hypothetical new feature of the Uber mobile app, which can monitor your Exchange calendar and book a ride whenever a suitable slot opens up within a certain time range. The Uber app would call an Uber-owned middle tier, in form of Web API, and the Web API would itself be a client of the Exchange API. Given that the Uber API doesn’t offer any browser ready surface, as it is meant to be accessed only via oauth2 bearer token, the [token exchange] is the only way through which it can obtain a token for the Exchange API; and the scenario definitely call for offline access, as the uber API should be able to monitor the Exchange calendar of the user even if the user closed the app on his/her phone."

While the current text in the draft allows for this kind of thing, it stigmatizes it somewhat with a "NOT RECOMMENDED" on sending an RT in the response. So the proposal here is to make refresh tokens OPTIONAL and change the accompanying text in sec 2.2.1 to the following:

   refresh_token
      OPTIONAL.  A refresh token will typically not be issued when the
      the exchange is of one temporary credential (the subject_token)
      for a different temporary credential (the issued token) for use in
      some other context.  A refresh token can be issued in cases where
      the client of the token exchange needs the ability to access a
      resource even when the original credential is no longer valid
      (e.g. user-not-present or offline scenarios where there is no
      longer any user entertaining an active session with the client).
      Profiles or deployments of this specification should clearly
      document the conditions under which a client should expect a
      refresh token in response to "urn:ietf:params:oauth:grant-
      type:token-exchange" grant type requests.

I plan to make the aforementioned change and get a new draft published with that and some other updates later this week before the Internet Draft submission cut-off on Friday.
 





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

--------------019CAFA061D84C94DC05E5A4-- From nobody Wed Jul 6 07:55:10 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 634DE12D7DD for ; Fri, 1 Jul 2016 13:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.697 X-Spam-Level: X-Spam-Status: No, score=-2.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, 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=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id djHmAQ9eJ8my for ; Fri, 1 Jul 2016 13:35:24 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d: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 1787B12D7BA for ; Fri, 1 Jul 2016 13:35:24 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id j2so167176156qkf.3 for ; Fri, 01 Jul 2016 13:35:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3/CXDNpbF/fD84qF7jkp2s5HvEfEjO2FGGnE0+AULTA=; b=eGZa9TKsih9JdHZAIT/7QKKPfqA+cAQ8kiCBGdf9i3SWupF4e9LJLWvd0RF3BO9oFD +Pt+r9BZgzJw6EInD+WIlKRsqIyUudXD6AJCqz9+Gq/Jbat6oW/b8PB0qQNodwJdg4u3 A2a7MDtT5/YOmDL4xaBSeK0QJtAu2oHowQqvmnzbN04iQ6fyVy79Wzox94igPx4MhhWz iYIhjXrCpFhVe+XRZqEldpByzzj5hA68bwh2xKDCTJTidmE446kLeY0x7a262HJpf0ND eH1LxMkBRBVoObay5e+LYmcSjcBuMMaSZkgV3lzeS8qyZ6zRjdqyezkeZ9CcYQwn90u2 Nqag== 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=3/CXDNpbF/fD84qF7jkp2s5HvEfEjO2FGGnE0+AULTA=; b=nK0y1wpLlKCKrs/X9JQHyeSvD9/OyHvzxN/hjuHFdS/TIgAXi6HtPvEvTHUQDz7kvC SPkL8AaKMWz3lfJZwJmffcchIX+9KX6FTL6bDVGXicsHdE+KwhC9e5HesjaKgs/KK6cC 9EQEfDyBxs9TjSJ/DJlQ+S7YsEajUnqDszfpb9z00JDRWTqdaeLSLhfLpof5ulAb5v09 KpxavWTy+zcSyojQePCGPdsggJrZr46xUq7sVA8TSeY8/szEmNq7hq96n9spv5n0pSIV 9HPYOj6bAZOIrAaifnAfX9vwA3MA+BTk6sY//EXOKWLf++CcOpw5DPgCCA1F8sFk5U0i x4ew== X-Gm-Message-State: ALyK8tJA8ZfvXbDfgmuQiXv14LIymSnJ3ZWd9Sy1x7R6GQUNK41uJ6bp9kPhU3iy2Assewhp1YLqUa88uNgvYQ== X-Received: by 10.37.112.4 with SMTP id l4mr118832ybc.56.1467405323100; Fri, 01 Jul 2016 13:35:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.80.13 with HTTP; Fri, 1 Jul 2016 13:35:22 -0700 (PDT) In-Reply-To: <6584BD74-B18F-4174-9E69-5C7B4B76F895@ve7jtb.com> References: <994121658.55005.1467329084208.JavaMail.yahoo@mail.yahoo.com> <235316006.458279.1467392709447.JavaMail.yahoo@mail.yahoo.com> <6584BD74-B18F-4174-9E69-5C7B4B76F895@ve7jtb.com> From: Liyu Yi Date: Fri, 1 Jul 2016 13:35:22 -0700 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=001a114bb016066610053698ed55 Archived-At: X-Mailman-Approved-At: Wed, 06 Jul 2016 07:55:07 -0700 Cc: Oleg Gryb , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 20:35:27 -0000 --001a114bb016066610053698ed55 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for the great comments and advices. I think it is a good idea for the working group to revise the fragment part in the spec, since there might be public available tools already implemented this approach and people can end up with a solution with serious security loopholes. The re-append issue can be mitigate by a logic on Resource Server which carefully re-writes/removes the fragment in any redirect, if the the redirect can not be avoided. -- Liyu On Fri, Jul 1, 2016 at 11:33 AM, John Bradley wrote: > This behaviour started changing around 2011 > > From HTTP/1.1 > See https://tools.ietf.org/html/rfc7231#section-7.1.2I > f the Location value provided in a 3xx (Redirection) response does > > not have a fragment component, a user agent MUST process the > redirection as if the value inherits the fragment component of the > URI reference used to generate the request target (i.e., the > redirection inherits the original reference's fragment, if any). > > For example, a GET request generated for the URI reference > "http://www.example.org/~tim" might result in a 303 (See Other) > response containing the header field: > > Location: /People.html#tim > > which suggests that the user agent redirect to > "http://www.example.org/People.html#tim=E2=80=9D > > > Likewise, a GET request generated for the URI reference > "http://www.example.org/index.html#larry" might result in a 301 > (Moved Permanently) response containing the header field: > > Location: http://www.example.net/index.html > > which suggests that the user agent redirect to > "http://www.example.net/index.html#larry", preserving the original > fragment identifier. > > > > This blog also explores the change. > > https://blogs.msdn.microsoft.com/ieinternals/2011/05/16/url-fragments-and= -redirects/ > > > On Jul 1, 2016, at 1:05 PM, Oleg Gryb wrote: > > "Browsers now re-append fragments across 302 redirects unless they are > explicitly cleared this makes fragment encoding less safe than it was wh= en > originally specified" - thanks Jim. Looks like a good reason for vetting > this flow out. > > John, > Please provide more details/links about re-appending fragments. > > Thanks, > Oleg. > > > ------------------------------ > *From:* Jim Manico > *To:* Oleg Gryb > *Cc:* "oauth@ietf.org" ; Liyu Yi > *Sent:* Thursday, June 30, 2016 10:25 PM > *Subject:* Re: [OAUTH-WG] Security concern for URI fragment as Implicit > grant > > Oleg! Hello! Great to see you pop up here with a similar concern. > > John Bradley just answered this thread with the details I was looking for > (thanks John, hat tip your way). > > He also mentioned details about fragment leakage: > > "Browsers now re-append fragments across 302 redirects unless they are > explicitly cleared this makes fragment encoding less safe than it was whe= n > originally specified" > > Again, I'm new here but I'm grateful for this conversation. > > Aloha, > -- > Jim Manico > @Manicode > > On Jul 1, 2016, at 1:24 AM, Oleg Gryb wrote: > > We've discussed access tokens in URI back in 2010 ( > https://www.ietf.org/mail-archive/web/oauth/current/msg04043.html). There > were two major objectives when I was saying that it's not secure: > > 1. Fragment is not sent to a server by a browser. When I've asked if this > is true for every browser in the world, nobody was able to answer. > 2. Replacing with POST would mean a significant performance impact in som= e > high volume implementations (I think it was Goole folks who were saying > this, but I don't remember now). > > AFAIR, nobody was arguing about browsing history, so it's valid. > > So, 6 years later we're at square one with this and I hope that this time > the community will be more successful with getting rid of secrets in URL. > > BTW, Jim, if you can come up with other scenarios when fragments can leak= , > please share. It'll probably help the community with solving this problem > faster than in 6 years. > > Thanks, > Oleg. > > > ------------------------------ > *From:* Jim Manico > *To:* Liyu Yi ; oauth@ietf.org > *Sent:* Wednesday, June 29, 2016 7:30 AM > *Subject:* Re: [OAUTH-WG] Security concern for URI fragment as Implicit > grant > > > Shouldn=E2=80=99t it be more secure if we change to use a post method f= or > access token, similar to the SAML does? > I say yes. But please note I'm very new at this and someone with more > experience will have more to say or correct my comments. > Here are a few more details to consider. > 1) OAuth is a framework and not a standard, per se. Different > authorization servers will have different implementations that are not > necessarily compatible with other service providers. So there is no > standard to break, per se. > 2) Sensitive data in a URI is a bad idea. They leak all over the place > even over HTTPS. Even in fragments. > 3) Break the "rules" and find a way to submit sensitive data like access > tokens, session information or any other (even short term) sensitive data > in a secure fashion. This includes POST, JSON data payloads over PUT/PATC= H > and other verbs - all over well configured HTTPS. > 4) If you really must submit sensitive data over GET , consider > JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level > confidentiality and integrity. > Aloha, > > Jim Manico > Manicode Securityhttps://www.manicode.com > > > On 6/27/16 9:30 PM, Liyu Yi wrote: > > While we are working on a project with OAuth2 implementation, one questio= n > arises from our engineers. > We noticed at > https://tools.ietf.org/html/draft-ietf-oauth-v2-31#page-30, it is > specified that > > (C) Assuming the resource owner grants access, the authorization > server redirects the user-agent back to the client using the > redirection URI provided earlier. The redirection URI includes > the access token in the URI fragment. > > For my understanding, the browser keeps the URI fragment in the history, > and this introduces unexpected exposure of the access token. A user witho= ut > authorization for the resource can get the access token as long as he has > the access to the browser. This can happen in a shared computer in librar= y, > or for an IT staff who works on other employee=E2=80=99s computer. > > Shouldn=E2=80=99t it be more secure if we change to use a post method for= access > token, similar to the SAML does? > I feel there might be something I missed here. Any advices will be > appreciated. > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > > -- > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > --001a114bb016066610053698ed55 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the great comments and advices.
=
I think it is a good idea for the working group to revise the fra= gment part in the spec, since there might be public available tools already= implemented this approach and people can end up with a solution with serio= us security loopholes.

The re-append issue can be mitiga= te by a logic on Resource Server which carefully re-writes/removes the frag= ment in any redirect, if the the redirect can not be avoided.
-- Liyu
=C2=A0

On Fri, Jul 1, 2016 at 11:33 AM, = John Bradley <ve7jtb@ve7jtb.com> wrote:
This behaviour started ch= anging around 2011

From HTTP/1.1
=C2= =A0 =C2=A0 =C2=A0 f the Location value provided in a 3xx (Redirection) resp= onse does
   not have a fragment component, a user =
agent MUST process the
   redirection as if the value inherits the fragment component of the
   URI reference used to generate the request target (i.e., the
   redirection inherits the original reference's fragment, if any).

   For example, a GET request generated for the URI reference
   "http://w=
ww.example.org/~tim" might result in a 303 (See Other)
   response containing the header field:

     Location: /People.html#tim

   which suggests that the user agent redirect to
   "http://www.example.org/People.html#tim=E2=80=9D
   Likewise, a GET request generated for the URI re=
ference
   "http://www.example.org/index.html#larry" might result in a 301
   (Moved Permanently) response containing the header field:

     Location: http://www.example.net/index.html

   which suggests that the user agent redirect to
   "http://www.example.net/index.html#larry", preserving the origi=
nal
   fragment identifier.


This blog also explores the = change.
https://blogs.msd= n.microsoft.com/ieinternals/2011/05/16/url-fragments-and-redirects/


On Jul 1, 2016, at 1:05 PM, Oleg Gryb <oleg_gryb@yahoo.com> wrote:
<= br>
"Browsers now re-append =C2=A0fragments across 302 redirects unles= s they are explicitly cleared this makes fragment encoding less safe than i= t was =C2=A0when originally specified" - thanks Jim. Looks like a good= reason for vetting this flow out.

=
John,
Please provide more de= tails/links about re-appending fragments.=C2=A0

=
Thanks,
Oleg.


From: Jim Manico <jim= @manicode.com>
To: Oleg Gryb <oleg@gr= yb.info>
Cc: &quo= t;oauth@ietf.org&qu= ot; <oauth@ietf.org<= /a>>; Liyu Yi <= liyuyi@gmail.com>
Sent: Thursday, June 30, 2016 10:25 PM
Subject: Re: [OAUTH-WG] Security concern for URI fragment a= s Implicit grant

Oleg! Hello! Gr= eat to see you pop up here with a similar concern.

John Bradley just answered this thread with the details I w= as looking for (thanks John, hat tip your way).

He also mentioned details about fragment leakage:
"Browsers now re-append =C2=A0fragme= nts across 302 redirects unless they are explicitly cleared this makes frag= ment encoding less safe than it was when originally specified"<= /div>

Again, I'm new here but I'm= grateful for this conversation.

Al= oha,
--
Jim Manico
@Manicode
=

On Jul 1, 2016, at 1:24 AM, Oleg Gryb <oleg_gryb@yahoo.com> wrote:

We've discussed access = tokens in URI back in 2010 (https://www.ietf.org/mail-archive/web/oauth/current/msg04043.= html). There were two major objectives when I was saying that it's = not secure:

1. Fragment is not sent to a server by a browser. When I've asked if t= his is true for every browser in the world, nobody was able to answer.
2. Replacing with POST would mean a significant performan= ce impact in some high volume implementations (I think it was Goole folks w= ho were saying this, but I don't remember now).
<= br clear=3D"none">
AFAIR, nobody was arguing about br= owsing history, so it's valid.

So, 6 years later we're at square one with this= and I hope that this time the community will be more successful with getti= ng rid of secrets in URL.

BTW, Jim, if you can come up with other scenarios when fragm= ents can leak, please share. It'll probably help the community with sol= ving this problem faster than in 6 years.

Thanks,
Oleg.
<= div>

From: Jim Manico <jim@mani= code.com>
To:= Liyu Yi <liyuyi@gmail.com>; oauth= @ietf.org
Sent:= Wednesday, June 29, 2016 7:30 AM
Subject: Re: [OAUTH-WG] Security concer= n for URI fragment as Implicit grant

> Shouldn=E2=80=99t it be more secure if we change to use a post method for access token, similar to the SAML does?
I say yes. But please note I'm very new at this and someone wi= th more experience will have more to say or correct my comments.
Here are a few more details to consider.
1) OAuth is a framework and not a standard, per se. Different authorization servers will have different implementations that are not necessarily compatible with other service providers. So there is no standard to break, per se.
2) Sensitive data in a URI is a bad idea. They leak all over the place even over HTTPS. Even in fragments.
3) Break the "rules" and find a way to submit sensitive = data like access tokens, session information or any other (even short term) sensitive data in a secure fashion. This includes POST, JSON data payloads over PUT/PATCH and other verbs - all over well configured HTTPS.
4) If you really must submit sensitive data over GET , consider JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level confidentiality and integrity.
Aloha,
Jim Manico
Manicode Security
https://www.manicode.com

On 6/27/16 9:30 PM, Liyu Yi wrote:
While we are working on a project with OAuth2 implementation, one question arises from our engineers.
=C2=A0=C2=A0
(C)=C2=A0 Assuming the resource owner grants access, the authorization
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 server redire= cts the user-agent back to the client using the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 redirection U= RI provided earlier.=C2=A0 The redirection URI includes
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the access to= ken in the URI fragment.
=C2=A0
For my understanding, the browser keeps the URI fragment in the history, and this introduces unexpected exposure of the access token. A user without authorization for the resource can get the access token as long as he has the access to the browser. This can happen in a shared computer in library, or for an IT staff who works on other employee=E2=80=99s computer.
=C2=A0
Shouldn=E2=80=99t it be more secure if we change to use a post method for access token, similar to the SAML does?
I feel there might be something I missed here. Any advices will be appreciated.


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


--=20




____________________________= ___________________
OAuth mailing list
= OAuth@ie= tf.org
https://www.ietf.org/mailman/lis= tinfo/oauth




--001a114bb016066610053698ed55-- From nobody Wed Jul 6 07:55:14 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DBCB12D7E9 for ; Fri, 1 Jul 2016 13:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.697 X-Spam-Level: X-Spam-Status: No, score=-2.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, 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=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7307FOmqI25X for ; Fri, 1 Jul 2016 13:42:05 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4183A12D7BA for ; Fri, 1 Jul 2016 13:42:05 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id a125so222641194qkc.2 for ; Fri, 01 Jul 2016 13:42:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5LI7Sp9+4EWwGb//n6GpfcTu1YASMLFSsSlWQNHfdE4=; b=xotI9MhAYUk0EAOaDzfttyghK+dOMYCeu/T5vAb9JM1V9dzkxcoIw4FaAei66UqKa6 n/SeL+0Z/AiN3C3xzAp+bSzYGsy4Tj8lxYU7eC3ZEEqeWk6rhRVC+rCSZPDaBcKJNlSn d3sReQ6TO6yehiKf1kXXxF3M0VxdEzKVmQt/nAbU4jgQWfDfzogoVvxKywMMpQlByC++ Tyvr4gdsTGxIZK/tJBBJsPcQPOzn3VKbmoLVy7+5ZeLvPhfnvXDskTUcK7GG3cl2Jq5q OzUEgNi1wic/Ng8jaaQ4l0QLUaBXlx0ZIAyLeImKPg3kdZetKktrHKGIgM5djLnm/KKM XbPg== 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=5LI7Sp9+4EWwGb//n6GpfcTu1YASMLFSsSlWQNHfdE4=; b=Ag+gXW5G+pp+D98vWXzkVidJWV+YBo9Zh8VWE2Joi1dAjk/YP6pMmBZjQO6+JQSq2l qChaG8tcs+EKuSnZ47/5bt82pgyiYYFLtO0w81uT0RMFXhH0ckCZ6DC41I9r25753zzO 5yNPQxKNdSdcZu3OE3tkP7QdtFUkD7SzPtAA8mxxOBZXDLZXOM3KGz0XWFAsPlGfVYx/ DDA7mQmtrLUJukk7XJy6PHAhUZFVgyl8BnnGF2oSI1TfMYIZOiSl8bNCBHIC5oaB37qk oQ9URC/wAHqR9K1CilV/Vc85fSZUa/iLUsPwiRWOL3wNySigFGS3/VSF5DSZMGHsCDLH HkZA== X-Gm-Message-State: ALyK8tJl/8ALT47Tv8rFmW9VunFmHpDpDizeqsBOaxzC/SyD9nYmRQWnDldChbUON4oHc1rSCMy26gW0Nk1z+A== X-Received: by 10.129.33.87 with SMTP id h84mr128204ywh.304.1467405724289; Fri, 01 Jul 2016 13:42:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.80.13 with HTTP; Fri, 1 Jul 2016 13:42:03 -0700 (PDT) In-Reply-To: References: <994121658.55005.1467329084208.JavaMail.yahoo@mail.yahoo.com> <235316006.458279.1467392709447.JavaMail.yahoo@mail.yahoo.com> <6584BD74-B18F-4174-9E69-5C7B4B76F895@ve7jtb.com> From: Liyu Yi Date: Fri, 1 Jul 2016 13:42:03 -0700 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=001a1142a226f0102a05369904fe Archived-At: X-Mailman-Approved-At: Wed, 06 Jul 2016 07:55:07 -0700 Cc: Oleg Gryb , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 20:42:08 -0000 --001a1142a226f0102a05369904fe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable BTW, I do not see any significant performance concerns for post. Parsing and executing the Javascript logic for post operation will be on the client side, no extra server load is introduced. Plus post will remove the size restriction of the URL length. -- Liyu On Fri, Jul 1, 2016 at 1:35 PM, Liyu Yi wrote: > Thanks for the great comments and advices. > > I think it is a good idea for the working group to revise the fragment > part in the spec, since there might be public available tools already > implemented this approach and people can end up with a solution with > serious security loopholes. > > The re-append issue can be mitigate by a logic on Resource Server which > carefully re-writes/removes the fragment in any redirect, if the the > redirect can not be avoided. > > -- Liyu > > > On Fri, Jul 1, 2016 at 11:33 AM, John Bradley wrote: > >> This behaviour started changing around 2011 >> >> From HTTP/1.1 >> See https://tools.ietf.org/html/rfc7231#section-7.1.2I >> f the Location value provided in a 3xx (Redirection) response does >> >> not have a fragment component, a user agent MUST process the >> redirection as if the value inherits the fragment component of the >> URI reference used to generate the request target (i.e., the >> redirection inherits the original reference's fragment, if any). >> >> For example, a GET request generated for the URI reference >> "http://www.example.org/~tim" might result in a 303 (See Other) >> response containing the header field: >> >> Location: /People.html#tim >> >> which suggests that the user agent redirect to >> "http://www.example.org/People.html#tim=E2=80=9D >> >> >> Likewise, a GET request generated for the URI reference >> "http://www.example.org/index.html#larry" might result in a 301 >> (Moved Permanently) response containing the header field: >> >> Location: http://www.example.net/index.html >> >> which suggests that the user agent redirect to >> "http://www.example.net/index.html#larry", preserving the original >> fragment identifier. >> >> >> >> This blog also explores the change. >> >> https://blogs.msdn.microsoft.com/ieinternals/2011/05/16/url-fragments-an= d-redirects/ >> >> >> On Jul 1, 2016, at 1:05 PM, Oleg Gryb wrote: >> >> "Browsers now re-append fragments across 302 redirects unless they are >> explicitly cleared this makes fragment encoding less safe than it was w= hen >> originally specified" - thanks Jim. Looks like a good reason for vetting >> this flow out. >> >> John, >> Please provide more details/links about re-appending fragments. >> >> Thanks, >> Oleg. >> >> >> ------------------------------ >> *From:* Jim Manico >> *To:* Oleg Gryb >> *Cc:* "oauth@ietf.org" ; Liyu Yi >> *Sent:* Thursday, June 30, 2016 10:25 PM >> *Subject:* Re: [OAUTH-WG] Security concern for URI fragment as Implicit >> grant >> >> Oleg! Hello! Great to see you pop up here with a similar concern. >> >> John Bradley just answered this thread with the details I was looking fo= r >> (thanks John, hat tip your way). >> >> He also mentioned details about fragment leakage: >> >> "Browsers now re-append fragments across 302 redirects unless they are >> explicitly cleared this makes fragment encoding less safe than it was wh= en >> originally specified" >> >> Again, I'm new here but I'm grateful for this conversation. >> >> Aloha, >> -- >> Jim Manico >> @Manicode >> >> On Jul 1, 2016, at 1:24 AM, Oleg Gryb wrote: >> >> We've discussed access tokens in URI back in 2010 ( >> https://www.ietf.org/mail-archive/web/oauth/current/msg04043.html). >> There were two major objectives when I was saying that it's not secure: >> >> 1. Fragment is not sent to a server by a browser. When I've asked if thi= s >> is true for every browser in the world, nobody was able to answer. >> 2. Replacing with POST would mean a significant performance impact in >> some high volume implementations (I think it was Goole folks who were >> saying this, but I don't remember now). >> >> AFAIR, nobody was arguing about browsing history, so it's valid. >> >> So, 6 years later we're at square one with this and I hope that this tim= e >> the community will be more successful with getting rid of secrets in URL= . >> >> BTW, Jim, if you can come up with other scenarios when fragments can >> leak, please share. It'll probably help the community with solving this >> problem faster than in 6 years. >> >> Thanks, >> Oleg. >> >> >> ------------------------------ >> *From:* Jim Manico >> *To:* Liyu Yi ; oauth@ietf.org >> *Sent:* Wednesday, June 29, 2016 7:30 AM >> *Subject:* Re: [OAUTH-WG] Security concern for URI fragment as Implicit >> grant >> >> > Shouldn=E2=80=99t it be more secure if we change to use a post method = for >> access token, similar to the SAML does? >> I say yes. But please note I'm very new at this and someone with more >> experience will have more to say or correct my comments. >> Here are a few more details to consider. >> 1) OAuth is a framework and not a standard, per se. Different >> authorization servers will have different implementations that are not >> necessarily compatible with other service providers. So there is no >> standard to break, per se. >> 2) Sensitive data in a URI is a bad idea. They leak all over the place >> even over HTTPS. Even in fragments. >> 3) Break the "rules" and find a way to submit sensitive data like access >> tokens, session information or any other (even short term) sensitive dat= a >> in a secure fashion. This includes POST, JSON data payloads over PUT/PAT= CH >> and other verbs - all over well configured HTTPS. >> 4) If you really must submit sensitive data over GET , consider >> JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level >> confidentiality and integrity. >> Aloha, >> >> Jim Manico >> Manicode Securityhttps://www.manicode.com >> >> >> On 6/27/16 9:30 PM, Liyu Yi wrote: >> >> While we are working on a project with OAuth2 implementation, one >> question arises from our engineers. >> We noticed at >> >> https://tools.ietf.org/html/draft-ietf-oauth-v2-31#page-30, it is >> specified that >> >> (C) Assuming the resource owner grants access, the authorization >> server redirects the user-agent back to the client using the >> redirection URI provided earlier. The redirection URI includes >> the access token in the URI fragment. >> >> For my understanding, the browser keeps the URI fragment in the history, >> and this introduces unexpected exposure of the access token. A user with= out >> authorization for the resource can get the access token as long as he ha= s >> the access to the browser. This can happen in a shared computer in libra= ry, >> or for an IT staff who works on other employee=E2=80=99s computer. >> >> Shouldn=E2=80=99t it be more secure if we change to use a post method fo= r access >> token, similar to the SAML does? >> I feel there might be something I missed here. Any advices will be >> appreciated. >> >> >> _______________________________________________ >> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oa= uth >> >> >> -- >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> > --001a1142a226f0102a05369904fe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
BTW, I do not see any significant performance concerns for= post. Parsing and executing the Javascript logic for post operation will b= e on the client side, no extra server load is introduced.

Plus post will remove the size restriction of the URL length.
<= br>
-- Liyu=C2=A0

On Fri, Jul 1, 2016 at 1:35 PM, Liyu Yi <liyuyi@gmail= .com> wrote:
Thanks for the great comments and advices.

I th= ink it is a good idea for the working group to revise the fragment part in = the spec, since there might be public available tools already implemented t= his approach and people can end up with a solution with serious security lo= opholes.

The re-append issue can be mitigate by a logic = on Resource Server which carefully re-writes/removes the fragment in any re= direct, if the the redirect can not be avoided.

-- Liyu
=C2=A0<= /div>

On Fri, Jul 1, 2016 a= t 11:33 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
This behaviou= r started changing around 2011

From HTTP/1.1
=C2=A0 =C2=A0 =C2=A0 f the Location value provided in a 3xx (Redirec= tion) response does
   not have a fragment componen=
t, a user agent MUST process the
   redirection as if the value inherits the fragment component of the
   URI reference used to generate the request target (i.e., the
   redirection inherits the original reference's fragment, if any).

   For example, a GET request generated for the URI reference
   "http://w=
ww.example.org/~tim" might result in a 303 (See Other)
   response containing the header field:

     Location: /People.html#tim

   which suggests that the user agent redirect to
   "http://www.example.org/People.html#tim=E2=80=9D
   Likewise, a GET request generated for the URI re=
ference
   "http://www.example.org/index.html#larry" might result in a 301
   (Moved Permanently) response containing the header field:

     Location: http://www.example.net/index.html

   which suggests that the user agent redirect to
   "http://www.example.net/index.html#larry", preserving the origi=
nal
   fragment identifier.


This blog also explores the = change.
https://blogs.msd= n.microsoft.com/ieinternals/2011/05/16/url-fragments-and-redirects/


On = Jul 1, 2016, at 1:05 PM, Oleg Gryb <oleg_gryb@yahoo.com> wrote:

=
"Brow= sers now re-append =C2=A0fragments across 302 redirects unless they are exp= licitly cleared this makes fragment encoding less safe than it was =C2=A0wh= en originally specified" - thanks Jim. Looks like a good reason for ve= tting this flow out.

=
John,
Please provide more details/links a= bout re-appending fragments.=C2=A0

=
Thanks,
Oleg.


From: Jim Manico= <jim@manicode.com= >
To: Oleg Gryb &= lt;oleg@gryb.info&g= t;
Cc: "oauth@ietf.org" <oauth@ietf.org>; Liyu= Yi <liyuyi@gmail.= com>
Sent: Thursd= ay, June 30, 2016 10:25 PM
Subject:= Re: [OAUTH-WG] Security concern for URI fragment as Implicit gr= ant

Oleg! Hello! Great to see yo= u pop up here with a similar concern.

John Bradley just answered this thread with the details I was looking fo= r (thanks John, hat tip your way).

= He also mentioned details about fragment leakage:

"Browsers now re-append =C2=A0fragments across 30= 2 redirects unless they are explicitly cleared this makes fragment encoding= less safe than it was when originally specified"
Again, I'm new here but I'm grateful for= this conversation.

Aloha,
--
Jim Manico
@Manicode
On Jul 1, 2016, at 1:24 AM, Oleg Gryb <ole= g_gryb@yahoo.com> wrote:

=
We've discussed access tokens in URI ba= ck in 2010 (htt= ps://www.ietf.org/mail-archive/web/oauth/current/msg04043.html). There = were two major objectives when I was saying that it's not secure:
=

1. Fragment is n= ot sent to a server by a browser. When I've asked if this is true for e= very browser in the world, nobody was able to answer.
2. Replacing with POST would mean a significant performance impact in some= high volume implementations (I think it was Goole folks who were saying th= is, but I don't remember now).

AFAIR, nobody was arguing about browsing history, s= o it's valid.

So, 6 years later we're at square one with this and I hope tha= t this time the community will be more successful with getting rid of secre= ts in URL.

= BTW, Jim, if you can come up with other scenarios when fragments can leak, = please share. It'll probably help the community with solving this probl= em faster than in 6 years.

<= div dir=3D"ltr">Thanks,
Oleg.


From: Jim Manico <jim@manicode.com><= br clear=3D"none"> To: Liyu = Yi <liyuyi@gmail.com>; oauth@ietf.org Sent: Wedne= sday, June 29, 2016 7:30 AM
Subject: Re: [OAUTH-WG] Security concern for URI fragmen= t as Implicit grant

> Shouldn=E2=80=99t it be more secure if we change to use a post method for access token, similar to the SAML does?
I say yes. But please note I'm very new at this and someone wi= th more experience will have more to say or correct my comments.
Here are a few more details to consider.
1) OAuth is a framework and not a standard, per se. Different authorization servers will have different implementations that are not necessarily compatible with other service providers. So there is no standard to break, per se.
2) Sensitive data in a URI is a bad idea. They leak all over the place even over HTTPS. Even in fragments.
3) Break the "rules" and find a way to submit sensitive = data like access tokens, session information or any other (even short term) sensitive data in a secure fashion. This includes POST, JSON data payloads over PUT/PATCH and other verbs - all over well configured HTTPS.
4) If you really must submit sensitive data over GET , consider JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level confidentiality and integrity.
Aloha,
Jim Manico
Manicode Security
https://www.manicode.com

On 6/27/16 9:30 PM, Liyu Yi wrote:
While we are working on a project with OAuth2 implementation, one question arises from our engineers.
=C2=A0=C2=A0
(C)=C2=A0 Assuming the resource owner grants access, the authorization
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 server redire= cts the user-agent back to the client using the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 redirection U= RI provided earlier.=C2=A0 The redirection URI includes
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the access to= ken in the URI fragment.
=C2=A0
For my understanding, the browser keeps the URI fragment in the history, and this introduces unexpected exposure of the access token. A user without authorization for the resource can get the access token as long as he has the access to the browser. This can happen in a shared computer in library, or for an IT staff who works on other employee=E2=80=99s computer.
=C2=A0
Shouldn=E2=80=99t it be more secure if we change to use a post method for access token, similar to the SAML does?
I feel there might be something I missed here. Any advices will be appreciated.


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


--=20




____________________________= ___________________
OAuth mailing list
= OAuth@ie= tf.org
https://www.ietf.org/mailman/lis= tinfo/oauth





--001a1142a226f0102a05369904fe-- From nobody Wed Jul 6 07:55:18 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC22F12B022 for ; Fri, 1 Jul 2016 15:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.697 X-Spam-Level: X-Spam-Status: No, score=-2.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, 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=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86yZJMkw9eQF for ; Fri, 1 Jul 2016 15:43:53 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d: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 E709E12B00F for ; Fri, 1 Jul 2016 15:43:52 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id e3so23631394qkd.0 for ; Fri, 01 Jul 2016 15:43:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5xo+oM8Vam+nIMpcT/FnsPF8Ce/PT1tPfKIGdbjYrlw=; b=rnVU5KP5q5lSwP2hbFe1gXlW22I81BW12ArYMk/YoqHdHQhdLtsY1P3LgIGrn+NLiE DbGj9QMSGU4VMdjuu2rOEp58FCARkCc/AtmQgIkBmcaLsbfb5e9sXtsNh46BSWdL98GN GAe2bBccdjDdl2KO167w4ROniNCJwh2C6xVq9E4LzO1Jf3dd/SIO8zEtRbLf+xz574v2 t9Z/QM4obIurEsSFb6iPWm7wdxLXlIv4t8zcVpcFhB/5qWTuUW01ADaia3cLSbuD1Zgl g+ZtzZdZ77G/llA07hJTqZiDB7zHsw+93wzv+Nw51zNZ50ED0CN7v+/+ff1qKHuuO5JR uZ/w== 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=5xo+oM8Vam+nIMpcT/FnsPF8Ce/PT1tPfKIGdbjYrlw=; b=JZZ7rQipjqiG5GWbwxYgVf+jWca2I0en8ZiceV4ZaQd71e6bAc5RR+8FwDy4vbQ5nc 6rVOq3Yg8FFxoruGKrF9xvNd09NyY3mTOXNV/TnJdJ1SD51uNrS3wuyFEPXZOMf5R7hJ Np6cYUSnxNyaEm0wr6CQ6VscXhiuOllgwDCaVia8CVVUxaTUkCFTenVQ774e2szTZ2G4 14lA3voWaFgGjoqrViTqSHkUMfUg+H1Jl+FpLmnQ4/eF2VU+aGqFvXUA8mlIcrPaJ0B/ FRixVWwJs/O7mGaF7bOoLF2iaLU/dIQi5C5CDWH+gMVon6/wx1/mDOUOKjsxB3YDWFK+ pJkA== X-Gm-Message-State: ALyK8tIzuMiYDMPN405jSWqJ2dHWBugM/oj16cnfyRZ7SHaauoo0wypg++KJHKXaCksqNlHCar0JucXSZnn9WQ== X-Received: by 10.37.80.13 with SMTP id e13mr366790ybb.162.1467413031882; Fri, 01 Jul 2016 15:43:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.80.13 with HTTP; Fri, 1 Jul 2016 15:43:50 -0700 (PDT) In-Reply-To: References: <994121658.55005.1467329084208.JavaMail.yahoo@mail.yahoo.com> <235316006.458279.1467392709447.JavaMail.yahoo@mail.yahoo.com> <6584BD74-B18F-4174-9E69-5C7B4B76F895@ve7jtb.com> <410908395.555462.1467407397629.JavaMail.yahoo@mail.yahoo.com> <8CC41328-C26D-42C0-BFDB-BF0216C7B76C@ve7jtb.com> <71CE61B3-FEC2-46A7-AB28-B53E89A8E53F@ve7jtb.com> From: Liyu Yi Date: Fri, 1 Jul 2016 15:43:50 -0700 Message-ID: To: Josh Mandel Content-Type: multipart/alternative; boundary=001a113e8bfe81186c05369ab887 Archived-At: X-Mailman-Approved-At: Wed, 06 Jul 2016 07:55:07 -0700 Cc: Oleg Gryb , "" Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 22:43:58 -0000 --001a113e8bfe81186c05369ab887 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Understood there is an Authorization Code grant type; here I am more focusing on the Implicit grant type. also when I mentioned POST, I did not mean postMessage, it is simply the HTTP POST. Specifically it is more like this ... 4.2 . Implicit Grant (modified) +----------+ | Resource | | Owner | | | +----------+ ^ | (B) +----|-----+ Client Identifier +---------------+ | -+----(A)-- & Redirection URI --->| | | User- | | Authorization | | Agent -|----(B)-- User authenticates -->| Server | | | | | | |<---(C)- Response embedded JS -<| | | | with Access Token +---------------+ | | in JS content, which will be posted to Resource Server | | +---------------+ | |----(D)-- JS post to RS URI --->| Web-Hosted | | | with Access Token | Client | | | | Resource | | (F) |<---(E)----- RS Script --------<| | | | with Access Token +---------------+ +-|--------+ | | (A) (G) Access Token | | ^ v +---------+ | | | Client | | | +---------+ Figure 4: Implicit Grant Flow The flow illustrated in Figure 4 includes the following steps: (A) The client initiates the flow by directing the resource owner's user-agent to the authorization endpoint. The client includes its client identifier, requested scope, local state, and a redirection URI to which the authorization server will send the user-agent back once access is granted (or denied). (B) The authorization server authenticates the resource owner (via the user-agent) and establishes whether the resource owner grants or denies the client's access request. (C) Assuming the resource owner grants access, the authorization server responds with a JavaScript logic which automatically posts t= o "redirection" URI provided earlier. The JavaScript includes the access token in the URI fragment. (D) The user-agent does the post with the access token. Granted, user agent can actually do post without the access token in a different iframe, then use postMessage to pass the token over, but I do not see why get it need that compexity. On Fri, Jul 1, 2016 at 3:13 PM, Josh Mandel wrote: > Thanks John! Yes, we're following the CORS based flow you've described > below (though I should note that the actual redirection back to the clien= t > could be a 302, or could be a simple Web link that the user follows from = an > authorization page; this is up to the authorization server). > > Overall I don't argue that this flow is "more secure" than the implicit > flow -- though I believe it does help client developers avoid some common > pitfalls. (For example, clients that, through careless programming or poo= r > understanding of the spec, fail to validate incoming "state" are still no= t > susceptible to arbitrary token injection, which means at least they won't > readily be tricked into using a token designated for an entirely differen= t > client. With poorly written implicit flow clients, this is an issue.) > > That said, I wasn't aiming to discuss the relative security; just wanted > to make sure I knew what you meant by "won't work well". > > Thanks again! > > -Josh > On Jul 1, 2016 18:02, "John Bradley" wrote: > >> I am making a distinction between a browser talking to a Web server that >> is acting as a OAuth Client POST response mode =3D good , and a oauth cl= ient >> running in the browser user agent as a Java script application (that can= =E2=80=99t >> directly capture a POST response back to the server) >> >> So it depends on where the client is actually running. >> >> Are you saying that you are using a 302 redirect from the authorization >> endpoint back to the server hosting the JS and then loading the JS >> including the code and then using CORES to exchange the code for a AT? >> >> You can do that but I don=E2=80=99t think a public client like that is m= ore >> secure than just using the fragment encoded response and is more work. >> It also may give the server a false sense of security. >> >> John B. >> >> On Jul 1, 2016, at 5:52 PM, Josh Mandel wrote: >> >> I think the confusion here is that I'm not using HEART's OAuth profiles >> :-) >> >> I'm using the SMART profiles, where we do specify the use of an >> authorization code grant even for browser-based public clients (in which >> case, no client_secret is issued or used). I'm just trying to understand >> your perspective eon why this "won't work well". Perhaps you didn't mean >> this comment to refer to browser-based OAuth clients generally? >> >> -Josh >> >> On Fri, Jul 1, 2016 at 5:45 PM, John Bradley wrote: >> >>> I don=E2=80=99t think the post response mode is supported by heart so I= suspect >>> that we are talking about different things. >>> >>> You are probably using the supported code flow that uses a 302 get to >>> return the code to the OAuth client on the server. >>> The Web server is then acting as a confidential client to exchange the >>> code via a POST (different POST) with the AS token_endpoint. >>> >>> The Token endpoint will return a access token (AT) and optional refresh >>> token (RT). >>> >>> The web page may be getting the server to make the OAuth calls on it=E2= =80=99s >>> behalf to the Resource Server, or possibly you are passing the AT from = the >>> server back to a Java script app that is using CORES to make calls dire= ctly >>> to the RS without going through the Web server. >>> >>> Passing the AT back to the user agent from the client is not >>> recommended. >>> >>> For in browser clients where the JS is using the AT to make the calls >>> directly to the RS via CORES the recommended approach is to use the >>> fragment encoded response via a 302 to deliver the AT directly to the >>> client (It never hits the backend Web server). >>> >>> However I believe In browser OAuth clients are not currently supported >>> in HEART, so I am not quite sure what you are doing. >>> >>> Perhaps Justin has a better answer. >>> >>> John B. >>> >>> >>> On Jul 1, 2016, at 5:33 PM, Josh Mandel wrote: >>> >>> John, >>> >>> I appreciate your response. I'm hoping you can clarify why you say that >>> "HTTP POST... won't work well for... [a] single page OAuth client"? >>> >>> We commonly build single-page apps that act as OAuth clients for SMART >>> (e.g. this sample app >>> ), >>> and we've had good experience with the technique. Could you elaborate? >>> >>> -J >>> >>> On Fri, Jul 1, 2016 at 5:26 PM, John Bradley wrote: >>> >>>> HEART only supports web server clients at the moment. That might >>>> change in future to support native apps if that an be made to support = the >>>> security requirements of Heath IT. >>>> >>>> So the thing HTTP POST responses won=E2=80=99t work well for is a type= of in >>>> browser single page OAuth client. That still needs fragment encoded >>>> responses or the new post-message Java Script API approach. >>>> >>>> John B. >>>> >>>> >>>> On Jul 1, 2016, at 5:16 PM, Josh Mandel wrote: >>>> >>>> Thanks Justin, >>>> >>>> To clarify: John's comment and my question were about POST. (I do >>>> understand the behavior of HTTP POST and of window.postMessage; these = are >>>> totally different things.) From my perspective in SMART Health IT, we = use >>>> the OAuth 2.0 authorization code flow, including HTTP POST, in our aut= horization >>>> spec even for public >>>> clients, and it has worked very well for us, with about a dozen electr= onic >>>> health record servers supporting this approach. That's why I was curio= us to >>>> hear John's perspective about limitations. >>>> >>>> -J >>>> >>>> On Fri, Jul 1, 2016 at 5:09 PM, Oleg Gryb wrote: >>>> >>>>> > POST will send things to the server, which isn=E2=80=99t desirable = if your >>>>> client is solely in the browser >>>>> Why it's not desirable, assuming that we disregard performance? You >>>>> can generate HTTP POST from JS, e.g. through an AJAX call. What is wr= ong >>>>> with this? >>>>> >>>>> >>>>> ------------------------------ >>>>> *From:* Justin Richer >>>>> *To:* Josh Mandel >>>>> *Cc:* Oleg Gryb ; "" = ; >>>>> Liyu Yi >>>>> *Sent:* Friday, July 1, 2016 2:00 PM >>>>> >>>>> *Subject:* Re: [OAUTH-WG] Security concern for URI fragment as >>>>> Implicit grant >>>>> >>>>> POST will send things to the server, which isn=E2=80=99t desirable if= your >>>>> client is solely in the browser. postMessage is a browser API and not= to be >>>>> confused with HTTP POST. postMessage messages stay (or can stay) with= in the >>>>> browser, which is the intent here. >>>>> >>>>> =E2=80=94 Justin >>>>> >>>>> On Jul 1, 2016, at 4:56 PM, Josh Mandel wrote: >>>>> >>>>> John, >>>>> >>>>> Could you clarify what you mean by "POST doesn't really work"? Do you >>>>> just mean that CORS support (e.g., http://caniuse.com/#feat=3Dcors) >>>>> isn't universal, or something more? >>>>> >>>>> On Fri, Jul 1, 2016 at 4:51 PM, John Bradley >>>>> wrote: >>>>> >>>>> Yes but POST doesn't really work for in browser apps. >>>>> >>>>> If it is a server app it should be using the code flow with GET or >>>>> POST as you like. >>>>> >>>>> If we do a post message based binding it will be targeted at in >>>>> browser applications. >>>>> >>>>> John B. >>>>> >>>>> On Fri, Jul 1, 2016 at 4:42 PM, Liyu Yi wrote: >>>>> >>>>> BTW, I do not see any significant performance concerns for post. >>>>> Parsing and executing the Javascript logic for post operation will be= on >>>>> the client side, no extra server load is introduced. >>>>> >>>>> Plus post will remove the size restriction of the URL length. >>>>> >>>>> -- Liyu >>>>> >>>>> On Fri, Jul 1, 2016 at 1:35 PM, Liyu Yi wrote: >>>>> >>>>> Thanks for the great comments and advices. >>>>> >>>>> I think it is a good idea for the working group to revise the fragmen= t >>>>> part in the spec, since there might be public available tools already >>>>> implemented this approach and people can end up with a solution with >>>>> serious security loopholes. >>>>> >>>>> The re-append issue can be mitigate by a logic on Resource Server >>>>> which carefully re-writes/removes the fragment in any redirect, if th= e the >>>>> redirect can not be avoided. >>>>> >>>>> -- Liyu >>>>> >>>>> >>>>> On Fri, Jul 1, 2016 at 11:33 AM, John Bradley >>>>> wrote: >>>>> >>>>> This behaviour started changing around 2011 >>>>> >>>>> From HTTP/1.1 >>>>> See https://tools.ietf.org/html/rfc7231#section-7.1.2I >>>>> f the Location value provided in a 3xx (Redirection) response >>>>> does >>>>> >>>>> not have a fragment component, a user agent MUST process the >>>>> redirection as if the value inherits the fragment component of the >>>>> URI reference used to generate the request target (i.e., the >>>>> redirection inherits the original reference's fragment, if any). >>>>> >>>>> For example, a GET request generated for the URI reference >>>>> "http://www.example.org/~tim" might result in a 303 (See Other) >>>>> response containing the header field: >>>>> >>>>> Location: /People.html#tim >>>>> >>>>> which suggests that the user agent redirect to >>>>> "http://www.example.org/People.html#tim=E2=80=9D >>>>> >>>>> >>>>> Likewise, a GET request generated for the URI reference >>>>> "http://www.example.org/index.html#larry" might result in a 301 >>>>> (Moved Permanently) response containing the header field: >>>>> >>>>> Location: http://www.example.net/index.html >>>>> >>>>> which suggests that the user agent redirect to >>>>> "http://www.example.net/index.html#larry", preserving the original >>>>> fragment identifier. >>>>> >>>>> >>>>> >>>>> This blog also explores the change. >>>>> >>>>> https://blogs.msdn.microsoft.com/ieinternals/2011/05/16/url-fragments= -and-redirects/ >>>>> >>>>> >>>>> On Jul 1, 2016, at 1:05 PM, Oleg Gryb wrote: >>>>> >>>>> "Browsers now re-append fragments across 302 redirects unless they >>>>> are explicitly cleared this makes fragment encoding less safe than it= was >>>>> when originally specified" - thanks Jim. Looks like a good reason fo= r >>>>> vetting this flow out. >>>>> >>>>> John, >>>>> Please provide more details/links about re-appending fragments. >>>>> >>>>> Thanks, >>>>> Oleg. >>>>> >>>>> >>>>> ------------------------------ >>>>> *From:* Jim Manico >>>>> *To:* Oleg Gryb >>>>> *Cc:* "oauth@ietf.org" ; Liyu Yi >>>>> *Sent:* Thursday, June 30, 2016 10:25 PM >>>>> *Subject:* Re: [OAUTH-WG] Security concern for URI fragment as >>>>> Implicit grant >>>>> >>>>> Oleg! Hello! Great to see you pop up here with a similar concern. >>>>> >>>>> John Bradley just answered this thread with the details I was looking >>>>> for (thanks John, hat tip your way). >>>>> >>>>> He also mentioned details about fragment leakage: >>>>> >>>>> "Browsers now re-append fragments across 302 redirects unless they >>>>> are explicitly cleared this makes fragment encoding less safe than it= was >>>>> when originally specified" >>>>> >>>>> Again, I'm new here but I'm grateful for this conversation. >>>>> >>>>> Aloha, >>>>> -- >>>>> Jim Manico >>>>> @Manicode >>>>> >>>>> On Jul 1, 2016, at 1:24 AM, Oleg Gryb wrote: >>>>> >>>>> We've discussed access tokens in URI back in 2010 ( >>>>> https://www.ietf.org/mail-archive/web/oauth/current/msg04043.html). >>>>> There were two major objectives when I was saying that it's not secur= e: >>>>> >>>>> 1. Fragment is not sent to a server by a browser. When I've asked if >>>>> this is true for every browser in the world, nobody was able to answe= r. >>>>> 2. Replacing with POST would mean a significant performance impact in >>>>> some high volume implementations (I think it was Goole folks who were >>>>> saying this, but I don't remember now). >>>>> >>>>> AFAIR, nobody was arguing about browsing history, so it's valid. >>>>> >>>>> So, 6 years later we're at square one with this and I hope that this >>>>> time the community will be more successful with getting rid of secret= s in >>>>> URL. >>>>> >>>>> BTW, Jim, if you can come up with other scenarios when fragments can >>>>> leak, please share. It'll probably help the community with solving th= is >>>>> problem faster than in 6 years. >>>>> >>>>> Thanks, >>>>> Oleg. >>>>> >>>>> >>>>> ------------------------------ >>>>> *From:* Jim Manico >>>>> *To:* Liyu Yi ; oauth@ietf.org >>>>> *Sent:* Wednesday, June 29, 2016 7:30 AM >>>>> *Subject:* Re: [OAUTH-WG] Security concern for URI fragment as >>>>> Implicit grant >>>>> >>>>> > Shouldn=E2=80=99t it be more secure if we change to use a post meth= od for >>>>> access token, similar to the SAML does? >>>>> I say yes. But please note I'm very new at this and someone with more >>>>> experience will have more to say or correct my comments. >>>>> Here are a few more details to consider. >>>>> 1) OAuth is a framework and not a standard, per se. Different >>>>> authorization servers will have different implementations that are no= t >>>>> necessarily compatible with other service providers. So there is no >>>>> standard to break, per se. >>>>> 2) Sensitive data in a URI is a bad idea. They leak all over the plac= e >>>>> even over HTTPS. Even in fragments. >>>>> 3) Break the "rules" and find a way to submit sensitive data like >>>>> access tokens, session information or any other (even short term) sen= sitive >>>>> data in a secure fashion. This includes POST, JSON data payloads over >>>>> PUT/PATCH and other verbs - all over well configured HTTPS. >>>>> 4) If you really must submit sensitive data over GET , consider >>>>> JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level >>>>> confidentiality and integrity. >>>>> Aloha, >>>>> >>>>> Jim Manico >>>>> Manicode Securityhttps://www.manicode.com >>>>> >>>>> >>>>> On 6/27/16 9:30 PM, Liyu Yi wrote: >>>>> >>>>> While we are working on a project with OAuth2 implementation, one >>>>> question arises from our engineers. >>>>> We noticed at >>>>> >>>>> https://tools.ietf.org/html/draft-ietf-oauth-v2-31#page-30, it is >>>>> specified that >>>>> >>>>> (C) Assuming the resource owner grants access, the authorization >>>>> server redirects the user-agent back to the client using the >>>>> redirection URI provided earlier. The redirection URI includ= es >>>>> the access token in the URI fragment. >>>>> >>>>> For my understanding, the browser keeps the URI fragment in the >>>>> history, and this introduces unexpected exposure of the access token.= A >>>>> user without authorization for the resource can get the access token = as >>>>> long as he has the access to the browser. This can happen in a shared >>>>> computer in library, or for an IT staff who works on other employee= =E2=80=99s >>>>> computer. >>>>> >>>>> Shouldn=E2=80=99t it be more secure if we change to use a post method= for >>>>> access token, similar to the SAML does? >>>>> I feel there might be something I missed here. Any advices will be >>>>> appreciated. >>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo= /oauth >>>>> >>>>> >>>>> -- >>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> >>> >>> >> >> --001a113e8bfe81186c05369ab887 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Understood there is an Authorization Code grant type;= here I am more focusing on the Implicit grant type.=C2=A0
=C2=A0= =C2=A0
also when I mentioned POST, I did not mean postMessage, it= is simply the HTTP POST. Specifically it is more like this ...
<= br>


4.2.  Implicit Grant (modified)


     +----------+
     | Resource |
     |  Owner   |
     |          |
     +----------+
          ^
          |
         (B)
     +----|-----+          Client Identifier     +---------------+
     |         -+----(A)-- & Redirection URI --->|               |
     |  User-   |                                | Authorization |
     |  Agent  -|----(B)-- User authenticates -->|     Server    |
     |          |                                |               |
     |          |<---(C)- Response embedded JS -<|               |
     |          |          with Access Token     +---------------+
     |          |            in JS content, which will be posted to Resourc=
e Server
     |          |                                +---------------+
     |          |----(D)-- JS post to RS URI --->|   Web-Hosted  |
     |          |         with Access Token      |     Client    |
     |          |                                |    Resource   |
     |     (F)  |<---(E)----- RS Script --------<|               |
     |          |         with Access Token      +---------------+
     +-|--------+
       |    |
      (A)  (G) Access Token
       |    |
       ^    v
     +---------+
     |         |
     |  Client |
     |         |
     +---------+



                       Figure 4: Implicit Grant Flow


   The flow illustrated in Figure 4 includes the=
 following steps:

   (A)  The client initiates the flow by directing the resource owner's
        user-agent to the authorization endpoint.  The client includes
        its client identifier, requested scope, local state, and a
        redirection URI to which the authorization server will send the
        user-agent back once access is granted (or denied).

   (B)  The authorization server authenticates the resource owner (via
        the user-agent) and establishes whether the resource owner
        grants or denies the client's access request.

   (C)  Assuming the resource owner grants access, the authorization
        server responds with a JavaScript logic which automatically posts t=
o=20
        "redirection" URI provided earlier.  The JavaScript inclu=
des
        the access token in the URI fragment.

   (D)  The user-agent does the post with the access token. Granted,
user agent can actually do post without the acce= ss token in a different iframe, 
                  the=
n use postMessage to pass the token over, but I do not see why get it need =
that compexity.


On Fri, Jul 1, 2016 a= t 3:13 PM, Josh Mandel <jmandel@gmail.com> wrote:

Thanks John! Yes, we're followin= g the CORS based flow you've described below (though I should note that= the actual redirection back to the client could be a 302, or could be a si= mple Web link that the user follows from an authorization page; this is up = to the authorization server).

Overall I don't argue that this flow is "more secur= e" than the implicit flow -- though I believe it does help client deve= lopers avoid some common pitfalls. (For example, clients that, through care= less programming or poor understanding of the spec, fail to validate incomi= ng "state" are still not susceptible to arbitrary token injection= , which means at least they won't readily be tricked into using a token= designated for an entirely different client. With poorly written implicit = flow clients, this is an issue.)

That said, I wasn't aiming to discuss the relative secur= ity; just wanted to make sure I knew what you meant by "won't work= well".

Thanks again!

-Josh

On Jul 1, 2016 18:02, "John Bradley" &= lt;ve7jtb@ve7jtb.com= > wrote:
I am making a distinction between a browser= talking to a Web server that is acting as a OAuth Client POST response mod= e =3D good , and a oauth client running in the browser user agent as a Java= script application (that can=E2=80=99t directly capture a POST response ba= ck to the server)

So it depends on where the client is a= ctually running.

Are you saying that you are using= a 302 redirect from the authorization endpoint back to the server hosting = the JS and then loading the JS including the code and then using CORES =C2= =A0to exchange the code for a AT?

You can do that = but I don=E2=80=99t think a public client like that is more secure than jus= t using the fragment encoded response and is more work.
It also m= ay give the server a false sense of security.

John= B.
On Jul 1, 2016, at 5:52 PM, Josh= Mandel <jmandel@= gmail.com> wrote:

I think the confusi= on here is that I'm not using HEART's OAuth profiles :-)

I'm using the SMART profiles, where we do specify the use of a= n authorization code grant even for browser-based public clients (in which = case, no client_secret is issued or used). I'm just trying to understan= d your perspective eon why this "won't work well". Perhaps yo= u didn't mean this comment to refer to browser-based OAuth clients gene= rally?

=C2=A0 -Josh

On Fri, Jul 1, 2016 at 5:45 PM, John Bradl= ey <ve7jtb@ve7jtb.com> wrote:
I don=E2=80=99t think the post resp= onse mode is supported by heart so I suspect that we are talking about diff= erent things.

You are probably using the supported code = flow that uses a 302 get to return the code to the OAuth client on the serv= er. =C2=A0
The Web server is then acting as a confidential client= to exchange the code via a POST (different POST) with the AS token_endpoin= t.

The Token endpoint will return a access token (= AT) and optional refresh token (RT).

The web page = may be getting the server to make the OAuth calls on it=E2=80=99s behalf to= the Resource Server, or possibly you are passing the AT from the server ba= ck to a Java script app that is using CORES to make calls directly to the R= S without going through the Web server.

Passing th= e AT back to the user agent from the client is not recommended.=C2=A0
=

For in browser clients where the JS is using the AT to = make the calls directly to the RS via CORES the recommended approach is to = use the fragment encoded response via a 302 to deliver the AT directly to t= he client (It never hits the backend Web server).

= However I believe In browser OAuth clients are not currently supported in H= EART, so I am not quite sure what you are doing.

P= erhaps Justin has a better answer.

John B.


On Jul = 1, 2016, at 5:33 PM, Josh Mandel <jmandel@gmail.com> wrote:

John,

I appreciate your response. I'm hoping y= ou can clarify why you say that "HTTP POST... won't work well for.= .. [a] single page OAuth client"?

We commonly build= single-page apps that act as OAuth clients for SMART (e.g. this sample app=C2=A0), and we= 've had good experience with the technique. Could you elaborate?
<= div>
=C2=A0 -J

On Fri, Jul 1, 2016 at 5:26 PM, John Bradley <ve7jtb@ve7j= tb.com> wrote:
HEART only supports web server clients at the mom= ent. =C2=A0 That might change in future to support native apps if that an b= e made to support the security requirements of Heath IT.

So th= e thing HTTP POST responses won=E2=80=99t work well for is a type of in bro= wser single page OAuth client.=C2=A0 That still needs fragment encoded resp= onses or the new post-message Java Script API approach.

John B.


On Jul 1, 2016, at 5:16 PM, Josh Mandel <jmandel@gmail.com> wrote:
Thanks Justin,

To clarify: J= ohn's comment and my question were about POST. (I do understand the beh= avior of HTTP POST and of window.postMessage; these are totally different t= hings.) From my perspective in SMART Health IT, we use the OAuth 2.0 author= ization code flow, including HTTP POST, in our authorization spec=C2=A0= even for public clients, and it has worked very well for us, with about a d= ozen electronic health record servers supporting this approach. That's = why I was curious to hear John's perspective about limitations.

=C2=A0 -J

On Fri, Jul 1, 2016 at 5:09 PM, Oleg Gryb <oleg_gryb@ya= hoo.com> wrote:
> POST will se= nd things to the server, which isn=E2=80=99t desirable if your client is so= lely in the browser
Why it's not desirable= , assuming that we disregard performance? You can generate HTTP POST from J= S, e.g. through an AJAX call. What is wrong with this?
=


From: Justin Richer <jricher@mit.edu>
To: Josh Mandel <jmandel@gmail.com>
Cc: Oleg Gryb <oleg@gryb.info>; "<oauth@ietf.org>" <oauth@ietf.org>; Liyu Yi <liyuyi@gmail.com> Sent: Friday, July 1, 2016= 2:00 PM

Subject:<= /b> Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant
=

POST will send thin= gs to the server, which isn=E2=80=99t desirable if your client is solely in= the browser. postMessage is a browser API and not to be confused with HTTP= POST. postMessage messages stay (or can stay) within the browser, which is= the intent here.

=C2=A0=E2=80=94 Justin<= /div>

On Ju= l 1, 2016, at 4:56 PM, Josh Mandel <jmandel@gmail.com>= ; wrote:

=
John,

Co= uld you clarify what you mean by "POS= T doesn't really work"? Do you just mean that CORS support (e.g.,= =C2=A0http://caniuse.com/#feat=3Dcors) isn't u= niversal, or something more?

On Fr= i, Jul 1, 2016 at 4:51 PM, John Bradley <v= e7jtb@ve7jtb.com> wrote:
Yes but POST doesn't really work for in browser apps.

If it is a server app it should be using the code= flow with GET or POST as you like.

If we do a =C2=A0post message based binding it will be targeted at in brow= ser applications.

John B.

On Fri, Jul 1, 2016 at 4:42 PM, Liyu Yi <liyuyi@gmail.com> wrote:
BTW, I do not see any significant perf= ormance concerns for post. Parsing and executing the Javascript logic for p= ost operation will be on the client side, no extra server load is introduce= d.

Plus post will remove the size restric= tion of the URL length.

-- Liyu=C2=A0
On Fri, Jul 1, 2016 at 1:35 PM, Liyu Yi <liyuyi@gmail.com> wrote:
Thanks for the great comments and advices.=

I think it is a good idea for the worki= ng group to revise the fragment part in the spec, since there might be publ= ic available tools already implemented this approach and people can end up = with a solution with serious security loopholes.

The re-append issue can be mitigate by a logic on Resource Server w= hich carefully re-writes/removes the fragment in any redirect, if the the r= edirect can not be avoided.

-- Liyu
=C2=A0

On Fri, Jul 1, 20= 16 at 11:33 AM, John Bradley <ve7jtb@ve7jt= b.com> wrote:
This behaviour started changing around 2011

From HTTP/1.1
=C2=A0 =C2=A0 =C2=A0 f the Location value provided in a 3xx (Redi= rection) response does
   not have a fragment compo=
nent, a user agent MUST process the
   redirection as if the value inherits the fragment component of the
   URI reference used to generate the request target (i.e., the
   redirection inherits the original reference's fragment, if any).

   For example, a GET request generated for the URI reference
   "http://www.example.org/~tim" might result =
in a 303 (See Other)
   response containing the header field:

     Location: /People.html#tim

   which suggests that the user agent redirect to
   "http://www.example.org/People.html#tim=E2=80=9D

   L=
ikewise, a GET request generated for the URI reference
   "http://www.example.org/index.html#larry=
" might result in a 301
   (Moved Permanently) response containing the header field:

     Location: http://www.example.net/index.html

   which suggests that the user agent redirect to
   "http://www.example.net/index.html#larry=
", preserving the original
   fragment identifier.


This blog also explores the change.


On Jul 1, 2016, at 1:05 PM, Oleg Gryb <ole= g_gryb@yahoo.com> wrote:

"Browsers now re-append =C2=A0fragments across 302 redirects unle= ss they are explicitly cleared this makes fragment encoding less safe than = it was =C2=A0when originally specified" - thanks Jim. Looks like a goo= d reason for vetting this flow out.

John,
Please provide more details/links about re-ap= pending fragments.=C2=A0

Thanks,
Oleg.


=
From: Jim M= anico <jim@manicode.com>
To: Oleg Gryb <oleg@gryb.i= nfo>
Cc: "oauth@ietf.org" <oauth@ietf.org<= /a>>; Liyu Yi <liyuyi@gmail.com>
= Sent: Thursday, June 30, 20= 16 10:25 PM
Subject:= Re: [OAUTH-WG] Security concern for URI fragment as Implicit gr= ant

Oleg!= Hello! Great to see you pop up here with a similar concern.

John Bradley just answered this thread with the d= etails I was looking for (thanks John, hat tip your way).

He also mentioned details about fragment leakage:

"Browsers now re-append = =C2=A0fragments across 302 redirects unless they are explicitly cleared thi= s makes fragment encoding less safe than it was when originally specified&q= uot;

Again, I'm new here= but I'm grateful for this conversation.

<= /div>
Aloha,
--
Jim Manico
@Manicode=

On Jul 1, 2016, at 1:24 AM, Oleg G= ryb <oleg_gryb@yahoo.com> wrote:
=
We've discusse= d access tokens in URI back in 2010 (https://www.ietf.org/mail-archive/web/oauth/current/m= sg04043.html). There were two major objectives when I was saying that i= t's not secure:

1. Fragment is not sent to a server by a browser. When I've as= ked if this is true for every browser in the world, nobody was able to answ= er.
2. Replacing with POST would mean a significant p= erformance impact in some high volume implementations (I think it was Goole= folks who were saying this, but I don't remember now).

AFAIR, nobody was arguin= g about browsing history, so it's valid.

So, 6 years later we're at square one= with this and I hope that this time the community will be more successful = with getting rid of secrets in URL.

BTW, Jim, if you can come up with other scenarios = when fragments can leak, please share. It'll probably help the communit= y with solving this problem faster than in 6 years.
<= br clear=3D"none">
Thanks,
Oleg= .


<= span style=3D"font-weight:bold">From: Jim Manico <= jim@manicode.com>
To: Liyu Yi <liyuyi@gmail.com>; oauth@ietf.org
Sent: Wednesday, June 29, 2016 7:30 AM
= Subject: Re: [OAUTH-WG] Securit= y concern for URI fragment as Implicit grant

> Shouldn=E2=80=99t it be more secure if we change to use a post method for access token, similar to the SAML does?
I say yes. But please note I'm very new at this and someone wi= th more experience will have more to say or correct my comments.
Here are a few more details to consider.
1) OAuth is a framework and not a standard, per se. Different authorization servers will have different implementations that are not necessarily compatible with other service providers. So there is no standard to break, per se.
2) Sensitive data in a URI is a bad idea. They leak all over the place even over HTTPS. Even in fragments.
3) Break the "rules" and find a way to submit sensitive = data like access tokens, session information or any other (even short term) sensitive data in a secure fashion. This includes POST, JSON data payloads over PUT/PATCH and other verbs - all over well configured HTTPS.
4) If you really must submit sensitive data over GET , consider JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level confidentiality and integrity.
Aloha,
Jim Manico
Manicode Security
https://www.manicode.com

On 6/27/16 9:30 PM, Liyu Yi wrote:
While we are working on a project with OAuth2 implementation, one question arises from our engineers.
=C2=A0=C2=A0
(C)=C2=A0 Assuming the resource owner grants access, the authorization
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 server redire= cts the user-agent back to the client using the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 redirection U= RI provided earlier.=C2=A0 The redirection URI includes
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the access to= ken in the URI fragment.
=C2=A0
For my understanding, the browser keeps the URI fragment in the history, and this introduces unexpected exposure of the access token. A user without authorization for the resource can get the access token as long as he has the access to the browser. This can happen in a shared computer in library, or for an IT staff who works on other employee=E2=80=99s computer.
=C2=A0
Shouldn=E2=80=99t it be more secure if we change to use a post method for access token, similar to the SAML does?
I feel there might be something I missed here. Any advices will be appreciated.


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


--=20




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


=





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


_______________________________________________
OAuth mai= ling list
OAuth@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">ht= tps://www.ietf.org/mailman/listinfo/oauth


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



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




--001a113e8bfe81186c05369ab887-- From nobody Wed Jul 6 07:55:30 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48D8612B046 for ; Fri, 1 Jul 2016 16:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.697 X-Spam-Level: X-Spam-Status: No, score=-2.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, 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=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x6WRtd_X0PQA for ; Fri, 1 Jul 2016 16:05:03 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d: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 7F12712B00F for ; Fri, 1 Jul 2016 16:05:03 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id t127so226209234qkf.1 for ; Fri, 01 Jul 2016 16:05:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CV3DkJ+uVl+9LDoeLFRiS03sWKQDCGqrq4vws++ntA8=; b=H4BOEODwOPapPoiv8hcowf+saREoo7PfphhjZqnPrtmDTYlRrFJUrQiWavGGEJIclB J4HjTZAP2FtLT4eYYfSUnBEalKbl2LIFQhujFYATZwgMEjgtOIjTmJD5smJuUYNY4BHh jNCjjQNC/mvf33Kt4TohlLE/CODQEPrfIpXoh24eKc6TcjUu07nfGXYH8I/NDax8cT9g 09UJdYmFCk+bK2/3PldvFB8ZJd9dv5iaW6mImXWdz8bPUiDsntRHOqE0Z63wU44S0oku 2rIU6+5qy8msMSkPO0eaXRpRjVWE6mA2PiGsqoCqo85MFfJvHH2KIM1BvMxHlrbUWtSS Zppg== 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=CV3DkJ+uVl+9LDoeLFRiS03sWKQDCGqrq4vws++ntA8=; b=gCb3+Ey40HbWmv1jQrtBZyR7sxE4r5FgeQnRiLNso72aCC8boeEK0Pw95h85F8XC6m NMdqawmwYU9Yz7h2Uj9bYrqFz7HhGgDm9rXESKVMxaiWedHt0HZjoolG8dlVWzOpxHAp X3x/GbL2jP+HdIp74kGS8AicQA886CMhJTqqI/oKwTTcF8KH0mV3aEhJ7fDVXkytdBEp 6cna4HYTZgR7bKinT2XKauPtAVtrpwNvvbTfwiuARLbNNT/fX8TaS8Ht3q9v8avBJ1++ GHOdrSH5CybIrb+jWAS7x64QhupD1qg17qriFTxSV2UFav+d7K/lH6nyzre4+xFTyHJk 3HUQ== X-Gm-Message-State: ALyK8tK/lqNzyFetBWe+mDD/+8Ji8k8HeMPiRTn8OJzMgRshqseNca1kJ0dGmKJSbqLudQscv9W/tX6959pOiw== X-Received: by 10.37.5.201 with SMTP id 192mr407471ybf.174.1467414302543; Fri, 01 Jul 2016 16:05:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.80.13 with HTTP; Fri, 1 Jul 2016 16:05:01 -0700 (PDT) In-Reply-To: <2041922420.584649.1467413075182.JavaMail.yahoo@mail.yahoo.com> References: <994121658.55005.1467329084208.JavaMail.yahoo@mail.yahoo.com> <235316006.458279.1467392709447.JavaMail.yahoo@mail.yahoo.com> <6584BD74-B18F-4174-9E69-5C7B4B76F895@ve7jtb.com> <717734404.555393.1467406368492.JavaMail.yahoo@mail.yahoo.com> <65E833F7-E277-4F7D-AB1B-B5B61B91BE5B@ve7jtb.com> <2041922420.584649.1467413075182.JavaMail.yahoo@mail.yahoo.com> From: Liyu Yi Date: Fri, 1 Jul 2016 16:05:01 -0700 Message-ID: To: Oleg Gryb Content-Type: multipart/alternative; boundary=001a11c02fe83dd52205369b04c4 Archived-At: X-Mailman-Approved-At: Wed, 06 Jul 2016 07:55:08 -0700 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 23:05:07 -0000 --001a11c02fe83dd52205369b04c4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable For Jim's comment "HTTP POST requests are also a lot more difficult to cache server side compared to URI's which are easier to cache. I'm likely not explaining this well, but I believe it's a webscale concern." I would say, most of the OAuth case will be using HTTPS. and caching with HTTPS is only possible at the end point where SSL/TLS is terminated. when it goes to the server side, it is all about turning the post data to the cache key, some logic is required, but does this have a serious performance issue? However, I do realized that if fetching the resource is implemented as a POST, the POST response is typically not cached. For this, we might be able to use the POST to establish HTTP session and then use the GET to fetch the resource, and with right logic to control the caching behavior. BTW, caching itself also has security implication. On Fri, Jul 1, 2016 at 3:44 PM, Oleg Gryb wrote: > I'm aware about exploits related to improper redirect_url validation, > which was FB case, no qs here, but I still can't understand if appending= a > fragment to Location by a browser makes this exploit simpler or can lead = to > other exploits that have not been described yet. > > > ------------------------------ > *From:* John Bradley > *To:* Oleg Gryb > *Cc:* "oauth@ietf.org" ; Liyu Yi > *Sent:* Friday, July 1, 2016 2:21 PM > > *Subject:* Re: [OAUTH-WG] Security concern for URI fragment as Implicit > grant > > If the attacker can modify the redirect URI to anything like an embedded > add that will do a 302 redirect then the recipient of the redirect can lo= ad > JS to extract the access token. > > This has happened at Facebook so many times I have lost count. It is no= t > theoretical, it happens all the time. > One reason you need to do exact redirect_uri matching in the AS but peopl= e > are not so good at following that and take redirects to any URI on the ho= st > in some cases. > > When used correctly for a real in web client it is fine. For a web serve= r > client it introduces unnecessary risks over the code flow, or hybrid flow > using POST. > > Others may differ with my opinion. > > John B. > > On Jul 1, 2016, at 4:52 PM, Oleg Gryb wrote: > > John, > > Thanks, very useful. However, I'm still trying to figure out why it's > dangerous. Fragment doesn't travel to a server in this new flow either. > Appending it to Location header is done by the browser who needs to > memorize what the original request was. If the original request had a > fragment and the browser got redirected, Location header will be appended > by the browser. > > Are you saying that this is dangerous because the browser would *always* > need to store the fragment somewhere in its memory just in case if a serv= er > decides to redirect? > > So an attack vector here is that an imposter can try to retrieve the > fragment from the browser's memory somehow. Is my understanding correct? > > Oleg. > > > ------------------------------ > *From:* John Bradley > *To:* Oleg Gryb > *Cc:* "oauth@ietf.org" ; Liyu Yi > *Sent:* Friday, July 1, 2016 11:33 AM > *Subject:* Re: [OAUTH-WG] Security concern for URI fragment as Implicit > grant > > This behaviour started changing around 2011 > > From HTTP/1.1 > See https://tools.ietf.org/html/rfc7231#section-7.1.2I > f the Location value provided in a 3xx (Redirection) response does > > not have a fragment component, a user agent MUST process the > redirection as if the value inherits the fragment component of the > URI reference used to generate the request target (i.e., the > redirection inherits the original reference's fragment, if any). > > For example, a GET request generated for the URI reference > "http://www.example.org/~tim" might result in a 303 (See Other) > response containing the header field: > > Location: /People.html#tim > > which suggests that the user agent redirect to > "http://www.example.org/People.html#tim=E2=80=9D > > > Likewise, a GET request generated for the URI reference > "http://www.example.org/index.html#larry" might result in a 301 > (Moved Permanently) response containing the header field: > > Location: http://www.example.net/index.html > > which suggests that the user agent redirect to > "http://www.example.net/index.html#larry", preserving the original > fragment identifier. > > > > This blog also explores the change. > > https://blogs.msdn.microsoft.com/ieinternals/2011/05/16/url-fragments-and= -redirects/ > > > On Jul 1, 2016, at 1:05 PM, Oleg Gryb wrote: > > "Browsers now re-append fragments across 302 redirects unless they are > explicitly cleared this makes fragment encoding less safe than it was wh= en > originally specified" - thanks Jim. Looks like a good reason for vetting > this flow out. > > John, > Please provide more details/links about re-appending fragments. > > Thanks, > Oleg. > > > ------------------------------ > *From:* Jim Manico > *To:* Oleg Gryb > *Cc:* "oauth@ietf.org" ; Liyu Yi > *Sent:* Thursday, June 30, 2016 10:25 PM > *Subject:* Re: [OAUTH-WG] Security concern for URI fragment as Implicit > grant > > Oleg! Hello! Great to see you pop up here with a similar concern. > > John Bradley just answered this thread with the details I was looking for > (thanks John, hat tip your way). > > He also mentioned details about fragment leakage: > > "Browsers now re-append fragments across 302 redirects unless they are > explicitly cleared this makes fragment encoding less safe than it was whe= n > originally specified" > > Again, I'm new here but I'm grateful for this conversation. > > Aloha, > -- > Jim Manico > @Manicode > > On Jul 1, 2016, at 1:24 AM, Oleg Gryb wrote: > > We've discussed access tokens in URI back in 2010 ( > https://www.ietf.org/mail-archive/web/oauth/current/msg04043.html). There > were two major objectives when I was saying that it's not secure: > > 1. Fragment is not sent to a server by a browser. When I've asked if this > is true for every browser in the world, nobody was able to answer. > 2. Replacing with POST would mean a significant performance impact in som= e > high volume implementations (I think it was Goole folks who were saying > this, but I don't remember now). > > AFAIR, nobody was arguing about browsing history, so it's valid. > > So, 6 years later we're at square one with this and I hope that this time > the community will be more successful with getting rid of secrets in URL. > > BTW, Jim, if you can come up with other scenarios when fragments can leak= , > please share. It'll probably help the community with solving this problem > faster than in 6 years. > > Thanks, > Oleg. > > > ------------------------------ > *From:* Jim Manico > *To:* Liyu Yi ; oauth@ietf.org > *Sent:* Wednesday, June 29, 2016 7:30 AM > *Subject:* Re: [OAUTH-WG] Security concern for URI fragment as Implicit > grant > > > Shouldn=E2=80=99t it be more secure if we change to use a post method f= or > access token, similar to the SAML does? > I say yes. But please note I'm very new at this and someone with more > experience will have more to say or correct my comments. > Here are a few more details to consider. > 1) OAuth is a framework and not a standard, per se. Different > authorization servers will have different implementations that are not > necessarily compatible with other service providers. So there is no > standard to break, per se. > 2) Sensitive data in a URI is a bad idea. They leak all over the place > even over HTTPS. Even in fragments. > 3) Break the "rules" and find a way to submit sensitive data like access > tokens, session information or any other (even short term) sensitive data > in a secure fashion. This includes POST, JSON data payloads over PUT/PATC= H > and other verbs - all over well configured HTTPS. > 4) If you really must submit sensitive data over GET , consider > JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level > confidentiality and integrity. > Aloha, > > Jim Manico > Manicode Securityhttps://www.manicode.com > > > On 6/27/16 9:30 PM, Liyu Yi wrote: > > While we are working on a project with OAuth2 implementation, one questio= n > arises from our engineers. > We noticed at > https://tools.ietf.org/html/draft-ietf-oauth-v2-31#page-30, it is > specified that > > (C) Assuming the resource owner grants access, the authorization > server redirects the user-agent back to the client using the > redirection URI provided earlier. The redirection URI includes > the access token in the URI fragment. > > For my understanding, the browser keeps the URI fragment in the history, > and this introduces unexpected exposure of the access token. A user witho= ut > authorization for the resource can get the access token as long as he has > the access to the browser. This can happen in a shared computer in librar= y, > or for an IT staff who works on other employee=E2=80=99s computer. > > Shouldn=E2=80=99t it be more secure if we change to use a post method for= access > token, similar to the SAML does? > I feel there might be something I missed here. Any advices will be > appreciated. > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > > -- > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --001a11c02fe83dd52205369b04c4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
For Jim's comment

"HTTP POST requests are also a lot more difficult to c= ache server side compared to URI's which are easier to cache. I'm l= ikely not explaining this well, but I believe it's a webscale concern.&= quot;

I would say,=C2=A0most of the OAuth case will be using HTTPS.=C2=A0 and=C2=A0caching with HTTPS is only possible at the end point where SSL/TLS = is terminated. when it goes to the server side, it is all about turning the= post data to the cache key, =C2=A0some logic is required, but does this ha= ve a serious performance issue?

However, I do= realized that if fetching the resource is implemented as a POST, the POST = response is typically not cached. For this, we might be able to use the POS= T to establish HTTP session and then use the GET to fetch the resource, and= with right logic to control the caching behavior. BTW, caching itself also= has security implication.=C2=A0


On Fri, Ju= l 1, 2016 at 3:44 PM, Oleg Gryb <oleg_gryb@yahoo.com> wrot= e:
I'm awa= re about exploits related to improper redirect_url validation, which was FB= case, no qs here,=C2=A0 but I still can't understand if appending a fr= agment to Location by a browser makes this exploit simpler or can lead to o= ther exploits that have not been described yet.
=


From: John Bradley <ve7jtb@ve7jtb.com>
To: Oleg Gryb <oleg@gryb.info>
Cc: "oauth@ietf.org" <oauth@ietf.org>; Liyu Yi <liyuyi@gmail.com>
Sent: Friday, July 1, 2016 2:21 PM

Subject:= Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

If the at= tacker can modify the redirect URI to anything like an embedded add that wi= ll do a 302 redirect then the recipient of the redirect can load JS to extr= act the access token.

This has happened a= t Facebook so many times I have lost count. =C2=A0 It is not theoretical, i= t happens all the time.
One reason you need to do exact redirect_= uri matching in the AS but people are not so good at following that and tak= e redirects to any URI on the host in some cases.

When used correctly for a real in web client it is fine.=C2= =A0 For a web server client it introduces unnecessary risks over the code f= low, or hybrid flow using POST.

Oth= ers may differ with my opinion.

Joh= n B.

On Jul 1, 2016, at 4:52 PM, Oleg Gryb <oleg_gry= b@yahoo.com> wrote:

John,

Thanks, very useful. However, I'm still trying to figure= out why it's dangerous. Fragment doesn't travel to a server in thi= s new flow either. Appending it to Location header is done by the browser w= ho needs to memorize what the original request was. If the original request= had a fragment and the browser got redirected, Location header will be app= ended by the browser.

Are you sayin= g that this is dangerous because the browser would *always* need to store t= he fragment somewhere in its memory just in case if a server decides to red= irect?

So an attack vector here is = that an imposter can try to retrieve the fragment from the browser's me= mory somehow. Is my understanding correct?

Oleg.


From: John Bradley <ve7jtb@ve7jtb.com= >
To:<= /b> Oleg Gryb <oleg@gryb.info>
Cc: "oauth@ietf.org<= /a>" <oauth@ietf.org>; Liyu Yi <liyuy= i@gmail.com>
= Sent: Friday, July 1, 2016 11:33 AM
Subject: Re: [OAUTH-WG] Security conc= ern for URI fragment as Implicit grant

This behaviour started changing around 2011
From HTTP/1.1
   not have a fragmen=
t component, a user agent MUST process the
   redirection as if the value inherits the fragment component of the
   URI reference used to generate the request target (i.e., the
   redirection inherits the original reference's fragment, if any).

   For example, a GET request generated for the URI reference
   "http://www.example.org/~tim" might result =
in a 303 (See Other)
   response containing the header field:

     Location: /People.html#tim

   which suggests that the user agent redirect to
   "http://www.example.org/People.html#tim=E2=80=9D

   L=
ikewise, a GET request generated for the URI reference
   "http://www.example.org/index.html#larry=
" might result in a 301
   (Moved Permanently) response containing the header field:

     Location: http://www.example.net/index.html

   which suggests that the user agent redirect to
   "http://www.example.net/index.html#larry=
", preserving the original
   fragment identifier.


This blog also explores the change.


On Jul 1, 2016, at 1:05 PM, Oleg Gryb <oleg_gry= b@yahoo.com> wrote:

"= Browsers now re-append =C2=A0fragments across 302 redirects unless th= ey are explicitly cleared this makes fragment encoding less safe than it wa= s =C2=A0when originally specified" - thanks Jim. Looks like a good rea= son for vetting this flow out.

John,
Please provide more details/links about re-appendi= ng fragments.=C2=A0

<= /span>
Thanks,
Oleg.


From: Jim Manico &= lt;jim@manicode.com>
To: Oleg Gryb <oleg@gryb.info>
Cc: "oauth@ietf.org" <oauth@ietf.org&g= t;; Liyu Yi <liyuyi@gmail.com>
<= span style=3D"font-weight:bold">Sent: Thursday, June 30, 2016 10= :25 PM
Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

Oleg! Hell= o! Great to see you pop up here with a similar concern.

John Bradley just answered this thread with the detail= s I was looking for (thanks John, hat tip your way).

He also mentioned details about fragment leakage:

"Browsers now re-append =C2=A0f= ragments across 302 redirects unless they are explicitly cleared this makes= fragment encoding less safe than it was when originally specified"

Again, I'm new here but I&= #39;m grateful for this conversation.

Aloha,
--
Jim Manico
@Manicode
<= /div>

On Jul 1, 2016, at 1:24 AM, Oleg Gryb <= ;oleg_gryb@yahoo.com> wrote:

We've discussed acces= s tokens in URI back in 2010 (https://www.ietf.org/mail-archive/web/oauth/current/msg04043= .html). There were two major objectives when I was saying that it's= not secure:

1. Fragment is not sent to a server by a browser. When I've asked if = this is true for every browser in the world, nobody was able to answer.
2. Replacing with POST would mean a significant performa= nce impact in some high volume implementations (I think it was Goole folks = who were saying this, but I don't remember now).
=
AFAIR, nobody was arguing about b= rowsing history, so it's valid.

So, 6 years later we're at square one with thi= s and I hope that this time the community will be more successful with gett= ing rid of secrets in URL.

<= div dir=3D"ltr">BTW, Jim, if you can come up with other scenarios when frag= ments can leak, please share. It'll probably help the community with so= lving this problem faster than in 6 years.

Thanks,
Oleg.
<= div>

From: Jim Manico <jim@mani= code.com>
To:= Liyu Yi <liyuyi@gmail.com>; oauth= @ietf.org
Sent:= Wednesday, June 29, 2016 7:30 AM
Subject: Re: [OAUTH-WG] Security concer= n for URI fragment as Implicit grant

> Shouldn=E2=80=99t it be more secure if we change to use a post method for access token, similar to the SAML does?
I say yes. But please note I'm very new at this and someone wi= th more experience will have more to say or correct my comments.
Here are a few more details to consider.
1) OAuth is a framework and not a standard, per se. Different authorization servers will have different implementations that are not necessarily compatible with other service providers. So there is no standard to break, per se.
2) Sensitive data in a URI is a bad idea. They leak all over the place even over HTTPS. Even in fragments.
3) Break the "rules" and find a way to submit sensitive = data like access tokens, session information or any other (even short term) sensitive data in a secure fashion. This includes POST, JSON data payloads over PUT/PATCH and other verbs - all over well configured HTTPS.
4) If you really must submit sensitive data over GET , consider JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level confidentiality and integrity.
Aloha,
Jim Manico
Manicode Security
https://www.manicode.com

On 6/27/16 9:30 PM, Liyu Yi wrote:
While we are working on a project with OAuth2 implementation, one question arises from our engineers.
=C2=A0=C2=A0
(C)=C2=A0 Assuming the resource owner grants access, the authorization
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 server redire= cts the user-agent back to the client using the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 redirection U= RI provided earlier.=C2=A0 The redirection URI includes
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the access to= ken in the URI fragment.
=C2=A0
For my understanding, the browser keeps the URI fragment in the history, and this introduces unexpected exposure of the access token. A user without authorization for the resource can get the access token as long as he has the access to the browser. This can happen in a shared computer in library, or for an IT staff who works on other employee=E2=80=99s computer.
=C2=A0
Shouldn=E2=80=99t it be more secure if we change to use a post method for access token, similar to the SAML does?
I feel there might be something I missed here. Any advices will be appreciated.


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


--=20




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


=


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


=

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



--001a11c02fe83dd52205369b04c4-- From nobody Wed Jul 6 07:55:33 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 637FD12B046 for ; Fri, 1 Jul 2016 16:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99I_Rb9lL3M5 for ; Fri, 1 Jul 2016 16:26:25 -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 10CD412B02B for ; Fri, 1 Jul 2016 16:26:25 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id e3so24790005qkd.0 for ; Fri, 01 Jul 2016 16:26:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oT5yNOsPOJEyk7idjYj3mft+ZLmhYLsD/DB8Jh0zXPQ=; b=QJrgq02WyYwJq6BPT7cXQOFshWHZg6kSIeBYcUG0JQlx+58iUbWrSrhaiHxMlig2Rs nMPUWkPAqDL9lvm8gqyr8Ekfp2aZTZjKhXUaLnvtW2JHKjAwFhb9+eB7X4Tpf+dBxGIl NNQFzAIdlwNGljKTxj0y4ogH6ir1YuqzZ1FGol6qa73malCAvLPPfJrgPoLteMoLbD1f cJPGOkgCpv9MF7zCG+daNItNkgDPfC7IO9be0vtWmQAAY/6OucxOsFtoRhT79Ix14P7s erthcfHNrboDxhAUB8T3bHHBaC4RWN5ub7of4EV1RVCDJJpMHTzrCVcmW5C3Mj0LCT3U Nxrg== 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=oT5yNOsPOJEyk7idjYj3mft+ZLmhYLsD/DB8Jh0zXPQ=; b=NMIOKkM+Qd0yf8BnfWGnKvf7QHNs+bKlRjF8AZGc7b9nAuSA/19T92D5w7m1O83Wg/ gR0wupQ7EbpMSNnRUTwqXfoRHRYv/MXjdCAqw0cRdOzcAT3bfmb7IZRDQo+hxfmesJHM nTL7hPXt4NXDPTaviWcxlT0zTlZJRj0T75uOOELIvOrNAorXyGasJeU+Aobfqc8E0AHG s7wQYBiYck4uYs6FWlTahDFjmVxonGbt4QEwKtlgbJi1XDCNrAu4vtzEvdtslXf+9zzV hjPEql51RVPygZyTwn0Z/ILNsbd+0QP1Z9NT7vzG8+mYmAUfPFYBV+OzpD8X6S0fBYQ+ yong== X-Gm-Message-State: ALyK8tIdcNbXoaeI2wrfNV7kPhKfIN9m+WAMEEvPxoqcy4Yal25DzDHDeof/D+l6Mrw1qqC9t+jd+4cL0E18JA== X-Received: by 10.129.82.135 with SMTP id g129mr471351ywb.163.1467415584109; Fri, 01 Jul 2016 16:26:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.80.13 with HTTP; Fri, 1 Jul 2016 16:26:22 -0700 (PDT) In-Reply-To: References: <994121658.55005.1467329084208.JavaMail.yahoo@mail.yahoo.com> <235316006.458279.1467392709447.JavaMail.yahoo@mail.yahoo.com> <6584BD74-B18F-4174-9E69-5C7B4B76F895@ve7jtb.com> <410908395.555462.1467407397629.JavaMail.yahoo@mail.yahoo.com> <8CC41328-C26D-42C0-BFDB-BF0216C7B76C@ve7jtb.com> <71CE61B3-FEC2-46A7-AB28-B53E89A8E53F@ve7jtb.com> From: Liyu Yi Date: Fri, 1 Jul 2016 16:26:22 -0700 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=001a114ddbaaa0f93605369b5048 Archived-At: X-Mailman-Approved-At: Wed, 06 Jul 2016 07:55:08 -0700 Cc: Oleg Gryb , "" Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 23:26:29 -0000 --001a114ddbaaa0f93605369b5048 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable John, I am a little bit confused :) Are you talking about a SPA type of client application and concerning the POST will reload the browser DOM from the RS domain? If that is the case, even the current spec using a redirect with fragment in URL will have the same behavior, right? On Fri, Jul 1, 2016 at 4:06 PM, John Bradley wrote: > I take it that Web-hosted client resource is part of the client. > > I think perhaps you have client and resource serve r mixed up a bit in > your diagram. > > Yes you could do that but it is not a great way to build the client as it > will blow away context. > You can do it but people generally want to start the application in the > browser first and then call out to the IdP in a iFrame. > > What you propose would work more or less. I don=E2=80=99t see it as a pa= ttern > that I would necessarily recommend over the current fragment encoding. > > If we mover to post message it would include API for logout and session > management, not just login. > > John B. > > > On Jul 1, 2016, at 6:43 PM, Liyu Yi wrote: > > Understood there is an Authorization Code grant type; here I am more > focusing on the Implicit grant type. > > also when I mentioned POST, I did not mean postMessage, it is simply the > HTTP POST. Specifically it is more like this ... > > > > 4.2 . Implicit Grant (m= odified) > > +----------+ > | Resource | > | Owner | > | | > +----------+ > ^ > | > (B) > +----|-----+ Client Identifier +---------------+ > | -+----(A)-- & Redirection URI --->| | > | User- | | Authorization | > | Agent -|----(B)-- User authenticates -->| Server | > | | | | > | |<---(C)- Response embedded JS -<| | > | | with Access Token +---------------+ > | | in JS content, which will be posted to Resou= rce Server > | | +---------------+ > | |----(D)-- JS post to RS URI --->| Web-Hosted | > | | with Access Token | Client | > | | | Resource | > | (F) |<---(E)----- RS Script --------<| | > | | with Access Token +---------------+ > +-|--------+ > | | > (A) (G) Access Token > | | > ^ v > +---------+ > | | > | Client | > | | > +---------+ > > > > Figure 4: Implicit Grant Flow > > > The flow illustrated in Figure 4 includes the following steps: > > (A) The client initiates the flow by directing the resource owner's > user-agent to the authorization endpoint. The client includes > its client identifier, requested scope, local state, and a > redirection URI to which the authorization server will send the > user-agent back once access is granted (or denied). > > (B) The authorization server authenticates the resource owner (via > the user-agent) and establishes whether the resource owner > grants or denies the client's access request. > > (C) Assuming the resource owner grants access, the authorization > server responds with a JavaScript logic which automatically posts= to > "redirection" URI provided earlier. The JavaScript includes > the access token in the URI fragment. > > (D) The user-agent does the post with the access token. Granted, > > user agent can actually do post without the access toke= n in a different iframe, > > then use postMessage to pass the token over, but I do n= ot see why get it need that compexity. > > > > On Fri, Jul 1, 2016 at 3:13 PM, Josh Mandel wrote: > >> Thanks John! Yes, we're following the CORS based flow you've described >> below (though I should note that the actual redirection back to the clie= nt >> could be a 302, or could be a simple Web link that the user follows from= an >> authorization page; this is up to the authorization server). >> >> Overall I don't argue that this flow is "more secure" than the implicit >> flow -- though I believe it does help client developers avoid some commo= n >> pitfalls. (For example, clients that, through careless programming or po= or >> understanding of the spec, fail to validate incoming "state" are still n= ot >> susceptible to arbitrary token injection, which means at least they won'= t >> readily be tricked into using a token designated for an entirely differe= nt >> client. With poorly written implicit flow clients, this is an issue.) >> >> That said, I wasn't aiming to discuss the relative security; just wanted >> to make sure I knew what you meant by "won't work well". >> >> Thanks again! >> >> -Josh >> On Jul 1, 2016 18:02, "John Bradley" wrote: >> >>> I am making a distinction between a browser talking to a Web server tha= t >>> is acting as a OAuth Client POST response mode =3D good , and a oauth c= lient >>> running in the browser user agent as a Java script application (that ca= n=E2=80=99t >>> directly capture a POST response back to the server) >>> >>> So it depends on where the client is actually running. >>> >>> Are you saying that you are using a 302 redirect from the authorization >>> endpoint back to the server hosting the JS and then loading the JS >>> including the code and then using CORES to exchange the code for a AT? >>> >>> You can do that but I don=E2=80=99t think a public client like that is = more >>> secure than just using the fragment encoded response and is more work. >>> It also may give the server a false sense of security. >>> >>> John B. >>> >>> On Jul 1, 2016, at 5:52 PM, Josh Mandel wrote: >>> >>> I think the confusion here is that I'm not using HEART's OAuth profiles >>> :-) >>> >>> I'm using the SMART profiles, where we do specify the use of an >>> authorization code grant even for browser-based public clients (in whic= h >>> case, no client_secret is issued or used). I'm just trying to understan= d >>> your perspective eon why this "won't work well". Perhaps you didn't mea= n >>> this comment to refer to browser-based OAuth clients generally? >>> >>> -Josh >>> >>> On Fri, Jul 1, 2016 at 5:45 PM, John Bradley wrote: >>> >>>> I don=E2=80=99t think the post response mode is supported by heart so = I suspect >>>> that we are talking about different things. >>>> >>>> You are probably using the supported code flow that uses a 302 get to >>>> return the code to the OAuth client on the server. >>>> The Web server is then acting as a confidential client to exchange the >>>> code via a POST (different POST) with the AS token_endpoint. >>>> >>>> The Token endpoint will return a access token (AT) and optional refres= h >>>> token (RT). >>>> >>>> The web page may be getting the server to make the OAuth calls on it= =E2=80=99s >>>> behalf to the Resource Server, or possibly you are passing the AT from= the >>>> server back to a Java script app that is using CORES to make calls dir= ectly >>>> to the RS without going through the Web server. >>>> >>>> Passing the AT back to the user agent from the client is not >>>> recommended. >>>> >>>> For in browser clients where the JS is using the AT to make the calls >>>> directly to the RS via CORES the recommended approach is to use the >>>> fragment encoded response via a 302 to deliver the AT directly to the >>>> client (It never hits the backend Web server). >>>> >>>> However I believe In browser OAuth clients are not currently supported >>>> in HEART, so I am not quite sure what you are doing. >>>> >>>> Perhaps Justin has a better answer. >>>> >>>> John B. >>>> >>>> >>>> On Jul 1, 2016, at 5:33 PM, Josh Mandel wrote: >>>> >>>> John, >>>> >>>> I appreciate your response. I'm hoping you can clarify why you say tha= t >>>> "HTTP POST... won't work well for... [a] single page OAuth client"? >>>> >>>> We commonly build single-page apps that act as OAuth clients for SMART >>>> (e.g. this sample app >>>> ), >>>> and we've had good experience with the technique. Could you elaborate? >>>> >>>> -J >>>> >>>> On Fri, Jul 1, 2016 at 5:26 PM, John Bradley wrote= : >>>> >>>>> HEART only supports web server clients at the moment. That might >>>>> change in future to support native apps if that an be made to support= the >>>>> security requirements of Heath IT. >>>>> >>>>> So the thing HTTP POST responses won=E2=80=99t work well for is a typ= e of in >>>>> browser single page OAuth client. That still needs fragment encoded >>>>> responses or the new post-message Java Script API approach. >>>>> >>>>> John B. >>>>> >>>>> >>>>> On Jul 1, 2016, at 5:16 PM, Josh Mandel wrote: >>>>> >>>>> Thanks Justin, >>>>> >>>>> To clarify: John's comment and my question were about POST. (I do >>>>> understand the behavior of HTTP POST and of window.postMessage; these= are >>>>> totally different things.) From my perspective in SMART Health IT, we= use >>>>> the OAuth 2.0 authorization code flow, including HTTP POST, in our au= thorization >>>>> spec even for public >>>>> clients, and it has worked very well for us, with about a dozen elect= ronic >>>>> health record servers supporting this approach. That's why I was curi= ous to >>>>> hear John's perspective about limitations. >>>>> >>>>> -J >>>>> >>>>> On Fri, Jul 1, 2016 at 5:09 PM, Oleg Gryb wrote= : >>>>> >>>>>> > POST will send things to the server, which isn=E2=80=99t desirable= if your >>>>>> client is solely in the browser >>>>>> Why it's not desirable, assuming that we disregard performance? You >>>>>> can generate HTTP POST from JS, e.g. through an AJAX call. What is w= rong >>>>>> with this? >>>>>> >>>>>> >>>>>> ------------------------------ >>>>>> *From:* Justin Richer >>>>>> *To:* Josh Mandel >>>>>> *Cc:* Oleg Gryb ; "" ; >>>>>> Liyu Yi >>>>>> *Sent:* Friday, July 1, 2016 2:00 PM >>>>>> >>>>>> *Subject:* Re: [OAUTH-WG] Security concern for URI fragment as >>>>>> Implicit grant >>>>>> >>>>>> POST will send things to the server, which isn=E2=80=99t desirable i= f your >>>>>> client is solely in the browser. postMessage is a browser API and no= t to be >>>>>> confused with HTTP POST. postMessage messages stay (or can stay) wit= hin the >>>>>> browser, which is the intent here. >>>>>> >>>>>> =E2=80=94 Justin >>>>>> >>>>>> On Jul 1, 2016, at 4:56 PM, Josh Mandel wrote: >>>>>> >>>>>> John, >>>>>> >>>>>> Could you clarify what you mean by "POST doesn't really work"? Do >>>>>> you just mean that CORS support (e.g., http://caniuse.com/#feat=3Dco= rs) >>>>>> isn't universal, or something more? >>>>>> >>>>>> On Fri, Jul 1, 2016 at 4:51 PM, John Bradley >>>>>> wrote: >>>>>> >>>>>> Yes but POST doesn't really work for in browser apps. >>>>>> >>>>>> If it is a server app it should be using the code flow with GET or >>>>>> POST as you like. >>>>>> >>>>>> If we do a post message based binding it will be targeted at in >>>>>> browser applications. >>>>>> >>>>>> John B. >>>>>> >>>>>> On Fri, Jul 1, 2016 at 4:42 PM, Liyu Yi wrote: >>>>>> >>>>>> BTW, I do not see any significant performance concerns for post. >>>>>> Parsing and executing the Javascript logic for post operation will b= e on >>>>>> the client side, no extra server load is introduced. >>>>>> >>>>>> Plus post will remove the size restriction of the URL length. >>>>>> >>>>>> -- Liyu >>>>>> >>>>>> On Fri, Jul 1, 2016 at 1:35 PM, Liyu Yi wrote: >>>>>> >>>>>> Thanks for the great comments and advices. >>>>>> >>>>>> I think it is a good idea for the working group to revise the >>>>>> fragment part in the spec, since there might be public available too= ls >>>>>> already implemented this approach and people can end up with a solut= ion >>>>>> with serious security loopholes. >>>>>> >>>>>> The re-append issue can be mitigate by a logic on Resource Server >>>>>> which carefully re-writes/removes the fragment in any redirect, if t= he the >>>>>> redirect can not be avoided. >>>>>> >>>>>> -- Liyu >>>>>> >>>>>> >>>>>> On Fri, Jul 1, 2016 at 11:33 AM, John Bradley >>>>>> wrote: >>>>>> >>>>>> This behaviour started changing around 2011 >>>>>> >>>>>> From HTTP/1.1 >>>>>> See https://tools.ietf.org/html/rfc7231#section-7.1.2I >>>>>> f the Location value provided in a 3xx (Redirection) response >>>>>> does >>>>>> >>>>>> not have a fragment component, a user agent MUST process the >>>>>> redirection as if the value inherits the fragment component of th= e >>>>>> URI reference used to generate the request target (i.e., the >>>>>> redirection inherits the original reference's fragment, if any). >>>>>> >>>>>> For example, a GET request generated for the URI reference >>>>>> "http://www.example.org/~tim" might result in a 303 (See Other) >>>>>> response containing the header field: >>>>>> >>>>>> Location: /People.html#tim >>>>>> >>>>>> which suggests that the user agent redirect to >>>>>> "http://www.example.org/People.html#tim=E2=80=9D >>>>>> >>>>>> >>>>>> Likewise, a GET request generated for the URI reference >>>>>> "http://www.example.org/index.html#larry" might result in a 301 >>>>>> (Moved Permanently) response containing the header field: >>>>>> >>>>>> Location: http://www.example.net/index.html >>>>>> >>>>>> which suggests that the user agent redirect to >>>>>> "http://www.example.net/index.html#larry", preserving the origina= l >>>>>> fragment identifier. >>>>>> >>>>>> >>>>>> >>>>>> This blog also explores the change. >>>>>> >>>>>> https://blogs.msdn.microsoft.com/ieinternals/2011/05/16/url-fragment= s-and-redirects/ >>>>>> >>>>>> >>>>>> On Jul 1, 2016, at 1:05 PM, Oleg Gryb wrote: >>>>>> >>>>>> "Browsers now re-append fragments across 302 redirects unless they >>>>>> are explicitly cleared this makes fragment encoding less safe than i= t was >>>>>> when originally specified" - thanks Jim. Looks like a good reason f= or >>>>>> vetting this flow out. >>>>>> >>>>>> John, >>>>>> Please provide more details/links about re-appending fragments. >>>>>> >>>>>> Thanks, >>>>>> Oleg. >>>>>> >>>>>> >>>>>> ------------------------------ >>>>>> *From:* Jim Manico >>>>>> *To:* Oleg Gryb >>>>>> *Cc:* "oauth@ietf.org" ; Liyu Yi >>>>>> *Sent:* Thursday, June 30, 2016 10:25 PM >>>>>> *Subject:* Re: [OAUTH-WG] Security concern for URI fragment as >>>>>> Implicit grant >>>>>> >>>>>> Oleg! Hello! Great to see you pop up here with a similar concern. >>>>>> >>>>>> John Bradley just answered this thread with the details I was lookin= g >>>>>> for (thanks John, hat tip your way). >>>>>> >>>>>> He also mentioned details about fragment leakage: >>>>>> >>>>>> "Browsers now re-append fragments across 302 redirects unless they >>>>>> are explicitly cleared this makes fragment encoding less safe than i= t was >>>>>> when originally specified" >>>>>> >>>>>> Again, I'm new here but I'm grateful for this conversation. >>>>>> >>>>>> Aloha, >>>>>> -- >>>>>> Jim Manico >>>>>> @Manicode >>>>>> >>>>>> On Jul 1, 2016, at 1:24 AM, Oleg Gryb wrote: >>>>>> >>>>>> We've discussed access tokens in URI back in 2010 ( >>>>>> https://www.ietf.org/mail-archive/web/oauth/current/msg04043.html). >>>>>> There were two major objectives when I was saying that it's not secu= re: >>>>>> >>>>>> 1. Fragment is not sent to a server by a browser. When I've asked if >>>>>> this is true for every browser in the world, nobody was able to answ= er. >>>>>> 2. Replacing with POST would mean a significant performance impact i= n >>>>>> some high volume implementations (I think it was Goole folks who wer= e >>>>>> saying this, but I don't remember now). >>>>>> >>>>>> AFAIR, nobody was arguing about browsing history, so it's valid. >>>>>> >>>>>> So, 6 years later we're at square one with this and I hope that this >>>>>> time the community will be more successful with getting rid of secre= ts in >>>>>> URL. >>>>>> >>>>>> BTW, Jim, if you can come up with other scenarios when fragments can >>>>>> leak, please share. It'll probably help the community with solving t= his >>>>>> problem faster than in 6 years. >>>>>> >>>>>> Thanks, >>>>>> Oleg. >>>>>> >>>>>> >>>>>> ------------------------------ >>>>>> *From:* Jim Manico >>>>>> *To:* Liyu Yi ; oauth@ietf.org >>>>>> *Sent:* Wednesday, June 29, 2016 7:30 AM >>>>>> *Subject:* Re: [OAUTH-WG] Security concern for URI fragment as >>>>>> Implicit grant >>>>>> >>>>>> > Shouldn=E2=80=99t it be more secure if we change to use a post met= hod for >>>>>> access token, similar to the SAML does? >>>>>> I say yes. But please note I'm very new at this and someone with mor= e >>>>>> experience will have more to say or correct my comments. >>>>>> Here are a few more details to consider. >>>>>> 1) OAuth is a framework and not a standard, per se. Different >>>>>> authorization servers will have different implementations that are n= ot >>>>>> necessarily compatible with other service providers. So there is no >>>>>> standard to break, per se. >>>>>> 2) Sensitive data in a URI is a bad idea. They leak all over the >>>>>> place even over HTTPS. Even in fragments. >>>>>> 3) Break the "rules" and find a way to submit sensitive data like >>>>>> access tokens, session information or any other (even short term) se= nsitive >>>>>> data in a secure fashion. This includes POST, JSON data payloads ove= r >>>>>> PUT/PATCH and other verbs - all over well configured HTTPS. >>>>>> 4) If you really must submit sensitive data over GET , consider >>>>>> JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level >>>>>> confidentiality and integrity. >>>>>> Aloha, >>>>>> >>>>>> Jim Manico >>>>>> Manicode Securityhttps://www.manicode.com >>>>>> >>>>>> >>>>>> On 6/27/16 9:30 PM, Liyu Yi wrote: >>>>>> >>>>>> While we are working on a project with OAuth2 implementation, one >>>>>> question arises from our engineers. >>>>>> We noticed at >>>>>> >>>>>> https://tools.ietf.org/html/draft-ietf-oauth-v2-31#page-30, it is >>>>>> specified that >>>>>> >>>>>> (C) Assuming the resource owner grants access, the authorization >>>>>> server redirects the user-agent back to the client using the >>>>>> redirection URI provided earlier. The redirection URI >>>>>> includes >>>>>> the access token in the URI fragment. >>>>>> >>>>>> For my understanding, the browser keeps the URI fragment in the >>>>>> history, and this introduces unexpected exposure of the access token= . A >>>>>> user without authorization for the resource can get the access token= as >>>>>> long as he has the access to the browser. This can happen in a share= d >>>>>> computer in library, or for an IT staff who works on other employee= =E2=80=99s >>>>>> computer. >>>>>> >>>>>> Shouldn=E2=80=99t it be more secure if we change to use a post metho= d for >>>>>> access token, similar to the SAML does? >>>>>> I feel there might be something I missed here. Any advices will be >>>>>> appreciated. >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinf= o/oauth >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> >>>>> >>>> >>>> >>> >>> > > --001a114ddbaaa0f93605369b5048 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
John,

I am a little bit confused :)
Are you talking about a SPA type of client application and concernin= g the POST will reload the browser DOM from the RS domain? If that is the c= ase, even the current spec using a redirect with fragment in URL will have = the same behavior, right? =C2=A0

=
On Fri, Jul 1, 2016 at 4:06 PM, John Bradley <v= e7jtb@ve7jtb.com> wrote:
I take it that Web-hosted client resource= is part of the client.

I think perhaps you have client = and resource serve r mixed up a bit in your diagram.

Yes you could do that but it is not a great way to build the client as i= t will blow away context. =C2=A0
You can do it but people general= ly want to start the application in the browser first and then call out to = the IdP =C2=A0in a iFrame.

What you propose would = work more or less.=C2=A0 I don=E2=80=99t see it as a pattern that I would n= ecessarily recommend over the current fragment encoding.

If we mover to post message it would include API =C2=A0for logout an= d session management, not just login.

John B.


On Jul 1, 2016, at 6:43 PM, Liyu Yi <liyuyi@gmail.com> wrote:

<= div dir=3D"ltr">
Understood there is an Authorization Code grant type; = here I am more focusing on the Implicit grant type.=C2=A0
=C2=A0= =C2=A0
also when I mentioned POST, I did not mean postMessage, it= is simply the HTTP POST. Specifically it is more like this ...
<= br>


4.2.  Implicit Grant (modified)



 =
    +----------+
     | Resource |
     |  Owner   |
     |          |
     +----------+
          ^
          |
         (B)
     +----|-----+          Client Identifier     +---------------+
     |         -+----(A)-- & Redirection URI --->|               |
     |  User-   |                                | Authorization |
     |  Agent  -|----(B)-- User authenticates -->|     Server    |
     |          |                                |               |
     |          |<---(C)- Response embedded JS -<|               |
     |          |          with Access Token     +---------------+
     |          |            in JS content, which will be posted to Resourc=
e Server
     |          |                                +---------------+
     |          |----(D)-- JS post to RS URI --->|   Web-Hosted  |
     |          |         with Access Token      |     Client    |
     |          |                                |    Resource   |
     |     (F)  |<---(E)----- RS Script --------<|               |
     |          |         with Access Token      +---------------+
     +-|--------+
       |    |
      (A)  (G) Access Token
       |    |
       ^    v
     +---------+
     |         |
     |  Client |
     |         |
     +---------+



                       Figure 4: Implicit Grant Flow


 =
  The flow illustrated in Figure 4 includes the following steps:

   (A)  The client initiates the flow by directing the resource owner's
        user-agent to the authorization endpoint.  The client includes
        its client identifier, requested scope, local state, and a
        redirection URI to which the authorization server will send the
        user-agent back once access is granted (or denied).

   (B)  The authorization server authenticates the resource owner (via
        the user-agent) and establishes whether the resource owner
        grants or denies the client's access request.

   (C)  Assuming the resource owner grants access, the authorization
        server responds with a JavaScript logic which automatically posts t=
o=20
        "redirection" URI provided earlier.  The JavaScript inclu=
des
        the access token in the URI fragment.

   (D)  The user-agent does the post with the access token. Granted,
u= ser agent can actually do post without the access token in a different iframe= , 
  =
                then use postMessage to pass the token over, but I do not s=
ee why get it need that compexity.


On Fri, Jul 1, 2016 at 3:13 PM= , Josh Mandel <jmandel@gmail.com> wrote:

Thanks John! Yes, we're following the COR= S based flow you've described below (though I should note that the actu= al redirection back to the client could be a 302, or could be a simple Web = link that the user follows from an authorization page; this is up to the au= thorization server).

Overall I don't argue that this= flow is "more secure" than the implicit flow -- though I believe= it does help client developers avoid some common pitfalls. (For example, c= lients that, through careless programming or poor understanding of the spec= , fail to validate incoming "state" are still not susceptible to = arbitrary token injection, which means at least they won't readily be t= ricked into using a token designated for an entirely different client. With= poorly written implicit flow clients, this is an issue.)

That said, I wasn't aiming to discuss the relative security; just wan= ted to make sure I knew what you meant by "won't work well".<= /p>

Thanks again!

-Josh

On Jul 1, 2016 18:02, "John Bradley" &= lt;ve7jtb@ve7jtb.com= > wrote:
I am making a distinction between a browser= talking to a Web server that is acting as a OAuth Client POST response mod= e =3D good , and a oauth client running in the browser user agent as a Java= script application (that can=E2=80=99t directly capture a POST response ba= ck to the server)

So it depends on where the client is a= ctually running.

Are you saying that you are using= a 302 redirect from the authorization endpoint back to the server hosting = the JS and then loading the JS including the code and then using CORES =C2= =A0to exchange the code for a AT?

You can do that = but I don=E2=80=99t think a public client like that is more secure than jus= t using the fragment encoded response and is more work.
It also m= ay give the server a false sense of security.

John= B.
On Jul 1, 2016, at 5:52 PM, Josh= Mandel <jmandel@= gmail.com> wrote:

I think the confusi= on here is that I'm not using HEART's OAuth profiles :-)

I'm using the SMART profiles, where we do specify the use of a= n authorization code grant even for browser-based public clients (in which = case, no client_secret is issued or used). I'm just trying to understan= d your perspective eon why this "won't work well". Perhaps yo= u didn't mean this comment to refer to browser-based OAuth clients gene= rally?

=C2=A0 -Josh

On Fri, Jul 1, 2016 at 5:45 PM, John Bradl= ey <ve7jtb@ve7jtb.com> wrote:
I don=E2=80=99t think the post resp= onse mode is supported by heart so I suspect that we are talking about diff= erent things.

You are probably using the supported code = flow that uses a 302 get to return the code to the OAuth client on the serv= er. =C2=A0
The Web server is then acting as a confidential client= to exchange the code via a POST (different POST) with the AS token_endpoin= t.

The Token endpoint will return a access token (= AT) and optional refresh token (RT).

The web page = may be getting the server to make the OAuth calls on it=E2=80=99s behalf to= the Resource Server, or possibly you are passing the AT from the server ba= ck to a Java script app that is using CORES to make calls directly to the R= S without going through the Web server.

Passing th= e AT back to the user agent from the client is not recommended.=C2=A0
=

For in browser clients where the JS is using the AT to = make the calls directly to the RS via CORES the recommended approach is to = use the fragment encoded response via a 302 to deliver the AT directly to t= he client (It never hits the backend Web server).

= However I believe In browser OAuth clients are not currently supported in H= EART, so I am not quite sure what you are doing.

P= erhaps Justin has a better answer.

John B.


On Jul = 1, 2016, at 5:33 PM, Josh Mandel <jmandel@gmail.com> wrote:

John,

I appreciate your response. I'm hoping y= ou can clarify why you say that "HTTP POST... won't work well for.= .. [a] single page OAuth client"?

We commonly build= single-page apps that act as OAuth clients for SMART (e.g. this sample app=C2=A0), and we= 've had good experience with the technique. Could you elaborate?
<= div>
=C2=A0 -J

On Fri, Jul 1, 2016 at 5:26 PM, John Bradley <ve7jtb@ve7j= tb.com> wrote:
HEART only supports web server clients at the mom= ent. =C2=A0 That might change in future to support native apps if that an b= e made to support the security requirements of Heath IT.

So th= e thing HTTP POST responses won=E2=80=99t work well for is a type of in bro= wser single page OAuth client.=C2=A0 That still needs fragment encoded resp= onses or the new post-message Java Script API approach.

John B.


On Jul 1, 2016, at 5:16 PM, Josh Mandel <jmandel@gmail.com> wrote:
Thanks Justin,

To clarify: J= ohn's comment and my question were about POST. (I do understand the beh= avior of HTTP POST and of window.postMessage; these are totally different t= hings.) From my perspective in SMART Health IT, we use the OAuth 2.0 author= ization code flow, including HTTP POST, in our authorization spec=C2=A0= even for public clients, and it has worked very well for us, with about a d= ozen electronic health record servers supporting this approach. That's = why I was curious to hear John's perspective about limitations.

=C2=A0 -J

On Fri, Jul 1, 2016 at 5:09 PM, Oleg Gryb <oleg_gryb@ya= hoo.com> wrote:
> POST will se= nd things to the server, which isn=E2=80=99t desirable if your client is so= lely in the browser
Why it's not desirable= , assuming that we disregard performance? You can generate HTTP POST from J= S, e.g. through an AJAX call. What is wrong with this?
=


From: Justin Richer <jricher@mit.edu>
To: Josh Mandel <jmandel@gmail.com>
Cc: Oleg Gryb <oleg@gryb.info>; "<oauth@ietf.org>" <oauth@ietf.org>; Liyu Yi <liyuyi@gmail.com> Sent: Friday, July 1, 2016= 2:00 PM

Subject:<= /b> Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant
=

POST will send thin= gs to the server, which isn=E2=80=99t desirable if your client is solely in= the browser. postMessage is a browser API and not to be confused with HTTP= POST. postMessage messages stay (or can stay) within the browser, which is= the intent here.

=C2=A0=E2=80=94 Justin<= /div>

On Ju= l 1, 2016, at 4:56 PM, Josh Mandel <jmandel@gmail.com>= ; wrote:

=
John,

Co= uld you clarify what you mean by "POS= T doesn't really work"? Do you just mean that CORS support (e.g.,= =C2=A0http://caniuse.com/#feat=3Dcors) isn't u= niversal, or something more?

On Fr= i, Jul 1, 2016 at 4:51 PM, John Bradley <v= e7jtb@ve7jtb.com> wrote:
Yes but POST doesn't really work for in browser apps.

If it is a server app it should be using the code= flow with GET or POST as you like.

If we do a =C2=A0post message based binding it will be targeted at in brow= ser applications.

John B.

On Fri, Jul 1, 2016 at 4:42 PM, Liyu Yi <liyuyi@gmail.com> wrote:
BTW, I do not see any significant perf= ormance concerns for post. Parsing and executing the Javascript logic for p= ost operation will be on the client side, no extra server load is introduce= d.

Plus post will remove the size restric= tion of the URL length.

-- Liyu=C2=A0
On Fri, Jul 1, 2016 at 1:35 PM, Liyu Yi <liyuyi@gmail.com> wrote:
Thanks for the great comments and advices.=

I think it is a good idea for the worki= ng group to revise the fragment part in the spec, since there might be publ= ic available tools already implemented this approach and people can end up = with a solution with serious security loopholes.

The re-append issue can be mitigate by a logic on Resource Server w= hich carefully re-writes/removes the fragment in any redirect, if the the r= edirect can not be avoided.

-- Liyu
=C2=A0

On Fri, Jul 1, 20= 16 at 11:33 AM, John Bradley <ve7jtb@ve7jt= b.com> wrote:
This behaviour started changing around 2011

From HTTP/1.1
=C2=A0 =C2=A0 =C2=A0 f the Location value provided in a 3xx (Redi= rection) response does
   not have a fragment compo=
nent, a user agent MUST process the
   redirection as if the value inherits the fragment component of the
   URI reference used to generate the request target (i.e., the
   redirection inherits the original reference's fragment, if any).

   For example, a GET request generated for the URI reference
   "http://www.example.org/~tim" might result =
in a 303 (See Other)
   response containing the header field:

     Location: /People.html#tim

   which suggests that the user agent redirect to
   "http://www.example.org/People.html#tim=E2=80=9D

   L=
ikewise, a GET request generated for the URI reference
   "http://www.example.org/index.html#larry=
" might result in a 301
   (Moved Permanently) response containing the header field:

     Location: http://www.example.net/index.html

   which suggests that the user agent redirect to
   "http://www.example.net/index.html#larry=
", preserving the original
   fragment identifier.


This blog also explores the change.


On Jul 1, 2016, at 1:05 PM, Oleg Gryb <ole= g_gryb@yahoo.com> wrote:

"Browsers now re-append =C2=A0fragments across 302 redirects unle= ss they are explicitly cleared this makes fragment encoding less safe than = it was =C2=A0when originally specified" - thanks Jim. Looks like a goo= d reason for vetting this flow out.

John,
Please provide more details/links about re-ap= pending fragments.=C2=A0

Thanks,
Oleg.


=
From: Jim M= anico <jim@manicode.com>
To: Oleg Gryb <oleg@gryb.i= nfo>
Cc: "oauth@ietf.org" <oauth@ietf.org<= /a>>; Liyu Yi <liyuyi@gmail.com>
= Sent: Thursday, June 30, 20= 16 10:25 PM
Subject:= Re: [OAUTH-WG] Security concern for URI fragment as Implicit gr= ant

Oleg!= Hello! Great to see you pop up here with a similar concern.

John Bradley just answered this thread with the d= etails I was looking for (thanks John, hat tip your way).

He also mentioned details about fragment leakage:

"Browsers now re-append = =C2=A0fragments across 302 redirects unless they are explicitly cleared thi= s makes fragment encoding less safe than it was when originally specified&q= uot;

Again, I'm new here= but I'm grateful for this conversation.

<= /div>
Aloha,
--
Jim Manico
@Manicode=

On Jul 1, 2016, at 1:24 AM, Oleg G= ryb <oleg_gryb@yahoo.com> wrote:
=
We've discusse= d access tokens in URI back in 2010 (https://www.ietf.org/mail-archive/web/oauth/current/m= sg04043.html). There were two major objectives when I was saying that i= t's not secure:

1. Fragment is not sent to a server by a browser. When I've as= ked if this is true for every browser in the world, nobody was able to answ= er.
2. Replacing with POST would mean a significant p= erformance impact in some high volume implementations (I think it was Goole= folks who were saying this, but I don't remember now).

AFAIR, nobody was arguin= g about browsing history, so it's valid.

So, 6 years later we're at square one= with this and I hope that this time the community will be more successful = with getting rid of secrets in URL.

BTW, Jim, if you can come up with other scenarios = when fragments can leak, please share. It'll probably help the communit= y with solving this problem faster than in 6 years.
<= br clear=3D"none">
Thanks,
Oleg= .


<= span style=3D"font-weight:bold">From: Jim Manico <= jim@manicode.com>
To: Liyu Yi <liyuyi@gmail.com>; oauth@ietf.org
Sent: Wednesday, June 29, 2016 7:30 AM
= Subject: Re: [OAUTH-WG] Securit= y concern for URI fragment as Implicit grant

> Shouldn=E2=80=99t it be more secure if we change to use a post method for access token, similar to the SAML does?
I say yes. But please note I'm very new at this and someone wi= th more experience will have more to say or correct my comments.
Here are a few more details to consider.
1) OAuth is a framework and not a standard, per se. Different authorization servers will have different implementations that are not necessarily compatible with other service providers. So there is no standard to break, per se.
2) Sensitive data in a URI is a bad idea. They leak all over the place even over HTTPS. Even in fragments.
3) Break the "rules" and find a way to submit sensitive = data like access tokens, session information or any other (even short term) sensitive data in a secure fashion. This includes POST, JSON data payloads over PUT/PATCH and other verbs - all over well configured HTTPS.
4) If you really must submit sensitive data over GET , consider JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level confidentiality and integrity.
Aloha,
Jim Manico
Manicode Security
https://www.manicode.com

On 6/27/16 9:30 PM, Liyu Yi wrote:
While we are working on a project with OAuth2 implementation, one question arises from our engineers.
=C2=A0=C2=A0
(C)=C2=A0 Assuming the resource owner grants access, the authorization
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 server redire= cts the user-agent back to the client using the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 redirection U= RI provided earlier.=C2=A0 The redirection URI includes
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the access to= ken in the URI fragment.
=C2=A0
For my understanding, the browser keeps the URI fragment in the history, and this introduces unexpected exposure of the access token. A user without authorization for the resource can get the access token as long as he has the access to the browser. This can happen in a shared computer in library, or for an IT staff who works on other employee=E2=80=99s computer.
=C2=A0
Shouldn=E2=80=99t it be more secure if we change to use a post method for access token, similar to the SAML does?
I feel there might be something I missed here. Any advices will be appreciated.


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


--=20




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


=





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


_______________________________________________
OAuth mai= ling list
OAuth@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">ht= tps://www.ietf.org/mailman/listinfo/oauth


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



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





--001a114ddbaaa0f93605369b5048-- From nobody Wed Jul 6 07:55:46 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9B912B043 for ; Fri, 1 Jul 2016 18:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.697 X-Spam-Level: X-Spam-Status: No, score=-2.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, 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=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBeR_ZEKWEUj for ; Fri, 1 Jul 2016 18:11:05 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A0BB12B01B for ; Fri, 1 Jul 2016 18:11:04 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id l125so1089335ywb.2 for ; Fri, 01 Jul 2016 18:11:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HuUzkVR+j9z0BJrERw+b/Ozr1ZNkaUWeP9TemmYL+kg=; b=uPP37vdvQP0PYrdr5BtmY0b5PUjPztAXKghO82Tn12+/unJRh6UyxJEDKb9erdNb+V N7mfSk9MwC2QMasPW/g0yMK7Gj7ZPL4chj4PVyG4/Tobd3ggQdZ69XtqC41MoGG4N2qS 46S4h/ljvtmrIpJu8s4lElu4ekS81jsr1pPf91isqa7VVkCdRwELmxNf01TspmuTBpYQ vB2twmlfoUf+5so3zmVroGx9zNhTiJER3u668VwE569K+gbmyM5lNojKvRQGZYTmEeCm MXvK/9IUkH+ntcE7L+H+ncJSg86odTkMoBK084RgivhwL/n8y3aeLJMfv7tbOccy8qUJ mgng== 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=HuUzkVR+j9z0BJrERw+b/Ozr1ZNkaUWeP9TemmYL+kg=; b=ihWV8KUSEsxVXZUGVhHYk3CBuJ7pq6/IFvO9UjfSUjgVqofTr/ipsh8CIovTjhW+AQ N7AjLEfS/0jTDhtSMKwjYoI2wAALrFjpeImmXrrYvDK02V51BAonhO/StcTrhoC4Mlis 7STPuOk2qRpxvxa9jLpXJHPeMSYHmF+ub+2TixZ4w/Lw5bnMBjNSwTRWyxtR1Ispu7Cm poO0zO8YX7e4zGWg/K5+GvD4UzFWKjFUnDtssin9Nej3kkAgZEkIiQAzECLO2NU2TrG2 bG7ioHD5mJMkrpuPeoohVmu65rhdfqZQZhfme/nrat1SE+a8nB1dHBj9ucZUx8DYLUwK ozGA== X-Gm-Message-State: ALyK8tK3/5u6fPa80PJN8iP/qTXQsBB9HX3WGyO+/zBXMRe1tI3BMfFUvU+GnnXf2S9jfCSIhiuY/8NodW3DOA== X-Received: by 10.37.80.13 with SMTP id e13mr651021ybb.162.1467421863339; Fri, 01 Jul 2016 18:11:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.80.13 with HTTP; Fri, 1 Jul 2016 18:11:01 -0700 (PDT) In-Reply-To: <50E491F2-E08F-40A7-B9DE-AB50CB647C04@ve7jtb.com> References: <994121658.55005.1467329084208.JavaMail.yahoo@mail.yahoo.com> <235316006.458279.1467392709447.JavaMail.yahoo@mail.yahoo.com> <6584BD74-B18F-4174-9E69-5C7B4B76F895@ve7jtb.com> <410908395.555462.1467407397629.JavaMail.yahoo@mail.yahoo.com> <8CC41328-C26D-42C0-BFDB-BF0216C7B76C@ve7jtb.com> <71CE61B3-FEC2-46A7-AB28-B53E89A8E53F@ve7jtb.com> <560704570.608692.1467419971908.JavaMail.yahoo@mail.yahoo.com> <50E491F2-E08F-40A7-B9DE-AB50CB647C04@ve7jtb.com> From: Liyu Yi Date: Fri, 1 Jul 2016 18:11:01 -0700 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=001a113e8bfee67dce05369cc6fb Archived-At: X-Mailman-Approved-At: Wed, 06 Jul 2016 07:55:08 -0700 Cc: Oleg Gryb , "" Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2016 01:11:09 -0000 --001a113e8bfee67dce05369cc6fb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I would say AT is supposed to be consumed by the Resource Server. Although the original spec does not show how AT is used by the client, but the AT will be sent out, most likely by the browser directly, or in a rare case if the client application has another channel, indirectly. The fact is that the AT is not sent in the 1st GET request does leave the RS JavaScript a chance to choose the right method, say an ajax POST. But AT is NOT a secrete to RS. On Fri, Jul 1, 2016 at 5:53 PM, John Bradley wrote: > yes > > On Jul 1, 2016, at 8:39 PM, Oleg Gryb wrote: > > I think, the intention was not to share AT with the web-hosted client > resource. As you can see in the original flow the latter never receives t= he > AT, it simply provides code that can get AT from a fragment and some UI. = In > the modified flow AT is sent to the web-hosted client resource, which mak= es > security worse in my view, because you have your AT exposed in two places > now - in the User Agent *and* in the web-hosted client resource. > > > > ------------------------------ > *From:* John Bradley > *To:* Liyu Yi > *Cc:* Oleg Gryb ; "" > *Sent:* Friday, July 1, 2016 4:06 PM > *Subject:* Re: [OAUTH-WG] Security concern for URI fragment as Implicit > grant > > I take it that Web-hosted client resource is part of the client. > > I think perhaps you have client and resource serve r mixed up a bit in > your diagram. > > Yes you could do that but it is not a great way to build the client as it > will blow away context. > You can do it but people generally want to start the application in the > browser first and then call out to the IdP in a iFrame. > > What you propose would work more or less. I don=E2=80=99t see it as a pa= ttern > that I would necessarily recommend over the current fragment encoding. > > If we mover to post message it would include API for logout and session > management, not just login. > > John B. > > > On Jul 1, 2016, at 6:43 PM, Liyu Yi wrote: > > Understood there is an Authorization Code grant type; here I am more > focusing on the Implicit grant type. > > also when I mentioned POST, I did not mean postMessage, it is simply the > HTTP POST. Specifically it is more like this ... > > > > 4.2 . Implicit Grant > (modified) > > +----------+ > | Resource | > | Owner | > | | > +----------+ > ^ > | > (B) > +----|-----+ Client Identifier +---------------+ > | -+----(A)-- & Redirection URI --->| | > | User- | | Authorization | > | Agent -|----(B)-- User authenticates -->| Server | > | | | | > | |<---(C)- Response embedded JS -<| | > | | with Access Token +---------------+ > | | in JS content, which will be posted to Resou= rce Server > | | +---------------+ > | |----(D)-- JS post to RS URI --->| Web-Hosted | > | | with Access Token | Client | > | | | Resource | > | (F) |<---(E)----- RS Script --------<| | > | | with Access Token +---------------+ > +-|--------+ > | | > (A) (G) Access Token > | | > ^ v > +---------+ > | | > | Client | > | | > +---------+ > > > > Figure 4: Implicit Grant Flow > > > The flow illustrated in Figure 4 includes the following steps: > > (A) The client initiates the flow by directing the resource owner's > user-agent to the authorization endpoint. The client includes > its client identifier, requested scope, local state, and a > redirection URI to which the authorization server will send the > user-agent back once access is granted (or denied). > > (B) The authorization server authenticates the resource owner (via > the user-agent) and establishes whether the resource owner > grants or denies the client's access request. > > (C) Assuming the resource owner grants access, the authorization > server responds with a JavaScript logic which automatically posts= to > "redirection" URI provided earlier. The JavaScript includes > the access token in the URI fragment. > > (D) The user-agent does the post with the access token. Granted, > > user agent can actually do post without the access toke= n in a different iframe, > > then use postMessage to pass the token over, but I do n= ot see why get it need that compexity. > > > > On Fri, Jul 1, 2016 at 3:13 PM, Josh Mandel wrote: > > Thanks John! Yes, we're following the CORS based flow you've described > below (though I should note that the actual redirection back to the clien= t > could be a 302, or could be a simple Web link that the user follows from = an > authorization page; this is up to the authorization server). > Overall I don't argue that this flow is "more secure" than the implicit > flow -- though I believe it does help client developers avoid some common > pitfalls. (For example, clients that, through careless programming or poo= r > understanding of the spec, fail to validate incoming "state" are still no= t > susceptible to arbitrary token injection, which means at least they won't > readily be tricked into using a token designated for an entirely differen= t > client. With poorly written implicit flow clients, this is an issue.) > That said, I wasn't aiming to discuss the relative security; just wanted > to make sure I knew what you meant by "won't work well". > Thanks again! > -Josh > On Jul 1, 2016 18:02, "John Bradley" wrote: > > I am making a distinction between a browser talking to a Web server that > is acting as a OAuth Client POST response mode =3D good , and a oauth cli= ent > running in the browser user agent as a Java script application (that can= =E2=80=99t > directly capture a POST response back to the server) > > So it depends on where the client is actually running. > > Are you saying that you are using a 302 redirect from the authorization > endpoint back to the server hosting the JS and then loading the JS > including the code and then using CORES to exchange the code for a AT? > > You can do that but I don=E2=80=99t think a public client like that is mo= re secure > than just using the fragment encoded response and is more work. > It also may give the server a false sense of security. > > John B. > > On Jul 1, 2016, at 5:52 PM, Josh Mandel wrote: > > I think the confusion here is that I'm not using HEART's OAuth profiles := -) > > I'm using the SMART profiles, where we do specify the use of an > authorization code grant even for browser-based public clients (in which > case, no client_secret is issued or used). I'm just trying to understand > your perspective eon why this "won't work well". Perhaps you didn't mean > this comment to refer to browser-based OAuth clients generally? > > -Josh > > On Fri, Jul 1, 2016 at 5:45 PM, John Bradley wrote: > > I don=E2=80=99t think the post response mode is supported by heart so I s= uspect > that we are talking about different things. > > You are probably using the supported code flow that uses a 302 get to > return the code to the OAuth client on the server. > The Web server is then acting as a confidential client to exchange the > code via a POST (different POST) with the AS token_endpoint. > > The Token endpoint will return a access token (AT) and optional refresh > token (RT). > > The web page may be getting the server to make the OAuth calls on it=E2= =80=99s > behalf to the Resource Server, or possibly you are passing the AT from th= e > server back to a Java script app that is using CORES to make calls direct= ly > to the RS without going through the Web server. > > Passing the AT back to the user agent from the client is not recommended. > > For in browser clients where the JS is using the AT to make the calls > directly to the RS via CORES the recommended approach is to use the > fragment encoded response via a 302 to deliver the AT directly to the > client (It never hits the backend Web server). > > However I believe In browser OAuth clients are not currently supported in > HEART, so I am not quite sure what you are doing. > > Perhaps Justin has a better answer. > > John B. > > > On Jul 1, 2016, at 5:33 PM, Josh Mandel wrote: > > John, > > I appreciate your response. I'm hoping you can clarify why you say that > "HTTP POST... won't work well for... [a] single page OAuth client"? > > We commonly build single-page apps that act as OAuth clients for SMART > (e.g. this sample app > ), > and we've had good experience with the technique. Could you elaborate? > > -J > > On Fri, Jul 1, 2016 at 5:26 PM, John Bradley wrote: > > HEART only supports web server clients at the moment. That might change > in future to support native apps if that an be made to support the securi= ty > requirements of Heath IT. > > So the thing HTTP POST responses won=E2=80=99t work well for is a type of= in > browser single page OAuth client. That still needs fragment encoded > responses or the new post-message Java Script API approach. > > John B. > > > On Jul 1, 2016, at 5:16 PM, Josh Mandel wrote: > > Thanks Justin, > > To clarify: John's comment and my question were about POST. (I do > understand the behavior of HTTP POST and of window.postMessage; these are > totally different things.) From my perspective in SMART Health IT, we use > the OAuth 2.0 authorization code flow, including HTTP POST, in our author= ization > spec even for public > clients, and it has worked very well for us, with about a dozen electroni= c > health record servers supporting this approach. That's why I was curious = to > hear John's perspective about limitations. > > -J > > On Fri, Jul 1, 2016 at 5:09 PM, Oleg Gryb wrote: > > > POST will send things to the server, which isn=E2=80=99t desirable if y= our > client is solely in the browser > Why it's not desirable, assuming that we disregard performance? You can > generate HTTP POST from JS, e.g. through an AJAX call. What is wrong with > this? > > > ------------------------------ > *From:* Justin Richer > *To:* Josh Mandel > *Cc:* Oleg Gryb ; "" ; > Liyu Yi > *Sent:* Friday, July 1, 2016 2:00 PM > > *Subject:* Re: [OAUTH-WG] Security concern for URI fragment as Implicit > grant > > POST will send things to the server, which isn=E2=80=99t desirable if you= r client > is solely in the browser. postMessage is a browser API and not to be > confused with HTTP POST. postMessage messages stay (or can stay) within t= he > browser, which is the intent here. > > =E2=80=94 Justin > > On Jul 1, 2016, at 4:56 PM, Josh Mandel wrote: > > John, > > Could you clarify what you mean by "POST doesn't really work"? Do you > just mean that CORS support (e.g., http://caniuse.com/#feat=3Dcors) isn't > universal, or something more? > > On Fri, Jul 1, 2016 at 4:51 PM, John Bradley wrote: > > Yes but POST doesn't really work for in browser apps. > > If it is a server app it should be using the code flow with GET or POST a= s > you like. > > If we do a post message based binding it will be targeted at in browser > applications. > > John B. > > On Fri, Jul 1, 2016 at 4:42 PM, Liyu Yi wrote: > > BTW, I do not see any significant performance concerns for post. Parsing > and executing the Javascript logic for post operation will be on the clie= nt > side, no extra server load is introduced. > > Plus post will remove the size restriction of the URL length. > > -- Liyu > > On Fri, Jul 1, 2016 at 1:35 PM, Liyu Yi wrote: > > Thanks for the great comments and advices. > > I think it is a good idea for the working group to revise the fragment > part in the spec, since there might be public available tools already > implemented this approach and people can end up with a solution with > serious security loopholes. > > The re-append issue can be mitigate by a logic on Resource Server which > carefully re-writes/removes the fragment in any redirect, if the the > redirect can not be avoided. > > -- Liyu > > > On Fri, Jul 1, 2016 at 11:33 AM, John Bradley wrote: > > This behaviour started changing around 2011 > > From HTTP/1.1 > See https://tools.ietf.org/html/rfc7231#section-7.1.2I > f the Location value provided in a 3xx (Redirection) response does > > not have a fragment component, a user agent MUST process the > redirection as if the value inherits the fragment component of the > URI reference used to generate the request target (i.e., the > redirection inherits the original reference's fragment, if any). > > For example, a GET request generated for the URI reference > "http://www.example.org/~tim" might result in a 303 (See Other) > response containing the header field: > > Location: /People.html#tim > > which suggests that the user agent redirect to > "http://www.example.org/People.html#tim=E2=80=9D > > > Likewise, a GET request generated for the URI reference > "http://www.example.org/index.html#larry" might result in a 301 > (Moved Permanently) response containing the header field: > > Location: http://www.example.net/index.html > > which suggests that the user agent redirect to > "http://www.example.net/index.html#larry", preserving the original > fragment identifier. > > > > This blog also explores the change. > > https://blogs.msdn.microsoft.com/ieinternals/2011/05/16/url-fragments-and= -redirects/ > > > On Jul 1, 2016, at 1:05 PM, Oleg Gryb wrote: > > "Browsers now re-append fragments across 302 redirects unless they are > explicitly cleared this makes fragment encoding less safe than it was wh= en > originally specified" - thanks Jim. Looks like a good reason for vetting > this flow out. > > John, > Please provide more details/links about re-appending fragments. > > Thanks, > Oleg. > > > ------------------------------ > *From:* Jim Manico > *To:* Oleg Gryb > *Cc:* "oauth@ietf.org" ; Liyu Yi > *Sent:* Thursday, June 30, 2016 10:25 PM > *Subject:* Re: [OAUTH-WG] Security concern for URI fragment as Implicit > grant > > Oleg! Hello! Great to see you pop up here with a similar concern. > > John Bradley just answered this thread with the details I was looking for > (thanks John, hat tip your way). > > He also mentioned details about fragment leakage: > > "Browsers now re-append fragments across 302 redirects unless they are > explicitly cleared this makes fragment encoding less safe than it was whe= n > originally specified" > > Again, I'm new here but I'm grateful for this conversation. > > Aloha, > -- > Jim Manico > @Manicode > > On Jul 1, 2016, at 1:24 AM, Oleg Gryb wrote: > > We've discussed access tokens in URI back in 2010 ( > https://www.ietf.org/mail-archive/web/oauth/current/msg04043.html). There > were two major objectives when I was saying that it's not secure: > > 1. Fragment is not sent to a server by a browser. When I've asked if this > is true for every browser in the world, nobody was able to answer. > 2. Replacing with POST would mean a significant performance impact in som= e > high volume implementations (I think it was Goole folks who were saying > this, but I don't remember now). > > AFAIR, nobody was arguing about browsing history, so it's valid. > > So, 6 years later we're at square one with this and I hope that this time > the community will be more successful with getting rid of secrets in URL. > > BTW, Jim, if you can come up with other scenarios when fragments can leak= , > please share. It'll probably help the community with solving this problem > faster than in 6 years. > > Thanks, > Oleg. > > > ------------------------------ > *From:* Jim Manico > *To:* Liyu Yi ; oauth@ietf.org > *Sent:* Wednesday, June 29, 2016 7:30 AM > *Subject:* Re: [OAUTH-WG] Security concern for URI fragment as Implicit > grant > > > Shouldn=E2=80=99t it be more secure if we change to use a post method f= or > access token, similar to the SAML does? > I say yes. But please note I'm very new at this and someone with more > experience will have more to say or correct my comments. > Here are a few more details to consider. > 1) OAuth is a framework and not a standard, per se. Different > authorization servers will have different implementations that are not > necessarily compatible with other service providers. So there is no > standard to break, per se. > 2) Sensitive data in a URI is a bad idea. They leak all over the place > even over HTTPS. Even in fragments. > 3) Break the "rules" and find a way to submit sensitive data like access > tokens, session information or any other (even short term) sensitive data > in a secure fashion. This includes POST, JSON data payloads over PUT/PATC= H > and other verbs - all over well configured HTTPS. > 4) If you really must submit sensitive data over GET , consider > JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level > confidentiality and integrity. > Aloha, > > Jim Manico > Manicode Securityhttps://www.manicode.com > > > On 6/27/16 9:30 PM, Liyu Yi wrote: > > While we are working on a project with OAuth2 implementation, one questio= n > arises from our engineers. > We noticed at > https://tools.ietf.org/html/draft-ietf-oauth-v2-31#page-30, it is > specified that > > (C) Assuming the resource owner grants access, the authorization > server redirects the user-agent back to the client using the > redirection URI provided earlier. The redirection URI includes > the access token in the URI fragment. > > For my understanding, the browser keeps the URI fragment in the history, > and this introduces unexpected exposure of the access token. A user witho= ut > authorization for the resource can get the access token as long as he has > the access to the browser. This can happen in a shared computer in librar= y, > or for an IT staff who works on other employee=E2=80=99s computer. > > Shouldn=E2=80=99t it be more secure if we change to use a post method for= access > token, similar to the SAML does? > I feel there might be something I missed here. Any advices will be > appreciated. > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > > -- > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > --001a113e8bfee67dce05369cc6fb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I would say AT is supposed to be consumed by the Resource = Server. Although the original spec does not show how AT is used by the clie= nt, but the AT will be sent out, most likely by the browser directly, or in= a rare case if the client application has another channel, indirectly.
The fact is that the AT is not sent in the 1st GET request = does leave the RS JavaScript a chance to choose the right method, say an aj= ax POST. But AT is NOT =C2=A0a secrete to RS.


=


On Fri, Jul 1, 2016 at 5:53 PM, John Bradley &l= t;ve7jtb@ve7jtb.com<= /a>> wrote:
yes

I think, the intention was not to share AT with the web-hosted = client resource. As you can see in the original flow the latter never recei= ves the AT, it simply provides code that can get AT from a fragment and som= e UI. In the modified flow AT is sent to the web-hosted client resource, wh= ich makes security worse in my view, because you have your AT exposed in tw= o places now - in the User Agent *and* in the web-hosted client resource.



From: John Bradley <ve7jtb@ve7jtb.com>
To: Liyu Yi <= liyuyi@gmail.com>
Cc:= Oleg Gryb <oleg= @gryb.info>; "<oauth@ietf.org>" <oauth@ietf.org>
Sent: Friday, July 1, 2016 4:06 PM
Subject: Re: [OAUTH-WG] Security concern for URI= fragment as Implicit grant

I take it= that Web-hosted client resource is part of the client.

I think perhaps you have client and resource serve r mixed u= p a bit in your diagram.

Yes you co= uld do that but it is not a great way to build the client as it will blow a= way context. =C2=A0
You can do it but people generally want to st= art the application in the browser first and then call out to the IdP =C2= =A0in a iFrame.

What you propose wo= uld work more or less.=C2=A0 I don=E2=80=99t see it as a pattern that I wou= ld necessarily recommend over the current fragment encoding.

If we mover to post message it would include API = =C2=A0for logout and session management, not just login.

John B.

=
On Jul 1, 2016, at 6= :43 PM, Liyu Yi <liyuyi@gmail.com> wrote:

Understood there is an Authorization= Code grant type; here I am more focusing on the Implicit grant type.=C2=A0=
=C2=A0=C2=A0
also when I mentioned POST, I did not mea= n postMessage, it is simply the HTTP POST. Specifically it is more like thi= s ...



4.2. Implicit Grant (= modified)

     +-=
---------+
     | Resource |
     |  Owner   |
     |          |
     +----------+
          ^
          |
         (B)
     +----|-----+          Client Identifier     +---------------+
     |         -+----(A)-- & Redirection URI --->|               |
     |  User-   |                                | Authorization |
     |  Agent  -|----(B)-- User authenticates -->|     Server    |
     |          |                                |               |
     |          |<---(C)- Response embedded JS -<|               |
     |          |          with Access Token     +---------------+
     |          |            in JS content, which will be posted to Resourc=
e Server
     |          |                                +---------------+
     |          |----(D)-- JS post to RS URI --->|   Web-Hosted  |
     |          |         with Access Token      |     Client    |
     |          |                                |    Resource   |
     |     (F)  |<---(E)----- RS Script --------<|               |
     |          |         with Access Token      +---------------+
     +-|--------+
       |    |
      (A)  (G) Access Token
       |    |
       ^    v
     +---------+
     |         |
     |  Client |
     |         |
     +---------+



                       Figure 4: Implicit Grant Flow


 =
  The flow illustrated in Figure 4 includes the following steps:

   (A)  The client initiates the flow by directing the resource owner's
        user-agent to the authorization endpoint.  The client includes
        its client identifier, requested scope, local state, and a
        redirection URI to which the authorization server will send the
        user-agent back once access is granted (or denied).

   (B)  The authorization server authenticates the resource owner (via
        the user-agent) and establishes whether the resource owner
        grants or denies the client's access request.

   (C)  Assuming the resource owner grants access, the authorization
        server responds with a JavaScript logic which automatically posts t=
o=20
        "redirection" URI provided earlier.  The JavaScript inclu=
des
        the access token in the URI fragment.

   (D)  The user-agent does the post with the access token. Granted,
u= ser agent can actually do post without the access token in a different iframe= , 
  =
                then use postMessage to pass the token over, but I do not s=
ee why get it need that compexity.


On Fri, Jul 1, 2016 at 3:13 PM, Josh Mandel = <jmandel@gmail.com> wrote:
Thanks John! Yes, we're foll= owing the CORS based flow you've described below (though I should note = that the actual redirection back to the client could be a 302, or could be = a simple Web link that the user follows from an authorization page; this is= up to the authorization server).
Overall I don'= t argue that this flow is "more secure" than the implicit flow --= though I believe it does help client developers avoid some common pitfalls= . (For example, clients that, through careless programming or poor understa= nding of the spec, fail to validate incoming "state" are still no= t susceptible to arbitrary token injection, which means at least they won&#= 39;t readily be tricked into using a token designated for an entirely diffe= rent client. With poorly written implicit flow clients, this is an issue.) =
That said, I wasn't aiming to discuss the relati= ve security; just wanted to make sure I knew what you meant by "won= 9;t work well".
Thanks again!
-Josh
On Jul 1, 2016 18:02, "John Bradley" <ve7jtb@= ve7jtb.com> wrote:
I am making a distinction between a browser talking to a Web = server that is acting as a OAuth Client POST response mode =3D good , and a= oauth client running in the browser user agent as a Java script applicatio= n (that can=E2=80=99t directly capture a POST response back to the server)<= div>
So it depends on where the client is actu= ally running.

Are you saying that y= ou are using a 302 redirect from the authorization endpoint back to the ser= ver hosting the JS and then loading the JS including the code and then usin= g CORES =C2=A0to exchange the code for a AT?

<= /div>
You can do that but I don=E2=80=99t think a public client like th= at is more secure than just using the fragment encoded response and is more= work.
It also may give the server a false sense of security.

John B.
On Jul 1, 2016, at 5:52 PM, Josh Mandel <jmandel@gmail.com> wrote:

I think the confusion here is that I'm not using HEART's = OAuth profiles :-)

I'm using the SMAR= T profiles, where we do specify the use of an authorization code grant even= for browser-based public clients (in which case, no client_secret is issue= d or used). I'm just trying to understand your perspective eon why this= "won't work well". Perhaps you didn't mean this comment = to refer to browser-based OAuth clients generally?

=C2=A0 -Josh

On Fri, Jul = 1, 2016 at 5:45 PM, John Bradley <ve7jtb@v= e7jtb.com> wrote:
I don=E2=80=99t think the post response mode is support= ed by heart so I suspect that we are talking about different things.
You are probably using the supported code flow = that uses a 302 get to return the code to the OAuth client on the server. = =C2=A0
The Web server is then acting as a confidential client to = exchange the code via a POST (different POST) with the AS token_endpoint.

The Token endpoint will return a acc= ess token (AT) and optional refresh token (RT).

The web page may be getting the server to make the OAuth calls= on it=E2=80=99s behalf to the Resource Server, or possibly you are passing= the AT from the server back to a Java script app that is using CORES to ma= ke calls directly to the RS without going through the Web server.

Passing the AT back to the user agent from t= he client is not recommended.=C2=A0

For in browser clients where the JS is using the AT to make the calls dire= ctly to the RS via CORES the recommended approach is to use the fragment en= coded response via a 302 to deliver the AT directly to the client (It never= hits the backend Web server).

Howe= ver I believe In browser OAuth clients are not currently supported in HEART= , so I am not quite sure what you are doing.

<= /div>
Perhaps Justin has a better answer.

=
John B.


On Jul 1, 2016, at 5:33 PM= , Josh Mandel <jmandel@gmail.com> wrote:

John,

I= appreciate your response. I'm hoping you can clarify why you say that = "HTTP POST... won't work well for... [a] single page OAuth client&= quot;?

We commonly build single-page apps= that act as OAuth clients for SMART (e.g. this sample app= =C2=A0), and we've had good experience with the technique. Could you el= aborate?

=C2=A0 -J

On Fri, Jul 1, 2016 at 5:26 PM, John Bradley= <ve7jtb@ve7jtb.com> wrote:<= br clear=3D"none">
HEART only s= upports web server clients at the moment. =C2=A0 That might change in futur= e to support native apps if that an be made to support the security require= ments of Heath IT.

So the thing HTTP POST respo= nses won=E2=80=99t work well for is a type of in browser single page OAuth = client.=C2=A0 That still needs fragment encoded responses or the new post-m= essage Java Script API approach.

Jo= hn B.


=
On Jul 1, 2016, at 5:16 PM, Josh Mandel= <jmandel@gmail.com> wrote:

<= div>
Thanks Justin,

To cl= arify: John's comment and my question were about POST. (I do understand= the behavior of HTTP POST and of window.postMessage; these are totally dif= ferent things.) From my perspective in SMART Health IT, we use the OAuth 2.= 0 authorization code flow, including HTTP POST, in our authorization spec=C2=A0even for public clients, and it has= worked very well for us, with about a dozen electronic health record serve= rs supporting this approach. That's why I was curious to hear John'= s perspective about limitations.

= =C2=A0 -J

On Fri, Jul 1, 2016 at 5:09 PM,= Oleg Gryb <oleg_gryb@yahoo.com><= /span> wrote:
> POST will send things to the= server, which isn=E2=80=99t desirable if your client is solely in the brow= ser
Why it's not desirable, assuming that we disr= egard performance? You can generate HTTP POST from JS, e.g. through an AJAX= call. What is wrong with this?
<= /div>


From: Justin Richer <= jricher@mit.edu>
To: Josh Mandel <jmandel@gmail.com> <= br clear=3D"none">Cc: Oleg G= ryb <oleg@gryb.info>; "<oauth@ietf.org<= /a>>" <oauth@ietf.org>; Liyu Yi <l= iyuyi@gmail.com>
Sent: Friday, July 1, 2016 2:00 PM

Subject: Re: [OAUTH-WG] = Security concern for URI fragment as Implicit grant

POST will send = things to the server, which isn=E2=80=99t desirable if your client is solel= y in the browser. postMessage is a browser API and not to be confused with = HTTP POST. postMessage messages stay (or can stay) within the browser, whic= h is the intent here.

=C2=A0=E2=80=94 Jus= tin

O= n Jul 1, 2016, at 4:56 PM, Josh Mandel <jmandel@gmail.com> wrote:


On F= ri, Jul 1, 2016 at 4:51 PM, John Bradley <= ve7jtb@ve7jtb.com> wrote:
Yes but POST doesn't really work for in browser apps.

If it is a server app it should be using the code= flow with GET or POST as you like.

If we do a =C2=A0post message based binding it will be targeted at in brow= ser applications.

John B.

On Fri, Jul 1, 2016 at 4:42 PM, Liyu Yi <liyuyi@gmail.com> wrote:
BTW, I do not see any significant perf= ormance concerns for post. Parsing and executing the Javascript logic for p= ost operation will be on the client side, no extra server load is introduce= d.

Plus post will remove the size restric= tion of the URL length.

-- Liyu=C2=A0
On Fri, Jul 1, 2016 at 1:35 PM, Liyu Yi <liyuyi@gmail.com> wrote:
Thanks for the great comments and advices.=

I think it is a good idea for the worki= ng group to revise the fragment part in the spec, since there might be publ= ic available tools already implemented this approach and people can end up = with a solution with serious security loopholes.

The re-append issue can be mitigate by a logic on Resource Server w= hich carefully re-writes/removes the fragment in any redirect, if the the r= edirect can not be avoided.

-- Liyu
=C2=A0

On Fri, Jul 1, 20= 16 at 11:33 AM, John Bradley <ve7jtb@ve7jt= b.com> wrote:
This behaviour started changing around 2011

From HTTP/1.1
=C2=A0 =C2=A0 =C2=A0 f the Location value provided in a 3xx (Redi= rection) response does
   not have a fragment compo=
nent, a user agent MUST process the
   redirection as if the value inherits the fragment component of the
   URI reference used to generate the request target (i.e., the
   redirection inherits the original reference's fragment, if any).

   For example, a GET request generated for the URI reference
   "http://www.example.org/~tim" might result =
in a 303 (See Other)
   response containing the header field:

     Location: /People.html#tim

   which suggests that the user agent redirect to
   "http://www.example.org/People.html#tim=E2=80=9D

   L=
ikewise, a GET request generated for the URI reference
   "http://www.example.org/index.html#larry=
" might result in a 301
   (Moved Permanently) response containing the header field:

     Location: http://www.example.net/index.html

   which suggests that the user agent redirect to
   "http://www.example.net/index.html#larry=
", preserving the original
   fragment identifier.


This blog also explores the change.


On Jul 1, 2016, at 1:05 PM, Oleg Gryb <ole= g_gryb@yahoo.com> wrote:

"Browsers now re-append =C2=A0fragments across 302 redirects unle= ss they are explicitly cleared this makes fragment encoding less safe than = it was =C2=A0when originally specified" - thanks Jim. Looks like a goo= d reason for vetting this flow out.

John,
Please provide more details/links about re-ap= pending fragments.=C2=A0

Thanks,
Oleg.


=
From: Jim M= anico <jim@manicode.com>
To: Oleg Gryb <oleg@gryb.i= nfo>
Cc: "oauth@ietf.org" <oauth@ietf.org<= /a>>; Liyu Yi <liyuyi@gmail.com>
= Sent: Thursday, June 30, 20= 16 10:25 PM
Subject:= Re: [OAUTH-WG] Security concern for URI fragment as Implicit gr= ant

Oleg!= Hello! Great to see you pop up here with a similar concern.

John Bradley just answered this thread with the d= etails I was looking for (thanks John, hat tip your way).

He also mentioned details about fragment leakage:

"Browsers now re-append = =C2=A0fragments across 302 redirects unless they are explicitly cleared thi= s makes fragment encoding less safe than it was when originally specified&q= uot;

Again, I'm new here= but I'm grateful for this conversation.

<= /div>
Aloha,
--
Jim Manico
@Manicode=

On Jul 1, 2016, at 1:24 AM, Oleg G= ryb <oleg_gryb@yahoo.com> wrote:
=
We've discusse= d access tokens in URI back in 2010 (https://www.ietf.org/mail-archive/web/oauth/current/m= sg04043.html). There were two major objectives when I was saying that i= t's not secure:

1. Fragment is not sent to a server by a browser. When I've as= ked if this is true for every browser in the world, nobody was able to answ= er.
2. Replacing with POST would mean a significant p= erformance impact in some high volume implementations (I think it was Goole= folks who were saying this, but I don't remember now).

AFAIR, nobody was arguin= g about browsing history, so it's valid.

So, 6 years later we're at square one= with this and I hope that this time the community will be more successful = with getting rid of secrets in URL.

BTW, Jim, if you can come up with other scenarios = when fragments can leak, please share. It'll probably help the communit= y with solving this problem faster than in 6 years.
<= br clear=3D"none">
Thanks,
Oleg= .


<= span style=3D"font-weight:bold">From: Jim Manico <= jim@manicode.com>
To: Liyu Yi <liyuyi@gmail.com>; oauth@ietf.org
Sent: Wednesday, June 29, 2016 7:30 AM
= Subject: Re: [OAUTH-WG] Securit= y concern for URI fragment as Implicit grant

> Shouldn=E2=80=99t it be more secure if we change to use a post method for access token, similar to the SAML does?
I say yes. But please note I'm very new at this and someone wi= th more experience will have more to say or correct my comments.
Here are a few more details to consider.
1) OAuth is a framework and not a standard, per se. Different authorization servers will have different implementations that are not necessarily compatible with other service providers. So there is no standard to break, per se.
2) Sensitive data in a URI is a bad idea. They leak all over the place even over HTTPS. Even in fragments.
3) Break the "rules" and find a way to submit sensitive = data like access tokens, session information or any other (even short term) sensitive data in a secure fashion. This includes POST, JSON data payloads over PUT/PATCH and other verbs - all over well configured HTTPS.
4) If you really must submit sensitive data over GET , consider JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level confidentiality and integrity.
Aloha,
Jim Manico
Manicode Security
https://www.manicode.com

On 6/27/16 9:30 PM, Liyu Yi wrote:
While we are working on a project with OAuth2 implementation, one question arises from our engineers.
=C2=A0=C2=A0
(C)=C2=A0 Assuming the resource owner grants access, the authorization
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 server redire= cts the user-agent back to the client using the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 redirection U= RI provided earlier.=C2=A0 The redirection URI includes
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the access to= ken in the URI fragment.
=C2=A0
For my understanding, the browser keeps the URI fragment in the history, and this introduces unexpected exposure of the access token. A user without authorization for the resource can get the access token as long as he has the access to the browser. This can happen in a shared computer in library, or for an IT staff who works on other employee=E2=80=99s computer.
=C2=A0
Shouldn=E2=80=99t it be more secure if we change to use a post method for access token, similar to the SAML does?
I feel there might be something I missed here. Any advices will be appreciated.


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


--=20




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


=





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


_______________________________________________
OAuth mai= ling list
OAuth@ietf.org
<= a rel=3D"nofollow" shape=3D"rect" href=3D"https://www.ietf.org/mailman/list= info/oauth" target=3D"_blank">https://www.ietf.org/mailman/listinfo/oauth


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



_______________________________________________
OAuth mai= ling list
OAuth@ietf.org
<= a rel=3D"nofollow" shape=3D"rect" href=3D"https://www.ietf.org/mailman/list= info/oauth" target=3D"_blank">https://www.ietf.org/mailman/listinfo/oauth








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

<= br> =

--001a113e8bfee67dce05369cc6fb-- From nobody Wed Jul 6 07:55:50 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F75212D0AE for ; Fri, 1 Jul 2016 18:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.697 X-Spam-Level: X-Spam-Status: No, score=-2.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, 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=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-S_kUOnOG-B for ; Fri, 1 Jul 2016 18:37:14 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90B2C12D0A7 for ; Fri, 1 Jul 2016 18:37:13 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id i12so1380720ywa.1 for ; Fri, 01 Jul 2016 18:37:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3az9gH8UVW2kC+MQVt//tR49mIRoIe7Hg+n9nBzjxxE=; b=fsEL+2SDR8shfx90yBpAH/MuKDV0klXvfqrKJc6ZmI9Flsk7Z9Pi0XMKrMBK/0BlGg zp3h8xS42kWyTVWF+nqjMZKF9FUa7x6CGinTjFH05HTDGVKbuqnHVg6wi9/oiLMDa72b hhcxnnZ/bAPSOgRoOgjlvYzVTGbKuL7LvUdVaC8tJ9AwuGCe4c1K2Oi2JnnTX199jMip 8BN1k3gc1/rxylPurlHvPzDmHQuDG4PJNhfGkr8RTVugZsgSpOg1knKDkk0TH5FjY3RG V/Bf3USChhSncGr3OOmO2Vw49GNVoTz+mUwxhTzTE9TqET3vdCpEYxZDk6Y/mNVRYg8C HsMw== 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=3az9gH8UVW2kC+MQVt//tR49mIRoIe7Hg+n9nBzjxxE=; b=Mg/txL6g1F+onRxYF4a87rjHSpzXn7MR6nwciyjjsApRBb4LmTZPs+6LcoI1I+bB4/ r8ML8c5iIAr95qWtSnoGmggCp90aTE1YMn0NMgTku0AYh6GIdY0qZFPKO+9zU6GxTUPF P8tkQb6ef+YXtlsvtjegpY/hJgPmmVyVQ4qBWMeghQSRUcejXwqmciOU7q0XvUzhNO5R Sdj6SoUZNXh3yZDnyT9tRuqaEPW+LWiiwPPxmJKAWM6V38EVBy98KfD/iTx2kmwrqCYi TdIHjxD/H5dYHP8kfIM4AzYm1EVkxgTGAFqISnvbSiaXUGMRceIeQzoN7m0D2i4ogDm4 Y6fw== X-Gm-Message-State: ALyK8tLC6yj/3gD+OTPMHM2QAwP3dXBvlXWJfe1+EOuDRCygeDGbHcmUf8a/KUI2knoKrjKHSPNRpCUIIBvG5w== X-Received: by 10.129.82.135 with SMTP id g129mr765657ywb.163.1467423432687; Fri, 01 Jul 2016 18:37:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.80.13 with HTTP; Fri, 1 Jul 2016 18:37:10 -0700 (PDT) In-Reply-To: <597554829.619782.1467422094020.JavaMail.yahoo@mail.yahoo.com> References: <994121658.55005.1467329084208.JavaMail.yahoo@mail.yahoo.com> <235316006.458279.1467392709447.JavaMail.yahoo@mail.yahoo.com> <6584BD74-B18F-4174-9E69-5C7B4B76F895@ve7jtb.com> <410908395.555462.1467407397629.JavaMail.yahoo@mail.yahoo.com> <8CC41328-C26D-42C0-BFDB-BF0216C7B76C@ve7jtb.com> <71CE61B3-FEC2-46A7-AB28-B53E89A8E53F@ve7jtb.com> <560704570.608692.1467419971908.JavaMail.yahoo@mail.yahoo.com> <50E491F2-E08F-40A7-B9DE-AB50CB647C04@ve7jtb.com> <597554829.619782.1467422094020.JavaMail.yahoo@mail.yahoo.com> From: Liyu Yi Date: Fri, 1 Jul 2016 18:37:10 -0700 Message-ID: To: Oleg Gryb Content-Type: multipart/alternative; boundary=001a114ddbaa70d1f005369d24eb Archived-At: X-Mailman-Approved-At: Wed, 06 Jul 2016 07:55:08 -0700 Cc: "" Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2016 01:37:20 -0000 --001a114ddbaa70d1f005369d24eb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable John and Oleg, good point. I missed that. So in this case the "web-hosted client resource" is a party different from the RS and is also different from AS and is not supposed to access to AT. But I guess this "web-hosted client resource" must be trusted, since its JS has access the the AT on the browser side anyways. Maybe the secure way is to let the AS return an HTML with embedded JS and AT. It does make the AS do more work, but it cuts out the need of "web-hosted client resource". Comments? -- Liyu On Fri, Jul 1, 2016 at 6:14 PM, Oleg Gryb wrote: > As John has already pointed out - you're confusing RS with the web-hosted > client resource. > > > ------------------------------ > *From:* Liyu Yi > *To:* John Bradley > *Cc:* Oleg Gryb ; "" > *Sent:* Friday, July 1, 2016 6:11 PM > > *Subject:* Re: [OAUTH-WG] Security concern for URI fragment as Implicit > grant > > I would say AT is supposed to be consumed by the Resource Server. Althoug= h > the original spec does not show how AT is used by the client, but the AT > will be sent out, most likely by the browser directly, or in a rare case = if > the client application has another channel, indirectly. > > The fact is that the AT is not sent in the 1st GET request does leave the > RS JavaScript a chance to choose the right method, say an ajax POST. But = AT > is NOT a secrete to RS. > > > > > On Fri, Jul 1, 2016 at 5:53 PM, John Bradley wrote: > > yes > > On Jul 1, 2016, at 8:39 PM, Oleg Gryb wrote: > > I think, the intention was not to share AT with the web-hosted client > resource. As you can see in the original flow the latter never receives t= he > AT, it simply provides code that can get AT from a fragment and some UI. = In > the modified flow AT is sent to the web-hosted client resource, which mak= es > security worse in my view, because you have your AT exposed in two places > now - in the User Agent *and* in the web-hosted client resource. > > > > ------------------------------ > *From:* John Bradley > *To:* Liyu Yi > *Cc:* Oleg Gryb ; "" > *Sent:* Friday, July 1, 2016 4:06 PM > *Subject:* Re: [OAUTH-WG] Security concern for URI fragment as Implicit > grant > > I take it that Web-hosted client resource is part of the client. > > I think perhaps you have client and resource serve r mixed up a bit in > your diagram. > > Yes you could do that but it is not a great way to build the client as it > will blow away context. > You can do it but people generally want to start the application in the > browser first and then call out to the IdP in a iFrame. > > What you propose would work more or less. I don=E2=80=99t see it as a pa= ttern > that I would necessarily recommend over the current fragment encoding. > > If we mover to post message it would include API for logout and session > management, not just login. > > John B. > > > On Jul 1, 2016, at 6:43 PM, Liyu Yi wrote: > > Understood there is an Authorization Code grant type; here I am more > focusing on the Implicit grant type. > > also when I mentioned POST, I did not mean postMessage, it is simply the > HTTP POST. Specifically it is more like this ... > > > > 4.2 . Implicit Grant > (modified) > > +----------+ > | Resource | > | Owner | > | | > +----------+ > ^ > | > (B) > +----|-----+ Client Identifier +---------------+ > | -+----(A)-- & Redirection URI --->| | > | User- | | Authorization | > | Agent -|----(B)-- User authenticates -->| Server | > | | | | > | |<---(C)- Response embedded JS -<| | > | | with Access Token +---------------+ > | | in JS content, which will be posted to Resou= rce Server > | | +---------------+ > | |----(D)-- JS post to RS URI --->| Web-Hosted | > | | with Access Token | Client | > | | | Resource | > | (F) |<---(E)----- RS Script --------<| | > | | with Access Token +---------------+ > +-|--------+ > | | > (A) (G) Access Token > | | > ^ v > +---------+ > | | > | Client | > | | > +---------+ > > > > Figure 4: Implicit Grant Flow > > > The flow illustrated in Figure 4 includes the following steps: > > (A) The client initiates the flow by directing the resource owner's > user-agent to the authorization endpoint. The client includes > its client identifier, requested scope, local state, and a > redirection URI to which the authorization server will send the > user-agent back once access is granted (or denied). > > (B) The authorization server authenticates the resource owner (via > the user-agent) and establishes whether the resource owner > grants or denies the client's access request. > > (C) Assuming the resource owner grants access, the authorization > server responds with a JavaScript logic which automatically posts= to > "redirection" URI provided earlier. The JavaScript includes > the access token in the URI fragment. > > (D) The user-agent does the post with the access token. Granted, > > user agent can actually do post without the access toke= n in a different iframe, > > then use postMessage to pass the token over, but I do n= ot see why get it need that compexity. > > > > On Fri, Jul 1, 2016 at 3:13 PM, Josh Mandel wrote: > > Thanks John! Yes, we're following the CORS based flow you've described > below (though I should note that the actual redirection back to the clien= t > could be a 302, or could be a simple Web link that the user follows from = an > authorization page; this is up to the authorization server). > Overall I don't argue that this flow is "more secure" than the implicit > flow -- though I believe it does help client developers avoid some common > pitfalls. (For example, clients that, through careless programming or poo= r > understanding of the spec, fail to validate incoming "state" are still no= t > susceptible to arbitrary token injection, which means at least they won't > readily be tricked into using a token designated for an entirely differen= t > client. With poorly written implicit flow clients, this is an issue.) > That said, I wasn't aiming to discuss the relative security; just wanted > to make sure I knew what you meant by "won't work well". > Thanks again! > -Josh > On Jul 1, 2016 18:02, "John Bradley" wrote: > > I am making a distinction between a browser talking to a Web server that > is acting as a OAuth Client POST response mode =3D good , and a oauth cli= ent > running in the browser user agent as a Java script application (that can= =E2=80=99t > directly capture a POST response back to the server) > > So it depends on where the client is actually running. > > Are you saying that you are using a 302 redirect from the authorization > endpoint back to the server hosting the JS and then loading the JS > including the code and then using CORES to exchange the code for a AT? > > You can do that but I don=E2=80=99t think a public client like that is mo= re secure > than just using the fragment encoded response and is more work. > It also may give the server a false sense of security. > > John B. > > On Jul 1, 2016, at 5:52 PM, Josh Mandel wrote: > > I think the confusion here is that I'm not using HEART's OAuth profiles := -) > > I'm using the SMART profiles, where we do specify the use of an > authorization code grant even for browser-based public clients (in which > case, no client_secret is issued or used). I'm just trying to understand > your perspective eon why this "won't work well". Perhaps you didn't mean > this comment to refer to browser-based OAuth clients generally? > > -Josh > > On Fri, Jul 1, 2016 at 5:45 PM, John Bradley wrote: > > I don=E2=80=99t think the post response mode is supported by heart so I s= uspect > that we are talking about different things. > > You are probably using the supported code flow that uses a 302 get to > return the code to the OAuth client on the server. > The Web server is then acting as a confidential client to exchange the > code via a POST (different POST) with the AS token_endpoint. > > The Token endpoint will return a access token (AT) and optional refresh > token (RT). > > The web page may be getting the server to make the OAuth calls on it=E2= =80=99s > behalf to the Resource Server, or possibly you are passing the AT from th= e > server back to a Java script app that is using CORES to make calls direct= ly > to the RS without going through the Web server. > > Passing the AT back to the user agent from the client is not recommended. > > For in browser clients where the JS is using the AT to make the calls > directly to the RS via CORES the recommended approach is to use the > fragment encoded response via a 302 to deliver the AT directly to the > client (It never hits the backend Web server). > > However I believe In browser OAuth clients are not currently supported in > HEART, so I am not quite sure what you are doing. > > Perhaps Justin has a better answer. > > John B. > > > On Jul 1, 2016, at 5:33 PM, Josh Mandel wrote: > > John, > > I appreciate your response. I'm hoping you can clarify why you say that > "HTTP POST... won't work well for... [a] single page OAuth client"? > > We commonly build single-page apps that act as OAuth clients for SMART > (e.g. this sample app > ), > and we've had good experience with the technique. Could you elaborate? > > -J > > On Fri, Jul 1, 2016 at 5:26 PM, John Bradley wrote: > > HEART only supports web server clients at the moment. That might change > in future to support native apps if that an be made to support the securi= ty > requirements of Heath IT. > > So the thing HTTP POST responses won=E2=80=99t work well for is a type of= in > browser single page OAuth client. That still needs fragment encoded > responses or the new post-message Java Script API approach. > > John B. > > > On Jul 1, 2016, at 5:16 PM, Josh Mandel wrote: > > Thanks Justin, > > To clarify: John's comment and my question were about POST. (I do > understand the behavior of HTTP POST and of window.postMessage; these are > totally different things.) From my perspective in SMART Health IT, we use > the OAuth 2.0 authorization code flow, including HTTP POST, in our author= ization > spec even for public > clients, and it has worked very well for us, with about a dozen electroni= c > health record servers supporting this approach. That's why I was curious = to > hear John's perspective about limitations. > > -J > > On Fri, Jul 1, 2016 at 5:09 PM, Oleg Gryb wrote: > > > POST will send things to the server, which isn=E2=80=99t desirable if y= our > client is solely in the browser > Why it's not desirable, assuming that we disregard performance? You can > generate HTTP POST from JS, e.g. through an AJAX call. What is wrong with > this? > > > ------------------------------ > *From:* Justin Richer > *To:* Josh Mandel > *Cc:* Oleg Gryb ; "" ; > Liyu Yi > *Sent:* Friday, July 1, 2016 2:00 PM > > *Subject:* Re: [OAUTH-WG] Security concern for URI fragment as Implicit > grant > > POST will send things to the server, which isn=E2=80=99t desirable if you= r client > is solely in the browser. postMessage is a browser API and not to be > confused with HTTP POST. postMessage messages stay (or can stay) within t= he > browser, which is the intent here. > > =E2=80=94 Justin > > On Jul 1, 2016, at 4:56 PM, Josh Mandel wrote: > > John, > > Could you clarify what you mean by "POST doesn't really work"? Do you > just mean that CORS support (e.g., http://caniuse.com/#feat=3Dcors) isn't > universal, or something more? > > On Fri, Jul 1, 2016 at 4:51 PM, John Bradley wrote: > > Yes but POST doesn't really work for in browser apps. > > If it is a server app it should be using the code flow with GET or POST a= s > you like. > > If we do a post message based binding it will be targeted at in browser > applications. > > John B. > > On Fri, Jul 1, 2016 at 4:42 PM, Liyu Yi wrote: > > BTW, I do not see any significant performance concerns for post. Parsing > and executing the Javascript logic for post operation will be on the clie= nt > side, no extra server load is introduced. > > Plus post will remove the size restriction of the URL length. > > -- Liyu > > On Fri, Jul 1, 2016 at 1:35 PM, Liyu Yi wrote: > > Thanks for the great comments and advices. > > I think it is a good idea for the working group to revise the fragment > part in the spec, since there might be public available tools already > implemented this approach and people can end up with a solution with > serious security loopholes. > > The re-append issue can be mitigate by a logic on Resource Server which > carefully re-writes/removes the fragment in any redirect, if the the > redirect can not be avoided. > > -- Liyu > > > On Fri, Jul 1, 2016 at 11:33 AM, John Bradley wrote: > > This behaviour started changing around 2011 > > From HTTP/1.1 > See https://tools.ietf.org/html/rfc7231#section-7.1.2I > f the Location value provided in a 3xx (Redirection) response does > > not have a fragment component, a user agent MUST process the > redirection as if the value inherits the fragment component of the > URI reference used to generate the request target (i.e., the > redirection inherits the original reference's fragment, if any). > > For example, a GET request generated for the URI reference > "http://www.example.org/~tim" might result in a 303 (See Other) > response containing the header field: > > Location: /People.html#tim > > which suggests that the user agent redirect to > "http://www.example.org/People.html#tim=E2=80=9D > > > Likewise, a GET request generated for the URI reference > "http://www.example.org/index.html#larry" might result in a 301 > (Moved Permanently) response containing the header field: > > Location: http://www.example.net/index.html > > which suggests that the user agent redirect to > "http://www.example.net/index.html#larry", preserving the original > fragment identifier. > > > > This blog also explores the change. > > https://blogs.msdn.microsoft.com/ieinternals/2011/05/16/url-fragments-and= -redirects/ > > > On Jul 1, 2016, at 1:05 PM, Oleg Gryb wrote: > > "Browsers now re-append fragments across 302 redirects unless they are > explicitly cleared this makes fragment encoding less safe than it was wh= en > originally specified" - thanks Jim. Looks like a good reason for vetting > this flow out. > > John, > Please provide more details/links about re-appending fragments. > > Thanks, > Oleg. > > > ------------------------------ > *From:* Jim Manico > *To:* Oleg Gryb > *Cc:* "oauth@ietf.org" ; Liyu Yi > *Sent:* Thursday, June 30, 2016 10:25 PM > *Subject:* Re: [OAUTH-WG] Security concern for URI fragment as Implicit > grant > > Oleg! Hello! Great to see you pop up here with a similar concern. > > John Bradley just answered this thread with the details I was looking for > (thanks John, hat tip your way). > > He also mentioned details about fragment leakage: > > "Browsers now re-append fragments across 302 redirects unless they are > explicitly cleared this makes fragment encoding less safe than it was whe= n > originally specified" > > Again, I'm new here but I'm grateful for this conversation. > > Aloha, > -- > Jim Manico > @Manicode > > On Jul 1, 2016, at 1:24 AM, Oleg Gryb wrote: > > We've discussed access tokens in URI back in 2010 ( > https://www.ietf.org/mail-archive/web/oauth/current/msg04043.html). There > were two major objectives when I was saying that it's not secure: > > 1. Fragment is not sent to a server by a browser. When I've asked if this > is true for every browser in the world, nobody was able to answer. > 2. Replacing with POST would mean a significant performance impact in som= e > high volume implementations (I think it was Goole folks who were saying > this, but I don't remember now). > > AFAIR, nobody was arguing about browsing history, so it's valid. > > So, 6 years later we're at square one with this and I hope that this time > the community will be more successful with getting rid of secrets in URL. > > BTW, Jim, if you can come up with other scenarios when fragments can leak= , > please share. It'll probably help the community with solving this problem > faster than in 6 years. > > Thanks, > Oleg. > > > ------------------------------ > *From:* Jim Manico > *To:* Liyu Yi ; oauth@ietf.org > *Sent:* Wednesday, June 29, 2016 7:30 AM > *Subject:* Re: [OAUTH-WG] Security concern for URI fragment as Implicit > grant > > > Shouldn=E2=80=99t it be more secure if we change to use a post method f= or > access token, similar to the SAML does? > I say yes. But please note I'm very new at this and someone with more > experience will have more to say or correct my comments. > Here are a few more details to consider. > 1) OAuth is a framework and not a standard, per se. Different > authorization servers will have different implementations that are not > necessarily compatible with other service providers. So there is no > standard to break, per se. > 2) Sensitive data in a URI is a bad idea. They leak all over the place > even over HTTPS. Even in fragments. > 3) Break the "rules" and find a way to submit sensitive data like access > tokens, session information or any other (even short term) sensitive data > in a secure fashion. This includes POST, JSON data payloads over PUT/PATC= H > and other verbs - all over well configured HTTPS. > 4) If you really must submit sensitive data over GET , consider > JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level > confidentiality and integrity. > Aloha, > > Jim Manico > Manicode Securityhttps://www.manicode.com > > > On 6/27/16 9:30 PM, Liyu Yi wrote: > > While we are working on a project with OAuth2 implementation, one questio= n > arises from our engineers. > We noticed at > https://tools.ietf.org/html/draft-ietf-oauth-v2-31#page-30, it is > specified that > > (C) Assuming the resource owner grants access, the authorization > server redirects the user-agent back to the client using the > redirection URI provided earlier. The redirection URI includes > the access token in the URI fragment. > > For my understanding, the browser keeps the URI fragment in the history, > and this introduces unexpected exposure of the access token. A user witho= ut > authorization for the resource can get the access token as long as he has > the access to the browser. This can happen in a shared computer in librar= y, > or for an IT staff who works on other employee=E2=80=99s computer. > > Shouldn=E2=80=99t it be more secure if we change to use a post method for= access > token, similar to the SAML does? > I feel there might be something I missed here. Any advices will be > appreciated. > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > > -- > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > --001a114ddbaa70d1f005369d24eb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
John and Oleg, good point. I missed that. So in this case = the "web-hosted client resource" is a party different from the RS= and is also different from AS and is not supposed to access to AT. But I g= uess this "web-hosted client resource" must be trusted, since its= JS has access the the AT on the browser side anyways.

M= aybe the secure way is to let the AS return an HTML with embedded JS and AT= . It does make the AS do more work, but it cuts out the need of "web-h= osted client resource".

Comments?
<= br>
-- Liyu

On Fri, Jul 1, 2016 at 6:14 PM, Oleg Gryb <oleg_gryb@ya= hoo.com> wrote:
As John has already pointed out - yo= u're confusing RS with the=C2=A0web-hosted client resource.



I would say AT is supposed to be con= sumed by the Resource Server. Although the original spec does not show how = AT is used by the client, but the AT will be sent out, most likely by the b= rowser directly, or in a rare case if the client application has another ch= annel, indirectly.

The fact is that the A= T is not sent in the 1st GET request does leave the RS JavaScript a chance = to choose the right method, say an ajax POST. But AT is NOT =C2=A0a secrete= to RS.




On Fri,= Jul 1, 2016 at 5:53 PM, John Bradley <ve7= jtb@ve7jtb.com> wrote:
yes

On Jul 1, 2016, at 8:39 PM, Oleg Gryb <= oleg_gryb@yahoo.com> wrote:

I thi= nk, the intention was not to share AT with the web-hosted client resource. = As you can see in the original flow the latter never receives the AT, it si= mply provides code that can get AT from a fragment and some UI. In the modi= fied flow AT is sent to the web-hosted client resource, which makes securit= y worse in my view, because you have your AT exposed in two places now - in= the User Agent *and* in the web-hosted client resource.



=
From: John Bradley <ve7jtb@= ve7jtb.com>
T= o: Liyu Yi <liyuyi@gmail.com>
Cc: Oleg Gryb <oleg@gryb.info>; "<oauth@ietf.org>"= ; <oauth@ietf.org>
Sent: Friday, July 1, 2016 4:06 PM
Subject: Re: [OAUTH-= WG] Security concern for URI fragment as Implicit grant
=

I take it that Web-hosted client = resource is part of the client.

I think p= erhaps you have client and resource serve r mixed up a bit in your diagram.=

Yes you could do that but it is no= t a great way to build the client as it will blow away context. =C2=A0
You can do it but people generally want to start the application in t= he browser first and then call out to the IdP =C2=A0in a iFrame.
=
What you propose would work more or less.=C2= =A0 I don=E2=80=99t see it as a pattern that I would necessarily recommend = over the current fragment encoding.

If we mover to post message it would include API =C2=A0for logout and sess= ion management, not just login.

Joh= n B.


<= blockquote type=3D"cite">
On Jul 1, 2016, at 6:43 PM, Liyu Yi <liyuyi@gmail.com> wrote:

Understood there is an Authorization Code grant type; here I = am more focusing on the Implicit grant type.=C2=A0
=C2=A0=C2=A0
also when I mentioned POST, I did not mean postMessage, it is simp= ly the HTTP POST. Specifically it is more like this ...



<=
/pre>
4.2.  Implicit Grant (modif=
ied)



     +-=
---------+
     | Resource |
     |  Owner   |
     |          |
     +----------+
          ^
          |
         (B)
     +----|-----+          Client Identifier     +---------------+
     |         -+----(A)-- & Redirection URI --->|               |
     |  User-   |                                | Authorization |
     |  Agent  -|----(B)-- User authenticates -->|     Server    |
     |          |                                |               |
     |          |<---(C)- Response embedded JS -<|               |
     |          |          with Access Token     +---------------+
     |          |            in JS content, which will be posted to Resourc=
e Server
     |          |                                +---------------+
     |          |----(D)-- JS post to RS URI --->|   Web-Hosted  |
     |          |         with Access Token      |     Client    |
     |          |                                |    Resource   |
     |     (F)  |<---(E)----- RS Script --------<|               |
     |          |         with Access Token      +---------------+
     +-|--------+
       |    |
      (A)  (G) Access Token
       |    |
       ^    v
     +---------+
     |         |
     |  Client |
     |         |
     +---------+



                       Figure 4: Implicit Grant Flow


 =
  The flow illustrated in Figure 4 includes the following steps:

   (A)  The client initiates the flow by directing the resource owner's
        user-agent to the authorization endpoint.  The client includes
        its client identifier, requested scope, local state, and a
        redirection URI to which the authorization server will send the
        user-agent back once access is granted (or denied).

   (B)  The authorization server authenticates the resource owner (via
        the user-agent) and establishes whether the resource owner
        grants or denies the client's access request.

   (C)  Assuming the resource owner grants access, the authorization
        server responds with a JavaScript logic which automatically posts t=
o=20
        "redirection" URI provided earlier.  The JavaScript inclu=
des
        the access token in the URI fragment.

   (D)  The user-agent does the post with the access token. Granted,  
                  u=
ser agent can actually do post without the access token  in a different iframe=
, 
  =
                then use postMessage to pass the token over, but I do not s=
ee why get it need that compexity.


On Fri, Jul 1, 2016 at 3:13 PM, Josh Mandel = <jmandel@gmail.com> wrote:
Thanks John! Yes, we're foll= owing the CORS based flow you've described below (though I should note = that the actual redirection back to the client could be a 302, or could be = a simple Web link that the user follows from an authorization page; this is= up to the authorization server).
Overall I don'= t argue that this flow is "more secure" than the implicit flow --= though I believe it does help client developers avoid some common pitfalls= . (For example, clients that, through careless programming or poor understa= nding of the spec, fail to validate incoming "state" are still no= t susceptible to arbitrary token injection, which means at least they won&#= 39;t readily be tricked into using a token designated for an entirely diffe= rent client. With poorly written implicit flow clients, this is an issue.) =
That said, I wasn't aiming to discuss the relati= ve security; just wanted to make sure I knew what you meant by "won= 9;t work well".
Thanks again!
-Josh
On Jul 1, 2016 18:02, "John Bradley" <ve7jtb@= ve7jtb.com> wrote:
I am making a distinction between a browser talking to a Web = server that is acting as a OAuth Client POST response mode =3D good , and a= oauth client running in the browser user agent as a Java script applicatio= n (that can=E2=80=99t directly capture a POST response back to the server)<= div>
So it depends on where the client is actu= ally running.

Are you saying that y= ou are using a 302 redirect from the authorization endpoint back to the ser= ver hosting the JS and then loading the JS including the code and then usin= g CORES =C2=A0to exchange the code for a AT?

<= /div>
You can do that but I don=E2=80=99t think a public client like th= at is more secure than just using the fragment encoded response and is more= work.
It also may give the server a false sense of security.

John B.
On Jul 1, 2016, at 5:52 PM, Josh Mandel <jmandel@gmail.com> wrote:

I think the confusion here is that I'm not using HEART's = OAuth profiles :-)

I'm using the SMAR= T profiles, where we do specify the use of an authorization code grant even= for browser-based public clients (in which case, no client_secret is issue= d or used). I'm just trying to understand your perspective eon why this= "won't work well". Perhaps you didn't mean this comment = to refer to browser-based OAuth clients generally?

=C2=A0 -Josh

On Fri, Jul = 1, 2016 at 5:45 PM, John Bradley <ve7jtb@v= e7jtb.com> wrote:
I don=E2=80=99t think the post response mode is support= ed by heart so I suspect that we are talking about different things.
You are probably using the supported code flow = that uses a 302 get to return the code to the OAuth client on the server. = =C2=A0
The Web server is then acting as a confidential client to = exchange the code via a POST (different POST) with the AS token_endpoint.

The Token endpoint will return a acc= ess token (AT) and optional refresh token (RT).

The web page may be getting the server to make the OAuth calls= on it=E2=80=99s behalf to the Resource Server, or possibly you are passing= the AT from the server back to a Java script app that is using CORES to ma= ke calls directly to the RS without going through the Web server.

Passing the AT back to the user agent from t= he client is not recommended.=C2=A0

For in browser clients where the JS is using the AT to make the calls dire= ctly to the RS via CORES the recommended approach is to use the fragment en= coded response via a 302 to deliver the AT directly to the client (It never= hits the backend Web server).

Howe= ver I believe In browser OAuth clients are not currently supported in HEART= , so I am not quite sure what you are doing.

<= /div>
Perhaps Justin has a better answer.

=
John B.


On Jul 1, 2016, at 5:33 PM= , Josh Mandel <jmandel@gmail.com> wrote:

John,

I= appreciate your response. I'm hoping you can clarify why you say that = "HTTP POST... won't work well for... [a] single page OAuth client&= quot;?

We commonly build single-page apps= that act as OAuth clients for SMART (e.g. this sample app= =C2=A0), and we've had good experience with the technique. Could you el= aborate?

=C2=A0 -J

On Fri, Jul 1, 2016 at 5:26 PM, John Bradley= <ve7jtb@ve7jtb.com> wrote:<= br clear=3D"none">
HEART only s= upports web server clients at the moment. =C2=A0 That might change in futur= e to support native apps if that an be made to support the security require= ments of Heath IT.

So the thing HTTP POST respo= nses won=E2=80=99t work well for is a type of in browser single page OAuth = client.=C2=A0 That still needs fragment encoded responses or the new post-m= essage Java Script API approach.

Jo= hn B.


=
On Jul 1, 2016, at 5:16 PM, Josh Mandel= <jmandel@gmail.com> wrote:

<= div>
Thanks Justin,

To cl= arify: John's comment and my question were about POST. (I do understand= the behavior of HTTP POST and of window.postMessage; these are totally dif= ferent things.) From my perspective in SMART Health IT, we use the OAuth 2.= 0 authorization code flow, including HTTP POST, in our authorization spec=C2=A0even for public clients, and it has= worked very well for us, with about a dozen electronic health record serve= rs supporting this approach. That's why I was curious to hear John'= s perspective about limitations.

= =C2=A0 -J

On Fri, Jul 1, 2016 at 5:09 PM,= Oleg Gryb <oleg_gryb@yahoo.com><= /span> wrote:
> POST will send things to the= server, which isn=E2=80=99t desirable if your client is solely in the brow= ser
Why it's not desirable, assuming that we disr= egard performance? You can generate HTTP POST from JS, e.g. through an AJAX= call. What is wrong with this?
<= /div>


From: Justin Richer <= jricher@mit.edu>
To: Josh Mandel <jmandel@gmail.com> <= br clear=3D"none">Cc: Oleg G= ryb <oleg@gryb.info>; "<oauth@ietf.org<= /a>>" <oauth@ietf.org>; Liyu Yi <l= iyuyi@gmail.com>
Sent: Friday, July 1, 2016 2:00 PM

Subject: Re: [OAUTH-WG] = Security concern for URI fragment as Implicit grant

POST will send = things to the server, which isn=E2=80=99t desirable if your client is solel= y in the browser. postMessage is a browser API and not to be confused with = HTTP POST. postMessage messages stay (or can stay) within the browser, whic= h is the intent here.

=C2=A0=E2=80=94 Jus= tin

O= n Jul 1, 2016, at 4:56 PM, Josh Mandel <jmandel@gmail.com> wrote:


On F= ri, Jul 1, 2016 at 4:51 PM, John Bradley <= ve7jtb@ve7jtb.com> wrote:
Yes but POST doesn't really work for in browser apps.

If it is a server app it should be using the code= flow with GET or POST as you like.

If we do a =C2=A0post message based binding it will be targeted at in brow= ser applications.

John B.

On Fri, Jul 1, 2016 at 4:42 PM, Liyu Yi <liyuyi@gmail.com> wrote:
BTW, I do not see any significant perf= ormance concerns for post. Parsing and executing the Javascript logic for p= ost operation will be on the client side, no extra server load is introduce= d.

Plus post will remove the size restric= tion of the URL length.

-- Liyu=C2=A0
On Fri, Jul 1, 2016 at 1:35 PM, Liyu Yi <liyuyi@gmail.com> wrote:
Thanks for the great comments and advices.=

I think it is a good idea for the worki= ng group to revise the fragment part in the spec, since there might be publ= ic available tools already implemented this approach and people can end up = with a solution with serious security loopholes.

The re-append issue can be mitigate by a logic on Resource Server w= hich carefully re-writes/removes the fragment in any redirect, if the the r= edirect can not be avoided.

-- Liyu
=C2=A0

On Fri, Jul 1, 20= 16 at 11:33 AM, John Bradley <ve7jtb@ve7jt= b.com> wrote:
This behaviour started changing around 2011

From HTTP/1.1
=C2=A0 =C2=A0 =C2=A0 f the Location value provided in a 3xx (Redi= rection) response does
   not have a fragment compo=
nent, a user agent MUST process the
   redirection as if the value inherits the fragment component of the
   URI reference used to generate the request target (i.e., the
   redirection inherits the original reference's fragment, if any).

   For example, a GET request generated for the URI reference
   "http://www.example.org/~tim" might result =
in a 303 (See Other)
   response containing the header field:

     Location: /People.html#tim

   which suggests that the user agent redirect to
   "http://www.example.org/People.html#tim=E2=80=9D

   L=
ikewise, a GET request generated for the URI reference
   "http://www.example.org/index.html#larry=
" might result in a 301
   (Moved Permanently) response containing the header field:

     Location: http://www.example.net/index.html

   which suggests that the user agent redirect to
   "http://www.example.net/index.html#larry=
", preserving the original
   fragment identifier.


This blog also explores the change.


On Jul 1, 2016, at 1:05 PM, Oleg Gryb <ole= g_gryb@yahoo.com> wrote:

"Browsers now re-append =C2=A0fragments across 302 redirects unle= ss they are explicitly cleared this makes fragment encoding less safe than = it was =C2=A0when originally specified" - thanks Jim. Looks like a goo= d reason for vetting this flow out.

John,
Please provide more details/links about re-ap= pending fragments.=C2=A0

Thanks,
Oleg.


=
From: Jim M= anico <jim@manicode.com>
To: Oleg Gryb <oleg@gryb.i= nfo>
Cc: "oauth@ietf.org" <oauth@ietf.org<= /a>>; Liyu Yi <liyuyi@gmail.com>
= Sent: Thursday, June 30, 20= 16 10:25 PM
Subject:= Re: [OAUTH-WG] Security concern for URI fragment as Implicit gr= ant

Oleg!= Hello! Great to see you pop up here with a similar concern.

John Bradley just answered this thread with the d= etails I was looking for (thanks John, hat tip your way).

He also mentioned details about fragment leakage:

"Browsers now re-append = =C2=A0fragments across 302 redirects unless they are explicitly cleared thi= s makes fragment encoding less safe than it was when originally specified&q= uot;

Again, I'm new here= but I'm grateful for this conversation.

<= /div>
Aloha,
--
Jim Manico
@Manicode=

On Jul 1, 2016, at 1:24 AM, Oleg G= ryb <oleg_gryb@yahoo.com> wrote:
=
We've discusse= d access tokens in URI back in 2010 (https://www.ietf.org/mail-archive/web/oauth/current/m= sg04043.html). There were two major objectives when I was saying that i= t's not secure:

1. Fragment is not sent to a server by a browser. When I've as= ked if this is true for every browser in the world, nobody was able to answ= er.
2. Replacing with POST would mean a significant p= erformance impact in some high volume implementations (I think it was Goole= folks who were saying this, but I don't remember now).

AFAIR, nobody was arguin= g about browsing history, so it's valid.

So, 6 years later we're at square one= with this and I hope that this time the community will be more successful = with getting rid of secrets in URL.

BTW, Jim, if you can come up with other scenarios = when fragments can leak, please share. It'll probably help the communit= y with solving this problem faster than in 6 years.
<= br clear=3D"none">
Thanks,
Oleg= .


<= span style=3D"font-weight:bold">From: Jim Manico <= jim@manicode.com>
To: Liyu Yi <liyuyi@gmail.com>; oauth@ietf.org
Sent: Wednesday, June 29, 2016 7:30 AM
= Subject: Re: [OAUTH-WG] Securit= y concern for URI fragment as Implicit grant

> Shouldn=E2=80=99t it be more secure if we change to use a post method for access token, similar to the SAML does?
I say yes. But please note I'm very new at this and someone wi= th more experience will have more to say or correct my comments.
Here are a few more details to consider.
1) OAuth is a framework and not a standard, per se. Different authorization servers will have different implementations that are not necessarily compatible with other service providers. So there is no standard to break, per se.
2) Sensitive data in a URI is a bad idea. They leak all over the place even over HTTPS. Even in fragments.
3) Break the "rules" and find a way to submit sensitive = data like access tokens, session information or any other (even short term) sensitive data in a secure fashion. This includes POST, JSON data payloads over PUT/PATCH and other verbs - all over well configured HTTPS.
4) If you really must submit sensitive data over GET , consider JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level confidentiality and integrity.
Aloha,
Jim Manico
Manicode Security
https://www.manicode.com

On 6/27/16 9:30 PM, Liyu Yi wrote:
While we are working on a project with OAuth2 implementation, one question arises from our engineers.
=C2=A0=C2=A0
(C)=C2=A0 Assuming the resource owner grants access, the authorization
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 server redire= cts the user-agent back to the client using the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 redirection U= RI provided earlier.=C2=A0 The redirection URI includes
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the access to= ken in the URI fragment.
=C2=A0
For my understanding, the browser keeps the URI fragment in the history, and this introduces unexpected exposure of the access token. A user without authorization for the resource can get the access token as long as he has the access to the browser. This can happen in a shared computer in library, or for an IT staff who works on other employee=E2=80=99s computer.
=C2=A0
Shouldn=E2=80=99t it be more secure if we change to use a post method for access token, similar to the SAML does?
I feel there might be something I missed here. Any advices will be appreciated.


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


--=20




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


=





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


_______________________________________________
OAuth mai= ling list
OAuth@ietf.org
<= a rel=3D"nofollow" shape=3D"rect" href=3D"https://www.ietf.org/mailman/list= info/oauth" target=3D"_blank">https://www.ietf.org/mailman/listinfo/oauth


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



_______________________________________________
OAuth mai= ling list
OAuth@ietf.org
<= a rel=3D"nofollow" shape=3D"rect" href=3D"https://www.ietf.org/mailman/list= info/oauth" target=3D"_blank">https://www.ietf.org/mailman/listinfo/oauth








_______________________________________________
OAuth mailing list
OAuth@ietf.org<= br clear=3D"none">https://www.ietf.org/mailm= an/listinfo/oauth
--001a114ddbaa70d1f005369d24eb-- From nobody Thu Jul 7 16:04:35 2016 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3905C128B44; Thu, 7 Jul 2016 16:04:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160707230433.18694.92697.idtracker@ietfa.amsl.com> Date: Thu, 07 Jul 2016 16:04:33 -0700 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mix-up-mitigation-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 23:04:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol of the IETF. Title : OAuth 2.0 Mix-Up Mitigation Authors : Michael B. Jones John Bradley Nat Sakimura Filename : draft-ietf-oauth-mix-up-mitigation-01.txt Pages : 14 Date : 2016-07-07 Abstract: This specification defines an extension to The OAuth 2.0 Authorization Framework that enables the authorization server to dynamically provide the client using it with additional information about the current protocol interaction that can be validated by the client and that enables the client to dynamically provide the authorization server with additional information about the current protocol interaction that can be validated by the authorization server. This additional information can be used by the client and the authorization server to prevent classes of attacks in which the client might otherwise be tricked into using inconsistent sets of metadata from multiple authorization servers, including potentially using a token endpoint that does not belong to the same authorization server as the authorization endpoint used. Recent research publications refer to these as "IdP Mix-Up" and "Malicious Endpoint" attacks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-mix-up-mitigation/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-oauth-mix-up-mitigation-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-mix-up-mitigation-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jul 7 16:09:19 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B15F5128B44 for ; Thu, 7 Jul 2016 16:09:16 -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 5b3FMydtc_bP for ; Thu, 7 Jul 2016 16:09:14 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0131.outbound.protection.outlook.com [104.47.42.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A225D127071 for ; Thu, 7 Jul 2016 16:09:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=E+ajrPf6Y7wVf5Vkrdr3qppbJKr2KmxKcNajjPp7pJ8=; b=nvssiiTxg7vmTtYSqqJuyaVt1wTEAw1dIMrb01b3vI2XEHikiMG65kqkfSfWYcsbjlugZsLGPIIV26SRsEXF/rMgr/Iw1qERxsZ5C7fZdANx3bfBul+LCgopdoNht60EJjsxJYP9zj/eGmfHJ7LyPf2dfJCNBNWuzR0DWzV6xyw= 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.523.12; Thu, 7 Jul 2016 23:09:13 +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.0523.028; Thu, 7 Jul 2016 23:09:13 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: Terminology updates in OAuth Mix-Up Mitigation specification Thread-Index: AdHYoHSAQzxpSx+IT9+eFAC453JPqw== Date: Thu, 7 Jul 2016 23:09:13 +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: [2001:4898:80e8::18d] x-ms-office365-filtering-correlation-id: 0d8343fd-5ccf-458a-45a8-08d3a6bbb604 x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1648; 6:JhNfvNAGMDbZi+KpWyecpbATTb/tQKdsrURCQtuBKKHXmSwpLvyn8cXKDdkCDnwAsxGKC2p6blHcXZTmqCVTDxYvS/lnTNlIDOEHzTh0Y4bie6lEPDubwc6cd+Ov3FztjuE4ZdM5qOUadb2P167bzF9Tb/2R8rbmRdKzJcUJt9+dfjIegBjf6nBGZUTle1Zu6snPJSH9JB7/00RS3Z2vAKvSFDowgNA8E+opVHg6VpKLZKwjPHfbEVCo+l55oKmfmsKYAz2KXgUvLZgkr6cvfNL7QISVZjdY+90zvIUecV3XbZYwYuMB+H0Gw7l/LcCQ6urDGEzLzo1xCsDTZEo/Xw==; 5:bpuaioxqZ2zOwk1802n9HhDUCVWUudZIS2sbFLCy6nAil0QR0ZaabsGLOge4c6KKs2V/hKtnEDFfOpl+BElvyn5VSAxvw5XXkVzOyhns4+Fp0u71edMMLDsLQGZz6zPWo/eCqowjBTU6HuLhynsLKg==; 24:xxheSrdngjYYi4P8nuec0jX5O1OrN9rl61RAw9z9h0SqJ1nLzd6RYQ8yCbV4zK5VigeyQS2zEjG1KT+ciLyrq2wEP6lc+eVb6B019oyKPyg=; 7:bREWm0RpaY1Z6qpM9otvkTVZ2AmAA051E4la8xXlEKTFehzxlvh37gX/kB0lKeTNDO1Mz8JxAj9sor4AoKwxUH8ha1oDtarh0IYoYcemrO2RGkCHXdPVRhQIOCZd3+3wMxP0EWzrgCsk0/GtBJsg1DnxZf/Y2gErw4D1nM5HbYrZFLk29O9XgMleRz3hsF20gfE5Pp7ObYmMaDlki2i1iCgWm9mX2dFeeRqaY5/ut+TwDIfNZ0DpmUTyUsko9MVo x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1648; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(31418570063057)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:SN1PR0301MB1648; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1648; x-forefront-prvs: 0996D1900D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(209900001)(199003)(189002)(107886002)(110136002)(106356001)(19617315012)(105586002)(586003)(2351001)(229853001)(86612001)(450100001)(97736004)(99286002)(92566002)(2900100001)(189998001)(74316002)(77096005)(19625215002)(7906003)(101416001)(122556002)(15975445007)(11100500001)(7110500001)(50986999)(54356999)(19300405004)(15650500001)(33656002)(86362001)(5640700001)(76576001)(5630700001)(16236675004)(15395725005)(5005710100001)(5003600100003)(7736002)(7696003)(7846002)(5002640100001)(10090500001)(8990500004)(10290500002)(10400500002)(2420400007)(1730700003)(102836003)(3280700002)(87936001)(9686002)(8936002)(2906002)(6116002)(81166006)(81156014)(8676002)(68736007)(3660700001)(19580395003)(790700001)(2501003)(3826002)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0301MB1648; 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_SN1PR0301MB16452F12F49D49374278A119F53B0SN1PR0301MB1645_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jul 2016 23:09:13.1139 (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: Subject: [OAUTH-WG] Terminology updates in OAuth Mix-Up Mitigation specification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 23:09:17 -0000 --_000_SN1PR0301MB16452F12F49D49374278A119F53B0SN1PR0301MB1645_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The only change to the new draft is to use terminology more consistently. = Specifically, it changes the terms "issuer URL" and "configuration informat= ion location" to "issuer identifier" so that consistent terminology is used= for this. (This is the terminology used by OpenID Connect.) This is being posted in preparation for discussions at the upcoming OAuth S= ecurity Workshop in Trier, Germany and the IETF 96 meeting in Berlin. The specification is available at: * http://tools.ietf.org/html/draft-ietf-oauth-mix-up-mitigation-01 An HTML-formatted version is also available at: * http://self-issued.info/docs/draft-ietf-oauth-mix-up-mitigation-0= 1.html This notice was also posted at http://self-issued.info/?p=3D1582 and as @se= lfissued. --_000_SN1PR0301MB16452F12F49D49374278A119F53B0SN1PR0301MB1645_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The only change to the new draft is to use terminolo= gy more consistently.  Specifically, it changes the terms "issuer= URL" and "configuration information location" to "issu= er identifier" so that consistent terminology is used for this.  (This is the terminology used by OpenID Connect.)

 

This is being posted in preparation for discussions = at the upcoming OAuth Security Works= hop in Trier, Germany and the IETF 96 meeting in Berlin.=

 

The specification is available at:

·         http://tools.ietf.org/html/draft-ietf-oaut= h-mix-up-mitigation-01

 

An HTML-formatted version is also available at:=

·         http://self-issued.info/docs/draft-= ietf-oauth-mix-up-mitigation-01.html

 

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

--_000_SN1PR0301MB16452F12F49D49374278A119F53B0SN1PR0301MB1645_-- From nobody Thu Jul 7 18:32:35 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4449112D8F1 for ; Thu, 7 Jul 2016 18:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.747 X-Spam-Level: X-Spam-Status: No, score=-3.747 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJSxP0z5OxBg for ; Thu, 7 Jul 2016 18:32:31 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (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 8D4C712D8F2 for ; Thu, 7 Jul 2016 18:32:31 -0700 (PDT) X-AuditID: 1209190d-f8bff7000000410b-0c-577f02addf5b 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 C8.83.16651.DA20F775; Thu, 7 Jul 2016 21:32:30 -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 u681WTHo001961 for ; Thu, 7 Jul 2016 21:32:29 -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 u681WRmL020177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 7 Jul 2016 21:32:28 -0400 To: OAuth WG From: Justin Richer Message-ID: <9635afb2-a03b-a7a4-d722-8756b9cf5552@mit.edu> Date: Thu, 7 Jul 2016 21:32:19 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPIsWRmVeSWpSXmKPExsUixG6noruOqT7coHm9sMXJt6/YHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsWDvU9aCvYwVE5p3sjcwzmDsYuTkkBAwkXjTOZOti5GLQ0ig jUniytrpbCAJIYGjjBK31ulDJD4wSVybfIMZJCEiICsx/9JWFhCbTUBVYvqaFiYQW1hAXeLw 2XawGl4BK4nFb7axgtgsAioSe5deA9rGwSEqECOxvi8BokRQ4uTMJ2BjmAXMJOZtfsgMYctL bH87h3kCI+8sJGWzkJTNQlK2gJF5FaNsSm6Vbm5iZk5xarJucXJiXl5qka6RXm5miV5qSukm RlAocUry7mD8d9frEKMAB6MSD++PvNpwIdbEsuLK3EOMkhxMSqK8Cv514UJ8SfkplRmJxRnx RaU5qcWHGCU4mJVEeDcz1IcL8aYkVlalFuXDpKQ5WJTEeWNuHg0TEkhPLEnNTk0tSC2Cycpw cChJ8PYzAjUKFqWmp1akZeaUIKSZODhBhvMADX8KUsNbXJCYW5yZDpE/xWjM8WzatbVMHAt+ 3F7LJMSSl5+XKiXOKwJSKgBSmlGaBzcNlA4S3h42fcUoDvScMK8vSBUPMJXAzXsFtIoJaNVP l2qQVSWJCCmpBsZTDjdftnnWBMZv23ZyYWjsn/Zbi9qKnf9x+ylfeCY6K0o1v2nijmov0yX5 m+90q+yr2Sq+f9vE/+lzt6Sytpq+vq8rt9hka5711RsC6xn/qU/cmRe2c0fJz4ytdyffvCF/ o5ZzyowtXz9pVt636RMzSshxro6+/MPk05ndm7b+5bFOV9yoXrFEiaU4I9FQi7moOBEArQ17 mOICAAA= Archived-At: Subject: [OAUTH-WG] Small bug in HTTP Signing spec X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 01:32:33 -0000 Just had this bug reported on twitter: https://twitter.com/tcaesvk/status/751225569925144576 It's legit, I'll tweak it in the next draft, whenever that comes along. -- Justin From nobody Fri Jul 8 03:19:05 2016 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 986CC12D093; Fri, 8 Jul 2016 03:19:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160708101903.32067.39351.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2016 03:19:03 -0700 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-05.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 10:19:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol of the IETF. Title : OAuth 2.0 Token Exchange: An STS for the REST of Us Authors : Michael B. Jones Anthony Nadalin Brian Campbell John Bradley Chuck Mortimore Filename : draft-ietf-oauth-token-exchange-05.txt Pages : 30 Date : 2016-07-08 Abstract: This specification defines a protocol for a lightweight HTTP- and JSON- based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-exchange-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 8 09:50:19 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2C7512D106 for ; Fri, 8 Jul 2016 09:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.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 jZLPY2i8hliB for ; Fri, 8 Jul 2016 09:50:16 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1718012D11D for ; Fri, 8 Jul 2016 09:50:16 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id u186so13489494ita.0 for ; Fri, 08 Jul 2016 09:50:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=xi0FvWZmNkGnmhwE6QljJdN0yhE3UkW4zJdA9xbCEGc=; b=I64xtmwrHTOHn1F/QXYLu87cE7Ug4IRvpXK0OVxvmmX0/A/z0+1feM6V8agB0ElOTP Jt08hoIKAFVgKEmZkMRcxyrWaMGGD5a4m9Dv1J/7yjpJrXKUYo/efSQzfnSHXfnwi/mO 80lvt85Z6j0CZau8lL9P/eg1fGAfFTDE3DdzE= 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; bh=xi0FvWZmNkGnmhwE6QljJdN0yhE3UkW4zJdA9xbCEGc=; b=LAoJJlzsYpntYdO4FHk+VSeFHnQShZctQfgScTBZ9Uss29axLBygWlIIW0oUmTOiuj svcbDhJh+ofQDWDrnizAuURQyBtXSofaj6NXoPQz6kHcb31uaYhyMsxU0dbTgcsojQ2N 2LuZxxM649ACqvWnh7hRgPvhmGTlXh9d+Csjp93V3A5ewZ0uNolNgEa73F3vVGW6GO+k Uf5U1KCjrMkUGFaXIkgFYhF1cIDXD/G6UkmJXj8QX9so/5IcEdCAe2hWHngDOCqZGH6j ldfwcy3mYmnYy+A6BdsElvC5jlAjxWzg/v5rivdaiMCoyB9odNH/w0Qa2+zjEXrYKfEs lgzQ== X-Gm-Message-State: ALyK8tJLQdP/valxDYmAnd0pEhOgxp7lvaYzf9viw11TAghfPofiNmaGsVXLpfxJIq7rx1JZesCopDOHPbmibfRo X-Received: by 10.36.123.199 with SMTP id q190mr4433695itc.42.1467996614926; Fri, 08 Jul 2016 09:50:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.28.149 with HTTP; Fri, 8 Jul 2016 09:49:45 -0700 (PDT) In-Reply-To: <20160708101903.32067.39351.idtracker@ietfa.amsl.com> References: <20160708101903.32067.39351.idtracker@ietfa.amsl.com> From: Brian Campbell Date: Fri, 8 Jul 2016 10:49:45 -0600 Message-ID: To: oauth Content-Type: multipart/alternative; boundary=001a114762fec3c71a05372298ca Archived-At: Subject: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-token-exchange-05.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 16:50:18 -0000 --001a114762fec3c71a05372298ca Content-Type: text/plain; charset=UTF-8 Draft -05 of "OAuth 2.0 Token Exchange: An STS for the REST of Us" was published earlier this morning with the following relatively small set of changes. -05 o Defined the JWT claim "cid" to express the OAuth 2.0 client identifier of the client that requested the token. o Defined and requested registration for "act" and "may_act" as Token introspection response parameters (in addition to being JWT claims). o Loosen up the language about refresh_token in the response to OPTIONAL from NOT RECOMMENDED based on feedback form real world deployment experience. o Add clarifying text about the distinction between JWT and access token URIs. o Close out (remove) some of the Open Issues bullets that have been resolved. ---------- Forwarded message ---------- From: Date: Fri, Jul 8, 2016 at 4:19 AM Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-05.txt To: i-d-announce@ietf.org Cc: oauth@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol of the IETF. Title : OAuth 2.0 Token Exchange: An STS for the REST of Us Authors : Michael B. Jones Anthony Nadalin Brian Campbell John Bradley Chuck Mortimore Filename : draft-ietf-oauth-token-exchange-05.txt Pages : 30 Date : 2016-07-08 Abstract: This specification defines a protocol for a lightweight HTTP- and JSON- based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-exchange-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --001a114762fec3c71a05372298ca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Draft -05 of "OAuth 2.0 Token Exchange: An STS fo= r the REST of Us" was published earlier this morning=20 with the following relatively small set of changes.

   -05

   o  Defined the JWT claim "cid" to express the OAuth 2.0 client
      identifier of the client that requested the token.
   o  Defined and requested registration for "act" and "may_=
act" as
      Token introspection response parameters (in addition to being JWT
      claims).
   o  Loosen up the language about refresh_token in the response to
      OPTIONAL from NOT RECOMMENDED based on feedback form real world
      deployment experience.
   o  Add clarifying text about the distinction between JWT and access
      token URIs.
   o  Close out (remove) some of the Open Issues bullets that have been
      resolved.


---------- For= warded message ----------
From: <internet-drafts@ietf.org>
Date: Fri, Jul 8, 2016 at 4:= 19 AM
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-05= .txt
To: i-d-= announce@ietf.org
Cc: oauth@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Web Authorization Protocol of the IETF.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= OAuth 2.0 Token Exchange: An STS for the REST of Us
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Mich= ael B. Jones
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Anthony Nadalin
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Brian Campbell
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 John Bradley
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Chuck Mortimore
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-oauth-token-exchange-05.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 30
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2016-07-08

Abstract:
=C2=A0 =C2=A0This specification defines a protocol for a lightweight HTTP- = and
=C2=A0 =C2=A0JSON- based Security Token Service (STS) by defining how to re= quest
=C2=A0 =C2=A0and obtain security tokens from OAuth 2.0 authorization server= s,
=C2=A0 =C2=A0including security tokens employing impersonation and delegati= on.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/dr= aft-ietf-oauth-token-exchange/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf= -oauth-token-exchange-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?u= rl2=3Ddraft-ietf-oauth-token-exchange-05


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

--001a114762fec3c71a05372298ca-- From nobody Fri Jul 8 10:12:06 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93DDE12D580 for ; Fri, 8 Jul 2016 10:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.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 MNv8VUn0uOpc for ; Fri, 8 Jul 2016 10:12:01 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA17C12D592 for ; Fri, 8 Jul 2016 10:12:01 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id j8so2234659itb.1 for ; Fri, 08 Jul 2016 10:12:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=o14Dx3MeH2p7LgtPEaZo5QeUDUvhTvrHqP+/me08QtA=; b=DXRBrTHWuch3MaSUyCpLEIx49EPPcAbrc1BZQlKE4EkTnsbI0LZJduLzTD7yePlyId MdcQcg4nbbeuiS5zx6fI+zWo+v8NE0OylGfZCL704Jb6DXY4DG5CdWZDEV2Es1IBTgsA wTHfh6BMm19R0pKhvBKtddRtBkvUOaXPpMNaw= 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=o14Dx3MeH2p7LgtPEaZo5QeUDUvhTvrHqP+/me08QtA=; b=ECavLawUn2XZ0q8bSr62+02LvkE5RkeiiaHV3jMfnDsj7/DXiU3D46Qr2xcIm3+WmE ksRYG4n4/0zi+HhS9JKZhPVN7vG0dHv5bZtSGIWbynoURvoGe7feUszB5SNgQ8K+sRX4 swPZTrQRSS9W2+YQk8sPWUjW4j8ZUHvOahnoXZ2BEDPEM87CzPRoITf5VxOP7gKanjaI eGijfzS3mGPyXMNAIyBMXY0OYda9/k/MB6zUmAXeMXrw67jMrlBBQFMha2yiyuLgMDZj /LHczjEbmd8ynCy5VBkn5/MVKimShk1KLZKBWAMTNnlsig7EDilGayL34+Is8wWhaglK /oTw== X-Gm-Message-State: ALyK8tIVSLw/I159uU1q6b3ecTTo78igw7kU5TXGLUGS6HxikF9e5Hp/lVChS1iVMeh7hyHtJSFPaFhjNqpYu1GP X-Received: by 10.36.110.142 with SMTP id w136mr4502445itc.63.1467997920833; Fri, 08 Jul 2016 10:12:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.120.194 with HTTP; Fri, 8 Jul 2016 10:11:30 -0700 (PDT) In-Reply-To: References: <20160708162532.32067.26007.idtracker@ietfa.amsl.com> From: Brian Campbell Date: Fri, 8 Jul 2016 11:11:30 -0600 Message-ID: To: oauth Content-Type: multipart/alternative; boundary=001a11485f429a4ca0053722e6e2 Archived-At: Cc: "oauth-chairs@tools.ietf.org" Subject: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-tbpkce-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 17:12:03 -0000 --001a11485f429a4ca0053722e6e2 Content-Type: text/plain; charset=UTF-8 This extremely short draft is an initial take at utilizing Token Binding for PKCE. Charis, I'd like to request a small chunk of time in Berlin to present this as part of the wider conversation around the applications of Token Binding to OAuth. Thanks! ---------- Forwarded message ---------- From: Date: Fri, Jul 8, 2016 at 10:25 AM Subject: New Version Notification for draft-campbell-oauth-tbpkce-00.txt To: <...> A new version of I-D, draft-campbell-oauth-tbpkce-00.txt has been successfully submitted by Brian Campbell and posted to the IETF repository. Name: draft-campbell-oauth-tbpkce Revision: 00 Title: A Token Binding method for OAuth 2.0 Proof Key for Code Exchange Document date: 2016-07-08 Group: Individual Submission Pages: 5 URL: https://www.ietf.org/internet-drafts/draft-campbell-oauth-tbpkce-00.txt Status: https://datatracker.ietf.org/doc/draft-campbell-oauth-tbpkce/ Htmlized: https://tools.ietf.org/html/draft-campbell-oauth-tbpkce-00 Abstract: This specification describes a Proof Key for Code Exchange (PKCE) [RFC7636] method utilizing Token Binding over HTTP [I-D.ietf-tokbind-https] to cryptographically bind the OAuth 2.0 [RFC6749] authorization code to a key pair on the client, which it proves possession of during the access token request with the authorization code. 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 --001a11485f429a4ca0053722e6e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This extremely short draft is an initial take at= utilizing Token Binding for PKCE.

Charis, I'd like to re= quest a small chunk of time in Berlin to present this as part of the wider = conversation around the applications of Token Binding to OAuth.

Thanks!
---------- Forwarded message ----------
Fro= m: <internet-drafts@ietf.org= >
Date: Fri, Jul 8, 2016 at 10:25 AM
Subject: New Version N= otification for draft-campbell-oauth-tbpkce-00.txt
To: <...>


A new version of I-D, draft-campbell-oauth-tbpkce-00.txt
has been successfully submitted by Brian Campbell and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-campbell-oauth-tbpkce Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A Token Binding method for OAuth 2= .0 Proof Key for Code Exchange
Document date:=C2=A0 2016-07-08
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 5
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-campbell-oauth-= tbpkce-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-campbell-oauth-tbpkce/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https:= //tools.ietf.org/html/draft-campbell-oauth-tbpkce-00


Abstract:
=C2=A0 =C2=A0This specification describes a Proof Key for Code Exchange (PK= CE)
=C2=A0 =C2=A0[RFC7636] method utilizing Token Binding over HTTP
=C2=A0 =C2=A0[I-D.ietf-tokbind-https] to cryptographically bind the OAuth 2= .0
=C2=A0 =C2=A0[RFC6749] authorization code to a key pair on the client, whic= h it
=C2=A0 =C2=A0proves possession of during the access token request with the<= br> =C2=A0 =C2=A0authorization code.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



--001a11485f429a4ca0053722e6e2-- From nobody Fri Jul 8 10:14:40 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A4BC12D1A2 for ; Fri, 8 Jul 2016 10:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.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 XTOaL0N7EE5R for ; Fri, 8 Jul 2016 10:14:36 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1523312D0BF for ; Fri, 8 Jul 2016 10:14:36 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id u186so14049590ita.0 for ; Fri, 08 Jul 2016 10:14:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bcWnxPrW0AphUrOswCv3P5EPjliWhYvu/0O2cNSLybA=; b=dEt8HixrHNRJp1XPB98CvN/dwFcKaw5AFiS7jStVEClEz4PRFA7BOFbJoH50QpvdCA 1Jo0JLWVBkwnrESeB7OWfLS1jJKY7Y+eeWWtE2PVlaD6UL5zkpjvQWowtMOQHyNtdo7w vH1r+zyhZ8WwfPtWh4UWj1W96pMRg/lwgC6A0= 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=bcWnxPrW0AphUrOswCv3P5EPjliWhYvu/0O2cNSLybA=; b=H4shTTy3u/yz2ANQ34wU9p4fOHPVdX+hqmMdkH3/VgWlz4rSrMEDB11jhwH5lVu6vQ mlao8+EcMwgnqbyFNK/OM8Cb84UH6ofIxYW2gh5J8maia67cQ3siatl7Izj7mEHf9Hmz q31CHmUFl/TedqGTJkVNL/Q7SdSee92OsodUh6iLawbbe/hsE2mulGMgqv+5c8kzzfTw 1X118o9CwyOeflLXG4wIEupEfVfKOBZQ+umFRd1Yj5W1UvpwTUWc3j7H5h61hqwLCMoq MQG75tW5XTteFvlPaLJNsfq6g5/yRlyRPiJEIFBI1rU/y/sfdNv+yNwrFtrUM9hVeNeS pdag== X-Gm-Message-State: ALyK8tJhgtNo0ht/WdZ1CawFTW+ALPtu/1tYnX7N5anUq44n2T4BZ259Aj6wTp/parqPancyp+XOr4+b512QthjJ X-Received: by 10.36.123.199 with SMTP id q190mr4564950itc.42.1467998075334; Fri, 08 Jul 2016 10:14:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.120.194 with HTTP; Fri, 8 Jul 2016 10:14:05 -0700 (PDT) In-Reply-To: References: <20160708162532.32067.26007.idtracker@ietfa.amsl.com> From: Brian Campbell Date: Fri, 8 Jul 2016 11:14:05 -0600 Message-ID: To: oauth Content-Type: multipart/alternative; boundary=001a114762fecfe0c9053722efa0 Archived-At: Cc: "oauth-chairs@tools.ietf.org" Subject: Re: [OAUTH-WG] New Version Notification for draft-campbell-oauth-tbpkce-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 17:14:38 -0000 --001a114762fecfe0c9053722efa0 Content-Type: text/plain; charset=UTF-8 :s/Charis/Chairs/ On Fri, Jul 8, 2016 at 11:11 AM, Brian Campbell wrote: > This extremely short draft is an initial take at utilizing Token Binding > for PKCE. > > Charis, I'd like to request a small chunk of time in Berlin to present > this as part of the wider conversation around the applications of Token > Binding to OAuth. > > Thanks! > > ---------- Forwarded message ---------- > From: > Date: Fri, Jul 8, 2016 at 10:25 AM > Subject: New Version Notification for draft-campbell-oauth-tbpkce-00.txt > To: <...> > > > > A new version of I-D, draft-campbell-oauth-tbpkce-00.txt > has been successfully submitted by Brian Campbell and posted to the > IETF repository. > > Name: draft-campbell-oauth-tbpkce > Revision: 00 > Title: A Token Binding method for OAuth 2.0 Proof Key for Code > Exchange > Document date: 2016-07-08 > Group: Individual Submission > Pages: 5 > URL: > https://www.ietf.org/internet-drafts/draft-campbell-oauth-tbpkce-00.txt > Status: > https://datatracker.ietf.org/doc/draft-campbell-oauth-tbpkce/ > Htmlized: https://tools.ietf.org/html/draft-campbell-oauth-tbpkce-00 > > > Abstract: > This specification describes a Proof Key for Code Exchange (PKCE) > [RFC7636] method utilizing Token Binding over HTTP > [I-D.ietf-tokbind-https] to cryptographically bind the OAuth 2.0 > [RFC6749] authorization code to a key pair on the client, which it > proves possession of during the access token request with the > authorization code. > > > > > 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 > > > > --001a114762fecfe0c9053722efa0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
:s/Charis/Chairs/


On Fri, Jul 8, 2016 at 11:11 AM, = Brian Campbell <bcampbell@pingidentity.com> wrote:<= br>
This extremely= short draft is an initial take at utilizing Token Binding for PKCE.
Charis, I'd like to request a small chunk of time in Berlin to = present this as part of the wider conversation around the applications of T= oken Binding to OAuth.

Thanks!

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: F= ri, Jul 8, 2016 at 10:25 AM
Subject: New Version Notification for draft-= campbell-oauth-tbpkce-00.txt
To: <...&g= t;



A new version of I-D, draft-campbell-oauth-tbpkce-00.txt
has been successfully submitted by Brian Campbell and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-campbell-oauth-tbpkce Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A Token Binding method for OAuth 2= .0 Proof Key for Code Exchange
Document date:=C2=A0 2016-07-08
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 5
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-campbell-oauth-= tbpkce-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-campbell-oauth-tbpkce/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https:= //tools.ietf.org/html/draft-campbell-oauth-tbpkce-00


Abstract:
=C2=A0 =C2=A0This specification describes a Proof Key for Code Exchange (PK= CE)
=C2=A0 =C2=A0[RFC7636] method utilizing Token Binding over HTTP
=C2=A0 =C2=A0[I-D.ietf-tokbind-https] to cryptographically bind the OAuth 2= .0
=C2=A0 =C2=A0[RFC6749] authorization code to a key pair on the client, whic= h it
=C2=A0 =C2=A0proves possession of during the access token request with the<= br> =C2=A0 =C2=A0authorization code.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




--001a114762fecfe0c9053722efa0-- From nobody Fri Jul 8 10:39:57 2016 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6904512D819; Fri, 8 Jul 2016 10:39:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160708173952.32143.79722.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2016 10:39:52 -0700 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-amr-values-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 17:39:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol of the IETF. Title : Authentication Method Reference Values Authors : Michael B. Jones Phil Hunt Anthony Nadalin Filename : draft-ietf-oauth-amr-values-01.txt Pages : 12 Date : 2016-07-08 Abstract: The "amr" (Authentication Methods References) claim is defined and registered in the IANA "JSON Web Token Claims" registry but no standard Authentication Method Reference values are currently defined. This specification establishes a registry for Authentication Method Reference values and defines an initial set of Authentication Method Reference values. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-oauth-amr-values-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-amr-values-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 8 10:47:42 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 299C012D8F1 for ; Fri, 8 Jul 2016 10:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e6Tn0GgjqGPv for ; Fri, 8 Jul 2016 10:47:19 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0093.outbound.protection.outlook.com [104.47.41.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63F7412D800 for ; Fri, 8 Jul 2016 10:47:19 -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=awA49UnguRmQtcV5SLmFyo36BikuS0ICKw0ycFEC+IA=; b=Ux7MRfKmmtEpJqsnd9vIGKYE/yQo3gZl/f+a50bpDBu+NCuXqtT8tcQPlIgXFDq6Wq5C+DKkyeicKR00BN0qYKw1GIyRShqYn+AGYY3DoIhcFfRUSdQxopN7uBjutJNGvzggT14Vul+vpshTz088hKP3Shcf8E6rcp8eLchm6GM= 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.523.12; Fri, 8 Jul 2016 17:47: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.0523.028; Fri, 8 Jul 2016 17:47:17 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: =?Windows-1252?Q?=93amr=94_Values_specification_distinguishing_between_ir?= =?Windows-1252?Q?is_and_retina_scan_biometrics?= Thread-Index: AdHYsCN1R0bSYSG8Qb2cr4AaotZ0Iw== Date: Fri, 8 Jul 2016 17:47:17 +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: [2001:4898:80e8:d::18d] x-ms-office365-filtering-correlation-id: 007c10db-2582-467e-f348-08d3a757e781 x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1645; 6:wMo475AA/BUcHh+hxGaV5q2f3jCHV8jV18yzdQ81yVmfKFCUr91iEJQy7syN+Ew1MqOuJlgMs/FkhO6hIamDodJzhoaNyqPn+US6Cac+mTU01NkoDNtp2HQdU+4RkMKHBtHpaE0jCvDX01vL6H143EJW9K2SaYvWMjlMGl7KJ7hz45bEF9FHxjh7FX6uakppGs7zUwWKKMFt6WgsjJ2HwbU0ua4xDpoWEsJhOpHuGdaMyocCESiLP0yS27VB1FuYQpdeLdHxU4/dymnaZQbORGFKEgF14GAyP60y010+jtTsFE2C7IahQ7soVevggZkdsV2q0D1IXvDT2s4/Iefm5g==; 5:oB1JWKwlBPDYt9XXgnmsOc2BEtnNRAYzci6gSm+GBWxn3JEKHMFTUO8EtkS6MYpAeE0Wj6Ve1uGEbRh2oFXnw1jUsoTnryog9V/m6ZlhISgVenyWlvkD4HVBYF/YZIAnCCoCHBZrfpfcXLuC1HqCKg==; 24:afIm/7nCjhbd86WOjzb97kIF9IglF0uGtIVIL7LFBHD1JgD4DrFAMUwZDi71twrnJVfuo0uxMIXDftMOPQ1gtvCZjZQGqG3eDl47fzZYaw4=; 7:KPGiIffccUPujM40DK/YZSE+0dTRHC4PgERWnPxlcnQUCSrgBzb7tKZYSKdPuTZeVtGhuTXMdAyDp858meKBLfYMPQxU+Cau+2vvS+c6PuzfsjHh2AsI2wNgnlFCPiyblqqTxyj2cup7z44fDXp3cuoA1SK6y0vaICjwS2ZGjR+ylTEdWnPenqJH4I0fSVtLq+nN4F8EgC/685tFN3EiCCdc+MS/p4ZhJaoTbqBz29u9Je5eTysLJUCeGfv/Onw0 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1645; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(31418570063057)(63843785518722)(21748063052155)(21532816269658); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:SN1PR0301MB1645; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1645; x-forefront-prvs: 0997523C40 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(209900001)(199003)(189002)(229853001)(87936001)(19617315012)(3280700002)(19625215002)(33656002)(99286002)(68736007)(8990500004)(107886002)(122556002)(5005710100001)(8936002)(105586002)(2501003)(81156014)(106356001)(50986999)(3660700001)(11100500001)(16236675004)(86362001)(10090500001)(2351001)(5640700001)(9686002)(6116002)(102836003)(74316002)(77096005)(790700001)(5002640100001)(450100001)(7846002)(86612001)(92566002)(7906003)(15975445007)(7736002)(2900100001)(2906002)(7696003)(5003600100003)(97736004)(189998001)(76576001)(54356999)(101416001)(110136002)(5630700001)(19300405004)(586003)(19580395003)(10400500002)(1730700003)(81166006)(10290500002)(3826002)(6606295002); 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_SN1PR0301MB164584FFA145C0464FB1D52CF53C0SN1PR0301MB1645_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2016 17:47:17.5466 (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: [OAUTH-WG] =?windows-1252?q?=93amr=94_Values_specification_distin?= =?windows-1252?q?guishing_between_iris_and_retina_scan_biometrics?= X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 17:47:22 -0000 --_000_SN1PR0301MB164584FFA145C0464FB1D52CF53C0SN1PR0301MB1645_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable This draft distinguishes between iris and retina scan biometrics, as reques= ted by NIST, and adds a paragraph providing readers more context at the end= of the introduction, which was requested by the chairs during the call for= adoption. The OpenID Connect MODRNA Authentication Profile 1.0 s= pecification, which uses =93amr=94 values defined by this specification, is= now also referenced. The specification is available at: =B7 http://tools.ietf.org/html/draft-ietf-oauth-amr-values-01 An HTML-formatted version is also available at: =B7 http://self-issued.info/docs/draft-ietf-oauth-amr-values-01.htm= l -- Mike P.S. This notice was also posted at http://self-issued.info/?p=3D1586 and = as @selfissued. --_000_SN1PR0301MB164584FFA145C0464FB1D52CF53C0SN1PR0301MB1645_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

This draft distinguishes between iris and retina sca= n biometrics, as requested by NIST, and adds a paragraph providing readers = more context at the end of the introduction, which was requested by the cha= irs during the call for adoption.  The OpenID Connect MODRNA Authentication Profile 1.0 specification, which u= ses =93amr=94 va= lues defined by this specification, is now also referenced.

 

The specification is available at:

=B7         http://tools.ietf.org/html/draft-ietf-oauth-amr-v= alues-01

 

An HTML-formatted version is also available at:=

=B7         http://self-issued.info/docs/draft-ietf-oa= uth-amr-values-01.html

 

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

 

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

 

--_000_SN1PR0301MB164584FFA145C0464FB1D52CF53C0SN1PR0301MB1645_-- From nobody Fri Jul 8 11:08:55 2016 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1E412D51C; Fri, 8 Jul 2016 11:08:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160708180851.32116.84813.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2016 11:08:51 -0700 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-discovery-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 18:08:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol of the IETF. Title : OAuth 2.0 Authorization Server Discovery Metadata Authors : Michael B. Jones Nat Sakimura John Bradley Filename : draft-ietf-oauth-discovery-03.txt Pages : 22 Date : 2016-07-08 Abstract: This specification defines a discovery metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-discovery/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-oauth-discovery-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-discovery-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 8 11:45:52 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70EC012D74A for ; Fri, 8 Jul 2016 11:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 vr3FuCpTAoYT for ; Fri, 8 Jul 2016 11:45:48 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0104.outbound.protection.outlook.com [104.47.40.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E195D12D590 for ; Fri, 8 Jul 2016 11:45:47 -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=XQCKmNsQzUnOli7p7jXx47E+4xv5VGIuzts6jbXApl8=; b=mzsmqfwGafgmnPth4D8rYU304wZSfbz8qMtBniYuLYglaYrLlvJEJRC+lZWFGcyrYHyq8nR3WmOQkaLcGS5JhU4fnQSCDR/hrNrxStmfwP2MlX5k6xO/Ob9dD0wxIjS2GCZPKCxy9tRmaS8RH70CTK7qSXrHn+ic9c8DEro6U8c= 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.523.12; Fri, 8 Jul 2016 18:45:46 +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.0523.028; Fri, 8 Jul 2016 18:45:46 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-discovery-03.txt Thread-Index: AQHR2UPWIGN4si1loE6ze9bW2uNuiKAO3tXQ Date: Fri, 8 Jul 2016 18:45:46 +0000 Message-ID: References: <20160708180851.32116.84813.idtracker@ietfa.amsl.com> In-Reply-To: <20160708180851.32116.84813.idtracker@ietfa.amsl.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: [2001:4898:80e8:d::18d] x-ms-office365-filtering-correlation-id: 8dfefac4-81d3-4c44-ff4e-08d3a7601305 x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1645; 6:IH32mwcuYx8Y1TBGT89F3vcWW8D6w8z9tNAAs3GX6zaaaGDn6WOUFcHUnzK2emn2cRcNvPEX45MrnWSGhoOpLtQM03dH3Pzpw7LxhEE1DQI2XcL+31Mz9Vm2Ut+orXrRIpfPyXN6NUzx0rfazzO53JJgSoKx3LhU9GHTBrD45WFXbSfeCDLt6IGKLTg9GyfUMMXflS5/EN4MxjcnCJsn1twFZXpfz7cH15w7cofXWWTGQC7RyAcZRV7SWEfKEQfbB/+wb+v2YCNYa4il6uTGMCvZZ81YDJBpl51YbuGMgEqq5VDlceLODBxu7kIIXVBkhtBJXldqD7Rp13lPgqvS6Q==; 5:U5Q2DZ8lhV2b/n6cA8iMMYRPnDplnuOplhvMTDDLI1rObQL6LQTRpUw1205im3lHEOenM6lDLme125CcjeqeeaBgnkXffFWWfT4uecF/qodJLsa3STVdgjOlNSJ/86ToPIlPFOPIroPs5UZfXOSSWA==; 24:OZuX5bJ4GZ3Z00IF6exf1B37/udnsJYw8cPvxfN4eQQh2G0kzA0Wqz4rVIi6d2mZz8Ipe8eeY1KIYIjcZcOMnWTdoGvCMPqAZd9vp2ZQaPg=; 7:nXor9kW7Wf1CeFSGEwh8wi+FXKvuxu3stEnJa95JxcjM3MPTWpH3xxyghRIdZJiwleWK9ZUXtQPE48UMJqn8cRGDe9Y2NTDaMMWe4K0Kcljqg4YVX7KFHtFULwRcEtwVFGGeF2UvkADecBj7nadwj7ml6/Y1vwKxRuNlbSAggBUWqTOdRctdts2H2vM+B1uvfeQMlYzv+lEGxBAgSo/dYhx+ieeI48nQH52LielZ1s/yJnYBUMvrNhGHoXzObJPh x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1645; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(120809045254105)(35073007944872); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:SN1PR0301MB1645; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1645; x-forefront-prvs: 0997523C40 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(13464003)(199003)(377424004)(189002)(87936001)(3280700002)(33656002)(99286002)(68736007)(8990500004)(122556002)(5005710100001)(8936002)(105586002)(2501003)(230783001)(81156014)(2351001)(106356001)(50986999)(106116001)(3660700001)(11100500001)(86362001)(10090500001)(9686002)(102836003)(6116002)(74316002)(77096005)(5002640100001)(19580405001)(7846002)(86612001)(92566002)(15975445007)(4326007)(2950100001)(7736002)(2906002)(2900100001)(7696003)(305945005)(5003600100003)(97736004)(189998001)(76576001)(76176999)(54356999)(101416001)(110136002)(586003)(8676002)(19580395003)(10400500002)(1730700003)(81166006)(10290500002)(5640700001)(3826002); 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2016 18:45:46.6080 (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: [OAUTH-WG] I-D Action: draft-ietf-oauth-discovery-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 18:45:50 -0000 This version just changed the term "issuer URL" to "issuer identifier" for = terminology consistency, paralleling the same terminology consistency chang= e in the mix-up mitigation spec. I also added Hans Zandbelt to the acknowl= edgements. -- Mike -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of internet-drafts@ie= tf.org Sent: Friday, July 8, 2016 11:09 AM To: i-d-announce@ietf.org Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-discovery-03.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol of the IETF. Title : OAuth 2.0 Authorization Server Discovery Metadata Authors : Michael B. Jones Nat Sakimura John Bradley Filename : draft-ietf-oauth-discovery-03.txt Pages : 22 Date : 2016-07-08 Abstract: This specification defines a discovery metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-discovery/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-oauth-discovery-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-discovery-03 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From nobody Fri Jul 8 13:24:18 2016 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AFFD912D865; Fri, 8 Jul 2016 13:24:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160708202417.32095.24949.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2016 13:24:17 -0700 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-08.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 20:24:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol of the IETF. Title : OAuth 2.0 Proof-of-Possession (PoP) Security Architecture Authors : Phil Hunt Justin Richer William Mills Prateek Mishra Hannes Tschofenig Filename : draft-ietf-oauth-pop-architecture-08.txt Pages : 23 Date : 2016-07-08 Abstract: The OAuth 2.0 bearer token specification, as defined in RFC 6750, allows any party in possession of a bearer token (a "bearer") to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens must be protected from disclosure in transit and at rest. Some scenarios demand additional security protection whereby a client needs to demonstrate possession of cryptographic keying material when accessing a protected resource. This document motivates the development of the OAuth 2.0 proof-of-possession security mechanism. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-pop-architecture-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 8 13:26:08 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E13E12D923 for ; Fri, 8 Jul 2016 13:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.027 X-Spam-Level: X-Spam-Status: No, score=-4.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, 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 LV4QmdDRAbB9 for ; Fri, 8 Jul 2016 13:26:04 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FF7312D86C for ; Fri, 8 Jul 2016 13:26:04 -0700 (PDT) Received: from [192.168.10.131] ([80.92.118.242]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MJByE-1bOMQy0MuY-002qr4 for ; Fri, 08 Jul 2016 22:26:02 +0200 To: "oauth@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <57800C57.10909@gmx.net> Date: Fri, 8 Jul 2016 22:25:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="946af974WPDhv3vrALaCVrGw5Ix9QWfoK" X-Provags-ID: V03:K0:insuAczHZW3Hjnkxb0iQfb9Z3V8k+KoSXDZjIHb9ZSoAfWIofS7 AU9sJ1pE4vOw8A+gtEnD1iwRcsH3jerkz/XFdmdfMwffENhL9ZRPx9k6no7ExWGmcQN1MoJ V2u+68L28XWnUDP9WXd7SiV96wfER2+2ZH5Br5Mjx4YkLwCWp7lCYOIRP/+BvTQKuJZUoRp hrM7UpxZqb/bZfQl2niQg== X-UI-Out-Filterresults: notjunk:1;V01:K0:yy9KwlXhHrg=:8WQoABkva41JuIdy2ctpOm KmsbDrwo0YhNGlki5lrZfruIAKianzr5iDyltAei7locZJ5ZWjxGFCJNrmoCcYQh/rY/0R7nD e5hx0yup4AyehaWOY53GNO+0mvVwUeuRMjWfvBaAtY6F1J+9bLG8QhTzQv92iqkPtm6lQnugL x6AUAc+fsEfqcBtra8BYWU+0IU3Y7336Yy07fYD5wWUmANowfmXhRrFZ2Uv8QdtZi+CNEE552 TzTTp+8dp0vBKawT1YzKujpL29LGoiDqbkIKN9mVCN251Snn0Qta2LCTDsiZMMtc1sCqDrsE5 TD/Z4PNEpKUG084q4wdz5YFu8NGoE4sWrLMXmy9V1VIpSkFrogTsQ+U8eG361Fqrkf31dfnsJ Kcv0cVTdcm4S+iYu25UqbhXjcRekWjUBeLOFHA6FsdALOZRc1YrC4i9raC7Qf8uh8LKFV0nK3 s1dK+15JOlRINQYzXJrfnRImMK+jM691OynhGRYT36x0JNTHbgj2jJpka+eyUBxYirQIkEZzg 6+e1IO+5egof9WGxJSbIwzbYEXA/iEhE7ZiIzSKGvyma/dMGa7AUpERwwIGWRf/PkrBalKn3g B2bMCB0vpTcykesfua/8jB9+3L8AbTIa+qdFUsl5wbUeMYCZ6MNCnuiyriub3c58B4j609jcQ 3GuzgA5lHjZ988dzHC4xNjxEMGYT0jfVjPG8WSQPFMa5UaXPlEsW6V6ZcMSZCbeQkMVUasAv5 m50ByzEsebz6BpQZqZUPOH+EWZnUR+ie5ixqRx20meoJ/ol35A8pld/dHG4= Archived-At: Subject: [OAUTH-WG] PoP Architecture X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 20:26:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --946af974WPDhv3vrALaCVrGw5Ix9QWfoK Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, I just refreshed the PoP architecture document since it was expired. Here is the link to version -08: https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-08 We will have to update the document based on the recent draft submissions related to token binding for OAuth. Ciao Hannes --946af974WPDhv3vrALaCVrGw5Ix9QWfoK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJXgAxYAAoJEGhJURNOOiAtwAoH/2jx5eGajqc+uxOmqqrE2t0c CyO3lNPDgEpp2PK5pmaFDQ0RngCdDLTo0NZSGrhGLJDCGn+mXAae4jaX9cG1/wWO QD3fjP6YcEEz8vbrpry/UjpG/nwDPDDqto8YWIjJx94IA/SINKCBiB6zNAgzqgk9 Q4sIAhJNTlnrZ6loiZaQH/wlTcLufnM6LzP3ZbK160mpi8HiOzvcslGWf021VZHA tFR0JGaAdy3TDkHrA32Q3tYR3bI6iskPBd45Vp/NWkU4gKRa5+XeTcOH+jWuhjjB OjyEcvgP45t1K0rdbtWVLAAKN0zIlXq9cpbn9uYWRMWdbIIvwVUU4gRpkOCLqXs= =gOA4 -----END PGP SIGNATURE----- --946af974WPDhv3vrALaCVrGw5Ix9QWfoK-- From nobody Fri Jul 8 16:17:11 2016 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EF61412D978; Fri, 8 Jul 2016 16:17:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160708231708.32201.34664.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2016 16:17:08 -0700 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-device-flow-02.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 23:17:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol of the IETF. Title : OAuth 2.0 Device Flow Authors : William Denniss Stein Myrseth John Bradley Michael B. Jones Hannes Tschofenig Filename : draft-ietf-oauth-device-flow-02.txt Pages : 9 Date : 2016-07-08 Abstract: The device flow is suitable for OAuth 2.0 clients executing on devices that do not have an easy data-entry method (e.g., game consoles, TVs, picture frames, and media hubs), but where the end- user has separate access to a user-agent on another computer or device (e.g., desktop computer, a laptop, a smart phone, or a tablet). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-oauth-device-flow-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-device-flow-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 8 16:38:03 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4792712D984 for ; Fri, 8 Jul 2016 16:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 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.426, 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 nVadTAPvkbMy for ; Fri, 8 Jul 2016 16:37:58 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1D5812D69E for ; Fri, 8 Jul 2016 16:37:58 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id f189so79442811oig.3 for ; Fri, 08 Jul 2016 16:37:58 -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=ACnq3cgIKLWeSdUA9ln3yfb3u7ChP2vGiSvjD2VJhwA=; b=BwKnC7VqHDbQVjLMN/HuQEAUi/McvZ9SytWJ20jZw/sg7CYPmsPTm+Eyyqv4QjBqLf a9G0VC94ZOFNVLIGMT3RHR0o9w942IUZvwTEZWzU1fxs0TCO5t4H7E7bRgO+ceT5b/il EXN7BrCZJVu/qTObliQzWEm3GoYjAJ3ScuO2ggHkUGMTEMjEeaZwGeQfZnp0gdVkQ0X4 sDlwATL5Wc5TsaWONrThmEOIujDVL7jENQjM8WE96Pi2hmT5NNIyYF1fEPwmF47txelg ZmtlgmuCdNofIAzCfDV9pi/3KPMAcYuMiO9rMMLqmk+pyzWljLY+Flm0LpO+2hM7vduH w2EQ== 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=ACnq3cgIKLWeSdUA9ln3yfb3u7ChP2vGiSvjD2VJhwA=; b=VtR/ETLW1DUiRClC5HrUr4+tBo+4mA0BixU+GzTCDKIXhHDJOZMCp0basthJZdIoDI WgqdqSZNCr2kXq59i2PbfPcfjvbAP5msyMXjQ59NakEgUt7S2QYdmijd6iJ6+qNIhFM3 Izcz6QDiIpOR7eWgrWpO2dBYXExBJa4vXxd6ZN2kdqQw5G3DD3itJZ0eEpARkX2s/u/S 07w5k91P6k2tJxbGJmoryB2HMMhjpGyIK5SPgF6kvWMshM/0d39SwPabhTc3SOz+UXBq 5Gf1QkLgN9AVUKxhfa4hy2lqDa+VCGL3li2g4nBpka2mhTxHGyM/QImlzIXDlsiVeDdX kISQ== X-Gm-Message-State: ALyK8tK7wWwS5fnOqgGf916gDNH3TgOwh0ewYpUlc6ZqhsOKW5IKYLk2hr+8vTZuR4zEiwRKZ0be6QZJI6RfNVvt X-Received: by 10.157.44.73 with SMTP id f67mr5021582otb.116.1468021077832; Fri, 08 Jul 2016 16:37:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.232.134 with HTTP; Fri, 8 Jul 2016 16:37:38 -0700 (PDT) In-Reply-To: References: From: William Denniss Date: Fri, 8 Jul 2016 16:37:38 -0700 Message-ID: To: Aaron Parecki Content-Type: multipart/alternative; boundary=94eb2c11f134de61b10537284ad8 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Device flow clarifications X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 23:38:01 -0000 --94eb2c11f134de61b10537284ad8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree that the token request section was not well defined, using the OAuth 2.0 definition in this case isn't correct as there are unique aspects of the Device Flow grant_type that need to be specified I've posted an update that fleshes out the token request polling & response. https://tools.ietf.org/html/draft-ietf-oauth-device-flow-02 Section 3.2 referenced in the above email is now numbered 3.4 . I specified a grant_type value of "device_code" as it matches the convention for other OAuth grant types. Google's implementation currently uses a URI instead: http://oauth.net/grant_type/device/1.0. On Fri, Apr 15, 2016 at 3:42 PM, Aaron Parecki wrote: > Hi Alex and Oli, > > I also believe you are correct. I posted a similar question a while ago > here: > > https://www.ietf.org/mail-archive/web/oauth/current/msg15139.html > > I had a couple other notes you may be interested in: > > https://www.ietf.org/mail-archive/web/oauth/current/msg15138.html > > My implementation of a server that implements the device flow is here, > although it actually acts as a proxy for existing OAuth services: > > https://github.com/aaronpk/TVAuthServer > > Cheers! > > ---- > Aaron Parecki > aaronparecki.com > @aaronpk > > > On Fri, Apr 15, 2016 at 8:24 PM, Oli Dagenais > wrote: > >> Hi Alex, >> >> >> >> I=E2=80=99m also working on an implementation based on the draft specifi= cation. I >> came to the same conclusion about linking to Section 4.1.3 of RFC6749. >> >> >> >> As for your second question, I also came to the same conclusion, which >> was confirmed by looking at the source code to the Active Directory >> Authentication Library (ADAL) for .NET (Azure Active Directory is my >> project=E2=80=99s first target). ADAL also sets the grant_type parameter= to >> =E2=80=9Cdevice_code=E2=80=9D (contrast this with the value originally i= n section 4.1.3). >> >> >> >> I am hoping to also test my implementation against other major server >> implementations (Google and Facebook come to mind) in the next few weeks >> and will report my findings to this mailing list. >> >> >> >> Cheers, >> >> - Oli >> >> >> >> -- >> >> Let me help you be awesome at what you do, using >> >> Microsoft Developer Tools >> >> +1 613-212-5551 >> >> >> >> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Alex Bilbie >> *Sent:* Friday, April 15, 2016 13:32 >> *To:* oauth@ietf.org >> *Subject:* [OAUTH-WG] Device flow clarifications >> >> >> >> N.B: I sent the following email to >> draft-ietf-oauth-device-flow@tools.ietf.org on 12th April but didn't >> receive a reply so am reposting here: >> >> >> >> --- >> >> >> >> Hello, >> >> >> >> I've been working on an implementation of the OAuth 2.0 Device Flow (as >> described at https://tools.ietf.org/html/draft-ietf-oauth-device-flow-01 >> >> ). >> >> >> >> Please could the following points please be clarified: >> >> >> >> Section 3.2: "The client requests an access token by making an HTTP >> "POST" request to the token endpoint as described in Section 4.1.1 of >> [RFC6749]" >> >> >> >> Should this actually say Section 4.1.3 of RFC6749 which is the Access >> Token Request section for the authorisation code grant? >> >> >> >> Assuming the above is true, should the `code` parameter POSTed to the >> authorisation server be the value of the `device_code` parameter return= ed >> to the client in the initiating request? >> >> >> >> Many thanks, >> >> >> >> Alex Bilbie >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --94eb2c11f134de61b10537284ad8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree that the token request section was not well d= efined, using the OAuth 2.0 definition in this case isn't correct as th= ere are unique aspects of the Device Flow grant_type that need to be specif= ied

=C2=A0I've posted an update that fleshes o= ut the token request polling & response. https://tools.ietf.org/html/draft= -ietf-oauth-device-flow-02 =C2=A0Section 3.2 referenced in the above em= ail is now numbered=C2=A03.4.

I speci= fied a grant_type value of "device_code" as it matches the conven= tion for other OAuth grant types. Google's implement= ation currently uses a URI instead:=C2=A0http://oauth.net/grant_type/device/1.0.
=


On Fri, Apr 15, 2016 at 3:42 PM, Aaron Parecki <aaron@parecki.com&= gt; wrote:
Hi Ale= x and Oli,

I also believe you are correct. I posted a si= milar question a while ago here:


I had a couple other notes you may be intereste= d in:


My implementation of a server that implements the device flow is here, alt= hough it actually acts as a proxy for existing OAuth services:

Cheers!

=
----
Aaron Parecki

<= /div>

On Fri, Apr 15, 2016 = at 8:24 PM, Oli Dagenais <olivida@microsoft.com> wrote:<= br>

Hi Alex,

=C2=A0

I=E2=80=99m also working on an implementation based on the dra= ft specification. I came to the same conclusion about linking to Section 4.= 1.3 of RFC6749.

=C2=A0

As for your second question, I also came to the same conclusio= n, which was confirmed by looking at the source code to the Active Director= y Authentication Library (ADAL) for .NET (Azure Active Directory is my project=E2=80=99s fi= rst target). ADAL also sets the grant_type parameter to =E2=80=9Cdevice_cod= e=E2=80=9D (contrast this with the value originally in section 4.1.3).

=C2=A0

I am hoping to also test my implementation against= other major server implementations (Google and Facebook come to mind) in t= he next few weeks and will report my findings to this mailing list.

=C2=A0

Cheers,

- Oli

=C2=A0

--

Let me help you be awesome at what you do, using

Microsoft Developer Tools

+1 613-212-5551<= /p>

=C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Alex Bilbie
Sent: Friday, April 15, 2016 13:32
To: oauth@ietf.o= rg
Subject: [OAUTH-WG] Device flow clarifications<= /p>

=C2=A0

N.B: I = sent the following email to=C2=A0draft-ietf-oauth-device-flow@tools.i= etf.org=C2=A0on 12th April but didn't receive a=C2=A0reply s= o am reposting here:

=C2=A0

---

=C2=A0

Hello,

=C2=A0

I've been worki= ng on an implementation of the OAuth 2.0 Device Flow (as described at=C2=A0= https://tools.ietf.org/html/draft-ietf-oau= th-device-flow-01).

=C2=A0

Please could the fo= llowing points please be clarified:

=C2=A0

Section 3.2: "= The client requests an access token by making an HTTP "POST" requ= est to the token endpoint as described in Section 4.1.1 of [RFC6749]"<= u>

=C2=A0

Should this actuall= y say Section 4.1.3 of RFC6749 which is the Access Token Request section fo= r the authorisation code grant?

=C2=A0

Assuming the above = is true, should the `code` parameter POSTed to the authorisation server =C2= =A0be the value of the `device_code` parameter returned to the client in th= e initiating request?

=C2=A0

Many thanks,=

=C2=A0

Alex Bilbie<= u>

=C2=A0


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



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


--94eb2c11f134de61b10537284ad8-- From nobody Fri Jul 8 18:57:34 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15B5212D105 for ; Fri, 8 Jul 2016 18:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.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 IVJJS1htmsOS for ; Fri, 8 Jul 2016 18:57:30 -0700 (PDT) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22FA312D10E for ; Fri, 8 Jul 2016 18:57:30 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id f6so17219013ith.0 for ; Fri, 08 Jul 2016 18:57:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=inDTepX7yptqJwzo3Sux0Jnz2SNlua4wNWiIXGfVxX8=; b=ke1cGsgSNYti6oY9h1uGaJzBdP3gm0dMCEwTnRlbSw3+DOyjJMhJmx0ogvCPvuUP/P il/60evNJ5QtXYOrjbLIHnaCpK4PFY5z5r5cXbo313M+wQFnGhuOvjbetUeE3uNL6ETG zcl0oEHwqKxXwsg2mU76qLpUhosUBla2c6V8Q= 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=inDTepX7yptqJwzo3Sux0Jnz2SNlua4wNWiIXGfVxX8=; b=cQol+INl6ZEinPPSngRISxC77x+5QXgzE29SnW/4BUTYd/C8K3pDC3kvSD4JWsM2E+ GRgATB8hxkkhDOIpTj+uUHLrIWC//vvlMAGWYMx9aOroiLOT7l6DkfA4GoC4DpzfTqEr 0OA9NX6J6gmPUlkTO3gE0QfELOaJrDe1I2S9+YGhyfdxCLp9s0HaRD76aiKUFld46vDE 3fU0UkEaiPXje0/bQQuq/OzqvT8qJkOd6vKbcd/NBIGCtQgTqKAfM/GHwguuiSwxqZi1 3KEdEOLKlTey7SUmtok4sjw2VOGV5GhxsPMYX6KJ3YwV/r/XyqMKXRC+ZLYWFSScUOHZ E81w== X-Gm-Message-State: ALyK8tKjXcaorToxcfiF2XuciQZjmHz0Q50jPh8bjQGuANR9Kft/nDVXIn/T7Fj1CTD+uUo4S++XTGA7l/QNhjQZ X-Received: by 10.36.123.199 with SMTP id q190mr6305238itc.42.1468029449337; Fri, 08 Jul 2016 18:57:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.28.149 with HTTP; Fri, 8 Jul 2016 18:56:59 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Fri, 8 Jul 2016 19:56:59 -0600 Message-ID: To: William Denniss Content-Type: multipart/alternative; boundary=001a114762fed91b5d05372a3d06 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Device flow clarifications X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2016 01:57:33 -0000 --001a114762fed91b5d05372a3d06 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I hate to be pedantic but... well, here goes. Grant types other than those defined in RFC 6749 are supposed to be URIs (see section 4.5 on Extension Grants ). There's no registry for grant_type values so name collisions are avoided via the use of URIs. An IETF document like the Device Flow should probably use a stable IETF URI rather than something under oauth.net, which it has no real relationship with or control of. RFC 6755 exists specifically for the purpose of obtaining/registering such URIs and even has an example registration request for a grant type URI. On Fri, Jul 8, 2016 at 5:37 PM, William Denniss wrote= : > I agree that the token request section was not well defined, using the > OAuth 2.0 definition in this case isn't correct as there are unique aspec= ts > of the Device Flow grant_type that need to be specified > > I've posted an update that fleshes out the token request polling & > response. https://tools.ietf.org/html/draft-ietf-oauth-device-flow-02 > Section 3.2 referenced in the above email is now numbered 3.4 > = . > > I specified a grant_type value of "device_code" as it matches the > convention for other OAuth grant types. Google's implementation > > currently uses a URI instead: http://oauth.net/grant_type/device/1.0. > > > On Fri, Apr 15, 2016 at 3:42 PM, Aaron Parecki wrote: > >> Hi Alex and Oli, >> >> I also believe you are correct. I posted a similar question a while ago >> here: >> >> https://www.ietf.org/mail-archive/web/oauth/current/msg15139.html >> >> I had a couple other notes you may be interested in: >> >> https://www.ietf.org/mail-archive/web/oauth/current/msg15138.html >> >> My implementation of a server that implements the device flow is here, >> although it actually acts as a proxy for existing OAuth services: >> >> https://github.com/aaronpk/TVAuthServer >> >> Cheers! >> >> ---- >> Aaron Parecki >> aaronparecki.com >> @aaronpk >> >> >> On Fri, Apr 15, 2016 at 8:24 PM, Oli Dagenais >> wrote: >> >>> Hi Alex, >>> >>> >>> >>> I=E2=80=99m also working on an implementation based on the draft specif= ication. >>> I came to the same conclusion about linking to Section 4.1.3 of RFC6749= . >>> >>> >>> >>> As for your second question, I also came to the same conclusion, which >>> was confirmed by looking at the source code to the Active Directory >>> Authentication Library (ADAL) for .NET (Azure Active Directory is my >>> project=E2=80=99s first target). ADAL also sets the grant_type paramete= r to >>> =E2=80=9Cdevice_code=E2=80=9D (contrast this with the value originally = in section 4.1.3). >>> >>> >>> >>> I am hoping to also test my implementation against other major server >>> implementations (Google and Facebook come to mind) in the next few week= s >>> and will report my findings to this mailing list. >>> >>> >>> >>> Cheers, >>> >>> - Oli >>> >>> >>> >>> -- >>> >>> Let me help you be awesome at what you do, using >>> >>> Microsoft Developer Tools >>> >>> +1 613-212-5551 >>> >>> >>> >>> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Alex Bilbi= e >>> *Sent:* Friday, April 15, 2016 13:32 >>> *To:* oauth@ietf.org >>> *Subject:* [OAUTH-WG] Device flow clarifications >>> >>> >>> >>> N.B: I sent the following email to >>> draft-ietf-oauth-device-flow@tools.ietf.org on 12th April but didn't >>> receive a reply so am reposting here: >>> >>> >>> >>> --- >>> >>> >>> >>> Hello, >>> >>> >>> >>> I've been working on an implementation of the OAuth 2.0 Device Flow (as >>> described at https://tools.ietf.org/html/draft-ietf-oauth-device-flow-0= 1 >>> >>> ). >>> >>> >>> >>> Please could the following points please be clarified: >>> >>> >>> >>> Section 3.2: "The client requests an access token by making an HTTP >>> "POST" request to the token endpoint as described in Section 4.1.1 of >>> [RFC6749]" >>> >>> >>> >>> Should this actually say Section 4.1.3 of RFC6749 which is the Access >>> Token Request section for the authorisation code grant? >>> >>> >>> >>> Assuming the above is true, should the `code` parameter POSTed to the >>> authorisation server be the value of the `device_code` parameter retur= ned >>> to the client in the initiating request? >>> >>> >>> >>> Many thanks, >>> >>> >>> >>> Alex Bilbie >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a114762fed91b5d05372a3d06 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I hate to be pedantic but... well, here goes.
Grant types other than those defined in RFC 6749 are supposed t= o be URIs (see = section 4.5 on=C2=A0 Extension Grants).=C2=A0 There's no registry f= or grant_type values so name collisions are avoided via the use of URIs.
An IETF document like the Device Flow should probably use a sta= ble IETF URI rather than something under oauth= .net, which it has no real relationship with or control of. RFC 6755 exists specifically for t= he purpose of obtaining/registering such URIs and even has an example registration request= for a grant type URI.


On Fri, Jul 8, 2016 at 5:37 PM, William Denniss= <wdenniss@google.com> wrote:
I agree that the token request section was not = well defined, using the OAuth 2.0 definition in this case isn't correct= as there are unique aspects of the Device Flow grant_type that need to be = specified

=C2=A0I've posted an update that fle= shes out the token request polling & response. https://t= ools.ietf.org/html/draft-ietf-oauth-device-flow-02 =C2=A0Section 3.2 re= ferenced in the above email is now numbered=C2=A03.4.

I specified a grant_type value of "= device_code" as it matches the convention for other OAuth grant types.= Google's implementation curre= ntly uses a URI instead:=C2=A0http://oauth.net/grant_type/device/1.0.


On Fri, Apr 15, 2016 at 3:4= 2 PM, Aaron Parecki <aaron@parecki.com> wrote:
Hi Alex and Oli,

I= also believe you are correct. I posted a similar question a while ago here= :


I h= ad a couple other notes you may be interested in:


My implementation of a server = that implements the device flow is here, although it actually acts as a pro= xy for existing OAuth services:


Cheers!

----
Aaron = Parecki


On Fri, Apr 15, 2016 at 8:24 PM, O= li Dagenais <olivida@microsoft.com> wrote:

Hi Alex,

=C2=A0

I=E2=80=99m also working on an implementation based on the dra= ft specification. I came to the same conclusion about linking to Section 4.= 1.3 of RFC6749.

=C2=A0

As for your second question, I also came to the same conclusio= n, which was confirmed by looking at the source code to the Active Director= y Authentication Library (ADAL) for .NET (Azure Active Directory is my project=E2=80=99s fi= rst target). ADAL also sets the grant_type parameter to =E2=80=9Cdevice_cod= e=E2=80=9D (contrast this with the value originally in section 4.1.3).

=C2=A0

I am hoping to also test my implementation against= other major server implementations (Google and Facebook come to mind) in t= he next few weeks and will report my findings to this mailing list.

=C2=A0

Cheers,

- Oli

=C2=A0

--

Let me help you be awesome at what you do, using

Microsoft Developer Tools

+1 613-212-5551<= /p>

=C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Alex Bilbie
Sent: Friday, April 15, 2016 13:32
To: oauth@ietf.o= rg
Subject: [OAUTH-WG] Device flow clarifications<= /p>

=C2=A0

N.B: I = sent the following email to=C2=A0draft-ietf-oauth-device-flow@tools.i= etf.org=C2=A0on 12th April but didn't receive a=C2=A0reply s= o am reposting here:

=C2=A0

---

=C2=A0

Hello,

=C2=A0

I've been worki= ng on an implementation of the OAuth 2.0 Device Flow (as described at=C2=A0= https://tools.ietf.org/html/draft-ietf-oau= th-device-flow-01).

=C2=A0

Please could the fo= llowing points please be clarified:

=C2=A0

Section 3.2: "= The client requests an access token by making an HTTP "POST" requ= est to the token endpoint as described in Section 4.1.1 of [RFC6749]"<= u>

=C2=A0

Should this actuall= y say Section 4.1.3 of RFC6749 which is the Access Token Request section fo= r the authorisation code grant?

=C2=A0

Assuming the above = is true, should the `code` parameter POSTed to the authorisation server =C2= =A0be the value of the `device_code` parameter returned to the client in th= e initiating request?

=C2=A0

Many thanks,=

=C2=A0

Alex Bilbie<= u>

=C2=A0


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



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



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


--001a114762fed91b5d05372a3d06-- From nobody Sat Jul 9 10:22:43 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9D9912D5C6 for ; Sat, 9 Jul 2016 10:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[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=parecki-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 8hq0pzyJS5uu for ; Sat, 9 Jul 2016 10:22:37 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::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 DC9C212D0B5 for ; Sat, 9 Jul 2016 10:22:36 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id b192so91914247vke.0 for ; Sat, 09 Jul 2016 10:22:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jJMqaQ6oK6s6cskHhsR0sF28SRn5uE4zRrMuw4AZqZk=; b=Z/pU6rnwQyFGXXnu0D/2bAxaH8ojKtRmvwIa7+jyvjh+XAomXIEaZJd0KbbKz8+ORx 9B7CM3EN/jOnO+aTdECoU4PczaQLfI3EWi5f2+NcJkEo5cJynTjAAK9shzfJNQeaslAd 9eP3SWSBKjNsg2IvXkfhsMkyEVhrFltyksd1W64EJidRqp/Mp+Ac19zx/XIv7KoiSo/v TePj7/lU9dYigo8XwygAjM6nO6Jv6bP/G8aW7goC4WeS2lyHu4AZ6okOIJpgdpV62RPa b3Hb6HK1wuEFgk8OJAvTRD6CqiPO/9BZ/85uxbkKXZmiFSXGeBGwURkF1+BkI09hOKVb dkbg== 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=jJMqaQ6oK6s6cskHhsR0sF28SRn5uE4zRrMuw4AZqZk=; b=Ty2al7FAU7kPF+f+N+eDgUCd9CpqK5Iwec8w+xTtvte4DYEBylJNq8uAMFq05r8TQf mcLdx+1OUeyBMA4Jqr+GM/30eRRy+j9YXcHApAt6wYI40S08yc8jMPv1FEkpGFtLN87i vu1PZA+Sf7627S5rlJUIHxIiIAm1pvDfzipoY/JXy/ZaAoOOkOVDxyQv+RiSoCznvw4/ SNrWQykBh2FaOi6a2aqFE25tlSkt1Prw/c1Pg0gf0JGfkj7k1HxOoK3l8s7+BZFfAfY7 7cSnXDoOhHJIAg4hn12MQYpezqMjEhKJuL1r3wBviPVZ7CxIkV+RWU+txzRDxmurSMja N3Sw== X-Gm-Message-State: ALyK8tLu9sZ4moV3FZz1KVzgXCTb0NEStoKlaspkjNGYhapWyFIQ+gePd2MV5YThidyMRA== X-Received: by 10.31.182.129 with SMTP id g123mr5829795vkf.101.1468084955683; Sat, 09 Jul 2016 10:22:35 -0700 (PDT) Received: from mail-vk0-f52.google.com (mail-vk0-f52.google.com. [209.85.213.52]) by smtp.gmail.com with ESMTPSA id t137sm1285vkc.3.2016.07.09.10.22.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 Jul 2016 10:22:34 -0700 (PDT) Received: by mail-vk0-f52.google.com with SMTP id v6so92013118vkb.2 for ; Sat, 09 Jul 2016 10:22:34 -0700 (PDT) X-Received: by 10.31.7.68 with SMTP id 65mr5874845vkh.74.1468084954347; Sat, 09 Jul 2016 10:22:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.74.196 with HTTP; Sat, 9 Jul 2016 10:22:33 -0700 (PDT) In-Reply-To: References: From: Aaron Parecki Date: Sat, 9 Jul 2016 10:22:33 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Brian Campbell Content-Type: multipart/alternative; boundary=001a11441d4a34435a0537372a8d Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Device flow clarifications X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2016 17:22:40 -0000 --001a11441d4a34435a0537372a8d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable If you'd like to put up a web page at the http://oauth.net/grant_type/device/1.0 URI that Google is using, feel free to create it and send me a PR. I think it could be useful for developers if there is a minimal page there that talks about the device flow. https://github.com/aaronpk/oauth.net ---- Aaron Parecki aaronparecki.com @aaronpk On Fri, Jul 8, 2016 at 6:56 PM, Brian Campbell wrote: > I hate to be pedantic but... well, here goes. > > Grant types other than those defined in RFC 6749 are supposed to be URIs > (see section 4.5 on Extension Grants > ). There's no registry > for grant_type values so name collisions are avoided via the use of URIs. > > An IETF document like the Device Flow should probably use a stable IETF > URI rather than something under oauth.net, which it has no real > relationship with or control of. RFC 6755 > exists specifically for the purpose > of obtaining/registering such URIs and even has an example registration > request for a grant > type URI. > > > > On Fri, Jul 8, 2016 at 5:37 PM, William Denniss > wrote: > >> I agree that the token request section was not well defined, using the >> OAuth 2.0 definition in this case isn't correct as there are unique aspe= cts >> of the Device Flow grant_type that need to be specified >> >> I've posted an update that fleshes out the token request polling & >> response. https://tools.ietf.org/html/draft-ietf-oauth-device-flow-02 >> Section 3.2 referenced in the above email is now numbered 3.4 >> >> . >> >> I specified a grant_type value of "device_code" as it matches the >> convention for other OAuth grant types. Google's implementation >> >> currently uses a URI instead: http://oauth.net/grant_type/device/1.0. >> >> >> On Fri, Apr 15, 2016 at 3:42 PM, Aaron Parecki wrote= : >> >>> Hi Alex and Oli, >>> >>> I also believe you are correct. I posted a similar question a while ago >>> here: >>> >>> https://www.ietf.org/mail-archive/web/oauth/current/msg15139.html >>> >>> I had a couple other notes you may be interested in: >>> >>> https://www.ietf.org/mail-archive/web/oauth/current/msg15138.html >>> >>> My implementation of a server that implements the device flow is here, >>> although it actually acts as a proxy for existing OAuth services: >>> >>> https://github.com/aaronpk/TVAuthServer >>> >>> Cheers! >>> >>> ---- >>> Aaron Parecki >>> aaronparecki.com >>> @aaronpk >>> >>> >>> On Fri, Apr 15, 2016 at 8:24 PM, Oli Dagenais >>> wrote: >>> >>>> Hi Alex, >>>> >>>> >>>> >>>> I=E2=80=99m also working on an implementation based on the draft speci= fication. >>>> I came to the same conclusion about linking to Section 4.1.3 of RFC674= 9. >>>> >>>> >>>> >>>> As for your second question, I also came to the same conclusion, which >>>> was confirmed by looking at the source code to the Active Directory >>>> Authentication Library (ADAL) for .NET (Azure Active Directory is my >>>> project=E2=80=99s first target). ADAL also sets the grant_type paramet= er to >>>> =E2=80=9Cdevice_code=E2=80=9D (contrast this with the value originally= in section 4.1.3). >>>> >>>> >>>> >>>> I am hoping to also test my implementation against other major server >>>> implementations (Google and Facebook come to mind) in the next few wee= ks >>>> and will report my findings to this mailing list. >>>> >>>> >>>> >>>> Cheers, >>>> >>>> - Oli >>>> >>>> >>>> >>>> -- >>>> >>>> Let me help you be awesome at what you do, using >>>> >>>> Microsoft Developer Tools >>>> >>>> +1 613-212-5551 >>>> >>>> >>>> >>>> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Alex >>>> Bilbie >>>> *Sent:* Friday, April 15, 2016 13:32 >>>> *To:* oauth@ietf.org >>>> *Subject:* [OAUTH-WG] Device flow clarifications >>>> >>>> >>>> >>>> N.B: I sent the following email to >>>> draft-ietf-oauth-device-flow@tools.ietf.org on 12th April but didn't >>>> receive a reply so am reposting here: >>>> >>>> >>>> >>>> --- >>>> >>>> >>>> >>>> Hello, >>>> >>>> >>>> >>>> I've been working on an implementation of the OAuth 2.0 Device Flow (a= s >>>> described at >>>> https://tools.ietf.org/html/draft-ietf-oauth-device-flow-01 >>>> >>>> ). >>>> >>>> >>>> >>>> Please could the following points please be clarified: >>>> >>>> >>>> >>>> Section 3.2: "The client requests an access token by making an HTTP >>>> "POST" request to the token endpoint as described in Section 4.1.1 of >>>> [RFC6749]" >>>> >>>> >>>> >>>> Should this actually say Section 4.1.3 of RFC6749 which is the Access >>>> Token Request section for the authorisation code grant? >>>> >>>> >>>> >>>> Assuming the above is true, should the `code` parameter POSTed to the >>>> authorisation server be the value of the `device_code` parameter retu= rned >>>> to the client in the initiating request? >>>> >>>> >>>> >>>> Many thanks, >>>> >>>> >>>> >>>> Alex Bilbie >>>> >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > --001a11441d4a34435a0537372a8d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If you'd like to put up a web page at the=C2=A0http://oauth.net/grant_type/device/1.0=C2=A0URI that Goo= gle is using, feel free to create it and send me a PR. I think it could be = useful for developers if there is a minimal page there that talks about the= device flow.


----
Aaron Parecki
=

On Fri, Jul 8, 2016 at 6:56 PM, Brian Campbe= ll <bcampbell@pingidentity.com> wrote:
I hate to be pedantic but.= .. well, here goes.

Grant types other than those defined in R= FC 6749 are supposed to be URIs (see section 4.5 on=C2=A0 Extension Gran= ts).=C2=A0 There's no registry for grant_type values so name collis= ions are avoided via the use of URIs.

An IETF document like t= he Device Flow should probably use a stable IETF URI rather than something = under oauth.net, which i= t has no real relationship with or control of. RFC 6755 exists specifically for = the purpose of obtaining/registering such URIs and even has an example r= egistration request for a grant type URI.



On Fri, Jul 8, 2016 at 5:37 PM, William Denniss <wdenniss@g= oogle.com> wrote:
I agree that the token request section was not well defined, = using the OAuth 2.0 definition in this case isn't correct as there are = unique aspects of the Device Flow grant_type that need to be specified

=C2=A0I've posted an update that fleshes out the t= oken request polling & response. https://tools.ietf.org/= html/draft-ietf-oauth-device-flow-02 =C2=A0Section 3.2 referenced in th= e above email is now numbered=C2=A03.4.

I specified a grant_type value of "device_code&qu= ot; as it matches the convention for other OAuth grant types. Google's = implementation currently uses a UR= I instead:=C2=A0http://oauth.net/grant_type/device/1.0.


On Fri, Apr 15, 2016 at 3:42 PM, Aaron Parecki <aaron@parecki.com&g= t; wrote:
Hi Alex= and Oli,

I also believe you are correct. I posted a sim= ilar question a while ago here:


I had a couple other notes you may be interested= in:


= My implementation of a server that implements the device flow is here, alth= ough it actually acts as a proxy for existing OAuth services:

=
Cheers!

<= div>
----
Aaron Parecki


On Fri, Apr 15, 2016 at 8:24 PM, O= li Dagenais <olivida@microsoft.com> wrote:

Hi Alex,

=C2=A0

I=E2=80=99m also working on an implementation based on the dra= ft specification. I came to the same conclusion about linking to Section 4.= 1.3 of RFC6749.

=C2=A0

As for your second question, I also came to the same conclusio= n, which was confirmed by looking at the source code to the Active Director= y Authentication Library (ADAL) for .NET (Azure Active Directory is my project=E2=80=99s fi= rst target). ADAL also sets the grant_type parameter to =E2=80=9Cdevice_cod= e=E2=80=9D (contrast this with the value originally in section 4.1.3).

=C2=A0

I am hoping to also test my implementation against= other major server implementations (Google and Facebook come to mind) in t= he next few weeks and will report my findings to this mailing list.

=C2=A0

Cheers,

- Oli

=C2=A0

--

Let me help you be awesome at what you do, using

Microsoft Developer Tools

+1 613-212-5551<= /p>

=C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Alex Bilbie
Sent: Friday, April 15, 2016 13:32
To: oauth@ietf.o= rg
Subject: [OAUTH-WG] Device flow clarifications<= /p>

=C2=A0

N.B: I = sent the following email to=C2=A0draft-ietf-oauth-device-flow@tools.i= etf.org=C2=A0on 12th April but didn't receive a=C2=A0reply s= o am reposting here:

=C2=A0

---

=C2=A0

Hello,

=C2=A0

I've been worki= ng on an implementation of the OAuth 2.0 Device Flow (as described at=C2=A0= https://tools.ietf.org/html/draft-ietf-oau= th-device-flow-01).

=C2=A0

Please could the fo= llowing points please be clarified:

=C2=A0

Section 3.2: "= The client requests an access token by making an HTTP "POST" requ= est to the token endpoint as described in Section 4.1.1 of [RFC6749]"<= u>

=C2=A0

Should this actuall= y say Section 4.1.3 of RFC6749 which is the Access Token Request section fo= r the authorisation code grant?

=C2=A0

Assuming the above = is true, should the `code` parameter POSTed to the authorisation server =C2= =A0be the value of the `device_code` parameter returned to the client in th= e initiating request?

=C2=A0

Many thanks,=

=C2=A0

Alex Bilbie<= u>

=C2=A0


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



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



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



--001a11441d4a34435a0537372a8d-- From nobody Sat Jul 9 11:11:44 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2A5112D5D6 for ; Sat, 9 Jul 2016 11:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, 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 UyEigEKyRC_V for ; Sat, 9 Jul 2016 11:11:42 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E9D412D51F for ; Sat, 9 Jul 2016 11:11:41 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id s66so99494259oif.1 for ; Sat, 09 Jul 2016 11:11:41 -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=RbJEi1rPAZqLcqCEAPpHw+7xJlLCzB4WIrTAaS5EFQY=; b=SyZLRRSdHpt+TKbVHCOjxMe94a98i8KIZDmHHmBTXcgTQqY93gT2VG1Uk/ISf+x0h9 B5dCcU4eZbEvvg4agm5+1Z4bl/UY6niXa13QjbukEb82Ncb7c2k6GE2oSNE6ZxfGY2tV w1iL3qMg/C3HPZ3LlfopveEmO6zMZDmC+PtpOFigw+/NG3A8uFZd+tdTlP3RAzsVV/Wv G/tAYffWXYQFf3sTTkCq5bWssN8w3aTNOBgX2xTW3zD+lwMqfvXxL9DpbBTFqeVo0tDe SLO27ylDpJPxmi7dNzSwBmGRi34kildVsxfpPFusHzu11Cln9ZAkErTQ82wBSFBjJbR9 0jrg== 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=RbJEi1rPAZqLcqCEAPpHw+7xJlLCzB4WIrTAaS5EFQY=; b=SWFyhrSjwJC9zo1vc4xvNYZC6wfMwscefQDGjiq2rtg2t7tD2P5tf7/LzapCi6847G 1Ib0rELEv0DarXfLRLh+upPPe7842U2UhLmGxccBhTjpUQWqETXY4W6cgbWY5zz6E1kn 2qITOYG3EpMqkb9sah8eJ04QdW/7qVpar6UAWelqU2lE4XXXCBuyD+DZGOJCJsUpz1n2 T7TsP8dFApWEVR0Wj5biuBY/736gftw3TkL+hsGv912/FklZG+1j30/d8TWQfGlnwQKL uS9YQZgXBGSdQXwsbRg2hGAIpzvNGv7d1oKT8Uj6WfMpcfit6BLMCb0oYR+6s0smV38b 2CtQ== X-Gm-Message-State: ALyK8tLKtgCyZUedv6885J0JO9FME+x+FqbP7/RabT/PfsqJYeSvFec5u4lvYs35Zboqvlt+x53Ef3EQLAmBmf2C X-Received: by 10.202.80.76 with SMTP id e73mr6197699oib.170.1468087900753; Sat, 09 Jul 2016 11:11:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.232.134 with HTTP; Sat, 9 Jul 2016 11:11:21 -0700 (PDT) In-Reply-To: References: From: William Denniss Date: Sat, 9 Jul 2016 11:11:21 -0700 Message-ID: To: Aaron Parecki Content-Type: multipart/alternative; boundary=001a113d6a0ad331e2053737d95f Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Device flow clarifications X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2016 18:11:44 -0000 --001a113d6a0ad331e2053737d95f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Jul 9, 2016 at 10:22 AM, Aaron Parecki wrote: > If you'd like to put up a web page at the > http://oauth.net/grant_type/device/1.0 URI that Google is using, feel > free to create it and send me a PR. I think it could be useful for > developers if there is a minimal page there that talks about the device > flow. > > > > > https://github.com/aaronpk/oauth.ne= t > Good idea, thanks! https://github.com/aaronpk/oauth.net/pull/125 > > > ---- > Aaron Parecki > aaronparecki.com > @aaronpk > > > On Fri, Jul 8, 2016 at 6:56 PM, Brian Campbell > wrote: > >> I hate to be pedantic but... well, here goes. >> >> Grant types other than those defined in RFC 6749 are supposed to be URIs >> (see section 4.5 on Extension Grants >> ). There's no registry >> for grant_type values so name collisions are avoided via the use of URIs= . >> >> An IETF document like the Device Flow should probably use a stable IETF >> URI rather than something under oauth.net, which it has no real >> relationship with or control of. RFC 6755 >> exists specifically for the >> purpose of obtaining/registering such URIs and even has an example >> registration request >> for a grant type URI. >> >> >> >> On Fri, Jul 8, 2016 at 5:37 PM, William Denniss >> wrote: >> >>> I agree that the token request section was not well defined, using the >>> OAuth 2.0 definition in this case isn't correct as there are unique asp= ects >>> of the Device Flow grant_type that need to be specified >>> >>> I've posted an update that fleshes out the token request polling & >>> response. https://tools.ietf.org/html/draft-ietf-oauth-device-flow-02 >>> Section 3.2 referenced in the above email is now numbered 3.4 >>> >>> . >>> >>> I specified a grant_type value of "device_code" as it matches the >>> convention for other OAuth grant types. Google's implementation >>> >>> currently uses a URI instead: http://oauth.net/grant_type/device/1.0. >>> >>> >>> On Fri, Apr 15, 2016 at 3:42 PM, Aaron Parecki >>> wrote: >>> >>>> Hi Alex and Oli, >>>> >>>> I also believe you are correct. I posted a similar question a while ag= o >>>> here: >>>> >>>> https://www.ietf.org/mail-archive/web/oauth/current/msg15139.html >>>> >>>> I had a couple other notes you may be interested in: >>>> >>>> https://www.ietf.org/mail-archive/web/oauth/current/msg15138.html >>>> >>>> My implementation of a server that implements the device flow is here, >>>> although it actually acts as a proxy for existing OAuth services: >>>> >>>> https://github.com/aaronpk/TVAuthServer >>>> >>>> Cheers! >>>> >>>> ---- >>>> Aaron Parecki >>>> aaronparecki.com >>>> @aaronpk >>>> >>>> >>>> On Fri, Apr 15, 2016 at 8:24 PM, Oli Dagenais >>>> wrote: >>>> >>>>> Hi Alex, >>>>> >>>>> >>>>> >>>>> I=E2=80=99m also working on an implementation based on the draft >>>>> specification. I came to the same conclusion about linking to Section= 4.1.3 >>>>> of RFC6749. >>>>> >>>>> >>>>> >>>>> As for your second question, I also came to the same conclusion, whic= h >>>>> was confirmed by looking at the source code to the Active Directory >>>>> Authentication Library (ADAL) for .NET (Azure Active Directory is my >>>>> project=E2=80=99s first target). ADAL also sets the grant_type parame= ter to >>>>> =E2=80=9Cdevice_code=E2=80=9D (contrast this with the value originall= y in section 4.1.3). >>>>> >>>>> >>>>> >>>>> I am hoping to also test my implementation against other major server >>>>> implementations (Google and Facebook come to mind) in the next few we= eks >>>>> and will report my findings to this mailing list. >>>>> >>>>> >>>>> >>>>> Cheers, >>>>> >>>>> - Oli >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Let me help you be awesome at what you do, using >>>>> >>>>> Microsoft Developer Tools >>>>> >>>>> +1 613-212-5551 >>>>> >>>>> >>>>> >>>>> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Alex >>>>> Bilbie >>>>> *Sent:* Friday, April 15, 2016 13:32 >>>>> *To:* oauth@ietf.org >>>>> *Subject:* [OAUTH-WG] Device flow clarifications >>>>> >>>>> >>>>> >>>>> N.B: I sent the following email to >>>>> draft-ietf-oauth-device-flow@tools.ietf.org on 12th April but didn't >>>>> receive a reply so am reposting here: >>>>> >>>>> >>>>> >>>>> --- >>>>> >>>>> >>>>> >>>>> Hello, >>>>> >>>>> >>>>> >>>>> I've been working on an implementation of the OAuth 2.0 Device Flow >>>>> (as described at >>>>> https://tools.ietf.org/html/draft-ietf-oauth-device-flow-01 >>>>> >>>>> ). >>>>> >>>>> >>>>> >>>>> Please could the following points please be clarified: >>>>> >>>>> >>>>> >>>>> Section 3.2: "The client requests an access token by making an HTTP >>>>> "POST" request to the token endpoint as described in Section 4.1.1 of >>>>> [RFC6749]" >>>>> >>>>> >>>>> >>>>> Should this actually say Section 4.1.3 of RFC6749 which is the Access >>>>> Token Request section for the authorisation code grant? >>>>> >>>>> >>>>> >>>>> Assuming the above is true, should the `code` parameter POSTed to the >>>>> authorisation server be the value of the `device_code` parameter ret= urned >>>>> to the client in the initiating request? >>>>> >>>>> >>>>> >>>>> Many thanks, >>>>> >>>>> >>>>> >>>>> Alex Bilbie >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> > --001a113d6a0ad331e2053737d95f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Jul 9, 2016 at 10:22 AM, Aaron Parecki <aaron@parecki.com> wrote:<= br>
If you'd like to put up a web page= at the=C2=A0http://oauth.net/grant_type/device/1.0=C2=A0URI that= Google is using, feel free to create it and send me a PR. I think it could= be useful for developers if there is a minimal page there that talks about= the device flow.

=C2=A0


----
Aaron Parecki


On Fri, = Jul 8, 2016 at 6:56 PM, Brian Campbell <bcampbell@pingidentity.com> w= rote:
I hate to be pedantic = but... well, here goes.

Grant types other than those defined = in RFC 6749 are supposed to be URIs (see section 4.5 on=C2=A0 Extension Grants).=C2=A0= There's no registry for grant_type values so name collisions are avoid= ed via the use of URIs.

An IETF document like the Device Flow= should probably use a stable IETF URI rather than something under oauth.net, which it has no real relationship with= or control of. RFC 6755 exists specifically for the purpose of obtaining/registering such URIs an= d even has an e= xample registration request for a grant type URI.



On Fri, Ju= l 8, 2016 at 5:37 PM, William Denniss <wdenniss@google.com> wrote:
I agree that the token request section was= not well defined, using the OAuth 2.0 definition in this case isn't co= rrect as there are unique aspects of the Device Flow grant_type that need t= o be specified

=C2=A0I've posted an update tha= t fleshes out the token request polling & response. https://tools.ietf.org= /html/draft-ietf-oauth-device-flow-02 =C2=A0Section 3.2 referenced in t= he above email is now numbered=C2=A03.4.

<= div>I specified a grant_type value of "device_code" as it matches= the convention for other OAuth grant types. Google's http://oauth.net/grant_type/device/1.0.


On Fri, Apr 15, 2016 at 3:42 PM, Aaron Parecki <aaron@parecki.com> wrote:
Hi Alex and Oli,<= div>
I also believe you are correct. I posted a similar quest= ion a while ago here:


I= had a couple other notes you may be interested in:

https://www.ietf.org/mail-archive/web/oauth/current/msg15138.html<= br>

My implementation of a server that implements = the device flow is here, although it actually acts as a proxy for existing = OAuth services:


Cheers!

----
Aaron Parecki


On Fri, Apr 15, 2016 at 8:24 PM, O= li Dagenais <= olivida@microsoft.com> wrote:

Hi Alex,

=C2=A0

I=E2=80=99m also working on an implementation based on the draft spe= cification. I came to the same conclusion about linking to Section 4.1.3 of= RFC6749.

=C2=A0

As for your second question, I also came to the same conclusion, whi= ch was confirmed by looking at the source code to the Active Directory Auth= entication Library (ADAL) for .NET (Azure Active Directory is my project=E2=80=99s fi= rst target). ADAL also sets the grant_type parameter to =E2=80=9Cdevice_cod= e=E2=80=9D (contrast this with the value originally in section 4.1.3).

=C2=A0

I am hoping to also test my implementation against other= major server implementations (Google and Facebook come to mind) in the nex= t few weeks and will report my findings to this mailing list.

=C2=A0

Cheers,

- Oli

=C2=A0

--

Let me help you be awesome at what you do, using<= u>

Microsoft Developer Tools

+1 613-212-5551

=C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Alex Bilbie
Sent: Friday, April 15, 2016 13:32
To: oauth@ietf.org
Subject: [OAUTH-WG] Device flow clarifications<= /p>

=C2=A0

N.B= : I sent the following email to=C2=A0draft-ietf-oauth-device-flow@tools.ietf.org=C2= =A0on 12th April but didn't receive a=C2=A0reply so am reposting here:

=C2=A0

---

=C2=A0

Hello,

=C2=A0

I've been w= orking on an implementation of the OAuth 2.0 Device Flow (as described at= =C2=A0https://tools.ietf.org/html/draft-ietf-oauth-device-= flow-01).

=C2=A0

Please could th= e following points please be clarified:

=C2=A0

Section 3.2: &q= uot;The client requests an access token by making an HTTP "POST" = request to the token endpoint as described in Section 4.1.1 of [RFC6749]&qu= ot;

=C2=A0

Should this act= ually say Section 4.1.3 of RFC6749 which is the Access Token Request sectio= n for the authorisation code grant?

=C2=A0

Assuming the ab= ove is true, should the `code` parameter POSTed to the authorisation server= =C2=A0be the value of the `device_code` parameter returned to the client i= n the initiating request?

=C2=A0

Many thanks,=

=C2=A0

Alex Bilbie<= /u>

=C2=A0


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



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



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




--001a113d6a0ad331e2053737d95f-- From nobody Sat Jul 9 11:29:03 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1AA312D5F4 for ; Sat, 9 Jul 2016 11:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, 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 JmxO9PuKMlut for ; Sat, 9 Jul 2016 11:29:00 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FE4C12D5EB for ; Sat, 9 Jul 2016 11:29:00 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id f189so99754678oig.3 for ; Sat, 09 Jul 2016 11:29:00 -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=XSj2savepyAuIqYw+9sb4NInCwwmNu4wVRKXCsiaLJw=; b=n0v3E5IaCYL60yPkuSHfaWsARerPefdcqhokKZi2/q+R3xHxiahwVaLpIZWpC2gde8 hMnQXzJkr7iDOgnpPDpPtfkYVHy+H+MBfiUv7X9xEbkqZrTH/EgJmg6V/uFaciTyUQF3 JXEqqKyNBG8B1EgAcTojeAT5/ZfGNrosSxJkf42SRzveckKJOmBC0b1ez7P4C50DdTUz Plsg9wMI1dzQDHzzEhCC/gsU48/qqlK7RMZIFwsOTxFsKgUOPoVQ5QEo/6SBU1KDHOS5 c3b5RLCdy4qqUJn5M2RdqD20YYjmx+xduzr9XMRXxaPB6tbfaX7iyTnKkQFFrhBz+etc CC8Q== 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=XSj2savepyAuIqYw+9sb4NInCwwmNu4wVRKXCsiaLJw=; b=SIhC8zMRcftudeXpYCLYTKZyagDkVMP69ysCKYMi7+DvQOrKgLTQO29gC6RdXpGhtH 7ldYqtIRzvANNRi0JmVgugthLy8PxWgTXO7GKyU5Ftd1724MS998N5RoCwKAb2vBZtIU KTu8xwWt33wNjPz16F24xprnMTTLYfyXBYX3/kXXbwPpXcCAqCnnhSyZvCUV5/Yjr5qf 80af1tDFNfCoFlFLe5M6RXB79UVG4igtr8QB1QlSQxXlTcRrsG4Ecm0fr0ycQsycId6D 66tUvmXtrPB9mGyK/gHA/ka7PGdWH44kCg3Jyp+XlpGzUzT+lHNpLG3uALMrkLeT9/xD 7eIQ== X-Gm-Message-State: ALyK8tKAWuD2vlkj7Sx4w8nDSjFSt7aE1vI3MDCglGJyG0LP7XDv+MrMhoNpsvZtQVSqZGnytv91XOD0w8D1Poy6 X-Received: by 10.157.6.227 with SMTP id 90mr6696778otx.71.1468088939516; Sat, 09 Jul 2016 11:28:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.232.134 with HTTP; Sat, 9 Jul 2016 11:28:40 -0700 (PDT) In-Reply-To: References: From: William Denniss Date: Sat, 9 Jul 2016 11:28:40 -0700 Message-ID: To: Brian Campbell Content-Type: multipart/alternative; boundary=94eb2c04fa82bd63a105373817d0 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Device flow clarifications X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2016 18:29:03 -0000 --94eb2c04fa82bd63a105373817d0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Jul 8, 2016 at 6:56 PM, Brian Campbell wrote: > I hate to be pedantic but... well, here goes. > Thanks for your review, it's important to get this right :-) > Grant types other than those defined in RFC 6749 are supposed to be URIs > (see section 4.5 on Extension Grants > ). There's no registry > for grant_type values so name collisions are avoided via the use of URIs. > Glad you pointed this out. I had assumed there was a registry for base-level strings, and only non-standard extensions would need a URI, but you're right. > An IETF document like the Device Flow should probably use a stable IETF > URI rather than something under oauth.net, which it has no real > relationship with or control of. > I agree, it was never my proposal to use that, I was just pointing out that our current implementation does. My plan would be to release a new version of our endpoint once the spec is near-final, to conform to the standard. > RFC 6755 exists specifically for > the purpose of obtaining/registering such URIs and even has an example > registration request > for a grant type URI. > That example is useful. So what do people think about standardizing on: *urn:ietf:params:oauth:grant-type:device_code* > > On Fri, Jul 8, 2016 at 5:37 PM, William Denniss > wrote: > >> I agree that the token request section was not well defined, using the >> OAuth 2.0 definition in this case isn't correct as there are unique aspe= cts >> of the Device Flow grant_type that need to be specified >> >> I've posted an update that fleshes out the token request polling & >> response. https://tools.ietf.org/html/draft-ietf-oauth-device-flow-02 >> Section 3.2 referenced in the above email is now numbered 3.4 >> >> . >> >> I specified a grant_type value of "device_code" as it matches the >> convention for other OAuth grant types. Google's implementation >> >> currently uses a URI instead: http://oauth.net/grant_type/device/1.0. >> >> >> On Fri, Apr 15, 2016 at 3:42 PM, Aaron Parecki wrote= : >> >>> Hi Alex and Oli, >>> >>> I also believe you are correct. I posted a similar question a while ago >>> here: >>> >>> https://www.ietf.org/mail-archive/web/oauth/current/msg15139.html >>> >>> I had a couple other notes you may be interested in: >>> >>> https://www.ietf.org/mail-archive/web/oauth/current/msg15138.html >>> >>> My implementation of a server that implements the device flow is here, >>> although it actually acts as a proxy for existing OAuth services: >>> >>> https://github.com/aaronpk/TVAuthServer >>> >>> Cheers! >>> >>> ---- >>> Aaron Parecki >>> aaronparecki.com >>> @aaronpk >>> >>> >>> On Fri, Apr 15, 2016 at 8:24 PM, Oli Dagenais >>> wrote: >>> >>>> Hi Alex, >>>> >>>> >>>> >>>> I=E2=80=99m also working on an implementation based on the draft speci= fication. >>>> I came to the same conclusion about linking to Section 4.1.3 of RFC674= 9. >>>> >>>> >>>> >>>> As for your second question, I also came to the same conclusion, which >>>> was confirmed by looking at the source code to the Active Directory >>>> Authentication Library (ADAL) for .NET (Azure Active Directory is my >>>> project=E2=80=99s first target). ADAL also sets the grant_type paramet= er to >>>> =E2=80=9Cdevice_code=E2=80=9D (contrast this with the value originally= in section 4.1.3). >>>> >>>> >>>> >>>> I am hoping to also test my implementation against other major server >>>> implementations (Google and Facebook come to mind) in the next few wee= ks >>>> and will report my findings to this mailing list. >>>> >>>> >>>> >>>> Cheers, >>>> >>>> - Oli >>>> >>>> >>>> >>>> -- >>>> >>>> Let me help you be awesome at what you do, using >>>> >>>> Microsoft Developer Tools >>>> >>>> +1 613-212-5551 >>>> >>>> >>>> >>>> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Alex >>>> Bilbie >>>> *Sent:* Friday, April 15, 2016 13:32 >>>> *To:* oauth@ietf.org >>>> *Subject:* [OAUTH-WG] Device flow clarifications >>>> >>>> >>>> >>>> N.B: I sent the following email to >>>> draft-ietf-oauth-device-flow@tools.ietf.org on 12th April but didn't >>>> receive a reply so am reposting here: >>>> >>>> >>>> >>>> --- >>>> >>>> >>>> >>>> Hello, >>>> >>>> >>>> >>>> I've been working on an implementation of the OAuth 2.0 Device Flow (a= s >>>> described at >>>> https://tools.ietf.org/html/draft-ietf-oauth-device-flow-01 >>>> >>>> ). >>>> >>>> >>>> >>>> Please could the following points please be clarified: >>>> >>>> >>>> >>>> Section 3.2: "The client requests an access token by making an HTTP >>>> "POST" request to the token endpoint as described in Section 4.1.1 of >>>> [RFC6749]" >>>> >>>> >>>> >>>> Should this actually say Section 4.1.3 of RFC6749 which is the Access >>>> Token Request section for the authorisation code grant? >>>> >>>> >>>> >>>> Assuming the above is true, should the `code` parameter POSTed to the >>>> authorisation server be the value of the `device_code` parameter retu= rned >>>> to the client in the initiating request? >>>> >>>> >>>> >>>> Many thanks, >>>> >>>> >>>> >>>> Alex Bilbie >>>> >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > --94eb2c04fa82bd63a105373817d0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Fri, Jul 8, 2016 at 6:56 PM, Brian Campbell <bcampbell@pingide= ntity.com> wrote:
=
I hate to be pedantic but... well, here goes.

Thanks for your review, it's important t= o get this right :-)
=C2=A0
Grant types other than those defined in RFC 6749 are supposed to be = URIs (see section 4.5 on=C2=A0 Extension Grants).=C2=A0 There's = no registry for grant_type values so name collisions are avoided via the us= e of URIs.

Glad you pointe= d this out.=C2=A0 I had assumed there was a registry for base-level strings= , and only non-standard extensions would need a URI, but you're right.<= /div>
=C2=A0
An I= ETF document like the Device Flow should probably use a stable IETF URI rat= her than something under oau= th.net, which it has no real relationship with or control of.

I agree, it was never my proposal to use that= , I was just pointing out that our current implementation does. My plan wou= ld be to release a new version of our endpoint once the spec is near-final,= to conform to the standard.
=C2=A0
RFC 6755 exists specifically for the purpose of obtaining/registering = such URIs and even has an example registration request for a grant t= ype URI.

That example is useful. So what do people thi= nk about standardizing on:

urn:ietf:params:oauth:grant-type:device_code
=C2=A0

On Fri, Jul 8, 2016 at 5:37 PM, Willi= am Denniss <wdenniss@google.com> wrote:
I agree that the token request section was not well= defined, using the OAuth 2.0 definition in this case isn't correct as = there are unique aspects of the Device Flow grant_type that need to be spec= ified

=C2=A0I've posted an update that fleshes= out the token request polling & response. https://tools= .ietf.org/html/draft-ietf-oauth-device-flow-02 =C2=A0Section 3.2 refere= nced in the above email is now numbered=C2=A03.4= .

I specified a grant_type value of "devi= ce_code" as it matches the convention for other OAuth grant types. Goo= gle's implementation currently= uses a URI instead:=C2=A0http://oauth.net/grant_type/device/1.0.
<= div>

On Fri, Apr 15, 2016 at 3:42 PM, Aaron Parecki <aaron@parecki= .com> wrote:
Hi Alex and= Oli,

I also believe you are correct. I posted a similar= question a while ago here:

h= ttps://www.ietf.org/mail-archive/web/oauth/current/msg15139.html

I had a couple other notes you may be interested in:=


My i= mplementation of a server that implements the device flow is here, although= it actually acts as a proxy for existing OAuth services:

=
----
Aaron Parecki

=

On Fri, Apr 15, 2016 at 8:24 PM, O= li Dagenais <olivida@microsoft.com> wrote:

Hi Alex,

=C2=A0

I=E2=80=99m also wo= rking on an implementation based on the draft specification. I came to the = same conclusion about linking to Section 4.1.3 of RFC6749.

=C2=A0

As for your second = question, I also came to the same conclusion, which was confirmed by lookin= g at the source code to the Active Directory Authentication Library (ADAL) for .NET (Azure Active Directory is my project=E2=80=99s fi= rst target). ADAL also sets the grant_type parameter to =E2=80=9Cdevice_cod= e=E2=80=9D (contrast this with the value originally in section 4.1.3).

=C2=A0

I am ho= ping to also test my implementation against other major server implementati= ons (Google and Facebook come to mind) in the next few weeks and will report my findings to this mailing list.

= =C2=A0

Cheers,=

- Oli

= =C2=A0

--

Let me = help you be awesome at what you do, using

Microso= ft Developer Tools

+1 61= 3-212-5551

=C2=A0

From: OAu= th [mailto:oaut= h-bounces@ietf.org] On Behalf Of Alex Bilbie
Sent: Friday, April 15, 2016 13:32
To: oauth@ietf.o= rg
Subject: [OAUTH-WG] Device flow clarifications<= /p>

=C2=A0

N.B: I sent the following ema= il to=C2=A0draft-ietf-oauth-device-flow@tools.ietf.org=C2=A0on 12= th April but didn't receive a=C2=A0reply so am reposting here:

=C2=A0

---

=C2=A0

Hello,

=C2=A0

I've been working on an implementatio= n of the OAuth 2.0 Device Flow (as described at=C2=A0https://tools.ietf.org/html/draft-ietf-oauth-device-flow-01= ).

=C2=A0

Please could the following points please = be clarified:

=C2=A0

Section 3.2: "The client requests an= access token by making an HTTP "POST" request to the token endpo= int as described in Section 4.1.1 of [RFC6749]"

=C2=A0

Should this actually say Section 4.1.3 of= RFC6749 which is the Access Token Request section for the authorisation co= de grant?

=C2=A0

Assuming the above is true, should the `c= ode` parameter POSTed to the authorisation server =C2=A0be the value of the= `device_code` parameter returned to the client in the initiating request?<= u>

=C2=A0

Many thanks,

=C2=A0

Alex Bilbie

=C2=A0


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



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



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



--94eb2c04fa82bd63a105373817d0-- From nobody Sat Jul 9 12:50:26 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB92212D0D3 for ; Sat, 9 Jul 2016 12:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.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 nDJ9CSTG7EOs for ; Sat, 9 Jul 2016 12:50:23 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::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 41FA912B05A for ; Sat, 9 Jul 2016 12:50:23 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id f30so70042514ioj.2 for ; Sat, 09 Jul 2016 12:50:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Y/GCbt9jCyxEEc8acVZ8ZOFxhSJ7aFxR1wcxWo4/Wwc=; b=Prs/nX0f4Rx8RwrH2Ist8E/3O1LxMB412pLbFQ3Qv/tKFmo4rvn11+E9nBefyi8rIR BiH6cD3RzNH0y+slFS2GYvfdjf0agpz16SSohLx5rgFigHLDIiXxxSo2tA2vJDLIJH3M +2/sYxBo3uG5Q9TMxk49m/1YfUQokrOIvnk3I= 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=Y/GCbt9jCyxEEc8acVZ8ZOFxhSJ7aFxR1wcxWo4/Wwc=; b=MImp4Bxn5plOAHaVPxiKGtqqS3nh1sIu41yxgtyRcwMQ4l5ge9gCRdTK47byopaNQT BFESSwWh5CGFvJD9UCeJaWQRcIj2YUsJJoLOIFeM2yDGIXP1M/0S6tui75RNtS7UyM6I 9tNUrhk0ABhRYH7paWyOlDsI6WrWjUY7/6nHl2CoA23PFH/10KDR3qvc+5uBerwLPqNF /bFvGSZJkQV78TRnGcb6yPv988XtNhuh2MIirTq0DZgf8VXTCbwCFLpmRjljqr1IA+24 PJj5yPxl3WFe2uVYf39+YAUZu3UUNbkgJXm5S3xQkUIDtVWpWT+yyGiAZZQ4c3lewJTS RH4Q== X-Gm-Message-State: ALyK8tJWFcOZQtEXBmCtK5Qkdnu2QVFKBUGuWnm+TujM9pNTtnIL6ZtaaxaRFD2GZCJZZeP/cKYYV+lzdnwCmYqe X-Received: by 10.107.8.140 with SMTP id h12mr4810925ioi.95.1468093822490; Sat, 09 Jul 2016 12:50:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.28.149 with HTTP; Sat, 9 Jul 2016 12:49:52 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Sat, 9 Jul 2016 13:49:52 -0600 Message-ID: To: William Denniss Content-Type: multipart/alternative; boundary=001a113fb6b0c972cb0537393a6f Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Device flow clarifications X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2016 19:50:25 -0000 --001a113fb6b0c972cb0537393a6f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Jul 9, 2016 at 12:28 PM, William Denniss wrote: > > On Fri, Jul 8, 2016 at 6:56 PM, Brian Campbell > wrote: > >> I hate to be pedantic but... well, here goes. >> > > Thanks for your review, it's important to get this right :-) > Well, I haven't actually reviewed the draft yet. But I will. I just noticed the email thread. 6755 was my first RFC so I'm kind of partial to it getting used :) > > >> Grant types other than those defined in RFC 6749 are supposed to be URIs >> (see section 4.5 on Extension Grants >> ). There's no registry >> for grant_type values so name collisions are avoided via the use of URIs= . >> > > Glad you pointed this out. I had assumed there was a registry for > base-level strings, and only non-standard extensions would need a URI, bu= t > you're right. > That probably would have been a better way for 6749 to have set things up but that's water under the bridge at this point. > > >> An IETF document like the Device Flow should probably use a stable IETF >> URI rather than something under oauth.net, which it has no real >> relationship with or control of. >> > > I agree, it was never my proposal to use that, I was just pointing out > that our current implementation does. > I figured. I was just looking to head-off the potential suggesting coming from elsewhere. > My plan would be to release a new version of our endpoint once the spec i= s > near-final, to conform to the standard. > Excellent. > > >> RFC 6755 exists specifically for >> the purpose of obtaining/registering such URIs and even has an example >> registration request >> for a grant type URI. >> > > That example is useful. So what do people think about standardizing on: > > *urn:ietf:params:oauth:grant-type:device_code* > Works for me. > > >> >> On Fri, Jul 8, 2016 at 5:37 PM, William Denniss >> wrote: >> >>> I agree that the token request section was not well defined, using the >>> OAuth 2.0 definition in this case isn't correct as there are unique asp= ects >>> of the Device Flow grant_type that need to be specified >>> >>> I've posted an update that fleshes out the token request polling & >>> response. https://tools.ietf.org/html/draft-ietf-oauth-device-flow-02 >>> Section 3.2 referenced in the above email is now numbered 3.4 >>> >>> . >>> >>> I specified a grant_type value of "device_code" as it matches the >>> convention for other OAuth grant types. Google's implementation >>> >>> currently uses a URI instead: http://oauth.net/grant_type/device/1.0. >>> >>> >>> On Fri, Apr 15, 2016 at 3:42 PM, Aaron Parecki >>> wrote: >>> >>>> Hi Alex and Oli, >>>> >>>> I also believe you are correct. I posted a similar question a while ag= o >>>> here: >>>> >>>> https://www.ietf.org/mail-archive/web/oauth/current/msg15139.html >>>> >>>> I had a couple other notes you may be interested in: >>>> >>>> https://www.ietf.org/mail-archive/web/oauth/current/msg15138.html >>>> >>>> My implementation of a server that implements the device flow is here, >>>> although it actually acts as a proxy for existing OAuth services: >>>> >>>> https://github.com/aaronpk/TVAuthServer >>>> >>>> Cheers! >>>> >>>> ---- >>>> Aaron Parecki >>>> aaronparecki.com >>>> @aaronpk >>>> >>>> >>>> On Fri, Apr 15, 2016 at 8:24 PM, Oli Dagenais >>>> wrote: >>>> >>>>> Hi Alex, >>>>> >>>>> >>>>> >>>>> I=E2=80=99m also working on an implementation based on the draft >>>>> specification. I came to the same conclusion about linking to Section= 4.1.3 >>>>> of RFC6749. >>>>> >>>>> >>>>> >>>>> As for your second question, I also came to the same conclusion, whic= h >>>>> was confirmed by looking at the source code to the Active Directory >>>>> Authentication Library (ADAL) for .NET (Azure Active Directory is my >>>>> project=E2=80=99s first target). ADAL also sets the grant_type parame= ter to >>>>> =E2=80=9Cdevice_code=E2=80=9D (contrast this with the value originall= y in section 4.1.3). >>>>> >>>>> >>>>> >>>>> I am hoping to also test my implementation against other major server >>>>> implementations (Google and Facebook come to mind) in the next few we= eks >>>>> and will report my findings to this mailing list. >>>>> >>>>> >>>>> >>>>> Cheers, >>>>> >>>>> - Oli >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Let me help you be awesome at what you do, using >>>>> >>>>> Microsoft Developer Tools >>>>> >>>>> +1 613-212-5551 >>>>> >>>>> >>>>> >>>>> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Alex >>>>> Bilbie >>>>> *Sent:* Friday, April 15, 2016 13:32 >>>>> *To:* oauth@ietf.org >>>>> *Subject:* [OAUTH-WG] Device flow clarifications >>>>> >>>>> >>>>> >>>>> N.B: I sent the following email to >>>>> draft-ietf-oauth-device-flow@tools.ietf.org on 12th April but didn't >>>>> receive a reply so am reposting here: >>>>> >>>>> >>>>> >>>>> --- >>>>> >>>>> >>>>> >>>>> Hello, >>>>> >>>>> >>>>> >>>>> I've been working on an implementation of the OAuth 2.0 Device Flow >>>>> (as described at >>>>> https://tools.ietf.org/html/draft-ietf-oauth-device-flow-01 >>>>> >>>>> ). >>>>> >>>>> >>>>> >>>>> Please could the following points please be clarified: >>>>> >>>>> >>>>> >>>>> Section 3.2: "The client requests an access token by making an HTTP >>>>> "POST" request to the token endpoint as described in Section 4.1.1 of >>>>> [RFC6749]" >>>>> >>>>> >>>>> >>>>> Should this actually say Section 4.1.3 of RFC6749 which is the Access >>>>> Token Request section for the authorisation code grant? >>>>> >>>>> >>>>> >>>>> Assuming the above is true, should the `code` parameter POSTed to the >>>>> authorisation server be the value of the `device_code` parameter ret= urned >>>>> to the client in the initiating request? >>>>> >>>>> >>>>> >>>>> Many thanks, >>>>> >>>>> >>>>> >>>>> Alex Bilbie >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> > --001a113fb6b0c972cb0537393a6f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Jul 9, 2016 at 12:28 PM, William Denniss <= wdenniss@google.co= m> wrote:

On Fri, Jul 8, 2016 at 6:56 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:
=
I hate to be pedantic but... well, here goes.

Thanks for your review, it's impo= rtant to get this right :-)

Well, I haven't actually reviewed the draft yet. But I will. I= just noticed the email thread. 6755 was my first RFC so I'm kind of pa= rtial to it getting used :)

=C2=A0
=C2=A0
Grant types oth= er than those defined in RFC 6749 are supposed to be URIs (see section 4= .5 on=C2=A0 Extension Grants).=C2=A0 There's no registry for grant_= type values so name collisions are avoided via the use of URIs.
<= /div>

Glad you pointed this out.=C2= =A0 I had assumed there was a registry for base-level strings, and only non= -standard extensions would need a URI, but you're right.

That probably would have been a b= etter way for 6749 to have set things up but that's wa= ter under the bridge at this point.

=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
=C2=A0
=
An IETF document like the Device Flow should probably use a stab= le IETF URI rather than something under oauth.net, which it has no real relationship with or contro= l of.

I agree, it was never m= y proposal to use that, I was just pointing out that our current implementa= tion does.

I figure= d. I was just looking to head-off the potential suggesting coming from else= where.
=C2=A0
=C2=A0
My plan would be to release a new version of our endpoi= nt once the spec is near-final, to conform to the standard.

Excellent.

=C2= =A0
=C2=A0
RFC= 6755 exists specifically for the purpose of obtaining/registering such= URIs and even has an example registration request for a grant type = URI.

That example is useful. So what do people = think about standardizing on:

urn:ietf:params:oauth:grant-type:device_code

Works for = me.

=C2=A0
<= div>
=C2=A0

On Fri, Jul 8, 2016 at 5:37 PM, William Denniss &l= t;wdenniss@google.= com> wrote:
I agree that the token request section was not we= ll defined, using the OAuth 2.0 definition in this case isn't correct a= s there are unique aspects of the Device Flow grant_type that need to be sp= ecified

=C2=A0I've posted an update that flesh= es out the token request polling & response. https://too= ls.ietf.org/html/draft-ietf-oauth-device-flow-02 =C2=A0Section 3.2 refe= renced in the above email is now numbered=C2=A03= .4.

I specified a grant_type value of "de= vice_code" as it matches the convention for other OAuth grant types. G= oogle's implementation current= ly uses a URI instead:=C2=A0http://oauth.net/grant_type/device/1.0.


On Fri, Apr 15, 2016 at 3:42 PM, Aaron Parecki <aaron@p= arecki.com> wrote:
Hi Alex and Oli,

I also beli= eve you are correct. I posted a similar question a while ago here:


I had a coupl= e other notes you may be interested in:


My implementation of a server that impl= ements the device flow is here, although it actually acts as a proxy for ex= isting OAuth services:


Cheers!


On Fri, Apr 15, 2016 at 8:24 PM, O= li Dagenais <olivida@microsoft.com> wrote:

Hi Alex,=

=C2=A0

I=E2=80=99m also wo= rking on an implementation based on the draft specification. I came to the = same conclusion about linking to Section 4.1.3 of RFC6749.

=C2=A0

As for your second = question, I also came to the same conclusion, which was confirmed by lookin= g at the source code to the Active Directory Authentication Library (ADAL) for .NET (Azure Active Directory is my project=E2=80=99s fi= rst target). ADAL also sets the grant_type parameter to =E2=80=9Cdevice_cod= e=E2=80=9D (contrast this with the value originally in section 4.1.3).

=C2=A0

I am ho= ping to also test my implementation against other major server implementati= ons (Google and Facebook come to mind) in the next few weeks and will report my findings to this mailing list.

= =C2=A0

Cheers,=

- Oli

= =C2=A0

--

Let me = help you be awesome at what you do, using

Microso= ft Developer Tools

+1 61= 3-212-5551

=C2=A0

From: OAu= th [mailto:oaut= h-bounces@ietf.org] On Behalf Of Alex Bilbie
Sent: Friday, April 15, 2016 13:32
To: oauth@ietf.o= rg
Subject: [OAUTH-WG] Device flow clarifications<= /p>

=C2=A0

N.B: I sent the following ema= il to=C2=A0draft-ietf-oauth-device-flow@tools.ietf.org=C2=A0on 12= th April but didn't receive a=C2=A0reply so am reposting here:

=C2=A0

---

=C2=A0

Hello,

=C2=A0

I've been working on an implementatio= n of the OAuth 2.0 Device Flow (as described at=C2=A0https://tools.ietf.org/html/draft-ietf-oauth-device-flow-01= ).

=C2=A0

Please could the following points please = be clarified:

=C2=A0

Section 3.2: "The client requests an= access token by making an HTTP "POST" request to the token endpo= int as described in Section 4.1.1 of [RFC6749]"

=C2=A0

Should this actually say Section 4.1.3 of= RFC6749 which is the Access Token Request section for the authorisation co= de grant?

=C2=A0

Assuming the above is true, should the `c= ode` parameter POSTed to the authorisation server =C2=A0be the value of the= `device_code` parameter returned to the client in the initiating request?<= u>

=C2=A0

Many thanks,

=C2=A0

Alex Bilbie

=C2=A0


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



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



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




--001a113fb6b0c972cb0537393a6f-- From nobody Sun Jul 10 19:13:10 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A5AF12B077 for ; Sun, 10 Jul 2016 19:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 gkXUoiMOg4Kd for ; Sun, 10 Jul 2016 19:13:07 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id A764A12B074 for ; Sun, 10 Jul 2016 19:13:06 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.28,344,1464616800"; d="scan'208";a="180002759" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipocvi.tcif.telstra.com.au with ESMTP; 11 Jul 2016 12:13:03 +1000 X-IronPort-AV: E=McAfee;i="5700,7163,8222"; a="160864301" Received: from wsmsg3701.srv.dir.telstra.com ([172.49.40.169]) by ipcavi.tcif.telstra.com.au with ESMTP; 11 Jul 2016 12:13:03 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3701.srv.dir.telstra.com ([fe80::d462:bcaa:ad1:66fc%15]) with mapi; Mon, 11 Jul 2016 12:13:03 +1000 From: "Manger, James" To: "oauth@ietf.org" Date: Mon, 11 Jul 2016 12:13:01 +1000 Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-05.txt Thread-Index: AdHZAiyWvoK7K29lRD2ZWXGhhpb+6wB//99g Message-ID: <255B9BB34FB7D647A506DC292726F6E13BD67E62B2@WSMSG3153V.srv.dir.telstra.com> References: <20160708101903.32067.39351.idtracker@ietfa.amsl.com> In-Reply-To: <20160708101903.32067.39351.idtracker@ietfa.amsl.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-05.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 02:13:09 -0000 > Title : OAuth 2.0 Token Exchange: An STS for the REST of= Us > https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-05 This spec has some useful functionality, but comes across as a tad conceite= d. Suggestions: 1. Drop "An STS for the REST of Us" from the title. "STS" is not common enough to be unexpanded. The protocol isn't a poster-ch= ild for RESTful design; as the 3rd paragraph of the introduction explicitly= says ("the STS protocol defined in this specification is not itself RESTfu= l"). Hopefully it is easier for developers than the WS-* suite, but it is f= rom some of the same companies and for some similar purposes so "for the re= st of us" doesn't really ring true (though it is a cute play on words). 2. Drop "lightweight" from the abstract. Stick to the facts: an HTTP+JWT+JSON-based STS, as an alternative to an HTT= P+SOAP+XML-based STS. 3. Drop "heavyweight" and "lightweight" from the introduction. FROM: Web Service clients have used WS-Trust [WS-Trust] as the protocol to interact with an STS for token exchange, however WS-Trust is a fairly heavyweight protocol, which uses XML, SOAP, etc. Whereas, the trend in modern Web development has been towards lightweight services utilizing RESTful patterns and JSON. ... This specification defines a lightweight protocol extending OAuth 2.= 0 TO: Web Service clients have used WS-Trust [WS-Trust] as the protocol to interact with an STS for token exchange. While WS-Trust uses XML and SOAP, the trend in modern Web development has been towards RESTful patterns and JSON. ... This specification defines a protocol extending OAuth 2.0 Requiring "only an HTTP client and JSON parser" is nice for some developers= over requiring an XML/SOAP parser. But to warrant the "lightweight" tag th= e spec need to mention major design ideas from WS-Trust that are deliberate= ly dropped from OAuth-2.0-Token-Exchange (and will not need to be added lat= er). 4. Do we really need to put a non-access-token (eg an id-token) in a field = named "access_token", then override that with "issued_token_type":"urn:ietf= :params:oauth:token-type:id_token"? 5. I'm suspect I'm far too late to the party to comment on token_type vs {s= ubject|requested|actor|issued}_token_type, but surely we can do better than= create the confusion in this spec. I think the issue is that we want to su= pport tokens from other parties and tokens from this AS. For the former we = need to indicate the syntax (eg JWT or SAML) so the AS can parse it; for th= e latter we need to indicate what the AS issued it for (eg access_token or = refresh_token) so the AS can look it up in the correct DB. SUGGESTION: Rename xxxx_token_type to xxxx_token_context. subject_token_context REQUIRED. An identifier of either: the syntax of the token (when issued from another AS) so the AS knows= how to parse it; or the sort of token it is (when issued by this AS). See section 3. Adjust other xxxx_token_context definitions, and section 3. -- James Manger From nobody Mon Jul 11 09:41:19 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 780B112D0F6 for ; Mon, 11 Jul 2016 09:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.888 X-Spam-Level: X-Spam-Status: No, score=-3.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.287, 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 lg67An9c57eI for ; Mon, 11 Jul 2016 09:41:17 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3A4E12B02F for ; Mon, 11 Jul 2016 09:41:16 -0700 (PDT) Received: from [192.168.10.131] ([136.199.13.210]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MgszY-1bib0L3LTE-00M0II for ; Mon, 11 Jul 2016 18:41:13 +0200 To: "oauth@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <5783CC2C.7090909@gmx.net> Date: Mon, 11 Jul 2016 18:41:16 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="F0W6ajgXeliqaPw6Vkii6aJucvQSKX4q8" X-Provags-ID: V03:K0:Gh8X95Mp+Q9YwtTAeZXwAp2WbJtdz2v4uNakvw24oCZLTxQPERa 9MMa1IjS9ltAGsgeY0FMyP+BzsFeKlublXcSVmZzJPcRfO+a2W2mWigsMjfyYjGmd9SPQMV C6NI34bdEZfkJy0LvP5OTtZneLfq15GaioLZCi669ZsVDNK0JjvQMZvKmo9PLy5GenMeT35 URu/FJ/0f5hV4v6zUgqQQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:kDXy5WaFM+s=:dqoFo3jhdy5I4fTaC4BsTq +/4gRYLcTQNjkTN5vwchH3Vm6j/CJqnJJNzKKS16nNS3o//el4Fji2n+3RUtV9QoKv2bagSLO WNyD+ptszkrShxvPfSogQ3ri6N1AZSSTUcy57LgF86xHLPptnun+knUiAEtl/d7NQMgyOOjt1 N3nGqaLFDWmWSm0qP5g8/gM87zC0zRdzQpvAhVcze3FE12fZehGiiiJq3I+ghVlrHpq5A4z1i Wjuu15IZPZNNZpFJ+x29TM8DqARPt5WQoMov4QJYbLGoIM5zu6nZquutpCu8yOb4uQ0EXdOl/ /rCP20bneUs0oHDkhb+cffz0qeF+ue9AsUBdKqu/toyS4e3oABnTwniG4rX5utWHOGgdvAS/G h0mlMpInr/OEF2oDBFFkEH7iQHJsqQH/pHi//RLu/xkMNSXYqOSCW+ma3ex/8BBDC8jecs0iL gj16i5jJ2EAXl49wvJgOGYLnXsdZCJvhT7tSF+AaXnQ1gHuHaRPsObXKh5byoopApsOkcmKlB oadky470rU0842Is0uHbcND2I9+PKAxSiVqUs/xXB+jQu1uD8ls6iNiG/gp7Sfzx83R7hTsEU tGU1+W5zta9YSpxHFUbaMY5MSSJsygrTxnzaGJxK0tUcY1+dfNSmkYjIUVM4R/9+8rIgN3vCI Hg1vyGjguXJEqkZRERF9fPyD6KwMmdf+UrOsyhxEs3sLbsO00hXVlhrLqDmEPfUndhRYaIlAm BIJ7Y+YjQdGy1CGnYAJsF43kt+zA9m7A9Vc/K082XF3jClBf/1mzEn4DfMo= Archived-At: Subject: [OAUTH-WG] Proposals for OAuth Meeting Agenda X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 16:41:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --F0W6ajgXeliqaPw6Vkii6aJucvQSKX4q8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi guys, here is a proposal for the meeting agenda: https://www.ietf.org/proceedings/96/agenda/agenda-96-oauth Does this sound reasonable? Ciao Hannes --F0W6ajgXeliqaPw6Vkii6aJucvQSKX4q8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJXg8wtAAoJEGhJURNOOiAtt+4H/0pvOZQvFaUdhZ63R7yTtAJQ tzCxK5FieEawqV7FT5oZbTm8WdZbHlosO9wCpFzH+TLsb6Tv5wHNAKvmjbZwkM40 z55erniHhQw+kLdElrP0WEUKY5A/xqF4PLvIAocsqumSR8wx/EvZNnz5KzIdPyI3 LkZJ9+4dllAWCsONkhvxdm7h/PitWR6zl8KBtBkZ1EeWy8/0tiwvuLWubGRqFo4w nDoYpJaeVTGENdTMWccJVXS4wLCiFtOH4M2IpQroUkqjPa5EO9Z1XzyKeyY8hxMW 9X1GnFVkHYeOskqfeGtpvhTiMGeVKPdJlYU9UZNiuhpY5827o9C6hPYlUNvXptI= =aNjC -----END PGP SIGNATURE----- --F0W6ajgXeliqaPw6Vkii6aJucvQSKX4q8-- From prvs=99323d338=keshav.shrivastava@citrix.com Mon Jul 11 15:19:29 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC23E12D0BF for ; Mon, 11 Jul 2016 15:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gu74qyftcg7Q for ; Mon, 11 Jul 2016 15:19:28 -0700 (PDT) Received: from SMTP.CITRIX.COM.AU (smtp.citrix.com.au [103.14.252.240]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9390512B02A for ; Mon, 11 Jul 2016 15:19:27 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.28,348,1464652800"; d="scan'208,217"; a="58389098" From: Keshav Shrivastava To: "oauth@ietf.org" Thread-Topic: Regarding RFC 3389 Thread-Index: AQHR28JHwuGvpNGHDU6eifK4EPNH9w== Date: Mon, 11 Jul 2016 22:19:24 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_B5301A434E464F7F972E34C24B6BC8A5citrixcom_" MIME-Version: 1.0 X-DLP: SIN1 Archived-At: X-Mailman-Approved-At: Thu, 14 Jul 2016 06:22:06 -0700 Cc: "zopf@lucent.com" Subject: [OAUTH-WG] Regarding RFC 3389 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 22:21:49 -0000 --_000_B5301A434E464F7F972E34C24B6BC8A5citrixcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBBdXRob3IocyksDQoNClBlciBSRkMgc2VjdGlvbiA1LjEgdXNhZ2Ugb2YgU0RQLCBpdCBp cyBub3QgY2xlYXIgd2hhdCB3aWxsIGhhcHBlbiBpbiByZXNwb25zZSBmb3IgdGhlIHJlcXVlc3Qg Y29udGFpbmluZyAxMyBpbiBtIGhlYWRlciBmb3IgZm9sbG93aW5nIGNvbmRpdGlvbi4NCg0KQ29u c2lkZXI6DQoNCjEpICAgICAgIENhbGxlZCBwYXJ0eSB0aGF0IGRvZXNu4oCZdCBzdXBwb3J0cyBD TiB3aXRoIEc3MTFVIGJ1dCBvbmx5IHN1cHBvcnQgRzcxMVUsIHRoZW4gd2lsbCBpdCBzZW5kIGJh Y2sgZm9sbG93aW5nPw0KDQptPWF1ZGlvIDQ5MjMwIFJUUC9BVlAgMA0KDQoNCg0Kb3Igd2lsbCBz ZW5kIGJhY2sgNDg4IE5vdCBhY2NlcHRhYmxlIGhlcmU/DQoNClJlZ2FyZHMsDQpLZXNoYXYgU2hy aXZhc3RhdmENCg0KDQo= --_000_B5301A434E464F7F972E34C24B6BC8A5citrixcom_ Content-Type: text/html; charset="utf-8" Content-ID: <0E9CA86BB8797C4592F5DC006DF3F4E4@citrix.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z b0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBo DQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmln aHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTpDYWxp YnJpO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBv c2U7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4ubXNv SW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseTpDYWxpYnJpO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjU5NS4wcHQgODQyLjBwdDsNCgltYXJnaW46NzIu MHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3Qt aWQ6MTkyMTMyOTgwNzsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0 ZS1pZHM6NzAyNjg5MDAyIDY3Njk4NzA1IDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4 NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwwOmxldmVs MQ0KCXttc28tbGV2ZWwtdGV4dDoiJTFcKSI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0K QGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpA bGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2 ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZl bDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 O30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dl cjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9 DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkg Ymdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3 MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkRlYXIgQXV0aG9yKHMpLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+UGVyIFJGQyBzZWN0aW9uIDUuMSB1c2FnZSBv ZiBTRFAsIGl0IGlzIG5vdCBjbGVhciB3aGF0IHdpbGwgaGFwcGVuIGluIHJlc3BvbnNlIGZvciB0 aGUgcmVxdWVzdCBjb250YWluaW5nIDEzIGluIG0gaGVhZGVyIGZvciBmb2xsb3dpbmcgY29uZGl0 aW9uLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5Db25zaWRl cjogPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0 eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAh c3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PHNwYW4gc3R5bGU9 Im1zby1saXN0Oklnbm9yZSI+MSk8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9z cGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij5DYWxsZWQgcGFydHkgdGhhdCBkb2VzbuKAmXQgc3VwcG9ydHMgQ04gd2l0aCBHNzExVSBidXQg b25seSBzdXBwb3J0IEc3MTFVLCB0aGVuIHdpbGwgaXQgc2VuZCBiYWNrIGZvbGxvd2luZz88bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPm09YXVkaW8gNDkyMzAgUlRQL0FWUCAwDQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+b3Igd2lsbCBz ZW5kIGJhY2sgNDg4IE5vdCBhY2NlcHRhYmxlIGhlcmU/PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5LZXNoYXYgU2hy aXZhc3RhdmE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_B5301A434E464F7F972E34C24B6BC8A5citrixcom_-- From nobody Fri Jul 15 13:37:29 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22ABB12DDE2 for ; Fri, 15 Jul 2016 13:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.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 07s5LolZE8ws for ; Fri, 15 Jul 2016 13:37:16 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C273F12DDDF for ; Fri, 15 Jul 2016 13:37:10 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id f6so27988052ith.1 for ; Fri, 15 Jul 2016 13:37:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5cCrz81hL9slVSXOoR8NTRP5Kz+eX3kq9qoPJsInXgc=; b=i1LV9z6+ajMMZVlH3XazwsJUjNBL1LprRpffXxOqYUBHyBCiOmgd2lXB7H0ato3FzS Ne3NFOTOkzco1s7H2pdnocronr0iLYj7zVUosY97c3Nw8W7BLRkShffHlEOzRpvs5YTz 3CAP0IqSnDDtiTLDmAZDlA9IJaSgzdmjObOtw= 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=5cCrz81hL9slVSXOoR8NTRP5Kz+eX3kq9qoPJsInXgc=; b=gVRr1jxHm1p99JWfj3rNQrQJaFipKkH2MnOVNiR35B3y3XaWqVIJp52uQwYPzz5sAX WpvfM0zA+Rx758GG/zzO7Ukkkm+/zwwm/GnSIdNWU/y9/rt+Pdyx96s806ZCZKLhHGoP FhhF3+8+D5erjlnSjGG3aBHgAzqU0zXVVsIhTmo7Nxl54if4GOnhvvtBCrULDDyBvhKO wTlLSYVYkSr32Rn2yHcjdDJfE1K+d9RH62GV/Guy54UTQ3QjSWXD4KWbaKWecgbPjmEl gxdrQkFsG/ug0n/OjLanZarLCbvdNm3uDb6LK4PMVG7Vmx15b1e4RhJU0VQ27QLAb5XB v4MQ== X-Gm-Message-State: ALyK8tKQjs+4wIbADuf205vg0Mv2Lh2FS62wTksgZtYPtY5gZpNjYE4AJWx803VVbFzS+LMsYz7iq5xAMJCfnR9S X-Received: by 10.36.33.197 with SMTP id e188mr19771176ita.42.1468615029999; Fri, 15 Jul 2016 13:37:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.28.149 with HTTP; Fri, 15 Jul 2016 13:36:40 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E13BD67E62B2@WSMSG3153V.srv.dir.telstra.com> References: <20160708101903.32067.39351.idtracker@ietfa.amsl.com> <255B9BB34FB7D647A506DC292726F6E13BD67E62B2@WSMSG3153V.srv.dir.telstra.com> From: Brian Campbell Date: Fri, 15 Jul 2016 14:36:40 -0600 Message-ID: To: "Manger, James" Content-Type: multipart/alternative; boundary=001a1146ec4e2ceea20537b295c6 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-05.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 20:37:18 -0000 --001a1146ec4e2ceea20537b295c6 Content-Type: text/plain; charset=UTF-8 Thank you, James, for the review and feedback. I apologize for the slow reply - on top of being a busy week this was a difficult one to respond to. It's disappointing to hear that it came off as conceited. That certainly wasn't the intent (though I suppose it rarely is). While I think there's plenty of precedent in things calling themselves lightweight, whether or not it's justified, and do believe this is light enough to warrant the use of the term, I am open to dropping "heavyweight" and "lightweight", if you think it would improve the tone of the text. The title is something I'm less open to changes on. Honestly, I'm really partial to it. I described it as "really really important" on slide 7 of the IETF 93 presentation about token exchange and tried to brake it down humorously in a recent identity conference presentation . I've had numerous positive comments about it from people who appreciate the little touch of humor. I anticipate there may be some push-back in later stage reviews on the unexpanded acronym but I'll cross that bridge when/if I come to it and look to find some compromise. The "access_token" member/parameter is required per RFC 6749 so it has to be in the response anyway and seemed like a suitable bucket for the returned token even when the token isn't strictly an access token. What's an alternative, putting some dummy value in "access_token" and returning the requested token under a different name? You mention ID Tokens, which is a potentially interesting case as there's already sort of a way to additionally request an ID Token by using the "openid" scope. Perhaps there should be some discussion or guidance on that? I think that might even be helpful for something Tony has made statements about (maybe). Generally I think that it's a little too late to be changing parameter names like xxxx_token_type to xxxx_token_context. Unless there's overwhelming support from others for such a change. I do think the way that you've articulated the distinction between tokens from other parties and tokens from this AS is useful and I'll endeavor to add and/or adjust some text along those lines to further clarify. On Sun, Jul 10, 2016 at 8:13 PM, Manger, James < James.H.Manger@team.telstra.com> wrote: > > Title : OAuth 2.0 Token Exchange: An STS for the REST > of Us > > https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-05 > > This spec has some useful functionality, but comes across as a tad > conceited. > > Suggestions: > > 1. Drop "An STS for the REST of Us" from the title. > "STS" is not common enough to be unexpanded. The protocol isn't a > poster-child for RESTful design; as the 3rd paragraph of the introduction > explicitly says ("the STS protocol defined in this specification is not > itself RESTful"). Hopefully it is easier for developers than the WS-* > suite, but it is from some of the same companies and for some similar > purposes so "for the rest of us" doesn't really ring true (though it is a > cute play on words). > > 2. Drop "lightweight" from the abstract. > Stick to the facts: an HTTP+JWT+JSON-based STS, as an alternative to an > HTTP+SOAP+XML-based STS. > > 3. Drop "heavyweight" and "lightweight" from the introduction. > FROM: > Web Service clients have used WS-Trust > [WS-Trust] as the protocol to interact with an STS for token > exchange, however WS-Trust is a fairly heavyweight protocol, which > uses XML, SOAP, etc. Whereas, the trend in modern Web development > has been towards lightweight services utilizing RESTful patterns and > JSON. > ... This specification defines a lightweight protocol extending OAuth > 2.0 > TO: > Web Service clients have used WS-Trust > [WS-Trust] as the protocol to interact with an STS for token > exchange. While WS-Trust > uses XML and SOAP, the trend in modern Web development > has been towards RESTful patterns and > JSON. > ... This specification defines a protocol extending OAuth 2.0 > > Requiring "only an HTTP client and JSON parser" is nice for some > developers over requiring an XML/SOAP parser. But to warrant the > "lightweight" tag the spec need to mention major design ideas from WS-Trust > that are deliberately dropped from OAuth-2.0-Token-Exchange (and will not > need to be added later). > > > 4. Do we really need to put a non-access-token (eg an id-token) in a field > named "access_token", then override that with > "issued_token_type":"urn:ietf:params:oauth:token-type:id_token"? > > 5. I'm suspect I'm far too late to the party to comment on token_type vs > {subject|requested|actor|issued}_token_type, but surely we can do better > than create the confusion in this spec. I think the issue is that we want > to support tokens from other parties and tokens from this AS. For the > former we need to indicate the syntax (eg JWT or SAML) so the AS can parse > it; for the latter we need to indicate what the AS issued it for (eg > access_token or refresh_token) so the AS can look it up in the correct DB. > > SUGGESTION: Rename xxxx_token_type to xxxx_token_context. > > subject_token_context > REQUIRED. An identifier of either: > the syntax of the token (when issued from another AS) so the AS > knows how to parse it; > or the sort of token it is (when issued by this AS). See section 3. > > Adjust other xxxx_token_context definitions, and section 3. > > -- > James Manger > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a1146ec4e2ceea20537b295c6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--94eb2c0af9fc32df9f05389d0fe3-- From nobody Wed Jul 27 05:53:45 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AFC712E17D for ; Wed, 27 Jul 2016 05:53:42 -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 pCGe2mnVMpCE for ; Wed, 27 Jul 2016 05:53:40 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D19312D8BE for ; Wed, 27 Jul 2016 05:53:39 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id l72so15867764oig.2 for ; Wed, 27 Jul 2016 05:53:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=message-id:mime-version:to:cc:from:subject:date:importance :in-reply-to:references; bh=OTtvq7IDwJi/hbL0C2HYdJiZBVTUWQjiXVWrds9w0R0=; b=te9OnypSNbJtVWEO3ts5/RQbwAnsH/nUSUApGn9PykFF/C7rJVfZniFDksD13JXAze NhT4I9XJtu+/Oeb7e9+raz1PE8H2gZIUJC4bXu0buMUrN0QRCmOx4eqgeo/GoiyX/2+w TjwznlTjdee1V6uiyBUb1ZdQKzxcf0otV5TU+97zO1d3W1VTbi9X5UupwChjeZM6Drkn LY9eDwb4Dl0j0LG3cIHnHpMwJ8PoCw9+H6Z3QADDj3xI1RzxXwocXiZAYYgI5YXcXyzP 88BkKfQKIwgEsE19utn3GhlemX+WzhwcaWWIy+5Ewcdjf85jxNZ3EkLgspR+j0JvLSPe UtBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:mime-version:to:cc:from:subject:date :importance:in-reply-to:references; bh=OTtvq7IDwJi/hbL0C2HYdJiZBVTUWQjiXVWrds9w0R0=; b=YgZ6mge+/mA5qXcI9XpNJWKcyyAiXj7dM7OZRS0O9hBLTulZX6DU8cipTo8N1OhfHI mEzqCXdwyOF/LxYvhD5yp0cpbL+txc+tnhHwc8Iobi6rIJOtOVXCP01oGEb+MAY0nUK2 9pk1u+eQXQ+5x41HdpexIft4SIhV2fk0KamcgYl4oMYQazbFO0AEyXZYfZIkLxvPfiDo QjdOMFKFwyHrNV3kVONfDyB7bs++g9O3YDwJzip53eQLHOIxxzdVmVjnuU3/+m1uVT8u xiGfaie/ga2Pi9I4XLJDSoakbMUbkny8XMYUbrsbCS0qf7Qa2z7GzSTkbWb2jbKXWTOU MZBQ== X-Gm-Message-State: AEkooutjOZPNmXMR0OlyisasnOobbTn3eoB5EZiqhJ/qayJIWzIorjdbNhmfRMCai7CSyyZO X-Received: by 10.157.42.163 with SMTP id e32mr17377026otb.52.1469624018330; Wed, 27 Jul 2016 05:53:38 -0700 (PDT) Received: from ?IPv6:::ffff:10.2.2.249? (PING-IDENTI.bar1.Boston1.Level3.net. [4.16.11.118]) by smtp.gmail.com with ESMTPSA id o36sm2363447oik.21.2016.07.27.05.52.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Jul 2016 05:53:37 -0700 (PDT) Message-ID: <5798aed1.a468ca0a.6b8d4.a6c4@mx.google.com> MIME-Version: 1.0 To: nov matake , "torsten@lodderstedt.net" From: Date: Wed, 27 Jul 2016 08:52:58 -0400 Importance: normal X-Priority: 3 In-Reply-To: References: <57980887.1724c80a.e1de7.c7a7@mx.google.com> <57980a47.e928c80a.c54fd.c891@mx.google.com> Content-Type: multipart/alternative; boundary="_E8175F80-9868-4601-B3FC-167A2DC7356F_" Archived-At: Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] URGENT: WPAD attack exposes URL contents evenoverHTTPS X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2016 12:53:42 -0000 --_E8175F80-9868-4601-B3FC-167A2DC7356F_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" With the mix up attack we assumed that the attacker is able to modify the r= equest. In that case checking nonce in the code flow is not sufficient as= the attacker can modify nonce.=20 In this attack the attacker as I understand it can only view request and re= sponse, so checking nonce in code will prevent the paste of the code. Unf= ortunately (Torsten) checking nonce in the code flow is optional. What I don=E2=80=99t know is if there is a variation of the attack where t= he client uses the attackers proxy and the attacker can modify the request. One other mitigation is to use the Connect post response mode. That would = stop the code leak as long as the client is not going through the proxy.=20 Post response mode to stop referrer leaking etc is looking like a good idea= in general. PKCE S256 still seems like the best idea. However if a browser is using a = malicious proxy that could also probably be circumvented. Basically in that situation the attacker has access to cookies etc so OAuth= may not be the largest problem. John B. Sent from Mail for Windows 10 From: nov matake= --_E8175F80-9868-4601-B3FC-167A2DC7356F_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

With the mix up attack we assumed th= at the attacker is able to modify the request.=C2=A0=C2=A0 In that case che= cking nonce in the code flow is not sufficient as the attacker can modify n= once.

 

In= this attack the attacker as I understand it can only view request and resp= onse, so checking nonce in code will prevent the paste of the code.=C2=A0= =C2=A0 Unfortunately (Torsten) checking nonce in the code flow is optional.=

 

What I= =C2=A0 don=E2=80=99t know is if there is a variation of the attack where th= e client uses the attackers proxy and the attacker can modify the request.<= /p>

 

One other= mitigation is to use the Connect post response mode.=C2=A0 That would stop= the code leak as long as the client is not going through the proxy.

 

Post response = mode to stop referrer leaking etc is looking like a good idea in general.

 

PKCE S256 = still seems like the best idea.=C2=A0 However if a browser is using a malic= ious proxy that could also probably be circumvented.

Basically in that situation the attacker has access to cookies etc so OAu= th may not be the largest problem.

 

John B.

 =

 

Sent fro= m Mail for= Windows 10

 

= From: nov matake
Sent:= July 27, 2016 3:19 AM
To: torsten@lodderstedt.net
Cc: William Denniss; Jo= hn Bradley; oauth@ietf.org WG
= Subject: Re: [OAUTH-WG] URGENT: WPAD attack exposes URL contents eve= noverHTTPS

 

In Connect, if RP verifies nonce value in ID Token issued from Toke= n Endpoint, code cut & paste attack can be mitigated in "code"= ; flow, not in "code id_token", can't it?

<= div>

 

In pure = OAuth2 senario, I also think PKCE would be the simplest solution.

 <= /p>

2016-07-27 15:45 GMT+09:00 torsten@lodderstedt.net <torsten@lodderstedt.net>:

+1

I also think PKCE is currently the simplest way to protect OAuth client= s from injection.

Sent by MailWise =E2=80=93 See your emails as clean,= short chats.



-------- Originalnachricht --------=
Betreff: Re: [OAUTH-WG] URGENT: WPAD attack exposes URL contents even o= verHTTPS
Von: William Denniss <wdenniss@google.com>
An: John Bradley <ve7jtb@ve7jtb.com>= ;
Cc: Oauth Wrap Wg <oauth@ietf.org>

 

&nbs= p;

On Tue, Jul 26, 2016 at 6:11 PM, <= ;ve7jtb@ve7jtb.com> wrote:

PS   Using PKCE S256 w= ould prevent this attack on web server clients, as long as the client uses = a different PKCE vale for each request.    Even if the attac= ker can observe both the request and response, they would not have the code= _verifyer and if replaying the code to the client the client will use the w= rong verifier value to exchange the code and will get an error.<= /p>

 

That is probably the= simplest mitigation against this for the code flow on web servers and nati= ve apps.

 

I will thin= k about it overnight.

 

John B.

 

Sent from = Mail for Windows 10

 

<= p class=3DMsoNormal>From: ve7jtb@ve7jtb.com
Sent: July 26, 2016 9:04 PMTo: Dick = Hardt; Oauth Wrap W= g
Subject: RE: [OAUTH-WG] URGENT: WPAD attack exposes URL con= tents even overHTTPS

 

I need to think about it a bit,  however off the top= of my head based on the attack described the code flow should still be saf= e if the code is truly single use.   (Some implementations fudge = that)

 

If the attacke= r can stop the browser from delivering the code to the client then the clie= nt would be susceptible to the cut and paste attack for injecting the code = back into the client. 

 

The OpenID Connect =E2=80=9Ccode id_token=E2=80=9D flow is not vul= nerable to this if the client is properly validating the id_token.

 

I suspect that this would wo= rk against the implicit flow if the JS is sending the code back to its web = server via a GET. 

That I think we recommend = against doing, or should.

 

The Token binding proposals would stop a leaked code from being used,= but not from being stolen in this attack.

 

The attack against a confidential client would be th= e cut and paste one that we have identified.  Currently the only mitig= ation we have is =E2=80=9Ccode id_token=E2=80=9D  so the blog post at.=

http://openid.net/2= 016/07/16/preventing-mix-up-attacks-with-openid-connect/

 

I the most relevant current advice= .

The thing to add is that the code leaked in this = way should not be repayable at the client

 

I don=E2=80=99t think that native apps are vulnerabl= e to this if they are using custom scheme redirects. 

 

I don=E2=80=99t know what the risk = is if they are using loopback or claimed URI.  It may be that a browse= r might leak them in the same way.

That would need= to be tested.

 

John = B.

 

 

Sent from Mail for Windows 10

&nbs= p;

From: Dick Hardt
Sent: July = 26, 2016 8:15 PM
To: Oauth Wrap Wg
Subject: [OAUTH-WG] URGENT: WPAD attack= exposes URL contents even over HTTPS

 =

http://arstechnica.com/security/2016/07/new-attack-that-crip= ples-https-crypto-works-on-macs-windows-and-linux/

 

Access tokens included= as a URL query parameter when accessing a resource are susceptible to this= attack.

 

Authorization codes are also visible. From what I know, we hav= e not depended on the confidentiality of the authorization code. 

 

= What are the best current practices that we can point people towards to ens= ure they are not susceptible to this attack?

 

-- Dick 

<= /div>

Subscribe to the HARDTWARE mail list to learn about projects I am wo= rking on!

 

&nb= sp;

 


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



nov matake=

 

= --_E8175F80-9868-4601-B3FC-167A2DC7356F_-- From nobody Wed Jul 27 08:14:12 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2EEF12DBBC for ; Wed, 27 Jul 2016 08:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 XP7nyVYhGmW5 for ; Wed, 27 Jul 2016 08:14:09 -0700 (PDT) Received: from p3plsmtpa06-02.prod.phx3.secureserver.net (p3plsmtpa06-02.prod.phx3.secureserver.net [173.201.192.103]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8914912DB17 for ; Wed, 27 Jul 2016 08:14:09 -0700 (PDT) Received: from [192.168.1.9] ([46.10.70.150]) by p3plsmtpa06-02.prod.phx3.secureserver.net with id PrE71t00B3EY5i601rE8wi; Wed, 27 Jul 2016 08:14:09 -0700 To: oauth@ietf.org References: <578CE7F4.4080600@gmx.net> From: Vladimir Dzhuvinov Organization: Connect2id Ltd. Message-ID: <8b9dd6a2-d7fa-fe92-f6d4-83044c574167@connect2id.com> Date: Wed, 27 Jul 2016 18:14:06 +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: <578CE7F4.4080600@gmx.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060702010005060203000100" Archived-At: Subject: Re: [OAUTH-WG] Working Group Last Call on "Authentication Method Reference Values" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2016 15:14:11 -0000 This is a cryptographically signed message in MIME format. --------------ms060702010005060203000100 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 18/07/16 17:30, Hannes Tschofenig wrote: > Hi all, > > this is a Last Call for comments on the "Authentication Method Referenc= e > Values" specification. > > The document can be found here: > https://tools.ietf.org/html/draft-ietf-oauth-amr-values-01 > > Please have your comments in no later than August 1st. Thanks Hannes. Do we have an "amr" value for x.509 certificate based authentication? > Ciao > Hannes & Derek > --=20 Vladimir Dzhuvinov --------------ms060702010005060203000100 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 Fw0xNjA3MjcxNTE0MDZaMC8GCSqGSIb3DQEJBDEiBCAfeFlUynUXTWwAtRYUmLboL1ePw6wl PGM+suKi+0SnTTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQbyALwckZ9IF6bQSWzWYN4zCBwwYLKoZI hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQbyALwckZ9IF6bQSWzWYN4zANBgkqhkiG9w0BAQEFAASCAQAJBGq86pkC fyvUs2djsbplH48i2ntsg06Qx2aOb/RLLqu6SqPLbiBd+vgS/9cGXhBXm5FPN8MCcrASs7EF CbAKXnlPIgvjNUh1q8RbqzQ6UcrHksSrUwIl5TM/eABC9t2BuUA9hExKl4IvRzIQ35B6WYtZ OpcUR5i6LcWEnzApxTNmZt/H5QfOpEACsy62/Ua9YRHKOAwg70Z3PC3foomxWAY009kz6Tyi vFDrwI1phL3I7WcyVR5vNyyrjiuAOlXy3Wt7qUQo4ar+q9zd/6ynOohy1ArPta2VvAsYIo4O vOwUiWIwu5zF12Z9OdGqaqKgWKFHJxySf6KTt7BcF3WTAAAAAAAA --------------ms060702010005060203000100-- From nobody Wed Jul 27 14:49:02 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E79112D94F for ; Wed, 27 Jul 2016 14:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.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 RKkUCswMAm0D for ; Wed, 27 Jul 2016 14:49:00 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1313412D95D for ; Wed, 27 Jul 2016 14:49:00 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id m101so82849580ioi.2 for ; Wed, 27 Jul 2016 14:48:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5xZrkYXjPKrq3EI7rwrhanvqGwLucWPicymSxfBodXY=; b=ocN/ygWFEIUzqf8x66SlkdqZjwdtyOc/kDgAnq5HLVCHafN/SVdmlE7aHYHo5Scf9r UTZVsOTKQa6qUjkLIDqx29KUxopscMIf7GUBrV4i0rfvFLstsVihuRPAX7+obg+v17yY 0tSUvhLQ2BKdsHdfJUzgILgDcapRxRNysFpZU= 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=5xZrkYXjPKrq3EI7rwrhanvqGwLucWPicymSxfBodXY=; b=Y511xjOT1BiBkS6UZV/IoDJ673my3veMQSKxhQwaESBAthVQXuLeqfYgBDtT5wS7WJ VuPT+L8n5RyW5reO6AKz8ErYU6Ui8KAXEdVJnPSbhrcGM2nHst+L2fVYTMHGUSKKfJoG TZtCrQA4AGYp6vBDtI6bQetwJ0BD8TDxw0p2GcOMVziS+Ae3UqF12hXyKQKG/neOY//d wExMtHBVZCdV7aV3+AmoJbOWyQT0gXDgZgdvi2UWhyOGLQ8blA+jQDUI6DKouHfJUcKI AsQGbWZwtK4cR8rt+e0nxx1LM2i7ZiacJ6Y8zGHOe6jTbXyMnTHlGvtK+BA5TcJ68Qq7 tlWg== X-Gm-Message-State: AEkoouum7lkSd4vmJPg/U4VqEagBI93g1+Hb21qEj2HdKfP8o8mo/2k+LlE+XfvnAiQU/7MReMuLY1fFWszpJjNq X-Received: by 10.107.8.94 with SMTP id 91mr33496851ioi.86.1469656139191; Wed, 27 Jul 2016 14:48:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.28.149 with HTTP; Wed, 27 Jul 2016 14:48:29 -0700 (PDT) In-Reply-To: <0e5b8c6f-b594-fa9b-dcad-dff590e7bef5@lodderstedt.net> References: <57908256.7090107@gmx.net> <0e5b8c6f-b594-fa9b-dcad-dff590e7bef5@lodderstedt.net> From: Brian Campbell Date: Wed, 27 Jul 2016 15:48:29 -0600 Message-ID: To: Torsten Lodderstedt Content-Type: multipart/alternative; boundary=001a113f3a881e95de0538a4fc1e Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Working Group Last Call on "OAuth 2.0 for Native Apps" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2016 21:49:01 -0000 --001a113f3a881e95de0538a4fc1e Content-Type: text/plain; charset=UTF-8 I likewise believe there is a lot of value in this work and support the document moving forward. I reviewed -03 and have just a couple nits: Loopback URI Redirection in section 3 (which the author is already aware of because he mentioned it to me) doesn't fully account for how a path component of the URI would be used to allow a client to use and rely on distinct per-AS redirect URIs. Appendix A.1. iOS Implementation Details has "Clients SHOULD use Universal Links for authorization requests ... " but, in the context of what's being discussed there, shouldn't it say to use Universal Links for *redirect URIs*? Or am I confused here? On Sun, Jul 24, 2016 at 11:30 AM, Torsten Lodderstedt < torsten@lodderstedt.net> wrote: > Hi, > > generally, I considers this a highly valuable contribution and support to > move it forward. > > Some nits: > > section 7.3, last paragraph: "... as it is less susceptible > to misconfigured routing and client side firewalls Note ..." - I think > a period is missing between "firewalls" and "Note" potentially a line break > would be appropriate. > > section 8.2 - The term PKCE is used in the second paragraph but not > defined before the fourth paragraph. I suggest to define PKCE on first use. > > best regards, > Torsten. > > Am 21.07.2016 um 10:05 schrieb Hannes Tschofenig: > > Hi all, > > William has submitted an update, as promised during the OAuth WG session > on Monday. Hence, we will start a Last Call for comments on the "OAuth > 2.0 for Native Apps" specification. > > The document can be found here:https://tools.ietf.org/html/draft-ietf-oauth-native-apps-03 > > Please have your comments in no later than August 8th. > > Ciao > Hannes & Derek > > > > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a113f3a881e95de0538a4fc1e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I likewise believe there is a lot of value in this wo= rk and support the document moving forward.

I reviewed -= 03 and have just a couple nits:

Loopback U= RI Redirection in section 3 (which the author is already aware of becau= se he mentioned it to me) doesn't fully account for how a path componen= t of the URI would be used to allow a client to use and rely on distinct pe= r-AS redirect URIs.

Appendix A.1.=C2=A0 iOS Implementatio= n Details has "Clients SHOULD use Universal Links for authorizatio= n requests ... " but, in the context of what's being discussed the= re, shouldn't it say to use Universal Links for *redirect URIs*? Or am = I confused here?


On Sun, Jul 24, 2016 at 11:30 AM, Torsten Lodderstedt <= torsten@lodderstedt.net> wrote:
=20 =20 =20

Hi,

generally, I considers this a highly valuable contribution and support to move it forward.

Some nits:

section 7.3, last paragraph: "... as it is less susceptible
=C2=A0=C2=A0 to misconfigured routing and client side firewalls Note = ..." - I think a period is missing between "firewalls" and "N= ote" potentially a line break would be appropriate.

section 8.2 - The term PKCE is used in the second paragraph but not defined before the fourth paragraph. I suggest to define PKCE on first use.

best regards,
Torsten.


Am 21.07.2016 um 10:05 schrieb Hannes Tschofenig:
Hi all,

William has submitted an update, as promised during the OAuth WG session
on Monday. Hence, we will start a Last Call for comments on the "OAuth
2.0 for Native Apps"  specification.

The document can be found here:
https://tools.ietf.org/html/draft-ietf-oauth-native-apps-03<=
/a>

Please have your comments in no later than August 8th.

Ciao
Hannes & Derek





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


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


--001a113f3a881e95de0538a4fc1e-- From nobody Wed Jul 27 14:54:09 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38D1A12D966 for ; Wed, 27 Jul 2016 14:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.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 IMa9voc_U_T6 for ; Wed, 27 Jul 2016 14:54:06 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::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 D546012D1AE for ; Wed, 27 Jul 2016 14:54:05 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id u186so153764026ita.0 for ; Wed, 27 Jul 2016 14:54:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UZ5chlatvSYXgfsV8vMsPc7jqgiV91GHVUtJstGxeC8=; b=AxS5oFqjytQjfNHW8u3DnJxa4Zdsf7/WFWksMquA09loCgPEU+brR/0U3PMOsgDjmc NSu2SASlYNtw99oOaYstrtgdSxCN8oSAypo/fSqxw1evRuEmwpnHT1sVJNXOj0wE9Due loZL+gXeidm9S/2W9wb7SanNngBlDqDQYVGwQ= 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=UZ5chlatvSYXgfsV8vMsPc7jqgiV91GHVUtJstGxeC8=; b=k8Ov6PQtfCAEBY/FXaqEiGbmPWBWiUV1gWThftEPF8lUNtfJmAhuPraAC/hdczD1yC hGpRmnavAzpkVJBR/6TOd6ABW4RZIqcsA4pXzY41TXu9VHO4KKwpwjHIXoVr8bBGzD9Y cNYTtruKd58Uj59Ln6wQ2M4DJcrtwkTR4KDcKxgldOTq7JJvcu7tX+Qn6k8cqnZEq2qT ZdVeIQ7l/db7v1plNkKIipHDirtCy0cq2lOWp+qIJhItk+4ZfIMfIfwa5RM+hMwUeIHU FeJd8Ca4VURkv6yt4hgecwmPpJIgHxlR3OkODzje1AGRj4nsRxbgPB5rF09y9xc86bJd C2vQ== X-Gm-Message-State: ALyK8tKAjw+HUnVpHTZYXbqRBS6tco0klMQk43v1o/Mn+y2+ZwUnwClrTWsD9Y1sEnsfzZoYfpM7HDx1QN/Ro1eY X-Received: by 10.36.206.129 with SMTP id v123mr105440164itg.11.1469656445075; Wed, 27 Jul 2016 14:54:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.28.149 with HTTP; Wed, 27 Jul 2016 14:53:35 -0700 (PDT) In-Reply-To: References: <5795F109.9040403@gmx.net> From: Brian Campbell Date: Wed, 27 Jul 2016 15:53:35 -0600 Message-ID: To: Anthony Nadalin Content-Type: multipart/alternative; boundary=94eb2c0af9fc59dd9e0538a50e26 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Security -- Next Steps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2016 21:54:08 -0000 --94eb2c0af9fc59dd9e0538a50e26 Content-Type: text/plain; charset=UTF-8 Agree. The BCP would be larger in scope than just mix-up. And given that approach, I don't know if it makes sense to have a document specific to mix-up. On Mon, Jul 25, 2016 at 11:43 AM, Anthony Nadalin wrote: > Sounds about right, but I would imagine that the BCP would cover any issue > that arises not just mix-up > > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig > Sent: Monday, July 25, 2016 3:59 AM > To: oauth@ietf.org > Subject: [OAUTH-WG] OAuth Security -- Next Steps > > Hi all, > > We had two working group sessions at the Berlin IETF meeting and I am > happy about the progress on many of the subjects. We managed to progress > token exchange, native apps, AMR, and authorization server meta-data. We > also identified new use cases to explore with the device flow document. > > We also did a call for adoption of the OAuth token binding functionality, > which still needs to be confirmed on the mailing list. > (Further emails will follow.) > > There are, however, aspects I am not happy with. I was hoping to make some > progress on the mix-up mitigation and on the wider range of security > documents. > > Here is how I see the story after talking to some meeting participants. > > 1) It seems that the solution approach to deal with the mix-up attack > (only mix-up) described in draft-ietf-oauth-mix-up-mitigation-01 needs to > be modified to reflect the preference of the working group. My impression > (from speaking with participants at the meeting last week > privately) is that there is interest in a solution that does not require > protocol changes but rather relies on configuration. This may include a > combination of exact redirect_URI matching + per-AS redirect_URI + session > state checking. There are also other attacks described in > draft-ietf-oauth-mix-up-mitigation-01, which need to be moved elsewhere to > avoid confusion. > > 2) We need a new document, ideally a BCP, that serves as a high-level > write-up describing various security issues with OAuth that points to the > mostly existing documents for those who want to read the background > information. Torsten has posted a mail to the list providing one possible > outline of such a document. > > How does this sound? > > Ciao > Hannes > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --94eb2c0af9fc59dd9e0538a50e26 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Agree. The BCP would be larger in scope than just mix= -up. And given that approach, I don't know if it makes sense to have a = document specific to mix-up.
On Mon, Jul 25, 2016 at 11:43 AM, Anthony Nadal= in <tonynad@microsoft.com> wrote:
Sounds about right, but I would imagine that the BCP would co= ver any issue that arises not just mix-up

-----Original Message-----
From: OAuth [mailto:oauth-bounces= @ietf.org] On Behalf Of Hannes Tschofenig
Sent: Monday, July 25, 2016 3:59 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] OAuth Security -- Next Steps

Hi all,

We had two working group sessions at the Berlin IETF meeting and I am happy= about the progress on many of the subjects. We managed to progress token e= xchange, native apps, AMR, and authorization server meta-data. We also iden= tified new use cases to explore with the device flow document.

We also did a call for adoption of the OAuth token binding functionality, w= hich still needs to be confirmed on the mailing list.
(Further emails will follow.)

There are, however, aspects I am not happy with. I was hoping to make some = progress on the mix-up mitigation and on the wider range of security docume= nts.

Here is how I see the story after talking to some meeting participants.

1) It seems that the solution approach to deal with the mix-up attack (only= mix-up) described in draft-ietf-oauth-mix-up-mitigation-01 needs to be mod= ified to reflect the preference of the working group. My impression (from s= peaking with participants at the meeting last week
privately) is that there is interest in a solution that does not require pr= otocol changes but rather relies on configuration. This may include a combi= nation of exact redirect_URI matching + per-AS redirect_URI + session state= checking. There are also other attacks described in draft-ietf-oauth-mix-u= p-mitigation-01, which need to be moved elsewhere to avoid confusion.

2) We need a new document, ideally a BCP, that serves as a high-level write= -up describing various security issues with OAuth that points to the mostly= existing documents for those who want to read the background information. = Torsten has posted a mail to the list providing one possible outline of suc= h a document.

How does this sound?

Ciao
Hannes

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

--94eb2c0af9fc59dd9e0538a50e26-- From nobody Thu Jul 28 00:56:10 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9702D12D60D for ; Thu, 28 Jul 2016 00:56:08 -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 1qUht6iI3UTP for ; Thu, 28 Jul 2016 00:56:07 -0700 (PDT) Received: from p3plsmtpa08-01.prod.phx3.secureserver.net (p3plsmtpa08-01.prod.phx3.secureserver.net [173.201.193.102]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB9A6128E18 for ; Thu, 28 Jul 2016 00:56:06 -0700 (PDT) Received: from [192.168.1.9] ([46.10.70.150]) by p3plsmtpa08-01.prod.phx3.secureserver.net with id Q7w41t0033EY5i6017w5pv; Thu, 28 Jul 2016 00:56:06 -0700 To: oauth@ietf.org References: <5795F109.9040403@gmx.net> From: Vladimir Dzhuvinov Organization: Connect2id Ltd. Message-ID: Date: Thu, 28 Jul 2016 10:56:03 +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: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050102080502090902060205" Archived-At: Subject: Re: [OAUTH-WG] OAuth Security -- Next Steps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 07:56:08 -0000 This is a cryptographically signed message in MIME format. --------------ms050102080502090902060205 Content-Type: multipart/alternative; boundary="------------DBF56E57DF6FBA83109CA085" This is a multi-part message in MIME format. --------------DBF56E57DF6FBA83109CA085 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I congratulate the idea for a BCP. Ideally that would be a document written with the developer in mind, easy to consume, and outlining all necessary steps to take in order to harden / patch up an OAuth 2.0 implementation / app. The individual attacks could be referenced or described in an appendix. Working from documents that describe an individual attack, or a class of attacks, where a matching countermeasure is suggested, is harder for developers (the typical format of security research papers). In conversations with developers I found out that many of them have indeed read about the recently discovered problems, but don't have a good picture of the overall situation, and how to react. Therefore, putting together a clear course for action, sanctioned by the OAuth WG, would be really useful. I also imagine the BCP could suggest two variants for action: 1. For those people who have existing apps in the field, and mostly 3rd party client developers. They will probably be looking for the minimum amount of measures to secure their OAuth 2.0 stuff, to minimise disruption and all sorts of hassle related to updating APIs, clients, libraries, etc. 2. For people who want to have additional protections to OAuth 2.0 in place, e.g. JWT assertions for client auth, bound tokens, etc. Typically companies that are in control of their clients and apps, or those that consider introducing OAuth 2.0 for the first time. Thanks, Vladimir On 28/07/16 00:53, Brian Campbell wrote: > Agree. The BCP would be larger in scope than just mix-up. And given tha= t > approach, I don't know if it makes sense to have a document specific to= > mix-up. > > On Mon, Jul 25, 2016 at 11:43 AM, Anthony Nadalin > wrote: > >> Sounds about right, but I would imagine that the BCP would cover any i= ssue >> that arises not just mix-up >> >> -----Original Message----- >> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschof= enig >> Sent: Monday, July 25, 2016 3:59 AM >> To: oauth@ietf.org >> Subject: [OAUTH-WG] OAuth Security -- Next Steps >> >> Hi all, >> >> We had two working group sessions at the Berlin IETF meeting and I am >> happy about the progress on many of the subjects. We managed to progre= ss >> token exchange, native apps, AMR, and authorization server meta-data. = We >> also identified new use cases to explore with the device flow document= =2E >> >> We also did a call for adoption of the OAuth token binding functionali= ty, >> which still needs to be confirmed on the mailing list. >> (Further emails will follow.) >> >> There are, however, aspects I am not happy with. I was hoping to make = some >> progress on the mix-up mitigation and on the wider range of security >> documents. >> >> Here is how I see the story after talking to some meeting participants= =2E >> >> 1) It seems that the solution approach to deal with the mix-up attack >> (only mix-up) described in draft-ietf-oauth-mix-up-mitigation-01 needs= to >> be modified to reflect the preference of the working group. My impress= ion >> (from speaking with participants at the meeting last week >> privately) is that there is interest in a solution that does not requi= re >> protocol changes but rather relies on configuration. This may include = a >> combination of exact redirect_URI matching + per-AS redirect_URI + ses= sion >> state checking. There are also other attacks described in >> draft-ietf-oauth-mix-up-mitigation-01, which need to be moved elsewher= e to >> avoid confusion. >> >> 2) We need a new document, ideally a BCP, that serves as a high-level >> write-up describing various security issues with OAuth that points to = the >> mostly existing documents for those who want to read the background >> information. Torsten has posted a mail to the list providing one possi= ble >> outline of such a document. >> >> How does this sound? >> >> Ciao >> Hannes >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --=20 --------------DBF56E57DF6FBA83109CA085 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

I congratulate the idea for a BCP.

Ideally that would be a document written with the developer in mind, easy to consume, and outlining all necessary steps to take in order to harden / patch up an OAuth 2.0 implementation / app. The individual attacks could be referenced or described in an appendix.

Working from documents that describe an individual attack, or a class of attacks, where a matching countermeasure is suggested, is harder for developers (the typical format of security research papers). In conversations with developers I found out that many of them have indeed read about the recently discovered problems, but don't have a good picture of the overall situation, and how to react. Therefore, putting together a clear course for action, sanctioned by the OAuth WG, would be really useful.

I also imagine the BCP could suggest two variants for action:


1. For those people who have existing apps in the field, and mostly 3rd party client developers. They will probably be looking for the minimum amount of measures to secure their OAuth 2.0 stuff, to minimise disruption and all sorts of hassle related to updating APIs, clients, libraries, etc.


2. For people who want to have additional protections to OAuth 2.0 in place, e.g. JWT assertions for client auth, bound tokens, etc. Typically companies that are in control of their clients and apps, or those that consider introducing OAuth 2.0 for the first time.


Thanks,

Vladimir



On 28/07/16 00:53, Brian Campbell wrote:
Agree. The BCP would be larger in scope than just mi=
x-up. And given that
approach, I don't know if it makes sense to have a document specific to
mix-up.

On Mon, Jul 25, 2016 at 11:43 AM, Anthony Nadalin <tonynad@microsoft.c=
om>
wrote:


Sounds about right, but I would imagine that the B=
CP would cover any issue
that arises not just mix-up

-----Original Message-----
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tsch=
ofenig
Sent: Monday, July 25, 2016 3:59 AM
To: =
oauth@ietf.org
Subject: [OAUTH-WG] OAuth Security -- Next Steps

Hi all,

We had two working group sessions at the Berlin IETF meeting and I am
happy about the progress on many of the subjects. We managed to progress
token exchange, native apps, AMR, and authorization server meta-data. We
also identified new use cases to explore with the device flow document.

We also did a call for adoption of the OAuth token binding functionality,=

which still needs to be confirmed on the mailing list.
(Further emails will follow.)

There are, however, aspects I am not happy with. I was hoping to make som=
e
progress on the mix-up mitigation and on the wider range of security
documents.

Here is how I see the story after talking to some meeting participants.

1) It seems that the solution approach to deal with the mix-up attack
(only mix-up) described in draft-ietf-oauth-mix-up-mitigation-01 needs to=

be modified to reflect the preference of the working group. My impression=

(from speaking with participants at the meeting last week
privately) is that there is interest in a solution that does not require
protocol changes but rather relies on configuration. This may include a
combination of exact redirect_URI matching + per-AS redirect_URI + sessio=
n
state checking. There are also other attacks described in
draft-ietf-oauth-mix-up-mitigation-01, which need to be moved elsewhere t=
o
avoid confusion.

2) We need a new document, ideally a BCP, that serves as a high-level
write-up describing various security issues with OAuth that points to the=

mostly existing documents for those who want to read the background
information. Torsten has posted a mail to the list providing one possible=

outline of such a document.

How does this sound?

Ciao
Hannes

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



      

      

      

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


    

    

    
-- 

  


--------------DBF56E57DF6FBA83109CA085--

--------------ms050102080502090902060205
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
Fw0xNjA3MjgwNzU2MDNaMC8GCSqGSIb3DQEJBDEiBCBFxLJz9g46/7Lv/yd61Wt/08Bev8Wj
lMVAnwiTZBOsSDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw
CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD
VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP
TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQbyALwckZ9IF6bQSWzWYN4zCBwwYLKoZI
hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw
PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy
ZSBFbWFpbCBDQQIQbyALwckZ9IF6bQSWzWYN4zANBgkqhkiG9w0BAQEFAASCAQATjXGhhMtf
i8uP+jJdpBno2QM6n8Xy7FpyphiB3R3a/tyYShEOFbxqAd8iH2pYmj8ATFICGFRCMVU0VMzx
B43tWZgdtjN8ccjRXSfsxWeQt638WusBnWgiv65/aUOlpIt/L1QvqNmM1r05Y6mMnJoYXymM
Dh8XWHphPCoiwwjqyd1bF0g0RjLL5dyX24412QwMLeCoeNhhKyZb88ZcWEDQYr5O232+AlDr
sD+/hcQzgirmUNpDDtLhxTN438Sm2p7Hq907MPqUND3SMhM5uH7lyJKpkHGu3nMmmjfPHTmr
qOA+q+8mA6k6R7Ugx1k8+MKFqLJbf4QIBzAKgvPbftIPAAAAAAAA
--------------ms050102080502090902060205--


From nobody Thu Jul 28 13:23:57 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 587E312D0F0 for ; Thu, 28 Jul 2016 13:23:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.487
X-Spam-Level: 
X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, 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 7Ui3tnTYqQ-n for ; Thu, 28 Jul 2016 13:23:53 -0700 (PDT)
Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73BC312E0AD for ; Thu, 28 Jul 2016 13:23:53 -0700 (PDT)
X-AuditID: 1209190f-e0bff700000043b5-51-579a69d741b6
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 E1.46.17333.7D96A975; Thu, 28 Jul 2016 16:23:52 -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 u6SKNoHp021330; Thu, 28 Jul 2016 16:23:51 -0400
Received: from [10.36.16.144] ([38.90.135.101]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u6SKNm5E028151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 28 Jul 2016 16:23:50 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_1D82FEE9-ACB9-4F15-8FD4-8414F7435BD4"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Justin Richer 
In-Reply-To: 
Date: Thu, 28 Jul 2016 16:23:48 -0400
Message-Id: <92B0F263-A9E8-4F3A-B61F-23549DD1AAD8@mit.edu>
References:  <57980887.1724c80a.e1de7.c7a7@mx.google.com> <57980a47.e928c80a.c54fd.c891@mx.google.com>    
To: Brian Campbell 
X-Mailer: Apple Mail (2.3124)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEKsWRmVeSWpSXmKPExsUixCmqrXsjc1a4wY65zBar/99ktHiz8iOb xcm3r9gcmD12zrrL7rFkyU8mj7tHL7IEMEdx2aSk5mSWpRbp2yVwZazpXMxSsOEaY8W7XY/Z GhhP7WTsYuTkkBAwkbh6+StLFyMXh5BAG5PEzueTGSGcjYwS16etgXLWMEm8mruJCaSFWSBB YvLmPjYQm1dAT2LT+rdgcWEBf4mFFw6yg9hsAqoS09e0gMU5BQIl2qbfB4uzAMX3XVjLCDHH TeJw131WiDlWEjNmnGSCWLaFWWL960tgRSIC+hK3n85hh7hVVuLJyUUsExj5ZyG5YxaSOyDi 2hLLFr5mhrA1JfZ3L2fBFNeQ6Pw2kXUBI9sqRtmU3Crd3MTMnOLUZN3i5MS8vNQiXRO93MwS vdSU0k2M4KCX5N/BOKfB+xCjAAejEg/vDOlZ4UKsiWXFlbmHGCU5mJREecNCZ4YL8SXlp1Rm JBZnxBeV5qQWH2KU4GBWEuH9kQBUzpuSWFmVWpQPk5LmYFES593+rT1cSCA9sSQ1OzW1ILUI JivDwaEkwfspA6hRsCg1PbUiLTOnBCHNxMEJMpwHaPhLkBre4oLE3OLMdIj8KUZFKXHeeJCE AEgiozQPrheUlNSi2lNfMYoDvSLMuw+kigeY0OC6XwENZgIaXBw7A2RwSSJCSqqBccupKsXD dz20Jx371TVtj8/1JN2XLa/nf7kqGrEg4UW6z+M3zCnn1P82hDlyXjuj99Wy2JUp/s/RFc4X cpNO699d4LIvrUumW1b6WfNfoM8fHXukXfyofy/nu+vKut+d1fWtY5awXvE733ryZ1xV064r CSUtH50OuFwsn/R7EpvpxM4tfWmMSizFGYmGWsxFxYkARR0WFCUDAAA=
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] URGENT: WPAD attack exposes URL contents even overHTTPS
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jul 2016 20:23:55 -0000

--Apple-Mail=_1D82FEE9-ACB9-4F15-8FD4-8414F7435BD4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I=E2=80=99ve been thinking that we could, in some eventual rewrite of =
OAuth and its kin, collapse the =E2=80=9Cstate=E2=80=9D, =E2=80=9Cnonce=E2=
=80=9D, and =E2=80=9Ccode_challenge=E2=80=9D values all into a single =
thing. They=E2=80=99re all serving similar purposes but being used =
differently. There was even talk of replaying the =E2=80=9Cstate=E2=80=9D =
value at the token endpoint, just like we do with PKCE =E2=80=9Cplain=E2=80=
=9D. So why not just use them all together? Like so:


Client creates a value, we=E2=80=99ll call it the =E2=80=9Crequest_tag=E2=80=
=9D because I want something that doesn=E2=80=99t sound like any of the =
existing values on its own and I don=E2=80=99t care what it=E2=80=99s =
actually called in the long run. Client stores this for later use.

Client sends a request to the AS front channel and hashes the =
request_tag in that request, let=E2=80=99s call this =E2=80=9Crequest_hash=
=E2=80=9D. Client also sends a kind of =E2=80=9Crequest_hash_method=E2=80=9D=
 to tell the AS how it hashed things. [This functions just like the =
code_challenge_method today.]

AS returns to the client front channel and includes the request_hash. =
[This functions just like state today.] The client can verify this hash =
using its stored tag.

	- If AS is doing implicit OIDC, it adds the request_hash to the =
ID Token here. [This functions just like nonce today.] The client can =
verify this hash using its stored tag.

If the client is doing code flow, it now talks to the token endpoint and =
includes the request_tag in its request. [This functions just like =
code_verifier and the proposed include-the-state-in-token-request =
mitigation.] The AS can verify this tag against its stored hash.

	- If the AS is doing code OIDC, it adds the request_hash to the =
ID token value here. [This functions just like nonce today.] The client =
can verify this hash using its stored tag.

The token response can include the request_hash in its response JSON, =
because why not.


Yes I realize this requires redoing a lot of plumbing, but if we get to =
this point with the protocol I think this would be simpler than the =
functional patchwork we=E2=80=99ve got going right now.

 =E2=80=94 Justin


> On Jul 27, 2016, at 8:21 AM, Brian Campbell =
 wrote:
>=20
> Yeah, in a Connect "code" only flow, the nonce is optional but if the =
client/RP sends and checks it, that should mitigate this.=20
>=20
> On Wed, Jul 27, 2016 at 1:19 AM, nov matake > wrote:
> In Connect, if RP verifies nonce value in ID Token issued from Token =
Endpoint, code cut & paste attack can be mitigated in "code" flow, not =
in "code id_token", can't it?
>=20
> In pure OAuth2 senario, I also think PKCE would be the simplest =
solution.
>=20
> 2016-07-27 15:45 GMT+09:00 torsten@lodderstedt.net =
 >:
> +1
>=20
> I also think PKCE is currently the simplest way to protect OAuth =
clients from injection.
>=20
> Sent by MailWise  =E2=80=93 =
See your emails as clean, short chats.
>=20
>=20
>=20
> -------- Originalnachricht --------
> Betreff: Re: [OAUTH-WG] URGENT: WPAD attack exposes URL contents even	=
overHTTPS
> Von: William Denniss >
> An: John Bradley >
> Cc: Oauth Wrap Wg >
>=20
>=20
> PKCE S256 was indeed designed to protect against eavesdropping of both =
the authorization request & response.  It was originally created for =
native apps where URL leakage was deemed more likely (since it goes over =
inter-process communication channels), perhaps the practice should be =
expanded to all clients.
>=20
> On Tue, Jul 26, 2016 at 6:11 PM, > wrote:
> PS   Using PKCE S256 would prevent this attack on web server clients, =
as long as the client uses a different PKCE vale for each request.    =
Even if the attacker can observe both the request and response, they =
would not have the code_verifyer and if replaying the code to the client =
the client will use the wrong verifier value to exchange the code and =
will get an error.
>=20
> =20
>=20
> That is probably the simplest mitigation against this for the code =
flow on web servers and native apps.
>=20
> =20
>=20
> I will think about it overnight.
>=20
> =20
>=20
> John B.
>=20
> =20
>=20
> Sent from Mail  for =
Windows 10
>=20
> =20
>=20
> From: ve7jtb@ve7jtb.com 
> Sent: July 26, 2016 9:04 PM
> To: Dick Hardt ; Oauth Wrap Wg =

> Subject: RE: [OAUTH-WG] URGENT: WPAD attack exposes URL contents even =
overHTTPS
>=20
> =20
>=20
> I need to think about it a bit,  however off the top of my head based =
on the attack described the code flow should still be safe if the code =
is truly single use.   (Some implementations fudge that)
>=20
> =20
>=20
> If the attacker can stop the browser from delivering the code to the =
client then the client would be susceptible to the cut and paste attack =
for injecting the code back into the client.=20
>=20
> =20
>=20
> The OpenID Connect =E2=80=9Ccode id_token=E2=80=9D flow is not =
vulnerable to this if the client is properly validating the id_token.
>=20
> =20
>=20
> I suspect that this would work against the implicit flow if the JS is =
sending the code back to its web server via a GET.=20
>=20
> That I think we recommend against doing, or should.
>=20
> =20
>=20
> The Token binding proposals would stop a leaked code from being used, =
but not from being stolen in this attack.
>=20
> =20
>=20
> The attack against a confidential client would be the cut and paste =
one that we have identified.  Currently the only mitigation we have is =
=E2=80=9Ccode id_token=E2=80=9D  so the blog post at.
>=20
> =
http://openid.net/2016/07/16/preventing-mix-up-attacks-with-openid-connect=
/ =

> =20
>=20
> I the most relevant current advice.
>=20
> The thing to add is that the code leaked in this way should not be =
repayable at the client
>=20
> =20
>=20
> I don=E2=80=99t think that native apps are vulnerable to this if they =
are using custom scheme redirects.=20
>=20
> =20
>=20
> I don=E2=80=99t know what the risk is if they are using loopback or =
claimed URI.  It may be that a browser might leak them in the same way.
>=20
> That would need to be tested.
>=20
> =20
>=20
> John B.
>=20
> =20
>=20
> =20
>=20
> Sent from Mail  for =
Windows 10
>=20
> =20
>=20
> From: Dick Hardt 
> Sent: July 26, 2016 8:15 PM
> To: Oauth Wrap Wg 
> Subject: [OAUTH-WG] URGENT: WPAD attack exposes URL contents even over =
HTTPS
>=20
> =20
>=20
> =
http://arstechnica.com/security/2016/07/new-attack-that-cripples-https-cry=
pto-works-on-macs-windows-and-linux/ =

> =20
>=20
> Access tokens included as a URL query parameter when accessing a =
resource are susceptible to this attack.
>=20
> =20
>=20
> Authorization codes are also visible. =46rom what I know, we have not =
depended on the confidentiality of the authorization code.=20
>=20
> =20
>=20
> What are the best current practices that we can point people towards =
to ensure they are not susceptible to this attack?
>=20
> =20
>=20
> -- Dick=20
>=20
> Subscribe to the HARDTWARE  mail list to learn =
about projects I am working on!
>=20
> =20
>=20
> =20
>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth =

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

>=20
>=20
>=20
>=20
> --=20
> nov matake
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth =

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


--Apple-Mail=_1D82FEE9-ACB9-4F15-8FD4-8414F7435BD4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

I=E2=80=99ve been thinking that we could, in some eventual =
rewrite of OAuth and its kin, collapse the =E2=80=9Cstate=E2=80=9D, =
=E2=80=9Cnonce=E2=80=9D, and =E2=80=9Ccode_challenge=E2=80=9D values all =
into a single thing. They=E2=80=99re all serving similar purposes but =
being used differently. There was even talk of replaying the =E2=80=9Cstat=
e=E2=80=9D value at the token endpoint, just like we do with PKCE =
=E2=80=9Cplain=E2=80=9D. So why not just use them all together? Like =
so:


Client creates a value, we=E2=80=99ll =
call it the =E2=80=9Crequest_tag=E2=80=9D because I want something that =
doesn=E2=80=99t sound like any of the existing values on its own and I =
don=E2=80=99t care what it=E2=80=99s actually called in the long run. =
Client stores this for later use.

Client sends a request to the AS front =
channel and hashes the request_tag in that request, let=E2=80=99s call =
this =E2=80=9Crequest_hash=E2=80=9D. Client also sends a kind of =
=E2=80=9Crequest_hash_method=E2=80=9D to tell the AS how it hashed =
things. [This functions just like the code_challenge_method =
today.]

AS =
returns to the client front channel and includes the request_hash. [This =
functions just like state today.] The client can verify this hash using =
its stored tag.

	=
- If AS is doing implicit OIDC, it adds the request_hash to =
the ID Token here. [This functions just like nonce today.] The client =
can verify this hash using its stored tag.

If the client is doing code flow, it =
now talks to the token endpoint and includes the request_tag in its =
request. [This functions just like code_verifier and the proposed =
include-the-state-in-token-request mitigation.] The AS can verify this =
tag against its stored hash.

	- If the AS is doing code =
OIDC, it adds the request_hash to the ID token value here. [This =
functions just like nonce today.] The client can verify this hash using =
its stored tag.

The token response can include the request_hash in its =
response JSON, because why not.


Yes =
I realize this requires redoing a lot of plumbing, but if we get to this =
point with the protocol I think this would be simpler than the =
functional patchwork we=E2=80=99ve got going right now.

 =E2=80=94 =
Justin


On Jul 27, 2016, at 8:21 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:

Yeah, in a Connect "code" only =
flow, the nonce is optional but if the client/RP sends and checks it, =
that should mitigate this. 

On Wed, =
Jul 27, 2016 at 1:19 AM, nov matake <matake@gmail.com> wrote:
In Connect, if RP =
verifies nonce value in ID Token issued from Token Endpoint, code cut =
& paste attack can be mitigated in "code" flow, not in "code =
id_token", can't it?

In pure OAuth2 senario, I also think PKCE would be the =
simplest solution.

2016-07-27 15:45 GMT+09:00 torsten@lodderstedt.net <torsten@lodderstedt.net>:
+1
I also think PKCE is =
currently the simplest way to protect OAuth clients from =
injection.
Sent by MailWise =E2=80=93 See your emails as clean, short =
chats.



-------- Originalnachricht --------
Betreff: Re: [OAUTH-WG] URGENT: WPAD attack exposes URL =
contents even	overHTTPS
Von: William Denniss <wdenniss@google.com>
An: John Bradley =
<ve7jtb@ve7jtb.com>
Cc: Oauth Wrap Wg =
<oauth@ietf.org>


PKCE S256 was =
indeed designed to protect against eavesdropping of both the =
authorization request & response.  It was originally created =
for native apps where URL leakage was deemed more likely (since it goes =
over inter-process communication channels), perhaps the practice should =
be expanded to all clients.

On Tue, Jul 26, 2016 at 6:11 PM,  =
<ve7jtb@ve7jtb.com> wrote:
PS   Using PKCE S256 would prevent this =
attack on web server clients, as long as the client uses a different =
PKCE vale for each request.    Even if the attacker can =
observe both the request and response, they would not have the =
code_verifyer and if replaying the code to the client the client will =
use the wrong verifier value to exchange the code and will get an =
error.
 
That is probably the simplest =
mitigation against this for the code flow on web servers and native =
apps.
 
I will think about it =
overnight.
 
John =
B.
 
Sent =
from Mail for Windows 10
 
From: ve7jtb@ve7jtb.com
Sent: =
July 26, 2016 9:04 PM
To: Dick =
Hardt; Oauth Wrap Wg
Subject: =
RE: [OAUTH-WG] URGENT: WPAD attack exposes URL contents even =
overHTTPS
 
I need to think about it a bit,  however off =
the top of my head based on the attack described the code flow should =
still be safe if the code is truly single use.   (Some =
implementations fudge that)
 
If the =
attacker can stop the browser from delivering the code to the client =
then the client would be susceptible to the cut and paste attack for =
injecting the code back into the client.  
 
The OpenID Connect =E2=80=9Ccode id_token=E2=80=9D =
flow is not vulnerable to this if the client is properly validating the =
id_token.
 
I suspect that this would work =
against the implicit flow if the JS is sending the code back to its web =
server via a GET.  
That I think we =
recommend against doing, or should.
 
The =
Token binding proposals would stop a leaked code from being used, but =
not from being stolen in this attack.
 
The =
attack against a confidential client would be the cut and paste one that =
we have identified.  Currently the only mitigation we have is =
=E2=80=9Ccode id_token=E2=80=9D  so the blog post at.
http://openid.net/2016/07/16/preventing-mix-up-attacks-with-ope=
nid-connect/
 
I the most relevant current =
advice.
The thing to add is that the code =
leaked in this way should not be repayable at the client 
 
I don=E2=80=99t think that native apps are =
vulnerable to this if they are using custom scheme redirects.  =

 
I don=E2=80=99t know what the =
risk is if they are using loopback or claimed URI.  It may be that =
a browser might leak them in the same way. 
That=
 would need to be tested.
 
John =
B.
 
 
Sent from Mail for Windows 10
 
From: Dick =
Hardt
Sent: July 26, 2016 8:15 PM
To: Oauth Wrap Wg
Subject: [OAUTH-WG] URGENT: WPAD attack exposes URL =
contents even over HTTPS
 
http://arstechnica.com/security/2016/07/new-attack-that-cripple=
s-https-crypto-works-on-macs-windows-and-linux/
 
Access tokens included as a URL query parameter when =
accessing a resource are susceptible to this attack.
 
Authorization codes are also visible. =46rom what I know, we =
have not depended on the confidentiality of the authorization =
code. 
 
What are the best current practices that we can point people =
towards to ensure they are not susceptible to this attack?
 
-- Dick 
Subscribe to the HARDTWARE mail list to learn about =
projects I am working on!
 
 

_______________________________________________

OAuth mailing list

OAuth@ietf.org

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






_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





-- 
nov matake




_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




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

=

--Apple-Mail=_1D82FEE9-ACB9-4F15-8FD4-8414F7435BD4--


From nobody Thu Jul 28 13:25:46 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AABD312D579 for ; Thu, 28 Jul 2016 13:25:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.508
X-Spam-Level: 
X-Spam-Status: No, score=-5.508 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.287, 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 qxN45jFmTsq2 for ; Thu, 28 Jul 2016 13:25:42 -0700 (PDT)
Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 6573212E0C2 for ; Thu, 28 Jul 2016 13:25:41 -0700 (PDT)
X-AuditID: 1209190e-3b3ff70000003feb-0f-579a6a43491d
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 5B.79.16363.34A6A975; Thu, 28 Jul 2016 16:25:40 -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 u6SKPdCf016994; Thu, 28 Jul 2016 16:25:39 -0400
Received: from [10.36.16.144] ([38.90.135.101]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u6SKPZXU028722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 28 Jul 2016 16:25:37 -0400
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Justin Richer 
In-Reply-To: 
Date: Thu, 28 Jul 2016 16:25:35 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20160726204839.0874EB81C1A@rfc-editor.org> 
To: Jim Manico 
X-Mailer: Apple Mail (2.3124)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGIsWRmVeSWpSXmKPExsUixG6nruuSNSvcoP2PgMXKSTvYLV7sP8hu cfLtKzYHZo8lS34yeSz/+oDFo3HGA8YA5igum5TUnMyy1CJ9uwSujHNrGlkKLilUfFi8h7mB cYtUFyMnh4SAiUTjvBcsXYxcHEICbUwSe64dZgVJCAlsZJTYucEYIrGGSeLTry/sIAlmAXWJ P/MuMYPYvAJ6EpvWv2UCsYUFnCQ6tj4As9kEVCWmr2kBszkFHCSm9v0Hs1mA4sc+nWeFmOMu cWvGJSYIW1ti2cLXUDOtJG6f/QR1RLbE+S+/GUFsEQFFiQN7mpggrpaVeHJyEcsERoFZSE6a heSkWUjGLmBkXsUom5JbpZubmJlTnJqsW5ycmJeXWqRrrJebWaKXmlK6iREUvJySfDsYJzV4 H2IU4GBU4uGdIT0rXIg1say4MvcQoyQHk5Iob1jozHAhvqT8lMqMxOKM+KLSnNTiQ4wSHMxK Irw/EoDKeVMSK6tSi/JhUtIcLErivNu/tYcLCaQnlqRmp6YWpBbBZGU4OJQkeHMzgRoFi1LT UyvSMnNKENJMHJwgw3mAhr/MABleXJCYW5yZDpE/xagoJc4bD5IQAElklObB9YKSi1pUe+or RnGgV4R514Os4AEmJrjuV0CDmYAGF8fOABlckoiQkmpg7OJX8zdqLc29qPHw7LIUVz39fesa ePfyxf69Vrq4OXIq/0+7WcqPE5UXmqSu+VyYde3IFL+wHod29lTbNQ/LE/+w6z8sLfe+OXvy et6/B3eFfehy+bQgsN70R3+5XKj1jx+CD1bYWjcbl+7kbvzY7lqlxnCl4oxY0i5RvnmT71eL SuYvN7irxFKckWioxVxUnAgAhBIyDQkDAAA=
Archived-At: 
Cc: Derek Atkins , "" 
Subject: Re: [OAUTH-WG] [Technical Errata Reported] RFC6749 (4749)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jul 2016 20:25:44 -0000

These are client secrets, not user passwords, so they=E2=80=99re =
supposed to be high entropy and not human-memorable (or human-typable =
really). Also, this needs to be used over TLS. The connection requires =
TLS anyway because the tokens returned (or the token keys in the OAuth =
PoP case) also need to be protected, regardless of how you hash the =
client=E2=80=99s secret. With that in mind, Digest doesn=E2=80=99t buy =
you much.

 =E2=80=94 Justin

> On Jul 26, 2016, at 8:08 PM, Jim Manico  wrote:
>=20
> Please forgive me if this comment is out of order or inappropriate in =
any way...
>=20
> ...but why is HTTP Basic even being discussed in 2016? It has horrific =
security properties at multiple levels; shouldn't we at least move to =
HTTP Digest if not something stronger?
>=20
> Regards.
> --
> Jim Manico
> @Manicode
>=20
>> On Jul 26, 2016, at 4:48 PM, RFC Errata System =
 wrote:
>>=20
>> The following errata report has been submitted for RFC6749,
>> "The OAuth 2.0 Authorization Framework".
>>=20
>> --------------------------------------
>> You may review the report below and at:
>> http://www.rfc-editor.org/errata_search.php?rfc=3D6749&eid=3D4749
>>=20
>> --------------------------------------
>> Type: Technical
>> Reported by: Phil Hunt 
>>=20
>> Section: 2.3.1
>>=20
>> Original Text
>> -------------
>> Clients in possession of a client password MAY use the HTTP Basic
>> authentication scheme as defined in [RFC2617] to authenticate with
>> the authorization server.  The client identifier is encoded using the
>> "application/x-www-form-urlencoded" encoding algorithm per
>> Appendix B, and the encoded value is used as the username; the client
>> password is encoded using the same algorithm and used as the
>> password.  The authorization server MUST support the HTTP Basic
>> authentication scheme for authenticating clients that were issued a
>> client password.
>>=20
>> Corrected Text
>> --------------
>> Clients in possession of a client password MAY use the HTTP Basic
>> authentication scheme as defined in [RFC2617] to authenticate with
>> the authorization server.  The client identifier is encoded using the
>> "application/x-www-form-urlencoded" encoding algorithm per
>> Appendix B, and the encoded value is used as the username; the client
>> password is encoded using the same algorithm and used as the
>> password. The url encoded values are then encoded as defined in
>> [RFC2617]. The authorization server MUST support the HTTP Basic
>> authentication scheme for authenticating clients that were issued a
>> client password.
>>=20
>> Notes
>> -----
>> It was not clear to some implementers that the intention is a 2-step =
encoding. First for special characters and second the 2617 base 64 =
encoding.  Implementers thought 6749 was in conflict with 2617.
>>=20
>> To avoid inter-op issues, a new clarifying sentence is proposed.
>> "The url encoded values are then encoded as defined in [RFC2617]."
>>=20
>> Instructions:
>> -------------
>> This erratum is currently posted as "Reported". If necessary, please
>> use "Reply All" to discuss whether it should be verified or
>> rejected. When a decision is reached, the verifying party (IESG)
>> can log in to change the status and edit the report, if necessary.=20
>>=20
>> --------------------------------------
>> RFC6749 (draft-ietf-oauth-v2-31)
>> --------------------------------------
>> Title               : The OAuth 2.0 Authorization Framework
>> Publication Date    : October 2012
>> Author(s)           : D. Hardt, Ed.
>> Category            : PROPOSED STANDARD
>> Source              : Web Authorization Protocol
>> Area                : Security
>> Stream              : IETF
>> Verifying Party     : IESG
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Thu Jul 28 15:38:45 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE86512D08E for ; Thu, 28 Jul 2016 15:38:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.507
X-Spam-Level: 
X-Spam-Status: No, score=-5.507 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.287, 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 UCBaDHnyLv1Z for ; Thu, 28 Jul 2016 15:38:41 -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 0AE5912B069 for ; Thu, 28 Jul 2016 15:38:40 -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 u6SMccXF017308 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 28 Jul 2016 22:38:39 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 u6SMcc20032148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 28 Jul 2016 22:38:38 GMT
Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u6SMcbUe024834; Thu, 28 Jul 2016 22:38:37 GMT
MIME-Version: 1.0
Message-ID: <5d013715-9a4b-4c8f-8fb1-a914c3c2b3a8@default>
Date: Thu, 28 Jul 2016 15:38:35 -0700 (PDT)
From: Vivek Biswas 
Sender: Vivek Biswas 
To: ve7jtb@ve7jtb.com, nov matake , torsten@lodderstedt.net
References:  <57980887.1724c80a.e1de7.c7a7@mx.google.com> <57980a47.e928c80a.c54fd.c891@mx.google.com>    <5798aed1.a468ca0a.6b8d4.a6c4@mx.google.com>
In-Reply-To: <5798aed1.a468ca0a.6b8d4.a6c4@mx.google.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9  (901082) [OL 15.0.4551.0 (x86)]
Content-Type: multipart/alternative; boundary="__1469745517017254187abhmp0002.oracle.com"
X-Source-IP: userv0021.oracle.com [156.151.31.71]
Archived-At: 
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] URGENT: WPAD attack exposes URL contents evenoverHTTPS
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jul 2016 22:38:44 -0000

--__1469745517017254187abhmp0002.oracle.com
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

PKCE256 becomes mandatory in that case. PKCE plain is prone to same attack =
as that of state or none.

=C2=A0

Also PKCE256 should generate new code challenge for every Authorization req=
uest.

=C2=A0

-Vivek Biswas

Consulting Member@Security

Oracle.

=C2=A0

From: ve7jtb@ve7jtb.com [mailto:ve7jtb@ve7jtb.com]=20
Sent: Wednesday, July 27, 2016 5:53 AM
To: nov matake; torsten@lodderstedt.net
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] URGENT: WPAD attack exposes URL contents evenoverHT=
TPS

=C2=A0

With the mix up attack we assumed that the attacker is able to modify the r=
equest.=C2=A0=C2=A0 In that case checking nonce in the code flow is not suf=
ficient as the attacker can modify nonce.=20

=C2=A0

In this attack the attacker as I understand it can only view request and re=
sponse, so checking nonce in code will prevent the paste of the code.=C2=A0=
=C2=A0 Unfortunately (Torsten) checking nonce in the code flow is optional.

=C2=A0

What I=C2=A0 don=E2=80=99t know is if there is a variation of the attack wh=
ere the client uses the attackers proxy and the attacker can modify the req=
uest.

=C2=A0

One other mitigation is to use the Connect post response mode.=C2=A0 That w=
ould stop the code leak as long as the client is not going through the prox=
y.=20

=C2=A0

Post response mode to stop referrer leaking etc is looking like a good idea=
 in general.

=C2=A0

PKCE S256 still seems like the best idea.=C2=A0 However if a browser is usi=
ng a malicious proxy that could also probably be circumvented.

Basically in that situation the attacker has access to cookies etc so OAuth=
 may not be the largest problem.

=C2=A0

John B.

=C2=A0

=C2=A0

Sent from HYPERLINK "https://go.microsoft.com/fwlink/?LinkId=3D550986"Mail =
for Windows 10

=C2=A0

From: HYPERLINK "mailto:matake@gmail.com"nov matake
Sent: July 27, 2016 3:19 AM
To: HYPERLINK "mailto:torsten@lodderstedt.net"torsten@lodderstedt.net
Cc: HYPERLINK "mailto:wdenniss@google.com"William Denniss; HYPERLINK "mailt=
o:ve7jtb@ve7jtb.com"John Bradley; HYPERLINK "mailto:oauth@ietf.org"oauth@ie=
tf.org WG
Subject: Re: [OAUTH-WG] URGENT: WPAD attack exposes URL contents evenoverHT=
TPS

=C2=A0

In Connect, if RP verifies nonce value in ID Token issued from Token Endpoi=
nt, code cut & paste attack can be mitigated in "code" flow, not in "code i=
d_token", can't it?

=C2=A0

In pure OAuth2 senario, I also think PKCE would be the simplest solution.

=C2=A0

2016-07-27 15:45 GMT+09:00 HYPERLINK "mailto:torsten@lodderstedt.net"torste=
n@lodderstedt.net :

+1

I also think PKCE is currently the simplest way to protect OAuth clients fr=
om injection.

Sent by HYPERLINK "http://www.mail-wise.com/installation/2"MailWise =E2=80=
=93 See your emails as clean, short chats.



-------- Originalnachricht --------
Betreff: Re: [OAUTH-WG] URGENT: WPAD attack exposes URL contents even overH=
TTPS
Von: William Denniss 
An: John Bradley 
Cc: Oauth Wrap Wg 

=C2=A0

PKCE S256 was indeed designed to protect against eavesdropping of both the =
authorization request & response.=C2=A0 It was originally created for nativ=
e apps where URL leakage was deemed more likely (since it goes over inter-p=
rocess communication channels), perhaps the practice should be expanded to =
all clients.

=C2=A0

On Tue, Jul 26, 2016 at 6:11 PM,  wrote:

PS=C2=A0=C2=A0 Using PKCE S256 would prevent this attack on web server clie=
nts, as long as the client uses a different PKCE vale for each request.=C2=
=A0=C2=A0=C2=A0 Even if the attacker can observe both the request and respo=
nse, they would not have the code_verifyer and if replaying the code to the=
 client the client will use the wrong verifier value to exchange the code a=
nd will get an error.

=C2=A0

That is probably the simplest mitigation against this for the code flow on =
web servers and native apps.

=C2=A0

I will think about it overnight.

=C2=A0

John B.

=C2=A0

Sent from HYPERLINK "https://go.microsoft.com/fwlink/?LinkId=3D550986"Mail =
for Windows 10

=C2=A0

From: HYPERLINK "mailto:ve7jtb@ve7jtb.com"ve7jtb@ve7jtb.com
Sent: July 26, 2016 9:04 PM
To: HYPERLINK "mailto:dick.hardt@gmail.com"Dick Hardt; HYPERLINK "mailto:oa=
uth@ietf.org"Oauth Wrap Wg
Subject: RE: [OAUTH-WG] URGENT: WPAD attack exposes URL contents even overH=
TTPS

=C2=A0

I need to think about it a bit,=C2=A0 however off the top of my head based =
on the attack described the code flow should still be safe if the code is t=
ruly single use.=C2=A0=C2=A0 (Some implementations fudge that)

=C2=A0

If the attacker can stop the browser from delivering the code to the client=
 then the client would be susceptible to the cut and paste attack for injec=
ting the code back into the client.=C2=A0=20

=C2=A0

The OpenID Connect =E2=80=9Ccode id_token=E2=80=9D flow is not vulnerable t=
o this if the client is properly validating the id_token.

=C2=A0

I suspect that this would work against the implicit flow if the JS is sendi=
ng the code back to its web server via a GET.=C2=A0=20

That I think we recommend against doing, or should.

=C2=A0

The Token binding proposals would stop a leaked code from being used, but n=
ot from being stolen in this attack.

=C2=A0

The attack against a confidential client would be the cut and paste one tha=
t we have identified.=C2=A0 Currently the only mitigation we have is =E2=80=
=9Ccode id_token=E2=80=9D=C2=A0 so the blog post at.

http://openid.net/2016/07/16/preventing-mix-up-attacks-with-openid-connect/

=C2=A0

I the most relevant current advice.

The thing to add is that the code leaked in this way should not be repayabl=
e at the client=20

=C2=A0

I don=E2=80=99t think that native apps are vulnerable to this if they are u=
sing custom scheme redirects.=C2=A0=20

=C2=A0

I don=E2=80=99t know what the risk is if they are using loopback or claimed=
 URI.=C2=A0 It may be that a browser might leak them in the same way.=20

That would need to be tested.

=C2=A0

John B.

=C2=A0

=C2=A0

Sent from HYPERLINK "https://go.microsoft.com/fwlink/?LinkId=3D550986"Mail =
for Windows 10

=C2=A0

From: HYPERLINK "mailto:dick.hardt@gmail.com"Dick Hardt
Sent: July 26, 2016 8:15 PM
To: HYPERLINK "mailto:oauth@ietf.org"Oauth Wrap Wg
Subject: [OAUTH-WG] URGENT: WPAD attack exposes URL contents even over HTTP=
S

=C2=A0

http://arstechnica.com/security/2016/07/new-attack-that-cripples-https-cryp=
to-works-on-macs-windows-and-linux/

=C2=A0

Access tokens included as a URL query parameter when accessing a resource a=
re susceptible to this attack.

=C2=A0

Authorization codes are also visible. From what I know, we have not depende=
d on the confidentiality of the authorization code.=C2=A0

=C2=A0

What are the best current practices that we can point people towards to ens=
ure they are not susceptible to this attack?

=C2=A0

-- Dick=C2=A0

Subscribe to the HYPERLINK "http://hardtware.com/"HARDTWARE mail list to le=
arn about projects I am working on!

=C2=A0

=C2=A0


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

=C2=A0


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





=C2=A0

--=20

nov matake

=C2=A0

--__1469745517017254187abhmp0002.oracle.com
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


PKCE256 becomes mandatory in that case. PKCE plain is pr=
one to same attack as that of state or none.
 
Also PKCE=
256 should generate new code challenge for every Authorization request.=

&n=
bsp;
-Vi=
vek Biswas
 Consulting Member@Security
 Oracle.
 
From: ve7jtb@ve7jtb.com [mailto:ve7jtb@ve=
7jtb.com] 
Sent: Wednesday, July 27, 2016 5:53 AM
To: n=
ov matake; torsten@lodderstedt.net
Cc: oauth@ietf.org WG
Su=
bject: Re: [OAUTH-WG] URGENT: WPAD attack exposes URL contents evenover=
HTTPS
 
<=
p class=3DMsoNormal>With the mix up attack we assumed th=
at the attacker is able to modify the request.   In that case che=
cking nonce in the code flow is not sufficient as the attacker can modify n=
once. 
&n=
bsp;
In this attack=
 the attacker as I understand it can only view request and response, so che=
cking nonce in code will prevent the paste of the code.   Unfortu=
nately (Torsten) checking nonce in the code flow is optional.
 
What I  don=E2=80=99t know is=
 if there is a variation of the attack where the client uses the attackers =
proxy and the attacker can modify the request.
 
One other mitigation is to use the Connect post r=
esponse mode.  That would stop the code leak as long as the client is =
not going through the proxy. 
 
Post response mode to stop referrer leaking etc is looking like a =
good idea in general.
 
PKCE S256 still seems like the best idea.  However if a browser is u=
sing a malicious proxy that could also probably be circumvented.=

Basically in that situat=
ion the attacker has access to cookies etc so OAuth may not be the largest =
problem.
=
 
John B.=

 <=
/span>
 <=
/p>
Sent from Mail for Windows 10
 
From: nov matake
Sent: Jul=
y 27, 2016 3:19 AM
To: torsten@lodderstedt.net
Cc: William Denniss; John Bradl=
ey; oauth@ietf.org WG
Subje=
ct: Re: [OAUTH-WG] URGENT: WPAD attack exposes URL contents evenoverHTT=
PS
 
In Connect, if RP verifies =
nonce value in ID Token issued from Token Endpoint, code cut & paste at=
tack can be mitigated in "code" flow, not in "code id_token&=
quot;, can't it?
 
=
 
2016-07-27 1=
5:45 GMT+09:00 torsten@lodderste=
dt.net <torsten@lodderstedt.net>:
+1
I also think =
PKCE is currently the simplest way to protect OAuth clients from injection.=

Sent by MailWise =E2=80=93 See y=
our emails as clean, short chats.


-------- Originalnachricht --------
Betreff: Re: [OAUT=
H-WG] URGENT: WPAD attack exposes URL contents even overHTTPS
Von: Willi=
am Denniss <wde=
nniss@google.com>
An: John Bradley <ve7jtb@ve7jtb.com>
Cc: Oauth Wrap Wg=
 <oauth@ietf.org=
>
 
PKCE S256 was indeed designed to protect against eavesdropping of=
 both the authorization request & response.  It was originally cre=
ated for native apps where URL leakage was deemed more likely (since it goe=
s over inter-process communication channels), perhaps the practice should b=
e expanded to all clients.
 
PS  =
; Using PKCE S256 would prevent this attack on web server clients, as long =
as the client uses a different PKCE vale for each request.   =
; Even if the attacker can observe both the request and response, they woul=
d not have the code_verifyer and if replaying the code to the client the cl=
ient will use the wrong verifier value to exchange the code and will get an=
 error.
 =

That is proba=
bly the simplest mitigation against this for the code flow on web servers a=
nd native apps.
 
I wil=
l think about it overnight.
 
John B.
 
Sent=
 from Mail for Windows 10
 
=

From: ve7jtb@ve7jtb.co=
m
Sent: July 26, 2016 9:04 PM
To: Dick Hardt; Oauth Wrap Wg
Subject: RE: =
[OAUTH-WG] URGENT: WPAD attack exposes URL contents even overHTTPS
 
I need to think about it a bit,  however off the top of my head ba=
sed on the attack described the code flow should still be safe if the code =
is truly single use.   (Some implementations fudge that)
 
If the attacker can stop the =
browser from delivering the code to the client then the client would be sus=
ceptible to the cut and paste attack for injecting the code back into the c=
lient.  
=
 
The Ope=
nID Connect =E2=80=9Ccode id_token=E2=80=9D flow is not vulnerable to this =
if the client is properly validating the id_token.
 
I suspect that this would work against the =
implicit flow if the JS is sending the code back to its web server via a GE=
T.  
That=
 I think we recommend against doing, or should.
 
The Token binding proposals would stop a leaked =
code from being used, but not from being stolen in this attack.<=
/span>
 <=
/p>
The attack against a confidentia=
l client would be the cut and paste one that we have identified.  Curr=
ently the only mitigation we have is =E2=80=9Ccode id_token=E2=80=9D  =
so the blog post at.
http://openid.net/2016/07/16/preven=
ting-mix-up-attacks-with-openid-connect/
 
I the most relevant current advice.
The thing to add is that the=
 code leaked in this way should not be repayable at the client <=
/span>
 <=
/p>
I don=E2=80=99t think that nativ=
e apps are vulnerable to this if they are using custom scheme redirects.&nb=
sp; 
 
I don=E2=80=99t =
know what the risk is if they are using loopback or claimed URI.  It m=
ay be that a browser might leak them in the same way. 
That would need to be tested.=

 <=
/span>
John B.=

 
 
Sent from Mail for Windows 10<=
/o:p>
 
From: Dick Hardt
Sent: July 26, 2016 8:15 PMTo: Oauth Wrap=
 Wg
Subject: [OAUTH-WG] URGENT: WPAD attack exposes URL conte=
nts even over HTTPS
http://arstechnica.com/security/2016/07/new-attack-that-cripples-htt=
ps-crypto-works-on-macs-windows-and-linux/
 
A=
ccess tokens included as a URL query parameter when accessing a resource ar=
e susceptible to this attack.
 =

Authorizatio=
n codes are also visible. From what I know, we have not depended on the con=
fidentiality of the authorization code. 
 
What are the best current practices that we can point people towards t=
o ensure they are not susceptible to this attack?=

 
<=
span lang=3DEN-CA style=3D'font-size:12.0pt;font-family:"Times New Roman","=
serif"'>-- Dick 
=

Subscribe to the HARDTWARE mail list to learn about projec=
ts I am working on!
 
 

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

________=
_______________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/l=
istinfo/oauth


 
-- 
nov matake=

 

--__1469745517017254187abhmp0002.oracle.com--


From nobody Thu Jul 28 20:09:23 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5165212D619 for ; Thu, 28 Jul 2016 20:09:21 -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, 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=manicode-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 mU5Qfm4CzpVx for ; Thu, 28 Jul 2016 20:09:19 -0700 (PDT)
Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d: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 05B0112D57B for ; Thu, 28 Jul 2016 20:09:19 -0700 (PDT)
Received: by mail-qk0-x236.google.com with SMTP id o67so80275350qke.1 for ; Thu, 28 Jul 2016 20:09:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SDgnyfJi7TJE4mwT2RRsTrFssYoXThRdIQZtLyiOr1g=; b=xG23aPomP6txYZQ5yEuHkLYySx3RXawTuNuExjzuCFzLfkhvUky0CebChXhKxkvqJ6 xutXForr7cyjc/LedAZIsIXvEqxTfnxjlaymgeVX07y2kXZd9E0fhK1ZJfN76uEcj290 F/MeZY7Phmb6b81NQCSsMok9R7k6DTUAymZ4IEy2AVh75rvoBnA4rBzOCfFlhwwYPw88 r7syD5TTcFFCozNXn2hSWuB/5JRLNU6b9C7X2/WVqBJzqIHbDWJgCKx1MOmOYb4iF6GE 0BfkiY56u5V9Xj6QssZG9W2HA5OgU6LZfI82CM72Fde+uGtCN+9Aw8Yg7bPpi3ZlSB+R ewOw==
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 :content-transfer-encoding:message-id:references:to; bh=SDgnyfJi7TJE4mwT2RRsTrFssYoXThRdIQZtLyiOr1g=; b=fjE5eTzC9LJ3iSA5Nt2RcG+6B57yljKOVawKA6sFR1zwcVJVJGQMSpCy6/9zayAAat HLLZiwCLDJgUDRQhRal8kXGXu7mn1kdzth51eRt9SZRZ53KzUbSATOOEkyeLqxudKp67 vTo4MHfrs09T6fZl+PdLbUkJi77tUh1gMOszqWGicPV4CZJvpNXHGiaDCzUfUTPHchKp 3pxcs+GxY/q5xuN6YmHmTcpkNMMGGNuJzZC37JTQ4dvXAX4JmukKAixFUpHJQ6G/C53q ftXgYVoBICg/LRwH+yDRhH0F+4Vgku/ldRFW0fZmDb1qPUj1iCjKWOr/9ZOuazefIGXY /Q3g==
X-Gm-Message-State: AEkoouspD68fb1ksUqcYc/ivRpyodXtUYD6eEqziHmzNNvH5EMXrKNArQayOTSay1qhG/Z6J
X-Received: by 10.55.106.195 with SMTP id f186mr45937418qkc.52.1469761757880;  Thu, 28 Jul 2016 20:09:17 -0700 (PDT)
Received: from [172.20.7.198] ([38.101.171.207]) by smtp.gmail.com with ESMTPSA id x3sm8991832qkb.32.2016.07.28.20.09.15 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 28 Jul 2016 20:09:16 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
From: Jim Manico 
X-Mailer: iPhone Mail (13G34)
In-Reply-To: 
Date: Thu, 28 Jul 2016 23:09:14 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <76BFF944-7B23-4CF6-8EFC-3FBFBF207FBF@manicode.com>
References: <20160726204839.0874EB81C1A@rfc-editor.org>  
To: Justin Richer 
Archived-At: 
Cc: Derek Atkins , "" 
Subject: Re: [OAUTH-WG] [Technical Errata Reported] RFC6749 (4749)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jul 2016 03:09:21 -0000

Thank you Justin, comments inline.

> These are client secrets, not user passwords, so they=E2=80=99re supposed t=
o be high entropy and not human-memorable (or human-typable really).=20

This still sounds like sensitive data, and I don't understand the relevance o=
f "human memorable". If time allows can you tell me more?

> Also, this needs to be used over TLS.=20

Sure, but the problems of HTTP Basic are well established and go beyond TLS (=
no timeout, included in each request, cached by the browser for that window s=
ession, etc).

> The connection requires TLS anyway because the tokens returned (or the tok=
en keys in the OAuth PoP case) also need to be protected, regardless of how y=
ou hash the client=E2=80=99s secret. With that in mind, Digest doesn=E2=80=99=
t buy you much.

So this looks like a way to transport the client id and secret. Wouldn't som=
e form of "strong authentication" like mutual TLS or similar be a better def=
ault standard? The OAuth 2 threat model makes this exact recommendation.

Respectfully,
--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805

> On Jul 28, 2016, at 4:25 PM, Justin Richer  wrote:
>=20
> These are client secrets, not user passwords, so they=E2=80=99re supposed t=
o be high entropy and not human-memorable (or human-typable really). Also, t=
his needs to be used over TLS. The connection requires TLS anyway because th=
e tokens returned (or the token keys in the OAuth PoP case) also need to be p=
rotected, regardless of how you hash the client=E2=80=99s secret. With that i=
n mind, Digest doesn=E2=80=99t buy you much.
>=20
> =E2=80=94 Justin
>=20
>> On Jul 26, 2016, at 8:08 PM, Jim Manico  wrote:
>>=20
>> Please forgive me if this comment is out of order or inappropriate in any=
 way...
>>=20
>> ...but why is HTTP Basic even being discussed in 2016? It has horrific se=
curity properties at multiple levels; shouldn't we at least move to HTTP Dig=
est if not something stronger?
>>=20
>> Regards.
>> --
>> Jim Manico
>> @Manicode
>>=20
>>> On Jul 26, 2016, at 4:48 PM, RFC Errata System  wrote:
>>>=20
>>> The following errata report has been submitted for RFC6749,
>>> "The OAuth 2.0 Authorization Framework".
>>>=20
>>> --------------------------------------
>>> You may review the report below and at:
>>> http://www.rfc-editor.org/errata_search.php?rfc=3D6749&eid=3D4749
>>>=20
>>> --------------------------------------
>>> Type: Technical
>>> Reported by: Phil Hunt 
>>>=20
>>> Section: 2.3.1
>>>=20
>>> Original Text
>>> -------------
>>> Clients in possession of a client password MAY use the HTTP Basic
>>> authentication scheme as defined in [RFC2617] to authenticate with
>>> the authorization server.  The client identifier is encoded using the
>>> "application/x-www-form-urlencoded" encoding algorithm per
>>> Appendix B, and the encoded value is used as the username; the client
>>> password is encoded using the same algorithm and used as the
>>> password.  The authorization server MUST support the HTTP Basic
>>> authentication scheme for authenticating clients that were issued a
>>> client password.
>>>=20
>>> Corrected Text
>>> --------------
>>> Clients in possession of a client password MAY use the HTTP Basic
>>> authentication scheme as defined in [RFC2617] to authenticate with
>>> the authorization server.  The client identifier is encoded using the
>>> "application/x-www-form-urlencoded" encoding algorithm per
>>> Appendix B, and the encoded value is used as the username; the client
>>> password is encoded using the same algorithm and used as the
>>> password. The url encoded values are then encoded as defined in
>>> [RFC2617]. The authorization server MUST support the HTTP Basic
>>> authentication scheme for authenticating clients that were issued a
>>> client password.
>>>=20
>>> Notes
>>> -----
>>> It was not clear to some implementers that the intention is a 2-step enc=
oding. First for special characters and second the 2617 base 64 encoding.  I=
mplementers thought 6749 was in conflict with 2617.
>>>=20
>>> To avoid inter-op issues, a new clarifying sentence is proposed.
>>> "The url encoded values are then encoded as defined in [RFC2617]."
>>>=20
>>> Instructions:
>>> -------------
>>> This erratum is currently posted as "Reported". If necessary, please
>>> use "Reply All" to discuss whether it should be verified or
>>> rejected. When a decision is reached, the verifying party (IESG)
>>> can log in to change the status and edit the report, if necessary.=20
>>>=20
>>> --------------------------------------
>>> RFC6749 (draft-ietf-oauth-v2-31)
>>> --------------------------------------
>>> Title               : The OAuth 2.0 Authorization Framework
>>> Publication Date    : October 2012
>>> Author(s)           : D. Hardt, Ed.
>>> Category            : PROPOSED STANDARD
>>> Source              : Web Authorization Protocol
>>> Area                : Security
>>> Stream              : IETF
>>> Verifying Party     : IESG
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20


From nobody Thu Jul 28 20:36:04 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC11512D128 for ; Thu, 28 Jul 2016 20:36:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.508
X-Spam-Level: 
X-Spam-Status: No, score=-5.508 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.287, 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 WXH8uohPSPVo for ; Thu, 28 Jul 2016 20:36:00 -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 D14CA12D10C for ; Thu, 28 Jul 2016 20:36:00 -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 u6T3ZxG9027875 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 29 Jul 2016 03:35:59 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 u6T3ZwgM017555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 29 Jul 2016 03:35:59 GMT
Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u6T3ZvX2004887; Fri, 29 Jul 2016 03:35:57 GMT
Received: from [192.168.1.6] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 28 Jul 2016 20:35:57 -0700
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
From: "Phil Hunt (IDM)" 
X-Mailer: iPhone Mail (13G34)
In-Reply-To: <76BFF944-7B23-4CF6-8EFC-3FBFBF207FBF@manicode.com>
Date: Thu, 28 Jul 2016 20:35:55 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <601B9A7A-4812-4DA9-9C37-17DD6D1326B2@oracle.com>
References: <20160726204839.0874EB81C1A@rfc-editor.org>   <76BFF944-7B23-4CF6-8EFC-3FBFBF207FBF@manicode.com>
To: Jim Manico 
X-Source-IP: userv0021.oracle.com [156.151.31.71]
Archived-At: 
Cc: Derek Atkins , "" 
Subject: Re: [OAUTH-WG] [Technical Errata Reported] RFC6749 (4749)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jul 2016 03:36:03 -0000

This is off topic for the errata process. This is not the place to propose a=
 re-write.=20

As one of the authors of the threat model and sec considerations I think we c=
overed this to too much. :-) Justin's comments are spot on.=20

This has nothing to do with user authentication.=20

Phil

> On Jul 28, 2016, at 8:09 PM, Jim Manico  wrote:
>=20
> Thank you Justin, comments inline.
>=20
>> These are client secrets, not user passwords, so they=E2=80=99re supposed=
 to be high entropy and not human-memorable (or human-typable really).
>=20
> This still sounds like sensitive data, and I don't understand the relevanc=
e of "human memorable". If time allows can you tell me more?
>=20
>> Also, this needs to be used over TLS.
>=20
> Sure, but the problems of HTTP Basic are well established and go beyond TL=
S (no timeout, included in each request, cached by the browser for that wind=
ow session, etc).
>=20
>> The connection requires TLS anyway because the tokens returned (or the to=
ken keys in the OAuth PoP case) also need to be protected, regardless of how=
 you hash the client=E2=80=99s secret. With that in mind, Digest doesn=E2=80=
=99t buy you much.
>=20
> So this looks like a way to transport the client id and secret. Wouldn't s=
ome form of "strong authentication" like mutual TLS or similar be a better d=
efault standard? The OAuth 2 threat model makes this exact recommendation.
>=20
> Respectfully,
> --
> Jim Manico
> @Manicode
> Secure Coding Education
> +1 (808) 652-3805
>=20
>> On Jul 28, 2016, at 4:25 PM, Justin Richer  wrote:
>>=20
>> These are client secrets, not user passwords, so they=E2=80=99re supposed=
 to be high entropy and not human-memorable (or human-typable really). Also,=
 this needs to be used over TLS. The connection requires TLS anyway because t=
he tokens returned (or the token keys in the OAuth PoP case) also need to be=
 protected, regardless of how you hash the client=E2=80=99s secret. With tha=
t in mind, Digest doesn=E2=80=99t buy you much.
>>=20
>> =E2=80=94 Justin
>>=20
>>> On Jul 26, 2016, at 8:08 PM, Jim Manico  wrote:
>>>=20
>>> Please forgive me if this comment is out of order or inappropriate in an=
y way...
>>>=20
>>> ...but why is HTTP Basic even being discussed in 2016? It has horrific s=
ecurity properties at multiple levels; shouldn't we at least move to HTTP Di=
gest if not something stronger?
>>>=20
>>> Regards.
>>> --
>>> Jim Manico
>>> @Manicode
>>>=20
>>>> On Jul 26, 2016, at 4:48 PM, RFC Errata System  wrote:
>>>>=20
>>>> The following errata report has been submitted for RFC6749,
>>>> "The OAuth 2.0 Authorization Framework".
>>>>=20
>>>> --------------------------------------
>>>> You may review the report below and at:
>>>> http://www.rfc-editor.org/errata_search.php?rfc=3D6749&eid=3D4749
>>>>=20
>>>> --------------------------------------
>>>> Type: Technical
>>>> Reported by: Phil Hunt 
>>>>=20
>>>> Section: 2.3.1
>>>>=20
>>>> Original Text
>>>> -------------
>>>> Clients in possession of a client password MAY use the HTTP Basic
>>>> authentication scheme as defined in [RFC2617] to authenticate with
>>>> the authorization server.  The client identifier is encoded using the
>>>> "application/x-www-form-urlencoded" encoding algorithm per
>>>> Appendix B, and the encoded value is used as the username; the client
>>>> password is encoded using the same algorithm and used as the
>>>> password.  The authorization server MUST support the HTTP Basic
>>>> authentication scheme for authenticating clients that were issued a
>>>> client password.
>>>>=20
>>>> Corrected Text
>>>> --------------
>>>> Clients in possession of a client password MAY use the HTTP Basic
>>>> authentication scheme as defined in [RFC2617] to authenticate with
>>>> the authorization server.  The client identifier is encoded using the
>>>> "application/x-www-form-urlencoded" encoding algorithm per
>>>> Appendix B, and the encoded value is used as the username; the client
>>>> password is encoded using the same algorithm and used as the
>>>> password. The url encoded values are then encoded as defined in
>>>> [RFC2617]. The authorization server MUST support the HTTP Basic
>>>> authentication scheme for authenticating clients that were issued a
>>>> client password.
>>>>=20
>>>> Notes
>>>> -----
>>>> It was not clear to some implementers that the intention is a 2-step en=
coding. First for special characters and second the 2617 base 64 encoding.  I=
mplementers thought 6749 was in conflict with 2617.
>>>>=20
>>>> To avoid inter-op issues, a new clarifying sentence is proposed.
>>>> "The url encoded values are then encoded as defined in [RFC2617]."
>>>>=20
>>>> Instructions:
>>>> -------------
>>>> This erratum is currently posted as "Reported". If necessary, please
>>>> use "Reply All" to discuss whether it should be verified or
>>>> rejected. When a decision is reached, the verifying party (IESG)
>>>> can log in to change the status and edit the report, if necessary.=20
>>>>=20
>>>> --------------------------------------
>>>> RFC6749 (draft-ietf-oauth-v2-31)
>>>> --------------------------------------
>>>> Title               : The OAuth 2.0 Authorization Framework
>>>> Publication Date    : October 2012
>>>> Author(s)           : D. Hardt, Ed.
>>>> Category            : PROPOSED STANDARD
>>>> Source              : Web Authorization Protocol
>>>> Area                : Security
>>>> Stream              : IETF
>>>> Verifying Party     : IESG
>>>>=20
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Thu Jul 28 23:39:39 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2BD412B031 for ; Thu, 28 Jul 2016 23:39:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 cu5TDtQA3WRN for ; Thu, 28 Jul 2016 23:39:36 -0700 (PDT)
Received: from p3plsmtpa09-03.prod.phx3.secureserver.net (p3plsmtpa09-03.prod.phx3.secureserver.net [173.201.193.232]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 080A2124281 for ; Thu, 28 Jul 2016 23:39:35 -0700 (PDT)
Received: from [192.168.1.9] ([46.10.70.150]) by p3plsmtpa09-03.prod.phx3.secureserver.net with  id QWfX1t0013EY5i601WfY3w; Thu, 28 Jul 2016 23:39:35 -0700
To: Jim Manico , Justin Richer 
References: <20160726204839.0874EB81C1A@rfc-editor.org>   <76BFF944-7B23-4CF6-8EFC-3FBFBF207FBF@manicode.com>
From: Vladimir Dzhuvinov 
Organization: Connect2id Ltd.
Message-ID: 
Date: Fri, 29 Jul 2016 09:39:30 +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: <76BFF944-7B23-4CF6-8EFC-3FBFBF207FBF@manicode.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070904090602080404020402"
Archived-At: 
Cc: Derek Atkins , "" 
Subject: Re: [OAUTH-WG] [Technical Errata Reported] RFC6749 (4749)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jul 2016 06:39:37 -0000

This is a cryptographically signed message in MIME format.

--------------ms070904090602080404020402
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


On 29/07/16 06:09, Jim Manico wrote:
> Thank you Justin, comments inline.
>
>> These are client secrets, not user passwords, so they=E2=80=99re suppo=
sed to be high entropy and not human-memorable (or human-typable really).=
=20
> This still sounds like sensitive data, and I don't understand the relev=
ance of "human memorable". If time allows can you tell me more?
>
>> Also, this needs to be used over TLS.=20
> Sure, but the problems of HTTP Basic are well established and go beyond=
 TLS (no timeout, included in each request, cached by the browser for tha=
t window session, etc).
The browser is not involved in the token request.

One alternative to HTTP Basic (and its POST variant) is for the client
to authenticate by submitting a JWT hashed with the client secret, or a
JWT signed with an RSA or EC key that was previously registered with the =
AS:

https://tools.ietf.org/html/rfc7523#section-2.2

I find JWT auth the more secure method, as it mitigates against some
attacks previously discussed here. And it also lessens the potential
security damage if the client accidentally makes a plain HTTP request to
the token endpoint (the client_secret itself is not leaked).

>
>> The connection requires TLS anyway because the tokens returned (or the=
 token keys in the OAuth PoP case) also need to be protected, regardless =
of how you hash the client=E2=80=99s secret. With that in mind, Digest do=
esn=E2=80=99t buy you much.
> So this looks like a way to transport the client id and secret. Wouldn'=
t some form of "strong authentication" like mutual TLS or similar be a be=
tter default standard? The OAuth 2 threat model makes this exact recommen=
dation.
>
> Respectfully,
> --
> Jim Manico
> @Manicode
> Secure Coding Education
> +1 (808) 652-3805
>
>> On Jul 28, 2016, at 4:25 PM, Justin Richer  wrote:
>>
>> These are client secrets, not user passwords, so they=E2=80=99re suppo=
sed to be high entropy and not human-memorable (or human-typable really).=
 Also, this needs to be used over TLS. The connection requires TLS anyway=
 because the tokens returned (or the token keys in the OAuth PoP case) al=
so need to be protected, regardless of how you hash the client=E2=80=99s =
secret. With that in mind, Digest doesn=E2=80=99t buy you much.
>>
>> =E2=80=94 Justin
>>
>>> On Jul 26, 2016, at 8:08 PM, Jim Manico  wrote:
>>>
>>> Please forgive me if this comment is out of order or inappropriate in=
 any way...
>>>
>>> ...but why is HTTP Basic even being discussed in 2016? It has horrifi=
c security properties at multiple levels; shouldn't we at least move to H=
TTP Digest if not something stronger?
>>>
>>> Regards.
>>> --
>>> Jim Manico
>>> @Manicode
>>>
>>>> On Jul 26, 2016, at 4:48 PM, RFC Errata System  wrote:
>>>>
>>>> The following errata report has been submitted for RFC6749,
>>>> "The OAuth 2.0 Authorization Framework".
>>>>
>>>> --------------------------------------
>>>> You may review the report below and at:
>>>> http://www.rfc-editor.org/errata_search.php?rfc=3D6749&eid=3D4749
>>>>
>>>> --------------------------------------
>>>> Type: Technical
>>>> Reported by: Phil Hunt 
>>>>
>>>> Section: 2.3.1
>>>>
>>>> Original Text
>>>> -------------
>>>> Clients in possession of a client password MAY use the HTTP Basic
>>>> authentication scheme as defined in [RFC2617] to authenticate with
>>>> the authorization server.  The client identifier is encoded using th=
e
>>>> "application/x-www-form-urlencoded" encoding algorithm per
>>>> Appendix B, and the encoded value is used as the username; the clien=
t
>>>> password is encoded using the same algorithm and used as the
>>>> password.  The authorization server MUST support the HTTP Basic
>>>> authentication scheme for authenticating clients that were issued a
>>>> client password.
>>>>
>>>> Corrected Text
>>>> --------------
>>>> Clients in possession of a client password MAY use the HTTP Basic
>>>> authentication scheme as defined in [RFC2617] to authenticate with
>>>> the authorization server.  The client identifier is encoded using th=
e
>>>> "application/x-www-form-urlencoded" encoding algorithm per
>>>> Appendix B, and the encoded value is used as the username; the clien=
t
>>>> password is encoded using the same algorithm and used as the
>>>> password. The url encoded values are then encoded as defined in
>>>> [RFC2617]. The authorization server MUST support the HTTP Basic
>>>> authentication scheme for authenticating clients that were issued a
>>>> client password.
>>>>
>>>> Notes
>>>> -----
>>>> It was not clear to some implementers that the intention is a 2-step=
 encoding. First for special characters and second the 2617 base 64 encod=
ing.  Implementers thought 6749 was in conflict with 2617.
>>>>
>>>> To avoid inter-op issues, a new clarifying sentence is proposed.
>>>> "The url encoded values are then encoded as defined in [RFC2617]."
>>>>
>>>> Instructions:
>>>> -------------
>>>> This erratum is currently posted as "Reported". If necessary, please=

>>>> use "Reply All" to discuss whether it should be verified or
>>>> rejected. When a decision is reached, the verifying party (IESG)
>>>> can log in to change the status and edit the report, if necessary.=20
>>>>
>>>> --------------------------------------
>>>> RFC6749 (draft-ietf-oauth-v2-31)
>>>> --------------------------------------
>>>> Title               : The OAuth 2.0 Authorization Framework
>>>> Publication Date    : October 2012
>>>> Author(s)           : D. Hardt, Ed.
>>>> Category            : PROPOSED STANDARD
>>>> Source              : Web Authorization Protocol
>>>> Area                : Security
>>>> Stream              : IETF
>>>> Verifying Party     : IESG
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



--------------ms070904090602080404020402
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
Fw0xNjA3MjkwNjM5MzBaMC8GCSqGSIb3DQEJBDEiBCBM2r4zJPBLkY+Pl/VM00UHOFI+7FK0
sSG+gebysA5YGzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw
CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD
VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP
TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQbyALwckZ9IF6bQSWzWYN4zCBwwYLKoZI
hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw
PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy
ZSBFbWFpbCBDQQIQbyALwckZ9IF6bQSWzWYN4zANBgkqhkiG9w0BAQEFAASCAQBvftQaeBSI
dzaKA7yhMx4iMxwGMHo4SXRn5JyJi4XSetWlZSxNTlhgOmwSGJo6nRu8hwuUOu5iRvQiKB4h
01NqvroYZItaUl1K3m7v7w7lt5uOmMdd+10Brb8UisyUH0+bpR+W47VL0zaS6mYzl1oLgLs8
NBmfPAIBETOXJ/YHEkjAf6HOAxDlABB7yBiQNVvxfaGZkL+lVCf0qhxU9lA76ogOSda9wD9j
hV9qBj1vnnMHU3jqoFrOYU9iwd4oizwKY5XGnyDuNdZC5+/XZExaN6hb9WdyPGV5zwCvp638
c0aAoevL+llrRTgkyWL739soifED47qmYzknjd5M77GlAAAAAAAA
--------------ms070904090602080404020402--


From nobody Fri Jul 29 07:04:47 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A07B112D6A8 for ; Fri, 29 Jul 2016 07:04:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.218
X-Spam-Level: 
X-Spam-Status: No, score=0.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_96_XX=3.405, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mx.aol.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 M-df9_np8Mbr for ; Fri, 29 Jul 2016 07:04:42 -0700 (PDT)
Received: from oms-a003e.mx.aol.com (oms-a003e.mx.aol.com [204.29.186.149]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D822212D6B1 for ; Fri, 29 Jul 2016 07:04:41 -0700 (PDT)
Received: from omr-a019e.mx.aol.com (omr-a019.mx.aol.com [10.72.101.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by oms-a003e.mx.aol.com (AOL Outbound OMS Interface) with ESMTPS id D0B7F38000B7 for ; Fri, 29 Jul 2016 10:04:39 -0400 (EDT)
Received: from mtaout-aal02.mx.aol.com (mtaout-aal02.mx.aol.com [172.27.20.206]) by omr-a019e.mx.aol.com (Outbound Mail Relay) with ESMTP id A824938000B3 for ; Fri, 29 Jul 2016 10:04:39 -0400 (EDT)
Received: from [192.168.1.11] (unknown [112.208.41.205]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-aal02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id A0D853800008B for ; Fri, 29 Jul 2016 10:04:37 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2074.6\))
From: wax 
In-Reply-To: 
Date: Wed, 20 Jul 2016 15:20:44 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <70E09970-5D17-42E7-9BD5-F844714498A4@aol.com>
References: 
To: oauth@ietf.org
X-Mailer: Apple Mail (2.2074.6)
x-aol-global-disposition: S
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1469801079; bh=m3Wdos9flH3ESngj1KmT76arJRSoSE3nmD/uvCXEO0g=; h=From:To:Subject:Message-Id:Date:Mime-Version:Content-Type; b=yh3Hy0tq97s+qVtRVn7/3FjAPq/wssPXczM8VO0PC7KE9SwyN5Kopv3RAWJachTp9 yjeQrGdKo3pZRKVTECEwru+rCL1xwvFDuj6eDTBsTCAwBZqMO3p/++owaDIBjktGIq cDIu2oj2C+zMVtbzZBKZiFvj7FF+2Pk82NptMZnM=
X-AOL-REROUTE: YES
x-aol-sid: 3039ac1b14ce579b6275652e
X-AOL-IP: 112.208.41.205
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Digest, Vol 91, Issue 3
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jul 2016 14:04:45 -0000

> On May 2, 2016, at 22:39, oauth-request@ietf.org wrote:
>=20
> Send OAuth mailing list submissions to
> 	oauth@ietf.org
>=20
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://www.ietf.org/mailman/listinfo/oauth
> or, via email, send a message with subject or body 'help' to
> 	oauth-request@ietf.org
>=20
> You can reach the person managing the list at
> 	oauth-owner@ietf.org
>=20
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OAuth digest..."
>=20
>=20
> Today's Topics:
>=20
> 1. Re: Building on the protocol in the draft ?OAuth 2.0 Token
>    Exchange: An STS for the REST of Us? to include Authentication
>    Tokens (Fregly, Andrew)
>=20
>=20
> ----------------------------------------------------------------------
>=20
> Message: 1
> Date: Mon, 2 May 2016 14:39:44 +0000
> From: "Fregly, Andrew" 
> To: Justin Richer , George Fletcher
> 	, "John Bradley" ,
> 	"oauth@ietf.org" 
> Subject: Re: [OAUTH-WG] Building on the protocol in the draft ?OAuth
> 	2.0 Token Exchange: An STS for the REST of Us? to include
> 	Authentication Tokens
> Message-ID: 
> Content-Type: text/plain; charset=3D"utf-8"
>=20
> Thank you for that link Justin. The approach you mentioned would work =
well if we were dealing with an all OpenID Connect world. I don?t think =
it will work for our requirements. We need to support authentication =
with the legacy Identity Providers found within organizations from =
client types that might be native apps as well as Web clients. We can?t =
put in any requirements that require changes to the Identity Providers, =
such as requiring them to handle redirects in accordance with OAuth or =
OpenID Connect standards. The advice and direction I have received from =
this group has been very useful in pointing me to the various approaches =
that needed to be considered. After considering all that I have learned, =
I think our use case is out of the design constraints that have been =
driving the development of OAuth and OpenID Connect. Despite that, I can =
get very close with the existing OAuth RFCs. This may result in me =
writing a draft/profile that describes what was needed on top of those
> RFCs an
> d a discussion of the security implications of the additions. If =
anybody would like to follow up with me, please email me directly as I =
don?t know if it is worth beating on this topic any more with the full =
group.
>=20
> From: Justin Richer >
> Date: Saturday, April 23, 2016 at 9:55 AM
> To: "Fregly, Andrew" =
>, George Fletcher =
>, John Bradley =
>, =
"oauth@ietf.org" =
>
> Subject: Re: [OAUTH-WG] Building on the protocol in the draft ?OAuth =
2.0 Token Exchange: An STS for the REST of Us? to include Authentication =
Tokens
>=20
> OpenID Connect defines a third-party login endpoint for RP's, which is =
what the AS is acting as in this case:
>=20
> =
http://openid.net/specs/openid-connect-core-1_0.html#ThirdPartyInitiatedLo=
gin
>=20
> -- Justin
>=20
> On 4/22/2016 10:50 AM, Fregly, Andrew wrote:
> Hi George,
>=20
> You have the flow right for how I have been approaching the problem. =
Note that the client doesn?t have to be a mobile app, but that =
represents well what we are trying to solve. Per your recommendation, =
what I am missing in my knowledge is a standard for how the AS could be =
directed to use an external IdP for authentication. Not knowing this, I =
have been assuming the flow you described as my ?original thinking" =
would be required. I will do some more research on the topic and check =
back in.
>=20
> Thanks,
>  Andy
>=20
>=20
> From: George Fletcher >
> Organization: AOL LLC
> Date: Wednesday, April 20, 2016 at 1:36 PM
> To: "Fregly, Andrew" =
>, John Bradley =
>, =
"oauth@ietf.org" =
>
> Subject: Re: [OAUTH-WG] Building on the protocol in the draft ?OAuth =
2.0 Token Exchange: An STS for the REST of Us? to include Authentication =
Tokens
>=20
> Hi Andy,
>=20
> Glad I guessed correctly:) If there are network or other limitations =
in how the client gets and uses tokens, that would be helpful in a =
diagram sense. As John points out in his response, not having an =
audience has possible security implications.
>=20
> If I'm following your original thinking... it goes something like =
this...
>=20
> 1. Mobile app asks users to authenticate at "their" IdP
> 2. Mobile app gets back "authentication token" (likely some sort of =
SAML assertion)
> 3. Mobile app presents "authentication token" to Authorization Service
> 4. Authorization Service validate "authentication token" and returns =
an access_token
> 5. Mobile app invokes data provider passing the access_token
> 6. Data provider validates access_token (either locally or via an =
introspection endpoint on the AS)
>=20
> In this flow there are really two tokens: the "authentication token" =
and the access_token. There should be an audience for both tokens. The =
audience of the "authentication token" should be the AS, and the =
audience of the access_token should be the data provider the client is =
going to use.
>=20
> So, if there are no network firewall type limitations, it seems much =
simpler to just have the AS use the external IdPs as it's authentication =
mechanisms and the rest is just default OpenID Connect. Meaning that the =
Mobile app starts an OpenID Connect flow with the AS, the AS get the =
user authenticated via the user's IdP, the AS provides access and id =
tokens bask to the Mobile app (following the code or other flow).
>=20
> Am I missing something?
>=20
> Thanks,
> George
>=20
> On 4/20/16 10:31 AM, Fregly, Andrew wrote:
> Hi George,
>=20
> You fully captured one of the options we have been contemplating. I =
didn?t propose this flow because I was looking for a way to solve our =
our use case based on the existing RFCs and OpenID Connect =
specifications with minimal new specification required. That led me to =
the path described in the email response I sent out a little while ago =
to Nat Sakimura?s response. Please take a look at that email and see =
what you think.
>=20
> Given how well stated your summary of our needs was, do you still want =
me to provide a diagram?
>=20
> Thanks,
>  Andy
>=20
> From: George Fletcher >
> Organization: AOL LLC
> Date: Wednesday, April 20, 2016 at 8:49 AM
> To: Andrew Fregly >, =
John Bradley >, =
"oauth@ietf.org" =
>
> Subject: Re: [OAUTH-WG] Building on the protocol in the draft ?OAuth =
2.0 Token Exchange: An STS for the REST of Us? to include Authentication =
Tokens
>=20
> I should probably just wait for the diagram... but not wanting to =
wait... :)
>=20
> If I understand correctly, the user is going to use a client and the =
client will authenticate the user via some IdP using an existing method =
(SAML, LDAP (?), OpenID Connect, etc). The desire is to take that =
response and in some way present it to an "Authorization Server" which =
will validate the "authentication response" and return an access token =
for use at the data provider(s).
>=20
> What if the Authorization Server also took on the role of the OpenID =
Connect provider. This could work by having the client start an OpenID =
Connect flow with Authorization Server (hints could be provided as to =
which IdP the user wants to authenticate at). The AS would look at the =
"idp hint" and either start and SP SAML flow, or present UI for =
collecting LDAP credentials (I don't recommend this) or chain to any =
other proprietary IdP flow. Once the user successfully authenticates =
with the correct IdP, the AS will finish the OpenID Connect flow =
allowing the client to obtain an access token, refresh token and =
id_token. The AS could add to the id_token a claim specifying which IdP =
the user used during the authentication processed.
>=20
> The IdP the user used for authentication could also be encoded in the =
access_token (or returned as part of an introspection call).
>=20
> This way whether the data providers are validating the access_tokens =
locally or using introspection they can obtain the IdP the user used and =
apply their own authorization rules.
>=20
> The user is only required to do one authorization flow for the client =
that is managed by the Authorization Server.
>=20
> Thanks,
> George
>=20
> On 4/19/16 5:06 PM, Fregly, Andrew wrote:
> Thank you for your response George. It points me to some more research =
to do, such as looking at OpenID Connect support for both distributed =
and aggregated claims.
>=20
> Below are replies to your questions/assertions based on my current =
understanding of the various protocols. Further research and advice will =
likely enrich this significantly.
>=20
> Yes, what is required is a verifiable claim that the user is still a =
member of SomeOrg Inc. I have been operating under the assumption that =
the only way this can be done would be to have the user authenticated by =
the Identity Provider for SomeOrg. Perhaps the research into OpenID =
Connect support for distributed and aggregated claims will reveal an =
alternative. I foresee a challenge in dealing with Identity Provider?s =
for organizations using SAML assertions on top of Active Directory and =
LDAP, and which are not going to do any updating to support our needs.
>=20
> We do not expect the user to first go to the data provider. We =
anticipate that the client application would provide a Authentication =
Token to an  Authorization Service service that then issues to the =
client an access token that the data provider will trust. One of our =
reasons for doing it this way is that we are trying to eliminate =
redirects to ease implementation of a native client. We are therefore =
requiring the client to handle authentication with the Identity Provider =
as a separate step from authorization.
>=20
> It might help if I clarified that Verisign?s role in the scenario I =
described is to be just one of many data providers.
>=20
> From: George Fletcher >
> Organization: AOL LLC
> Date: Tuesday, April 19, 2016 at 4:18 PM
> To: Andrew Fregly >, =
John Bradley >, =
"oauth@ietf.org" =
>
> Subject: Re: [OAUTH-WG] Building on the protocol in the draft ?OAuth =
2.0 Token Exchange: An STS for the REST of Us? to include Authentication =
Tokens
>=20
> So if I understand this correctly, what is really required is a =
verifiable claim that the user is still a member of SomeOrg Inc. OpenID =
Connect supports both distributed and aggregated claims that can be =
signed by the appropriate Identity Provider. The point being that I'm =
not sure an "authentication token" is required for this use case to =
succeed, it's just one kind of token that can be used.
>=20
> Also, is the expected flow that the user will first go to the data =
provider and then be directed else where from there? If that is the =
case, the data provider can just be an OpenID Connect relying party and =
give the user an option of the list of supported IdPs to choose from. =
The user will then be redirected to SomeOrg Inc. IdP, authenticate and =
the data provider will have the authorization and recent authentication =
they can validate.
>=20
> Is the user/data flow more complicated than this?
>=20
> Thanks,
> George
>=20
> On 4/19/16 4:05 PM, Fregly, Andrew wrote:
> Thanks for your response John. I also got a good response from Brian =
Campbell and appreciate that. I will respond separately to Brian?s =
response as I think it would keep things clearer to do that.
>=20
> The problem we have for using OpenID Connect is that it combines the =
role of Authentication Service with the role of Authorization Service. =
Perhaps the following description of what we want to do will clarify why =
this won?t work for us:
>=20
> The basic problem statement is that we need to have a client =
application authorized by a Service Provider based on proof that a user =
is currently a member of some organization. This assumes the =
organization has previously established some level of authorized access =
with the Service Provider.
>=20
> Here is an example: Suppose I am a member of SomeOrg Inc. Suppose =
SomeOrg Inc. is doing research that requires it to gather data over the =
Internet from a number of data providers. The data providers require =
authentication and proof of organizational membership in order to =
authorize various levels of access to their data. The data providers do =
not consider having an account with them or a Public Identity Provider =
to be suitable for proving that I am still a member of SomeOrg at time =
of authentication. They would have no way of knowing whether or not my =
relationship with SomeOrg still exists at that time. The data providers =
would therefore like the Client software to authenticate me against =
SomeOrgs Identity Provider. This would be good proof that I am still a =
member of SomeOrg at the time I authenticate. This authentication would =
enable the data providers Authorization Server to grant me access =
appropriate to a member of SomeOrg.  Note that as a prerequisite to all =
of this, So
> meOrg wi
> ll have used an out-of-band process to set up a trust relationship for =
SomeOrg's Identity Provider with the data provider?s Authorization =
Service, and will have negotiated authorization claims to be granted to =
SomeOrgs members.
>=20
> What I am having difficulty with is in knitting together an approach =
based on the he OpenID Connect specifications, SAML specifications, and =
OAuth RFCs and drafts in a way that supports the above use case =
end-to-end. The OAuth RFCs and drafts almost get me there. What seems to =
be missing is a way of telling an Identity Provider the URL for the =
Authorization Service (the required Audience claim in an authentication =
assertion as defined in RFCs 7251, 7252 and 7253), and then a =
requirement that the Identity Providers put the supplied Audience =
Identifier into Authentication Tokens. Perhaps a little further =
back-and-forth with Brian will resolve this.
>=20
> I can go into deeper detail if needed. If this is off-topic for the =
OAuth working group, let me know.
>=20
> Thanks,
> Andrew Fregly
> Verisign Inc.
>=20
>=20
> From: John Bradley =
<ve7jtb@ve7jtb.com>
> Date: Tuesday, April 19, 2016 at 2:06 PM
> To: Andrew Fregly =
<afregly@verisign.com>
> Cc: "oauth@ietf.org" =
>
> Subject: Re: [OAUTH-WG] Building on the protocol in the draft ?OAuth =
2.0 Token Exchange: An STS for the REST of Us? to include Authentication =
Tokens
>=20
> Looking at OpenID Connect and it?s trust model for producing id_tokens =
that assert identity may help you.
> http://openid.net/wg/connect/
>=20
> Unfortunately I can?t quite make out what you are trying to do.
>=20
> It sort of sounds like you want an id_token from a idP and then have =
the client exchange that assertion for another token?
>=20
> John B.
> On Apr 19, 2016, at 1:18 PM, Fregly, Andrew =
<afregly@verisign.com> wrote:
>=20
> I have a use case where a client application needs to authenticate =
with a dynamically determined Identity Provider that is separate from =
the Authorization Service that will be used issue an access token to the =
client. The use case also requires that as part of authorization, the =
client provides to the Authorization Service an authentication token =
signed by an Identity Provider that the Authorization Service has a =
trust relationship with. The trust relationship is verifiable based on =
the Authorization Service having recorded the public keys or =
certificates of trusted Identity Providers in a trust store, this =
allowing the Authorization Service to verify an Identity Provider?s =
signature on an authentication token.
>=20
> In looking at the various OAuth RFCs, particularly RFCs 7521, 7522, =
and 7523, I see that they get me close in terms of supporting the use =
case. What is missing is a means for solving the following problem. =
These RFCs require that the Identity Provider put an Audience claim in =
the authentication token. The problem with this is that I do not see in =
the RFCs how the Identity Provider can be told who the Audience is to =
put into the authentication token. This leads me to the title of this =
message. The draft ?OAuth 2.0 Token Exchange: An STS for the REST of Us? =
defines a mechanism for identifying the Audience for an STS to put into =
a token it generates. That would solve my problem except that the draft =
limits the type of STS to being Authorization Servers. What is needed is =
this same capability for interacting with an Identity Provider. This =
would enable RFCs 7521, 7522 and 7523 to be useful in situation where =
the Identity Provider needs to be told the identity of the Authorization
> Service
> .
>=20
> I am new to interacting with the IETF. I also am not an expert on the =
RFCs or prior history of the OAuth group relative to this topic, so =
please point me to any existing solution if this is a solved problem. =
Otherwise, I would like to get feedback on my suggestion.
>=20
> Thanks You,
>=20
> Andrew Fregly
> Verisign Inc.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> =
https://www.ietf.org/mailman/=
listinfo/oauth
>=20
>=20
>=20
>=20
> _______________________________________________
> OAuth mailing list
> =
OAuth@ietf.orghttps://www.ietf.org/mailman/listinfo=
/oauth
>=20
>=20
>=20
>=20
> --
> Chief Architect
> Identity Services Engineering     Work: =
george.fletcher@teamaol.com
> AOL Inc.                          AIM:  gffletch
> Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
> Office: +1-703-265-2544           Photos: =
http://georgefletcher.photography
>=20
>=20
>=20
> _______________________________________________
> OAuth mailing list
> =
OAuth@ietf.orghttps://www.ietf.org/mailman/listinfo=
/oauth
>=20
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: =

>=20
> ------------------------------
>=20
> Subject: Digest Footer
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>=20
>=20
> ------------------------------
>=20
> End of OAuth Digest, Vol 91, Issue 3
> ************************************


From nobody Sat Jul 30 16:32:16 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8E512D0C0 for ; Sat, 30 Jul 2016 16:32:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=herberg.name
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 sah7T51KX-IM for ; Sat, 30 Jul 2016 16:32:10 -0700 (PDT)
Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24B5912B057 for ; Sat, 30 Jul 2016 16:32:10 -0700 (PDT)
Received: by mail-io0-x230.google.com with SMTP id 38so158650723iol.0 for ; Sat, 30 Jul 2016 16:32:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=znnqsQzAzz/CbR/SSz9lJvi18gsWBYs7rqFUnbO+9Uc=; b=pcQHX0KIPxBAQOovpt1gN22S8NwBSejDArPdnHqeQIUb6JIswZtDh8oKl063h9RaTx nOHbZS7zWBJCbgGhf1WAo3poHOkdhmWPZ8IHRVnivxcq9WOREZE1GlDbm4eVYoBtF4+L PmUv5A6r8CnYPOhXVBKKOhD3yeh83AGcuEYC4=
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=znnqsQzAzz/CbR/SSz9lJvi18gsWBYs7rqFUnbO+9Uc=; b=ECcF881/OABd4jLcq74Jf9Jn4b0gwScnE//6R2BgEbPTVcjNCwPoZ0kuNKmUw/qrGp ekB0Kbr406FOv7lpxzRcWhxztja/12YWjz06vzxIukCmQ7q97d+dwSiaTfNHkPyy0qf2 CPLCbPeSFAE11SM6rkan9BJK12LhboYbcLTFGtd14KJDCzHDI1Br66zbZb2/rrWMytWJ 2GRkA0eK8IIaH3RtbTqtc/uqyDentVjbq+hmmF5/BfpjVJ1rhhfJgGb+6mJJNGBFsmju SptfuAt6QTji2Op+NNKEMnmw51TqEh1b4BIhuLfUUHThXZxhwMoJQMoCY74Vttq4FXFa chzg==
X-Gm-Message-State: AEkoousoDArgEGUTG8EeaZu0U0/U7Iro/OiKDq/0uhOb2tO1/cD4P79EooIOHxuZss6rmPIquwyYfBACQ2KBUA==
X-Received: by 10.107.3.35 with SMTP id 35mr50425078iod.40.1469921529425; Sat, 30 Jul 2016 16:32:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.36.23.88 with HTTP; Sat, 30 Jul 2016 16:32:08 -0700 (PDT)
In-Reply-To: <57908256.7090107@gmx.net>
References: <57908256.7090107@gmx.net>
From: Ulrich Herberg 
Date: Sat, 30 Jul 2016 16:32:08 -0700
Message-ID: 
To: Hannes Tschofenig 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Working Group Last Call on "OAuth 2.0 for Native Apps"
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 30 Jul 2016 23:32:12 -0000

Hannes,

I think this is a good document and support it. Still, I asked
questions that have never been responded to on this list:
https://www.ietf.org/mail-archive/web/oauth/current/msg16293.html

Is it possible to address my comments during the WGLC?

Best regards
Ulrich

On Thu, Jul 21, 2016 at 1:05 AM, Hannes Tschofenig
 wrote:
> Hi all,
>
> William has submitted an update, as promised during the OAuth WG session
> on Monday. Hence, we will start a Last Call for comments on the "OAuth
> 2.0 for Native Apps"  specification.
>
> The document can be found here:
> https://tools.ietf.org/html/draft-ietf-oauth-native-apps-03
>
> Please have your comments in no later than August 8th.
>
> Ciao
> Hannes & Derek
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>


From nobody Sun Jul 31 11:24:46 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88EA912B024 for ; Sun, 31 Jul 2016 11:24:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level: 
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 OAZKRRDpFvdM for ; Sun, 31 Jul 2016 11:24:43 -0700 (PDT)
Received: from p3plsmtpa08-08.prod.phx3.secureserver.net (p3plsmtpa08-08.prod.phx3.secureserver.net [173.201.193.109]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4744812B011 for ; Sun, 31 Jul 2016 11:24:43 -0700 (PDT)
Received: from [192.168.19.126] ([109.160.89.229]) by p3plsmtpa08-08.prod.phx3.secureserver.net with  id RWQg1t0064wu8xH01WQhjZ; Sun, 31 Jul 2016 11:24:42 -0700
To: "oauth@ietf.org" 
From: Vladimir Dzhuvinov 
Organization: Connect2id Ltd.
Message-ID: 
Date: Sun, 31 Jul 2016 21:24:39 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080104050308000701090909"
Archived-At: 
Subject: [OAUTH-WG] Comments on draft-ietf-oauth-jwsreq-07: Support for other grants, charset
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 31 Jul 2016 18:24:44 -0000

This is a cryptographically signed message in MIME format.

--------------ms080104050308000701090909
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

I have a few comments on the signed requests draft:

1. Have there been thoughts on extending the request JWT concept to
other grant types, e.g. password and client_credentials? The ability to
seal selected request parameters could prove useful there too.

2. The SHA-256 hash is computed over the "resource contents", i.e. not
over the JWT [1]. Does this mean that line breaks and white space
intended for improving human readability is OK? Perhaps this should be
mentioned explicitly.

3. I see that no particular charset for the resource contents referenced
by the request_uri is mandated, and there is no mention that the web
server should indicate the charset. I suppose this was meant to make JWT
deployments / uploads easier. However, this may also lead to problems if
the AS tries to validate the SHA-256 hash and doesn't know what charset
was used (is anyone actually expected to be validating the fragment if
present?) JWT (RFC 7519) is explicit on UTF-8 though.


Thanks,

Vladimir

[1] https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-07#section-4.2

--=20
Vladimir Dzhuvinov



--------------ms080104050308000701090909
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
Fw0xNjA3MzExODI0MzlaMC8GCSqGSIb3DQEJBDEiBCAV+Ih7OQLAI97d5UGhFS1R3etYRnDs
RX1dB0OA6ssJQzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw
CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD
VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP
TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQbyALwckZ9IF6bQSWzWYN4zCBwwYLKoZI
hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw
PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy
ZSBFbWFpbCBDQQIQbyALwckZ9IF6bQSWzWYN4zANBgkqhkiG9w0BAQEFAASCAQBqulbSASyS
1t/JFKWCmBMtv7SSb6/jioxVtY9RkysDkQpZ9kKMusDK/50bXp5s+ki5F2BZecNZiLGukC5z
miLzAIAVTIYpjbnY+slQMCnNU6x0inG6kGKG36O5etA8lauhICfOVxgPzUkwZLgXgF41bDgi
Wg3hdp+79LUWZ6x6Xcsv1tVTJhpskvKQKAqZhtA9QDQS4UZYytQBn3e5B9WixJDm1dTj620j
o2j4DpwYhyzMG8yuqSkS5QiD3zQgKnwSWy28HS4h6P0QBsaDBhmpqcjku3SHA5YkPyBg6C9m
REDZp6ppGsDPlxFDF/fUpzfk9oMNCLavt/yfVxRLuch7AAAAAAAA
--------------ms080104050308000701090909--


From nobody Sun Jul 31 22:59:45 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB6E712D1AF for ; Sun, 31 Jul 2016 22:59:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 uXuGlcMasNQb for ; Sun, 31 Jul 2016 22:59:41 -0700 (PDT)
Received: from nrifs04.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E92912D176 for ; Sun, 31 Jul 2016 22:59:40 -0700 (PDT)
Received: from nriea03.index.or.jp (unknown [172.19.246.38]) by nrifs04.index.or.jp (Postfix) with SMTP id BF7C1472EE2; Mon,  1 Aug 2016 14:59:39 +0900 (JST)
Received: from nrims00b.nri.co.jp ([192.50.135.12]) by nriea03.index.or.jp (unknown) with ESMTP id u715xdPU017355; Mon, 1 Aug 2016 14:59:39 +0900
Received: from nrims00b.nri.co.jp (localhost.localdomain [127.0.0.1]) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id u715xdQ7003821; Mon, 1 Aug 2016 14:59:39 +0900
Received: (from mailnull@localhost) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id u715xddS003820; Mon, 1 Aug 2016 14:59:39 +0900
X-Authentication-Warning: nrims00b.nri.co.jp: mailnull set sender to n-sakimura@nri.co.jp using -f
Received: from nrizmf13.index.or.jp ([172.100.25.22]) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id u715xdjh003817; Mon, 1 Aug 2016 14:59:39 +0900
From: "Nat Sakimura" 
To: "'Vladimir Dzhuvinov'" , 
References: 
In-Reply-To: 
Date: Mon, 1 Aug 2016 14:59:49 +0900
Message-ID: <025d01d1ebb9$ea22c780$be685680$@nri.co.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQCUCnPrB/lmDBZmQmXc5SEqnRGKH6KvW8jQ
X-MailAdviser: 20141126
Content-Language: ja
Archived-At: 
Subject: Re: [OAUTH-WG] Comments on draft-ietf-oauth-jwsreq-07: Support for other grants, charset
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 01 Aug 2016 05:59:44 -0000

Thanks Vladmir,=20

Here are my answers to your comments:=20

A1. No, we have not thought about it. Interesting idea though.=20
A2. "Resource content" here means the binary response that you get from =
the URI.=20
    This mechanism was put in here to enforce that different response =
from the=20
    request_uri will mean different URI. Perhaps, we should just say =
that=20
    if the content is changed, the URI MUST change.=20
A3. Content of the request_uri MUST be a request object, which is a JWT, =

    which is UTF-8.=20

Cheers,=20

Nat
--
PLEASE READ :This e-mail is confidential and intended for the
named recipient only. If you are not an intended recipient,
please notify the sender  and delete this e-mail.


-----Original Message-----
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Vladimir =
Dzhuvinov
Sent: Monday, August 1, 2016 3:25 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Comments on draft-ietf-oauth-jwsreq-07: Support for =
other grants, charset

I have a few comments on the signed requests draft:

1. Have there been thoughts on extending the request JWT concept to =
other grant types, e.g. password and client_credentials? The ability to =
seal selected request parameters could prove useful there too.

2. The SHA-256 hash is computed over the "resource contents", i.e. not =
over the JWT [1]. Does this mean that line breaks and white space =
intended for improving human readability is OK? Perhaps this should be =
mentioned explicitly.

3. I see that no particular charset for the resource contents referenced =
by the request_uri is mandated, and there is no mention that the web =
server should indicate the charset. I suppose this was meant to make JWT =
deployments / uploads easier. However, this may also lead to problems if =
the AS tries to validate the SHA-256 hash and doesn't know what charset =
was used (is anyone actually expected to be validating the fragment if
present?) JWT (RFC 7519) is explicit on UTF-8 though.


Thanks,

Vladimir

[1] https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-07#section-4.2

--
Vladimir Dzhuvinov




Thank you, James, for the review =
and feedback. I apologize for the slow reply - on top of being a busy week =
this was a difficult one to respond to.

It's disappointing=
 to hear that it came off as conceited. That certainly wasn't the inten=
t (though I suppose it rarely is). 

While I think there's =
plenty of precedent in things calling themselves lightweight, whether or no=
t it's justified, and do believe this is light enough to warrant the us=
e of the term, I am open to dropping "heavyweight" and "ligh=
tweight", if you think it would improve the tone of the text.

<=
/div>The title is something I'm less open to changes on. Honestly, I=
9;m really partial to it. I described it as "really really important&q=
uot; on slide 7 of the IETF 93 presentation about token=
 exchange and tried to brake it down humorously in a recent identity conference presentation. I've had numerous positive comments about it from people who apprec=
iate the little touch of humor. I anticipate there may be some push-back in=
 later stage reviews on the unexpanded acronym but I'll cross that brid=
ge when/if I come to it and look to find some compromise. 

The=
 "access_token" member/parameter is required per RFC 6749 so it h=
as to be in the response anyway and seemed like a suitable bucket for the r=
eturned token even when the token isn't strictly an access token. What&=
#39;s an alternative, putting some dummy value in "access_token" =
and returning the requested token under a different name? You mention ID To=
kens, which is a potentially interesting case as there's already sort o=
f a way to additionally request an ID Token by using the "openid"=
 scope. Perhaps there should be some discussion or guidance on that? I thin=
k that might even be helpful for something Tony has made statements about (=
maybe). 

Generally I think that it's a little too lat=
e to be changing parameter names like xxxx_token_type to xxxx_token_context=
. Unless there's overwhelming support from others for such a change. I =
do think the way that you've articulated the distinction between tokens=
 from other parties and tokens from this AS is useful and I'll endeavor=
 to add and/or adjust some text along those lines to further clarify. 
<=
/div>







On Sun, Jul 10, 2016 at 8:13 PM, Manger, James <James.H.M=
anger@team.telstra.com> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0: OAuth 2.0 Token Exchange: An STS for the REST of Us

> https://tools.ietf.org/htm=
l/draft-ietf-oauth-token-exchange-05



This spec has some useful functionality, but comes across as a tad conceite=
d.



Suggestions:



1. Drop "An STS for the REST of Us" from the title.

"STS" is not common enough to be unexpanded. The protocol isn'=
;t a poster-child for RESTful design; as the 3rd paragraph of the introduct=
ion explicitly says ("the STS protocol defined in this specification i=
s not itself RESTful"). Hopefully it is easier for developers than the=
 WS-* suite, but it is from some of the same companies and for some similar=
 purposes so "for the rest of us" doesn't really ring true (t=
hough it is a cute play on words).



2. Drop "lightweight" from the abstract.

Stick to the facts: an HTTP+JWT+JSON-based STS, as an alternative to an HTT=
P+SOAP+XML-based STS.



3. Drop "heavyweight" and "lightweight" from the introd=
uction.

FROM:

=C2=A0 =C2=A0Web Service clients have used WS-Trust

=C2=A0 =C2=A0[WS-Trust] as the protocol to interact with an STS for token
=C2=A0 =C2=A0exchange, however WS-Trust is a fairly heavyweight protocol, w=
hich

=C2=A0 =C2=A0uses XML, SOAP, etc.=C2=A0 Whereas, the trend in modern Web de=
velopment

=C2=A0 =C2=A0has been towards lightweight services utilizing RESTful patter=
ns and

=C2=A0 =C2=A0JSON.

=C2=A0 =C2=A0... This specification defines a lightweight protocol extendin=
g OAuth 2.0

TO:

=C2=A0 =C2=A0Web Service clients have used WS-Trust

=C2=A0 =C2=A0[WS-Trust] as the protocol to interact with an STS for token
=C2=A0 =C2=A0exchange. While WS-Trust

=C2=A0 =C2=A0uses XML and SOAP, the trend in modern Web development

=C2=A0 =C2=A0has been towards RESTful patterns and

=C2=A0 =C2=A0JSON.

=C2=A0 =C2=A0... This specification defines a protocol extending OAuth 2.0<=
br>


Requiring "only an HTTP client and JSON parser" is nice for some =
developers over requiring an XML/SOAP parser. But to warrant the "ligh=
tweight" tag the spec need to mention major design ideas from WS-Trust=
 that are deliberately dropped from OAuth-2.0-Token-Exchange (and will not =
need to be added later).





4. Do we really need to put a non-access-token (eg an id-token) in a field =
named "access_token", then override that with "issued_token_=
type":"urn:ietf:params:oauth:token-type:id_token"?



5. I'm suspect I'm far too late to the party to comment on token_ty=
pe vs {subject|requested|actor|issued}_token_type, but surely we can do bet=
ter than create the confusion in this spec. I think the issue is that we wa=
nt to support tokens from other parties and tokens from this AS. For the fo=
rmer we need to indicate the syntax (eg JWT or SAML) so the AS can parse it=
; for the latter we need to indicate what the AS issued it for (eg access_t=
oken or refresh_token) so the AS can look it up in the correct DB.



SUGGESTION: Rename xxxx_token_type to xxxx_token_context.



=C2=A0 =C2=A0subject_token_context

=C2=A0 =C2=A0 =C2=A0 REQUIRED. An identifier of either:

=C2=A0 =C2=A0 =C2=A0 the syntax of the token (when issued from another AS) =
so the AS knows how to parse it;

=C2=A0 =C2=A0 =C2=A0 or the sort of token it is (when issued by this AS). S=
ee section 3.



Adjust other xxxx_token_context definitions, and section 3.



--

James Manger




_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





--001a1146ec4e2ceea20537b295c6--


From nobody Fri Jul 15 14:14:24 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1783212D5AB for ; Fri, 15 Jul 2016 14:14:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=samwhited.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 iKEN8teJWKGD for ; Fri, 15 Jul 2016 14:14:21 -0700 (PDT)
Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99F4712D9A5 for ; Fri, 15 Jul 2016 14:14:21 -0700 (PDT)
Received: by mail-qk0-x233.google.com with SMTP id s63so112913010qkb.2 for ; Fri, 15 Jul 2016 14:14:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samwhited.com; s=swgoo; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=yl3ysNkx6PxtIlCptT6+8qPrnfQSss1vLqGnswUU0sE=; b=BQ+s51oN/S7Y1OSDN6/8sM/B9e2bcQkmMqM5OOVh+PbhoqfSVTy82mw7PzTy25uNLG Zx64Kc6RTrCPrLCmwhxv7LWnl0BlmSN6VW7YPWUW9dJsRkIDns4j7RnwS0YwikvmMn1i KIG4gVfKVQhHG/Y3KjlkI3E8C4hDgQI2r/o3k=
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:content-transfer-encoding; bh=yl3ysNkx6PxtIlCptT6+8qPrnfQSss1vLqGnswUU0sE=; b=CPbev6yEG9s7ihKqzb57jYHR+y3Q7UMdIgAW2n/mpbTzlcC8m6jDVK6J5sgts2WgQ7 xbbEeERglxHuEvh9aBzj2bL44xmx4THruyPOKgvbP0ev8upZvHTaxn9E85Ut2/wIBJ2m BmLW4EboLTFOu2w5PhSdIQglku//n6SWLCOJRAPiYMZ+HtRBapuQbe0Lk1UaTWzOSRHM Ntpt9uiUYmCMOtnPjWInLhzU4rwa9wVTo9mogeHY/zKUxCqktbLm1CK46ugR69cIz9yV YcdDTfbaX8LBG33KHue0y3G/V8btulpComOocpgoNU8TnF+Jfedj/X3x4QY3pRFqDEAp EPcw==
X-Gm-Message-State: ALyK8tJSRFvQPovf0201+UZRVzx/youOj2ixBZdkYPIoa5UsCeHIRIvn9/E53yvniyyL3icwOX1m+93nltx4Rw==
X-Received: by 10.55.178.195 with SMTP id b186mr25802688qkf.81.1468617260732;  Fri, 15 Jul 2016 14:14:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.203.9 with HTTP; Fri, 15 Jul 2016 14:13:41 -0700 (PDT)
X-Originating-IP: [72.48.156.244]
In-Reply-To: 
References: <20160708101903.32067.39351.idtracker@ietfa.amsl.com> <255B9BB34FB7D647A506DC292726F6E13BD67E62B2@WSMSG3153V.srv.dir.telstra.com> 
From: Sam Whited 
Date: Fri, 15 Jul 2016 16:13:41 -0500
Message-ID: 
To: Brian Campbell 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-05.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jul 2016 21:14:23 -0000

Hi all,

Longtime reader / implementer, first time poster. I wanted to comment
specifically on the question of the title:

On Fri, Jul 15, 2016 at 3:36 PM, Brian Campbell
 wrote:
> The title is something I'm less open to changes on. Honestly, I'm really
> partial to it. I described it as "really really important" on slide 7 of =
the
> IETF 93 presentation about token exchange and tried to brake it down
> humorously in a recent identity conference presentation. I've had numerou=
s
> positive comments about it from people who appreciate the little touch of
> humor. I anticipate there may be some push-back in later stage reviews on
> the unexpanded acronym but I'll cross that bridge when/if I come to it an=
d
> look to find some compromise.

While I too appreciate the little touch of humor, the point the RFC
process is not humor, the point is to make something that conveys
information in an accessible and unambiguous way. I did not know the
acronym "STS" when I first glanced at this title, and even if I did
know the acronym I'm not sure that the title would immediately convey
what the document was about in its current form. This will be
detrimental to the accessibility of the document if non-expert users
have to go perform an internet search for an acronym before they've
even begun to read the document.

RFCs are generally a bit dry and sprucing them up with a bit can be
tempting. I appreciate that the joke is clever =E2=80=94 but the less of ou=
r
own quirky and fun personalities we put into RFCs the better it will
be for the series and the clearer they will be for the developers who
will have to implement them.

Thanks,
Sam



--=20
Sam Whited
pub 4096R/54083AE104EA7AD3


From nobody Fri Jul 15 14:56:20 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1441812D67A for ; Fri, 15 Jul 2016 14:56:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.506
X-Spam-Level: 
X-Spam-Status: No, score=-5.506 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.287, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVGWoGKPxLLA for ; Fri, 15 Jul 2016 14:56:12 -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 9915712D592 for ; Fri, 15 Jul 2016 14:56:12 -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 u6FLuBpm007205 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 15 Jul 2016 21:56: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 u6FLuAj0012271 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 15 Jul 2016 21:56:11 GMT
Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u6FLu97N030953; Fri, 15 Jul 2016 21:56:10 GMT
Received: from dhcp-whq-twvpn-2-vpnpool-10-159-173-89.vpn.oracle.com (/10.159.173.89) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 15 Jul 2016 14:56:09 -0700
Content-Type: multipart/alternative; boundary="Apple-Mail=_FB6AB2F8-607B-4634-9D6D-636A928AEB90"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Phil Hunt 
In-Reply-To: 
Date: Fri, 15 Jul 2016 14:56:07 -0700
Message-Id: <6AC90FA1-71C2-4DB6-BAA3-EB28ED5B8946@oracle.com>
References: <20160708101903.32067.39351.idtracker@ietfa.amsl.com> <255B9BB34FB7D647A506DC292726F6E13BD67E62B2@WSMSG3153V.srv.dir.telstra.com>  
To: Sam Whited 
X-Mailer: Apple Mail (2.3124)
X-Source-IP: aserv0021.oracle.com [141.146.126.233]
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-05.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jul 2016 21:56:18 -0000

--Apple-Mail=_FB6AB2F8-607B-4634-9D6D-636A928AEB90
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I agree. The title was useful as a working title as it conveyed a lot of =
useful intent information to members of the WG familiar with the =
technology.

I don=E2=80=99t think the broader community understands OASIS and the =
broader realm nor should they care.

At minimum it suggests they need to go read about STS=E2=80=99s before =
implementing the draft - which should not be needed.

Phil

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






> On Jul 15, 2016, at 2:13 PM, Sam Whited  wrote:
>=20
> Hi all,
>=20
> Longtime reader / implementer, first time poster. I wanted to comment
> specifically on the question of the title:
>=20
> On Fri, Jul 15, 2016 at 3:36 PM, Brian Campbell
>  wrote:
>> The title is something I'm less open to changes on. Honestly, I'm =
really
>> partial to it. I described it as "really really important" on slide 7 =
of the
>> IETF 93 presentation about token exchange and tried to brake it down
>> humorously in a recent identity conference presentation. I've had =
numerous
>> positive comments about it from people who appreciate the little =
touch of
>> humor. I anticipate there may be some push-back in later stage =
reviews on
>> the unexpanded acronym but I'll cross that bridge when/if I come to =
it and
>> look to find some compromise.
>=20
> While I too appreciate the little touch of humor, the point the RFC
> process is not humor, the point is to make something that conveys
> information in an accessible and unambiguous way. I did not know the
> acronym "STS" when I first glanced at this title, and even if I did
> know the acronym I'm not sure that the title would immediately convey
> what the document was about in its current form. This will be
> detrimental to the accessibility of the document if non-expert users
> have to go perform an internet search for an acronym before they've
> even begun to read the document.
>=20
> RFCs are generally a bit dry and sprucing them up with a bit can be
> tempting. I appreciate that the joke is clever =E2=80=94 but the less =
of our
> own quirky and fun personalities we put into RFCs the better it will
> be for the series and the clearer they will be for the developers who
> will have to implement them.
>=20
> Thanks,
> Sam
>=20
>=20
>=20
> --=20
> Sam Whited
> pub 4096R/54083AE104EA7AD3
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_FB6AB2F8-607B-4634-9D6D-636A928AEB90
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

I agree. The title was useful as a working title as it =
conveyed a lot of useful intent information to members of the WG =
familiar with the technology.

I don=E2=80=99t think the broader community understands OASIS =
and the broader realm nor should they care.

At minimum it suggests they need to go =
read about STS=E2=80=99s before implementing the draft - which should =
not be needed.








On Jul 15, 2016, at 2:13 PM, Sam Whited <sam@samwhited.com> =
wrote:

Hi all,

Longtime reader / =
implementer, first time poster. I wanted to comment
specifically on the question of the title:

On Fri, Jul 15, 2016 at 3:36 PM, Brian Campbell
<bcampbell@pingidentity.com> wrote:
The title is something =
I'm less open to changes on. Honestly, I'm really
partial =
to it. I described it as "really really important" on slide 7 of the
IETF 93 presentation about token exchange and tried to brake =
it down
humorously in a recent identity conference =
presentation. I've had numerous
positive comments about it =
from people who appreciate the little touch of
humor. I =
anticipate there may be some push-back in later stage reviews on
the unexpanded acronym but I'll cross that bridge when/if I =
come to it and
look to find some compromise.

While I too appreciate the little =
touch of humor, the point the RFC
process is not humor, =
the point is to make something that conveys
information in =
an accessible and unambiguous way. I did not know the
acronym "STS" when I first glanced at this title, and even if =
I did
know the acronym I'm not sure that the title would =
immediately convey
what the document was about in its =
current form. This will be
detrimental to the =
accessibility of the document if non-expert users
have to =
go perform an internet search for an acronym before they've
even begun to read the document.

RFCs are generally a bit dry and sprucing them up with a bit =
can be
tempting. I appreciate that the joke is clever =E2=80=
=94 but the less of our
own quirky and fun personalities =
we put into RFCs the better it will
be for the series and =
the clearer they will be for the developers who
will have =
to implement them.

Thanks,
Sam



-- 
Sam Whited
pub =
4096R/54083AE104EA7AD3

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

=

--Apple-Mail=_FB6AB2F8-607B-4634-9D6D-636A928AEB90--


From nobody Sat Jul 16 07:43:26 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AAF212D60D for ; Sat, 16 Jul 2016 07:43:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.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 rw8Z31MnwL7d for ; Sat, 16 Jul 2016 07:43:23 -0700 (PDT)
Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::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 2868512D529 for ; Sat, 16 Jul 2016 07:43:23 -0700 (PDT)
Received: by mail-io0-x229.google.com with SMTP id q83so127789895iod.1 for ; Sat, 16 Jul 2016 07:43:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=468j8R2r5RAs4kDaAEzw2VKDRMHoOeMk66E4vcvIIaE=; b=FmZl5SFZ10Gkoqrh/3k+TbGgbvu7mg57y+xOQsiXvEZMn/EBvfOV4dk2JbsjwBkK+m xtlTXAx3z9mwpCe0LKuy2eRD6fCc0PXOQzF8HAkVU6CyXmwHW1SREIyd5B53EcSQoTJb qcd0MpPS73Hy1RwlORSFTKBZoiF3BnxVeFJ80=
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=468j8R2r5RAs4kDaAEzw2VKDRMHoOeMk66E4vcvIIaE=; b=EduK7wPCfEPmfHqbaBVb5ooMUonSYh18wFeZvbER67vS4GXdqevEvyHAgYs6rwyObI lqenu8eMq7aE8p/jM9cPWaRgSu7/DgfCDQn0YHVpiFENBoKQqGGq3WU7Hy+G4dd9eLq7 /m8Y4CD0x44kmLdrvTGI1d+6zk7wqz+Zgw1cKUDQd6MqnShOSj0v8z9KJGSRLJrCH4hD 4Va3j+XqWnN7pr7o0HY03TSNclRufmVNb/+zfjA8mvehNQjF9InsE50nHXNtG4F9PrXH vXWYqHjkXnNIrI+gIQgte5qCpGyg1fPQ3bZ5n5BGCaIqi/mtBQLDTblgM0nmxBlOEUSQ mBcQ==
X-Gm-Message-State: ALyK8tKKrhvlM8Ge5DRhV6hmEr4P7lgpDJJvIJH2PNKgb02ozKj3j5Jc/k9+HZfGMjCOlc34xRgCNTN5KBV1/MD4
X-Received: by 10.107.50.19 with SMTP id y19mr25315437ioy.174.1468680202523; Sat, 16 Jul 2016 07:43:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.79.28.149 with HTTP; Sat, 16 Jul 2016 07:42:53 -0700 (PDT)
In-Reply-To: <6AC90FA1-71C2-4DB6-BAA3-EB28ED5B8946@oracle.com>
References: <20160708101903.32067.39351.idtracker@ietfa.amsl.com> <255B9BB34FB7D647A506DC292726F6E13BD67E62B2@WSMSG3153V.srv.dir.telstra.com>   <6AC90FA1-71C2-4DB6-BAA3-EB28ED5B8946@oracle.com>
From: Brian Campbell 
Date: Sat, 16 Jul 2016 08:42:53 -0600
Message-ID: 
To: Phil Hunt 
Content-Type: multipart/alternative; boundary=001a114469c4c2acdb0537c1c157
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-05.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Jul 2016 14:43:25 -0000

--001a114469c4c2acdb0537c1c157
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Et tu, Phil?

Do Sam and Phil represent the general consensus here or a vocal minority?

On Fri, Jul 15, 2016 at 3:56 PM, Phil Hunt  wrote:

> I agree. The title was useful as a working title as it conveyed a lot of
> useful intent information to members of the WG familiar with the technolo=
gy.
>
> I don=E2=80=99t think the broader community understands OASIS and the bro=
ader
> realm nor should they care.
>
> At minimum it suggests they need to go read about STS=E2=80=99s before
> implementing the draft - which should not be needed.
>
> Phil
>
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>
>
>
>
>
> On Jul 15, 2016, at 2:13 PM, Sam Whited  wrote:
>
> Hi all,
>
> Longtime reader / implementer, first time poster. I wanted to comment
> specifically on the question of the title:
>
> On Fri, Jul 15, 2016 at 3:36 PM, Brian Campbell
>  wrote:
>
> The title is something I'm less open to changes on. Honestly, I'm really
> partial to it. I described it as "really really important" on slide 7 of
> the
> IETF 93 presentation about token exchange and tried to brake it down
> humorously in a recent identity conference presentation. I've had numerou=
s
> positive comments about it from people who appreciate the little touch of
> humor. I anticipate there may be some push-back in later stage reviews on
> the unexpanded acronym but I'll cross that bridge when/if I come to it an=
d
> look to find some compromise.
>
>
> While I too appreciate the little touch of humor, the point the RFC
> process is not humor, the point is to make something that conveys
> information in an accessible and unambiguous way. I did not know the
> acronym "STS" when I first glanced at this title, and even if I did
> know the acronym I'm not sure that the title would immediately convey
> what the document was about in its current form. This will be
> detrimental to the accessibility of the document if non-expert users
> have to go perform an internet search for an acronym before they've
> even begun to read the document.
>
> RFCs are generally a bit dry and sprucing them up with a bit can be
> tempting. I appreciate that the joke is clever =E2=80=94 but the less of =
our
> own quirky and fun personalities we put into RFCs the better it will
> be for the series and the clearer they will be for the developers who
> will have to implement them.
>
> Thanks,
> Sam
>
>
>
> --
> Sam Whited
> pub 4096R/54083AE104EA7AD3
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>

--001a114469c4c2acdb0537c1c157
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Et tu, Phil?

Do Sam and Phil represent t=
he general consensus here or a vocal minority?=C2=A0 

On Fri, Jul 15, 2016 at 3:5=
6 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
I agree. The tit=
le was useful as a working title as it conveyed a lot of useful intent info=
rmation to members of the WG familiar with the technology.

I don=E2=80=99t think the broader community understands OASIS and the br=
oader realm nor should they care.

At minimum it su=
ggests they need to go read about STS=E2=80=99s before implementing the dra=
ft - which should not be needed.



On Jul 15, 2=
016, at 2:13 PM, Sam Whited <sam@samwhited.com> wrote:

Hi all,

Longtime reader / implementer, first=
 time poster. I wanted to comment
specifically on the question of the ti=
tle:

On Fri, Jul 15, 2016 at 3:36 PM, Brian Campbell
<bcampbell@pingiden=
tity.com> wrote:
The title is something=
 I'm less open to changes on. Honestly, I'm really
partial to it=
. I described it as "really really important" on slide 7 of theIETF 93 presentation about token exchange and tried to brake it down
h=
umorously in a recent identity conference presentation. I've had numero=
us
positive comments about it from people who appreciate the little touc=
h of
humor. I anticipate there may be some push-back in later stage revi=
ews on
the unexpanded acronym but I'll cross that bridge when/if I c=
ome to it and
look to find some compromise.

While I =
too appreciate the little touch of humor, the point the RFC
process is n=
ot humor, the point is to make something that conveys
information in an =
accessible and unambiguous way. I did not know the
acronym "STS&quo=
t; when I first glanced at this title, and even if I did
know the acrony=
m I'm not sure that the title would immediately convey
what the docu=
ment was about in its current form. This will be
detrimental to the acce=
ssibility of the document if non-expert users
have to go perform an inte=
rnet search for an acronym before they've
even begun to read the doc=
ument.

RFCs are generally a bit dry and sprucing them up with a bit =
can be
tempting. I appreciate that the joke is clever =E2=80=94 but the =
less of our
own quirky and fun personalities we put into RFCs the better=
 it will
be for the series and the clearer they will be for the develope=
rs who
will have to implement them.

Thanks,
Sam


-- 
Sam Whited
pub 4096R/54083AE104EA7AD3

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




--001a114469c4c2acdb0537c1c157--


From nobody Sun Jul 17 04:44:36 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57204126579 for ; Sun, 17 Jul 2016 04:44:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.487
X-Spam-Level: 
X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, 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 U34iKG7_k1CM for ; Sun, 17 Jul 2016 04:44:33 -0700 (PDT)
Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (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 B3E2012B031 for ; Sun, 17 Jul 2016 04:44:32 -0700 (PDT)
X-AuditID: 12074425-a2fff7000000600a-9c-578b6f9fd077
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 53.2B.24586.F9F6B875; Sun, 17 Jul 2016 07:44:31 -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 u6HBiUeh021382; Sun, 17 Jul 2016 07:44:30 -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 u6HBiSlB013958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 17 Jul 2016 07:44:29 -0400
To: Brian Campbell , Phil Hunt 
References: <20160708101903.32067.39351.idtracker@ietfa.amsl.com> <255B9BB34FB7D647A506DC292726F6E13BD67E62B2@WSMSG3153V.srv.dir.telstra.com>   <6AC90FA1-71C2-4DB6-BAA3-EB28ED5B8946@oracle.com> 
From: Justin Richer 
Message-ID: 
Date: Sun, 17 Jul 2016 07:44:27 -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="------------596498102F8A1F0809FB1578"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjleLIzCtJLcpLzFFi42IRYrdT0Z2f3x1u8H+1gMXq/zcZLU6+fcVm sWB+I7sDs8eSJT+ZPD4+vcXicffoRZYA5igum5TUnMyy1CJ9uwSujL+7LrMW/M+uOLltFXMD 4x/7LkZODgkBE4ljlxtYuhi5OIQE2pgkzjx6ywrhbGSUONm7kQ3Cuc0k8X3CS+YuRg4OYQEv iYWNMiDdIgJREosurGCHqJnBLPHq5nYmkASzgKrElwXvwWw2IHv6mhYwm1fASuLpn5mMIDYL UPze/5ksIDNFBWIk1vclQJQISpyc+YQFxOYUCJTYuXI6I8TIMIkvZ5ayTWDkn4WkbBaSFIRt K3Fn7m5mCFteonnrbChbV2LRthXsyOILGNlWMcqm5Fbp5iZm5hSnJusWJyfm5aUW6Vro5WaW 6KWmlG5iBAe7i+oOxjl/vQ4xCnAwKvHwLpjdFS7EmlhWXJl7iFGSg0lJlFddtTtciC8pP6Uy I7E4I76oNCe1+BCjBAezkgjv+SygHG9KYmVValE+TEqag0VJnHf7t/ZwIYH0xJLU7NTUgtQi mKwMB4eSBO/fPKBGwaLU9NSKtMycEoQ0EwcnyHAeoOH3QGp4iwsSc4sz0yHypxgVpcR5H4Ik BEASGaV5cL2gZJTw9rDpK0ZxoFeEeXlBqniAiQyu+xXQYCagwQaqYINLEhFSUg2My49yClws mtuy+MG6wyc6Z/517tvboFK89nOQmwNDbvdKrzvLnry5/1R9owzP6YaVUYE1bAHB7U6qj28r N65zlPPdpTl75hzxzJ1Vrqv6tiol5j3MkpzwWyZicbnXy3W/f22U55VY4LzmJqfY7X5Lnhr2 lK7d8dse/HQJSdxXs/dC9zw/SQMPJZbijERDLeai4kQAF3E2RCEDAAA=
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-05.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 17 Jul 2016 11:44:35 -0000

This is a multi-part message in MIME format.
--------------596498102F8A1F0809FB1578
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

I, for one, appreciate the title. It's a token swap, fulfilling and in 
some ways replacing the complicated functionality of an old-school STS, 
but in a more REST-friendly fashion. OAuth is not RESTful, nor has it 
ever intended to be so. It's REST-friendly and that's a good thing.

Besides: it's a subtitle, not the root document title. I say we keep it.

  -- Justin

On 7/16/2016 10:42 AM, Brian Campbell wrote:
> Et tu, Phil?
>
> Do Sam and Phil represent the general consensus here or a vocal minority?
>
> On Fri, Jul 15, 2016 at 3:56 PM, Phil Hunt  > wrote:
>
>     I agree. The title was useful as a working title as it conveyed a
>     lot of useful intent information to members of the WG familiar
>     with the technology.
>
>     I don’t think the broader community understands OASIS and the
>     broader realm nor should they care.
>
>     At minimum it suggests they need to go read about STS’s before
>     implementing the draft - which should not be needed.
>
>     Phil
>
>     @independentid
>     www.independentid.com 
>     phil.hunt@oracle.com 
>
>
>
>
>
>>     On Jul 15, 2016, at 2:13 PM, Sam Whited >     > wrote:
>>
>>     Hi all,
>>
>>     Longtime reader / implementer, first time poster. I wanted to comment
>>     specifically on the question of the title:
>>
>>     On Fri, Jul 15, 2016 at 3:36 PM, Brian Campbell
>>     >
>>     wrote:
>>>     The title is something I'm less open to changes on. Honestly,
>>>     I'm really
>>>     partial to it. I described it as "really really important" on
>>>     slide 7 of the
>>>     IETF 93 presentation about token exchange and tried to brake it down
>>>     humorously in a recent identity conference presentation. I've
>>>     had numerous
>>>     positive comments about it from people who appreciate the little
>>>     touch of
>>>     humor. I anticipate there may be some push-back in later stage
>>>     reviews on
>>>     the unexpanded acronym but I'll cross that bridge when/if I come
>>>     to it and
>>>     look to find some compromise.
>>
>>     While I too appreciate the little touch of humor, the point the RFC
>>     process is not humor, the point is to make something that conveys
>>     information in an accessible and unambiguous way. I did not know the
>>     acronym "STS" when I first glanced at this title, and even if I did
>>     know the acronym I'm not sure that the title would immediately convey
>>     what the document was about in its current form. This will be
>>     detrimental to the accessibility of the document if non-expert users
>>     have to go perform an internet search for an acronym before they've
>>     even begun to read the document.
>>
>>     RFCs are generally a bit dry and sprucing them up with a bit can be
>>     tempting. I appreciate that the joke is clever — but the less of our
>>     own quirky and fun personalities we put into RFCs the better it will
>>     be for the series and the clearer they will be for the developers who
>>     will have to implement them.
>>
>>     Thanks,
>>     Sam
>>
>>
>>
>>     -- 
>>     Sam Whited
>>     pub 4096R/54083AE104EA7AD3
>>
>>     _______________________________________________
>>     OAuth mailing list
>>     OAuth@ietf.org 
>>     https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--------------596498102F8A1F0809FB1578
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
I, for one, appreciate the title. It's a token swap, fulfilling
      and in some ways replacing the complicated functionality of an
      old-school STS, but in a more REST-friendly fashion. OAuth is not
      RESTful, nor has it ever intended to be so. It's REST-friendly and
      that's a good thing. 

    

    
Besides: it's a subtitle, not the root document title. I say we
      keep it.

    
 -- Justin

    

    
On 7/16/2016 10:42 AM, Brian Campbell
      wrote:

    

    

      
      

        
Et tu, Phil?

          

        

        Do Sam and Phil represent the general consensus here or a vocal
        minority?  

      

      


        
On Fri, Jul 15, 2016 at 3:56 PM, Phil
          Hunt <phil.hunt@oracle.com>
          wrote:

          

            
I agree. The title was
              useful as a working title as it conveyed a lot of useful
              intent information to members of the WG familiar with the
              technology.
              


              

              
I don’t think the broader community understands OASIS
                and the broader realm nor should they care.

              


              

              
At minimum it suggests they need to go read about
                STS’s before implementing the draft - which should not
                be needed.

              


                
                

                

                  

                    

                      

                        
On Jul 15, 2016, at 2:13 PM, Sam Whited
                          <sam@samwhited.com>
                          wrote:

                        

                      

                    

                    

                      

                        

                          
Hi all,

                            

                            Longtime reader / implementer, first time
                            poster. I wanted to comment

                            specifically on the question of the title:

                            

                            On Fri, Jul 15, 2016 at 3:36 PM, Brian
                            Campbell

                            <bcampbell@pingidentity.com>
                            wrote:

                            
The title is
                              something I'm less open to changes on.
                              Honestly, I'm really

                              partial to it. I described it as "really
                              really important" on slide 7 of the

                              IETF 93 presentation about token exchange
                              and tried to brake it down

                              humorously in a recent identity conference
                              presentation. I've had numerous

                              positive comments about it from people who
                              appreciate the little touch of

                              humor. I anticipate there may be some
                              push-back in later stage reviews on

                              the unexpanded acronym but I'll cross that
                              bridge when/if I come to it and

                              look to find some compromise.

                            

                            

                            While I too appreciate the little touch of
                            humor, the point the RFC

                            process is not humor, the point is to make
                            something that conveys

                            information in an accessible and unambiguous
                            way. I did not know the

                            acronym "STS" when I first glanced at this
                            title, and even if I did

                            know the acronym I'm not sure that the title
                            would immediately convey

                            what the document was about in its current
                            form. This will be

                            detrimental to the accessibility of the
                            document if non-expert users

                            have to go perform an internet search for an
                            acronym before they've

                            even begun to read the document.

                            

                            RFCs are generally a bit dry and sprucing
                            them up with a bit can be

                            tempting. I appreciate that the joke is
                            clever — but the less of our

                            own quirky and fun personalities we put into
                            RFCs the better it will

                            be for the series and the clearer they will
                            be for the developers who

                            will have to implement them.

                            

                            Thanks,

                            Sam

                            

                            

                            

                            -- 

                            Sam Whited

                            pub 4096R/54083AE104EA7AD3

                            

                          

                        

                        _______________________________________________

                          OAuth mailing list

                          OAuth@ietf.org

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

                        

                    

                  

                

                

              

            

          

        

        

      

      

      

      

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


    

    

  


--------------596498102F8A1F0809FB1578--


From nobody Sun Jul 17 07:24:05 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0BB912B01D for ; Sun, 17 Jul 2016 07:24:03 -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 lbnTNygY5eXz for ; Sun, 17 Jul 2016 07:24:01 -0700 (PDT)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0113.outbound.protection.outlook.com [104.47.36.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EB7212B051 for ; Sun, 17 Jul 2016 07:24: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=Z2jgVsQOvIu5tfr8VV79X6kt1LzfUXfOWMwGxqbWBW4=; b=LBeLIjr4ZyIS0T77yZUWZMrlwfhBphhNGcNhQQnwULJTVsJdSfmb3Osiz86d6eLy+zR6Yemf61iqNB5eiQ3CxWcJyLcHwg3oFSw1CcdYMzR+9hoOIf4zDIwlECTGbR6mO0h3fu+V13BaS2mQXR/L+0/JWbQUfZ+EWaVNC9fPp5s=
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.523.12; Sun, 17 Jul 2016 14:23: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.0523.028; Sun, 17 Jul 2016 14:23:52 +0000
From: Mike Jones 
To: Brian Campbell , Phil Hunt 
Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-05.txt
Thread-Index: AQHR2QIrUeciN6R5SEKdposHOlvVeaASgXuAgAd9rgCAAApYgIAAC9uAgAEZSoCAAYwiUA==
Date: Sun, 17 Jul 2016 14:23:52 +0000
Message-ID: 
References: <20160708101903.32067.39351.idtracker@ietfa.amsl.com> <255B9BB34FB7D647A506DC292726F6E13BD67E62B2@WSMSG3153V.srv.dir.telstra.com>   <6AC90FA1-71C2-4DB6-BAA3-EB28ED5B8946@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: [217.110.245.66]
x-ms-office365-filtering-correlation-id: 0147c597-28c9-4383-c45b-08d3ae4dfa46
x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1648; 6:15OHkyYFWUJY1PqVF8QaRVEterB7CM4ddb3hYM+O8PdR7Ey8dtBpDvN99JlH50zXjdjmV0ZZ4iASilXkOWfd7YHmKQMDxW1OacYeTMOqK+mfLpuq7s0DJlAxDOyyD7TVWi+ZiiTNv1W/hRZ1nd2hs4PkPQtoLv001hZjQLVOcl6xSCMOosegMI7nk8t7pqQsRRvmaHhLCGaINQS7nD5uEOzxqNRDptW4w48gkaE+BCushLlxOEMIA5UUM1t0rN7kwTAJTDb8z9Nu5DoclnxT/DXYJnUuWDsMZQ4FvVQFXwaecpiG1udDLvFz1aiUagO4BlNwdOwBGiQMhMk/QrPG2w==; 5:LDlyeL2dtBPog4YopcVJ6rz7PkX5V8NDPsbQTN9hvjZh9VaQnIQ0cjLCQq3xjz7tViTCFksHXaMgyxReYAJrnIXgwRs3/Q2jibIan5thkBz9oy01D1bDAeJEF4ZuqGLhGulgmW3VDahj/yyTmC2faw==; 24:u2Nb4ihCaEKcsG124bObwkF4FDQSidzfVszDdMkpoeFsd27KgK2+qIxuWr3v98cKh4a5pM96wuF/ACKqGrlJsv/OALobr8lGyH+8h3QShuQ=; 7:3lFRnM4ED6nDbrCJCBCsZ/MipOBvs/yS+81IxVAFWsTmLGZLmORsPk0RK3QTGKXzrKpbUoHmXI7zX+Jh0WenR0eSn9Km/T/ESucqVyqtEqwWOKvnpf1ZKic4gaP6V6j2wNat3kVP6qPPANxNP01YPe2UcPI69400twuQsZfdrxi2utwIXS8v+oV6E8AwdA2+7nEipqYrXM6fAsoDhPAbH06FLL8fvNn6UQyDvkloZBcJ3AsUEpW0jIgc5qAQTjAt
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1648;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(100405760836317)(21748063052155)(146099531331640); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:SN1PR0301MB1648; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1648; 
x-forefront-prvs: 00064751B6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(24454002)(377454003)(53754006)(199003)(189002)(3280700002)(3660700001)(86362001)(122556002)(19300405004)(586003)(3846002)(19609705001)(102836003)(86612001)(68736007)(19580395003)(33656002)(76576001)(87936001)(19580405001)(97736004)(6116002)(105586002)(11100500001)(790700001)(7846002)(7736002)(5003600100003)(7696003)(230783001)(66066001)(9686002)(50986999)(16601075003)(77096005)(101416001)(15975445007)(74316002)(189998001)(7906003)(4326007)(81166006)(2900100001)(81156014)(5005710100001)(10400500002)(8676002)(10290500002)(8990500004)(76176999)(5001770100001)(19617315012)(92566002)(16236675004)(2950100001)(106116001)(106356001)(93886004)(5002640100001)(10090500001)(8936002)(19625215002)(99286002)(54356999)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0301MB1648; 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_SN1PR0301MB164534FA85D5264176286A4EF5350SN1PR0301MB1645_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2016 14:23:52.2797 (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: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-05.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 17 Jul 2016 14:24:04 -0000

--_000_SN1PR0301MB164534FA85D5264176286A4EF5350SN1PR0301MB1645_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

U2luY2UgeW914oCZcmUgYXNraW5n4oCmDQoNCkkgbXVzdCBhZG1pdCwgZXZlcnkgdGltZSBJIHNl
ZSB0aGUgdGl0bGUsIEkgY3JpbmdlLiAgSSBoZWxkIG15IG5vc2UgYXQgdGhlIHRpbWUgb2YgdGhl
IG1lcmdlIHNpbmNlIEkga25ldyB0aGF0IGl0IHdhcyBpbXBvcnRhbnQgdG8geW91LCBidXQgc2lu
Y2Ugb3RoZXJzIGFyZSByYWlzaW5nIHRoZSBpc3N1ZSwgSeKAmWxsIHNheSB0aGF0IEkgYWN0dWFs
bHkgZmluZCBpdCB0byBiZSBlbWJhcnJhc3NpbmcuDQoNCkkgdGhpbmsgd2XigJlyZSBiZXR0ZXIg
b2ZmIHdpdGggYSBzdHJhaWdodGZvcndhcmQgdGl0bGUgd2l0aG91dCB0aGUgZXh0cmEgY2xhdXNl
IHRoYXQgaXMgYm90aCBtaXNsZWFkaW5nIGFuZCB0b28gY3V0ZSBieSBoYWxmLg0KDQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSG9uZXN0bHks
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
LS0gTWlrZQ0KDQpGcm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9u
IEJlaGFsZiBPZiBCcmlhbiBDYW1wYmVsbA0KU2VudDogU2F0dXJkYXksIEp1bHkgMTYsIDIwMTYg
NDo0MyBQTQ0KVG86IFBoaWwgSHVudCA8cGhpbC5odW50QG9yYWNsZS5jb20+DQpDYzogb2F1dGhA
aWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEktRCBBY3Rpb246IGRyYWZ0LWlldGYt
b2F1dGgtdG9rZW4tZXhjaGFuZ2UtMDUudHh0DQoNCkV0IHR1LCBQaGlsPw0KRG8gU2FtIGFuZCBQ
aGlsIHJlcHJlc2VudCB0aGUgZ2VuZXJhbCBjb25zZW5zdXMgaGVyZSBvciBhIHZvY2FsIG1pbm9y
aXR5Pw0KDQpPbiBGcmksIEp1bCAxNSwgMjAxNiBhdCAzOjU2IFBNLCBQaGlsIEh1bnQgPHBoaWwu
aHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+IHdyb3RlOg0KSSBh
Z3JlZS4gVGhlIHRpdGxlIHdhcyB1c2VmdWwgYXMgYSB3b3JraW5nIHRpdGxlIGFzIGl0IGNvbnZl
eWVkIGEgbG90IG9mIHVzZWZ1bCBpbnRlbnQgaW5mb3JtYXRpb24gdG8gbWVtYmVycyBvZiB0aGUg
V0cgZmFtaWxpYXIgd2l0aCB0aGUgdGVjaG5vbG9neS4NCg0KSSBkb27igJl0IHRoaW5rIHRoZSBi
cm9hZGVyIGNvbW11bml0eSB1bmRlcnN0YW5kcyBPQVNJUyBhbmQgdGhlIGJyb2FkZXIgcmVhbG0g
bm9yIHNob3VsZCB0aGV5IGNhcmUuDQoNCkF0IG1pbmltdW0gaXQgc3VnZ2VzdHMgdGhleSBuZWVk
IHRvIGdvIHJlYWQgYWJvdXQgU1RT4oCZcyBiZWZvcmUgaW1wbGVtZW50aW5nIHRoZSBkcmFmdCAt
IHdoaWNoIHNob3VsZCBub3QgYmUgbmVlZGVkLg0KDQpQaGlsDQoNCkBpbmRlcGVuZGVudGlkDQp3
d3cuaW5kZXBlbmRlbnRpZC5jb208aHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNvbT4NCnBoaWwu
aHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4NCg0KDQoNCg0KT24g
SnVsIDE1LCAyMDE2LCBhdCAyOjEzIFBNLCBTYW0gV2hpdGVkIDxzYW1Ac2Ftd2hpdGVkLmNvbTxt
YWlsdG86c2FtQHNhbXdoaXRlZC5jb20+PiB3cm90ZToNCg0KSGkgYWxsLA0KDQpMb25ndGltZSBy
ZWFkZXIgLyBpbXBsZW1lbnRlciwgZmlyc3QgdGltZSBwb3N0ZXIuIEkgd2FudGVkIHRvIGNvbW1l
bnQNCnNwZWNpZmljYWxseSBvbiB0aGUgcXVlc3Rpb24gb2YgdGhlIHRpdGxlOg0KDQpPbiBGcmks
IEp1bCAxNSwgMjAxNiBhdCAzOjM2IFBNLCBCcmlhbiBDYW1wYmVsbA0KPGJjYW1wYmVsbEBwaW5n
aWRlbnRpdHkuY29tPG1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT4+IHdyb3RlOg0K
DQpUaGUgdGl0bGUgaXMgc29tZXRoaW5nIEknbSBsZXNzIG9wZW4gdG8gY2hhbmdlcyBvbi4gSG9u
ZXN0bHksIEknbSByZWFsbHkNCnBhcnRpYWwgdG8gaXQuIEkgZGVzY3JpYmVkIGl0IGFzICJyZWFs
bHkgcmVhbGx5IGltcG9ydGFudCIgb24gc2xpZGUgNyBvZiB0aGUNCklFVEYgOTMgcHJlc2VudGF0
aW9uIGFib3V0IHRva2VuIGV4Y2hhbmdlIGFuZCB0cmllZCB0byBicmFrZSBpdCBkb3duDQpodW1v
cm91c2x5IGluIGEgcmVjZW50IGlkZW50aXR5IGNvbmZlcmVuY2UgcHJlc2VudGF0aW9uLiBJJ3Zl
IGhhZCBudW1lcm91cw0KcG9zaXRpdmUgY29tbWVudHMgYWJvdXQgaXQgZnJvbSBwZW9wbGUgd2hv
IGFwcHJlY2lhdGUgdGhlIGxpdHRsZSB0b3VjaCBvZg0KaHVtb3IuIEkgYW50aWNpcGF0ZSB0aGVy
ZSBtYXkgYmUgc29tZSBwdXNoLWJhY2sgaW4gbGF0ZXIgc3RhZ2UgcmV2aWV3cyBvbg0KdGhlIHVu
ZXhwYW5kZWQgYWNyb255bSBidXQgSSdsbCBjcm9zcyB0aGF0IGJyaWRnZSB3aGVuL2lmIEkgY29t
ZSB0byBpdCBhbmQNCmxvb2sgdG8gZmluZCBzb21lIGNvbXByb21pc2UuDQoNCldoaWxlIEkgdG9v
IGFwcHJlY2lhdGUgdGhlIGxpdHRsZSB0b3VjaCBvZiBodW1vciwgdGhlIHBvaW50IHRoZSBSRkMN
CnByb2Nlc3MgaXMgbm90IGh1bW9yLCB0aGUgcG9pbnQgaXMgdG8gbWFrZSBzb21ldGhpbmcgdGhh
dCBjb252ZXlzDQppbmZvcm1hdGlvbiBpbiBhbiBhY2Nlc3NpYmxlIGFuZCB1bmFtYmlndW91cyB3
YXkuIEkgZGlkIG5vdCBrbm93IHRoZQ0KYWNyb255bSAiU1RTIiB3aGVuIEkgZmlyc3QgZ2xhbmNl
ZCBhdCB0aGlzIHRpdGxlLCBhbmQgZXZlbiBpZiBJIGRpZA0Ka25vdyB0aGUgYWNyb255bSBJJ20g
bm90IHN1cmUgdGhhdCB0aGUgdGl0bGUgd291bGQgaW1tZWRpYXRlbHkgY29udmV5DQp3aGF0IHRo
ZSBkb2N1bWVudCB3YXMgYWJvdXQgaW4gaXRzIGN1cnJlbnQgZm9ybS4gVGhpcyB3aWxsIGJlDQpk
ZXRyaW1lbnRhbCB0byB0aGUgYWNjZXNzaWJpbGl0eSBvZiB0aGUgZG9jdW1lbnQgaWYgbm9uLWV4
cGVydCB1c2Vycw0KaGF2ZSB0byBnbyBwZXJmb3JtIGFuIGludGVybmV0IHNlYXJjaCBmb3IgYW4g
YWNyb255bSBiZWZvcmUgdGhleSd2ZQ0KZXZlbiBiZWd1biB0byByZWFkIHRoZSBkb2N1bWVudC4N
Cg0KUkZDcyBhcmUgZ2VuZXJhbGx5IGEgYml0IGRyeSBhbmQgc3BydWNpbmcgdGhlbSB1cCB3aXRo
IGEgYml0IGNhbiBiZQ0KdGVtcHRpbmcuIEkgYXBwcmVjaWF0ZSB0aGF0IHRoZSBqb2tlIGlzIGNs
ZXZlciDigJQgYnV0IHRoZSBsZXNzIG9mIG91cg0Kb3duIHF1aXJreSBhbmQgZnVuIHBlcnNvbmFs
aXRpZXMgd2UgcHV0IGludG8gUkZDcyB0aGUgYmV0dGVyIGl0IHdpbGwNCmJlIGZvciB0aGUgc2Vy
aWVzIGFuZCB0aGUgY2xlYXJlciB0aGV5IHdpbGwgYmUgZm9yIHRoZSBkZXZlbG9wZXJzIHdobw0K
d2lsbCBoYXZlIHRvIGltcGxlbWVudCB0aGVtLg0KDQpUaGFua3MsDQpTYW0NCg0KDQoNCi0tDQpT
YW0gV2hpdGVkDQpwdWIgNDA5NlIvNTQwODNBRTEwNEVBN0FEMw0KX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhA
aWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCg==

--_000_SN1PR0301MB164534FA85D5264176286A4EF5350SN1PR0301MB1645_
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
CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4
DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0
eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7
fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp
biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp
b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1
bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt
LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp
ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl
bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i
cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+U2luY2UgeW914oCZcmUgYXNraW5n4oCm
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmO2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5JIG11c3QgYWRtaXQs
IGV2ZXJ5IHRpbWUgSSBzZWUgdGhlIHRpdGxlLCBJIGNyaW5nZS4gJm5ic3A7SSBoZWxkIG15IG5v
c2UgYXQgdGhlIHRpbWUgb2YgdGhlIG1lcmdlIHNpbmNlIEkga25ldyB0aGF0IGl0IHdhcyBpbXBv
cnRhbnQgdG8geW91LCBidXQgc2luY2Ugb3RoZXJzIGFyZSByYWlzaW5nDQogdGhlIGlzc3VlLCBJ
4oCZbGwgc2F5IHRoYXQgSSBhY3R1YWxseSBmaW5kIGl0IHRvIGJlIGVtYmFycmFzc2luZy48bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7
Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPkkgdGhpbmsgd2XigJlyZSBi
ZXR0ZXIgb2ZmIHdpdGggYSBzdHJhaWdodGZvcndhcmQgdGl0bGUgd2l0aG91dCB0aGUgZXh0cmEg
Y2xhdXNlIHRoYXQgaXMgYm90aCBtaXNsZWFkaW5nIGFuZCB0b28gY3V0ZSBieSBoYWxmLjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj
b2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEhvbmVzdGx5LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48
L3A+DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PC9zcGFuPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmIj4gT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXQ0K
PGI+T24gQmVoYWxmIE9mIDwvYj5CcmlhbiBDYW1wYmVsbDxicj4NCjxiPlNlbnQ6PC9iPiBTYXR1
cmRheSwgSnVseSAxNiwgMjAxNiA0OjQzIFBNPGJyPg0KPGI+VG86PC9iPiBQaGlsIEh1bnQgJmx0
O3BoaWwuaHVudEBvcmFjbGUuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gb2F1dGhAaWV0Zi5vcmc8
YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gSS1EIEFjdGlvbjogZHJhZnQtaWV0
Zi1vYXV0aC10b2tlbi1leGNoYW5nZS0wNS50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5FdCB0dSwgUGhp
bD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RG8gU2FtIGFu
ZCBQaGlsIHJlcHJlc2VudCB0aGUgZ2VuZXJhbCBjb25zZW5zdXMgaGVyZSBvciBhIHZvY2FsIG1p
bm9yaXR5PyZuYnNwOw0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5PbiBGcmksIEp1bCAxNSwgMjAxNiBhdCAzOjU2IFBNLCBQaGlsIEh1bnQgJmx0OzxhIGhy
ZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBoaWwuaHVu
dEBvcmFjbGUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBz
dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n
OjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYWdyZWUuIFRoZSB0aXRsZSB3YXMgdXNlZnVs
IGFzIGEgd29ya2luZyB0aXRsZSBhcyBpdCBjb252ZXllZCBhIGxvdCBvZiB1c2VmdWwgaW50ZW50
IGluZm9ybWF0aW9uIHRvIG1lbWJlcnMgb2YgdGhlIFdHIGZhbWlsaWFyIHdpdGggdGhlIHRlY2hu
b2xvZ3kuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRv
buKAmXQgdGhpbmsgdGhlIGJyb2FkZXIgY29tbXVuaXR5IHVuZGVyc3RhbmRzIE9BU0lTIGFuZCB0
aGUgYnJvYWRlciByZWFsbSBub3Igc2hvdWxkIHRoZXkgY2FyZS48bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXQgbWluaW11bSBpdCBzdWdnZXN0
cyB0aGV5IG5lZWQgdG8gZ28gcmVhZCBhYm91dCBTVFPigJlzIGJlZm9yZSBpbXBsZW1lbnRpbmcg
dGhlIGRyYWZ0IC0gd2hpY2ggc2hvdWxkIG5vdCBiZSBuZWVkZWQuPG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5QaGlsPG86cD48
L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si
PkBpbmRlcGVuZGVudGlkPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YSBocmVmPSJodHRw
Oi8vd3d3LmluZGVwZW5kZW50aWQuY29tIiB0YXJnZXQ9Il9ibGFuayI+d3d3LmluZGVwZW5kZW50
aWQuY29tPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48
YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5waGls
Lmh1bnRAb3JhY2xlLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N
CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6
NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5PbiBKdWwgMTUsIDIwMTYsIGF0IDI6MTMgUE0sIFNhbSBXaGl0ZWQgJmx0
OzxhIGhyZWY9Im1haWx0bzpzYW1Ac2Ftd2hpdGVkLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnNhbUBz
YW13aGl0ZWQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBhbGwsPGJy
Pg0KPGJyPg0KTG9uZ3RpbWUgcmVhZGVyIC8gaW1wbGVtZW50ZXIsIGZpcnN0IHRpbWUgcG9zdGVy
LiBJIHdhbnRlZCB0byBjb21tZW50PGJyPg0Kc3BlY2lmaWNhbGx5IG9uIHRoZSBxdWVzdGlvbiBv
ZiB0aGUgdGl0bGU6PGJyPg0KPGJyPg0KT24gRnJpLCBKdWwgMTUsIDIwMTYgYXQgMzozNiBQTSwg
QnJpYW4gQ2FtcGJlbGw8YnI+DQombHQ7PGEgaHJlZj0ibWFpbHRvOmJjYW1wYmVsbEBwaW5naWRl
bnRpdHkuY29tIiB0YXJnZXQ9Il9ibGFuayI+YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208L2E+
Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxl
PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+VGhlIHRpdGxlIGlzIHNvbWV0aGluZyBJJ20gbGVzcyBvcGVuIHRvIGNoYW5nZXMgb24u
IEhvbmVzdGx5LCBJJ20gcmVhbGx5PGJyPg0KcGFydGlhbCB0byBpdC4gSSBkZXNjcmliZWQgaXQg
YXMgJnF1b3Q7cmVhbGx5IHJlYWxseSBpbXBvcnRhbnQmcXVvdDsgb24gc2xpZGUgNyBvZiB0aGU8
YnI+DQpJRVRGIDkzIHByZXNlbnRhdGlvbiBhYm91dCB0b2tlbiBleGNoYW5nZSBhbmQgdHJpZWQg
dG8gYnJha2UgaXQgZG93bjxicj4NCmh1bW9yb3VzbHkgaW4gYSByZWNlbnQgaWRlbnRpdHkgY29u
ZmVyZW5jZSBwcmVzZW50YXRpb24uIEkndmUgaGFkIG51bWVyb3VzPGJyPg0KcG9zaXRpdmUgY29t
bWVudHMgYWJvdXQgaXQgZnJvbSBwZW9wbGUgd2hvIGFwcHJlY2lhdGUgdGhlIGxpdHRsZSB0b3Vj
aCBvZjxicj4NCmh1bW9yLiBJIGFudGljaXBhdGUgdGhlcmUgbWF5IGJlIHNvbWUgcHVzaC1iYWNr
IGluIGxhdGVyIHN0YWdlIHJldmlld3Mgb248YnI+DQp0aGUgdW5leHBhbmRlZCBhY3JvbnltIGJ1
dCBJJ2xsIGNyb3NzIHRoYXQgYnJpZGdlIHdoZW4vaWYgSSBjb21lIHRvIGl0IGFuZDxicj4NCmxv
b2sgdG8gZmluZCBzb21lIGNvbXByb21pc2UuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4N
CldoaWxlIEkgdG9vIGFwcHJlY2lhdGUgdGhlIGxpdHRsZSB0b3VjaCBvZiBodW1vciwgdGhlIHBv
aW50IHRoZSBSRkM8YnI+DQpwcm9jZXNzIGlzIG5vdCBodW1vciwgdGhlIHBvaW50IGlzIHRvIG1h
a2Ugc29tZXRoaW5nIHRoYXQgY29udmV5czxicj4NCmluZm9ybWF0aW9uIGluIGFuIGFjY2Vzc2li
bGUgYW5kIHVuYW1iaWd1b3VzIHdheS4gSSBkaWQgbm90IGtub3cgdGhlPGJyPg0KYWNyb255bSAm
cXVvdDtTVFMmcXVvdDsgd2hlbiBJIGZpcnN0IGdsYW5jZWQgYXQgdGhpcyB0aXRsZSwgYW5kIGV2
ZW4gaWYgSSBkaWQ8YnI+DQprbm93IHRoZSBhY3JvbnltIEknbSBub3Qgc3VyZSB0aGF0IHRoZSB0
aXRsZSB3b3VsZCBpbW1lZGlhdGVseSBjb252ZXk8YnI+DQp3aGF0IHRoZSBkb2N1bWVudCB3YXMg
YWJvdXQgaW4gaXRzIGN1cnJlbnQgZm9ybS4gVGhpcyB3aWxsIGJlPGJyPg0KZGV0cmltZW50YWwg
dG8gdGhlIGFjY2Vzc2liaWxpdHkgb2YgdGhlIGRvY3VtZW50IGlmIG5vbi1leHBlcnQgdXNlcnM8
YnI+DQpoYXZlIHRvIGdvIHBlcmZvcm0gYW4gaW50ZXJuZXQgc2VhcmNoIGZvciBhbiBhY3Jvbnlt
IGJlZm9yZSB0aGV5J3ZlPGJyPg0KZXZlbiBiZWd1biB0byByZWFkIHRoZSBkb2N1bWVudC48YnI+
DQo8YnI+DQpSRkNzIGFyZSBnZW5lcmFsbHkgYSBiaXQgZHJ5IGFuZCBzcHJ1Y2luZyB0aGVtIHVw
IHdpdGggYSBiaXQgY2FuIGJlPGJyPg0KdGVtcHRpbmcuIEkgYXBwcmVjaWF0ZSB0aGF0IHRoZSBq
b2tlIGlzIGNsZXZlciDigJQgYnV0IHRoZSBsZXNzIG9mIG91cjxicj4NCm93biBxdWlya3kgYW5k
IGZ1biBwZXJzb25hbGl0aWVzIHdlIHB1dCBpbnRvIFJGQ3MgdGhlIGJldHRlciBpdCB3aWxsPGJy
Pg0KYmUgZm9yIHRoZSBzZXJpZXMgYW5kIHRoZSBjbGVhcmVyIHRoZXkgd2lsbCBiZSBmb3IgdGhl
IGRldmVsb3BlcnMgd2hvPGJyPg0Kd2lsbCBoYXZlIHRvIGltcGxlbWVudCB0aGVtLjxicj4NCjxi
cj4NClRoYW5rcyw8YnI+DQpTYW08YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQotLSA8YnI+DQpTYW0g
V2hpdGVkPGJyPg0KcHViIDQwOTZSLzU0MDgzQUUxMDRFQTdBRDM8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxh
IGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYu
b3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx
dW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0
bWw+DQo=

--_000_SN1PR0301MB164534FA85D5264176286A4EF5350SN1PR0301MB1645_--


From nobody Mon Jul 18 01:58:07 2016
Return-Path: 
X-Original-To: oauth@ietf.org
Delivered-To: oauth@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2009C12D196; Mon, 18 Jul 2016 01:58:03 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.28.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160718085803.12429.32081.idtracker@ietfa.amsl.com>
Date: Mon, 18 Jul 2016 01:58:03 -0700
Archived-At: 
Cc: oauth@ietf.org
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-device-flow-03.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Jul 2016 08:58:03 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol of the IETF.

        Title           : OAuth 2.0 Device Flow
        Authors         : William Denniss
                          Stein Myrseth
                          John Bradley
                          Michael B. Jones
                          Hannes Tschofenig
	Filename        : draft-ietf-oauth-device-flow-03.txt
	Pages           : 10
	Date            : 2016-07-18

Abstract:
   The device flow is suitable for OAuth 2.0 clients executing on
   devices that do not have an easy data-entry method (e.g., game
   consoles, TVs, picture frames, and media hubs), but where the end-
   user has separate access to a user-agent on another computer or
   device (e.g., desktop computer, a laptop, a smart phone, or a
   tablet).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-oauth-device-flow-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-device-flow-03


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Mon Jul 18 07:58:26 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B08D512DAEB for ; Mon, 18 Jul 2016 07:58:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.888
X-Spam-Level: 
X-Spam-Status: No, score=-3.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.287, 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 AnyRxjlBV2sP for ; Mon, 18 Jul 2016 07:58:22 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30A1312DA98 for ; Mon, 18 Jul 2016 07:30:10 -0700 (PDT)
Received: from [192.168.10.131] ([31.133.155.135]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Lg5kl-1b1d6J0k03-00pdlu for ; Mon, 18 Jul 2016 16:30:08 +0200
To: "oauth@ietf.org" 
From: Hannes Tschofenig 
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
Message-ID: <578CE7F4.4080600@gmx.net>
Date: Mon, 18 Jul 2016 16:30:12 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="drP96stUav165oghrAVPua7DuvTJrlrkr"
X-Provags-ID: V03:K0:sFT6cIu6E03sUCDXP6m0KjDtasQtj28g51qGPP56xYaBLohZqxf mzVUKRznqzngPskdBwZsLe/T/CeY1CSPGJf5SxVIT+EFzVvxBZkM7dSD0JcyPiMhVfCGo92 3BpmNZGfRT/pjXFoNdQcHUYQs9hpqjvi7cUcD/7tlXKPTI/j3B4DT349DOh1xSrAnLmUzey Vcwvdd+SbzP+1UyKQh23Q==
X-UI-Out-Filterresults: notjunk:1;V01:K0:DRxQGoizjLA=:em0pHbh81Q1ZZ9XKPWMXAl ZxXc9/n8+NKXEg1VSRdb30dDiGAhfuQrkmyw+XrXqXlspgnGWO43bg+Ecybk8A0cJOLpUF42K lO3e6EeTivbOIvUidtlxp216/73rEnFTC3TUYoAFOpP3PsgxQ3DHcghRg3uE1P6IFZ7gARgP0 Tezg0uMxAgFE/buEVoMIYEqlXuc75laveBw6d7O/wWopLhhCdrMgtPBeBgLD2XJT/xlE063dm /LaGOgmQ4V3aPqcT8NnqUECXBs3VDnka4L1SjPce9NqLynDGqYQhi90fSCIf/q6nHV0icMaeo sSVc13H05vvBFiCjMHbK1e7lNwR66sDZOSl8VPy4jsjk6IPkdnfpb8toyOG7TrJpCm/sCvPdH KQtBFMuFsI6K7/T9epAjO1Njo+62GGxTpwkqfEJ8JOF+NmQTZkEW7vx2iJUlpa+mgC1Ek95Bp eWgdhIHE8BMEIVSg3nTjMTzUdTYZaE8TxfoF+nibw9h7AWJYtUlL2dkTW6F4aEfAYBEnKRL6v KooJEt2OwqX1S8IKC9Ino2l75dJACVHE/2sBthLdigwHeGUrksBQMaYcOwoL1d8ETO0mT1F97 HaIIQ6ZpICn1kaBL9EpLuV69GW3mXw+lyymZWFh+hhUNr5ybRx7JozpwPMEVonZYBVgAzI8O3 5i2nkYgwHO+it2XxbQRFhYtJEQCnBTvSdTLUnuGZg+bxW31r92OBCecG5cvlIBIuJe0iC7zRb i6C2yAvxkuqXwjzQ7i2yu5JX3efxcW63+NqP9IOzeV4xqMJeXYOIx+wiEnk=
Archived-At: 
Subject: [OAUTH-WG] Working Group Last Call on "Authentication Method Reference Values"
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Jul 2016 14:58:24 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--drP96stUav165oghrAVPua7DuvTJrlrkr
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi all,

this is a Last Call for comments on the "Authentication Method Reference
Values" specification.

The document can be found here:
https://tools.ietf.org/html/draft-ietf-oauth-amr-values-01

Please have your comments in no later than August 1st.

Ciao
Hannes & Derek




--drP96stUav165oghrAVPua7DuvTJrlrkr
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJXjOf0AAoJEGhJURNOOiAte+sIAITDakg79CreBQGjocC3eWqL
RsSPFFtjg4lYkJzwwikB5oWL5/YXnpY+kilUafThFDT2fR9C1BvKka1HGqUxGuag
ULp1uDoc5Jy+kdKKUY3kJ16smnrG1deNOXrc7tf7Xu8mHg5jUuQhOszZeKNJ8w7p
TP5xJDlNtgiPRVwXn/02sUhPsgDxu4vZ2JgWwHm7JS2eEcvUs9mO0cqKM1k+zTtg
0kNhdj4obf/jy3AOuLfAg1fLDtroZUrLUUruusRLqQbfpqNgy8ud5dIHwePZODEp
Q/7wImqDhwyCWKMbJhER3u3cng09JTsFQDrlBrQI2QluGRgVMSmIvAAOck+ESaM=
=f9KJ
-----END PGP SIGNATURE-----

--drP96stUav165oghrAVPua7DuvTJrlrkr--


From nobody Mon Jul 18 08:23:56 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5243F12DA52 for ; Mon, 18 Jul 2016 08:23:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kLfzSNFMHf-1 for ; Mon, 18 Jul 2016 08:23:46 -0700 (PDT)
Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3370512DA8E for ; Mon, 18 Jul 2016 08:05:05 -0700 (PDT)
Received: by mail-it0-x230.google.com with SMTP id j124so34336434ith.1 for ; Mon, 18 Jul 2016 08:05:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mwAe0NaDtDHr2F8AwFdf9JI2WJCKMwPvBVuhKFA+D00=; b=KIjQdjpYY23L9YgDR3qrSPWfnw8UADikDMlSaxmSQp4IYsY0t+2o0h9h/OrgKRrzEi d34h/jdZYwM2Ym89M7V0Tc8a5cOf2yfmrtmq0qccBY0p4Kx4wrk5Cbic3kA+gsOf9XnQ T0F5Fkm6GxO6Ee6cdtUVP42wdX/TsjtuyW+uXDf5FCFgmBvLr1cSTqSeW/vXvsXBhfxm U2aqpUbKALl4IZDuX2TURtT/xYN9W9EYywGgvwYc4bzjCoZR0wjRKXE8fM5RERRAeXkA MiYyCatcn3ExaQC3WQ+X8sc4d9dKY9XebHuCTKkBdRYHpHEAvbZA355RrCx2+hZ/K785 IbPA==
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=mwAe0NaDtDHr2F8AwFdf9JI2WJCKMwPvBVuhKFA+D00=; b=Wq/LydkvAwAtUwss7XdVZO5AwJqjrdtMynUwteXIjVcyapB8Kbc9OigQU9UWvyYdX4 ee+VQv8Pp+P0uhXWfMMPBBeO9QAsRRDI+yrIE+gP+AXlKGDgCBa8TRCP/05lUvxKNevr gPhhAKsBByh4Q86CSr1UtarVIafpkqa9Icn/+4mEjrIiqhMyvRz7h3AAbUSD62Rjn3Xf MQAMmqNMVDGXlLjBeC77eRpnTFtMfEV87KtXZfVF9FFbxDrRTKbxZX1PW+XAG+yX3K2g SZPqdaAs/gwNlt4IBLSEVH1yux+jR7NLdKHmfk8lFyDEpuM7OZSyV4+z6fI5S8EofRAE yHZQ==
X-Gm-Message-State: ALyK8tKNcgF69G/y5D8TP/UEzBHiR38uuf8WqDfgdeB8w0VH+PtZqlznlfxqAkSEgUYk40V2YZmU3mZnutv6oQ==
X-Received: by 10.36.36.15 with SMTP id f15mr3200480ita.43.1468854304463; Mon, 18 Jul 2016 08:05:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.201.210 with HTTP; Mon, 18 Jul 2016 08:05:04 -0700 (PDT)
In-Reply-To: <578CE7F4.4080600@gmx.net>
References: <578CE7F4.4080600@gmx.net>
From: Blue Teazzers 
Date: Mon, 18 Jul 2016 20:35:04 +0530
Message-ID: 
To: Hannes Tschofenig 
Content-Type: multipart/alternative; boundary=001a1146fcfe0b65560537ea4b38
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Working Group Last Call on "Authentication Method Reference Values"
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Jul 2016 15:23:55 -0000

--001a1146fcfe0b65560537ea4b38
Content-Type: text/plain; charset=UTF-8

what is this


On Mon, Jul 18, 2016 at 8:00 PM, Hannes Tschofenig <
hannes.tschofenig@gmx.net> wrote:

> Hi all,
>
> this is a Last Call for comments on the "Authentication Method Reference
> Values" specification.
>
> The document can be found here:
> https://tools.ietf.org/html/draft-ietf-oauth-amr-values-01
>
> Please have your comments in no later than August 1st.
>
> Ciao
> Hannes & Derek
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

--001a1146fcfe0b65560537ea4b38
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


what is this


On Mon, Jul 18, 2016 at 8:00 PM, Hannes Ts=
chofenig <hannes.tschofenig@gmx.net> wrote:
Hi all,



this is a Last Call for comments on the "Authentication Method Referen=
ce

Values" specification.



The document can be found here:

https://tools.ietf.org/html/draft-ietf-oa=
uth-amr-values-01



Please have your comments in no later than August 1st.



Ciao

Hannes & Derek








_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





--001a1146fcfe0b65560537ea4b38--


From nobody Tue Jul 19 15:22:27 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA2412D1A5 for ; Tue, 19 Jul 2016 15:22:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.987
X-Spam-Level: 
X-Spam-Status: No, score=-3.987 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.287, 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 FqANktxZxPvi for ; Tue, 19 Jul 2016 15:22:23 -0700 (PDT)
Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c: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 3E5D312D0A6 for ; Tue, 19 Jul 2016 15:22:22 -0700 (PDT)
Received: by mail-wm0-x22c.google.com with SMTP id f65so153796880wmi.0 for ; Tue, 19 Jul 2016 15:22:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=yywPbMzvIppxNJ3aqOjevcz+iQ/q4qWW4qYQDK1S8vc=; b=LuVB/4Asum/AGf6QJbvsp0i2E7nu5yAvSIvN1lV0A4js6BRjEL4HCbMT5OqAGM9F88 jJnvryUBv6ByrchWOYA8i1ojMSQneJe79i928/+Vp0dQCK6fPMJv/2f6WdQJkAmnQVpL qgU1oY8XlkobIRVU6WEjh94FDNxRYvgTj3JYlhTmADfgbjtKvdfQHdJxGeYuTAKn/4op CONhbxUqumRpAabOP4C95fiNmOgBjZNIb91pvwXBpScbDKSnS61LaHq9XTCTx29j9qmG VJWu5Z0U/omncsbVOD2dMx0ApMS3+SMIqocbNXheW8BLIsc9rVyiCiXqUEeTzjqWzn/q 7ANw==
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=yywPbMzvIppxNJ3aqOjevcz+iQ/q4qWW4qYQDK1S8vc=; b=BmSczBmZQl24TX4HnENUxtAPVBEE718R4JI1ENPDDcE47DOnIwXlOjwBZXntK5Q5cS bfcLNq2Q1DvvTEHhhW8FTZNtuCgFM+b3ybQ9O/7MT1qjkMHLlRi9ySUJ+b/d74IGYQCo tXaNPFn8yScXbOGUQ0g87niVCyeJGCXiFIQz99sxMnMAMCy0skt7KIHUp0yyz8d8/X71 76QzsOsLBpiLpBFzqeZjdTkagjK7KjxS2dHtLRsyk3RV3tWYfdLho27Jq47GS4wV6WIw VGXHfZvzQPsFl5wTkp1747hOPEaZm/MWpjfgwfd60bZjegdLqbrFy1jHes3aI831q+YL nxfw==
X-Gm-Message-State: ALyK8tLAWwKiBH5AxIoaWRxAtlEYkgW3fvtALljH0O67PU+WW/rgtfR1oeDjgj+ZJTCIVWWrtW/mXvel3Kf0f7qk
X-Received: by 10.28.128.15 with SMTP id b15mr7424839wmd.100.1468966939556; Tue, 19 Jul 2016 15:22:19 -0700 (PDT)
MIME-Version: 1.0
From: Dirk Balfanz 
Date: Tue, 19 Jul 2016 22:22:06 +0000
Message-ID: 
To: OAuth WG 
Content-Type: multipart/mixed; boundary=001a11417eb09f2a5e0538048405
Archived-At: 
Subject: [OAUTH-WG] some thoughts on OAuth on Token Binding
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jul 2016 22:22:25 -0000

--001a11417eb09f2a5e0538048405
Content-Type: multipart/alternative; boundary=001a11417eb09f2a580538048403

--001a11417eb09f2a580538048403
Content-Type: text/plain; charset=UTF-8

Hi there,

I recently wrote down some thoughts on how Token Binding and OAuth could be
done. If there is time tomorrow during the session, I'm happy to talk about
some of the ideas; and I realize that I can't talk about anything without
having it shared first with the group. So here it is (attached).

My apologies for

- not writing this down in an I-D friendly way - this is mostly
stream-of-consciousness listing of the issues/proposals that occurred to me
(view this more as a contribution to the discussion than a proposed I-D);

- attaching it as a PDF, which is terrible for inline commenting :-(

- framing my thoughts in a very Google-centric way (the AS in the examples
is always Google, but I believe the conclusions are general).

Dirk.

--001a11417eb09f2a580538048403
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi there,=C2=A0

I recently wrote down s=
ome thoughts on how Token Binding and OAuth could be done. If there is time=
 tomorrow during the session, I'm happy to talk about some of the ideas=
; and I realize that I can't talk about anything without having it shar=
ed first with the group. So here it is (attached).=C2=A0

My apologies for

- not writing this down in=
 an I-D friendly way - this is mostly stream-of-consciousness listing of th=
e issues/proposals that occurred to me (view this more as a contribution to=
 the discussion than a proposed I-D);

- attaching =
it as a PDF, which is terrible for inline commenting :-(

- framing my thoughts in a very Google-centric way (the AS in the ex=
amples is always Google, but I believe the conclusions are general).=C2=A0<=
/div>

Dirk.



--001a11417eb09f2a580538048403--

--001a11417eb09f2a5e0538048405
Content-Type: application/pdf; name="TokenBindingandOAuth.pdf"
Content-Disposition: attachment; filename="TokenBindingandOAuth.pdf"
Content-Transfer-Encoding: base64
Content-ID: <156053e94cc4c14d5901>
X-Attachment-Id: 156053e94cc4c14d5901

JVBERi0xLjUKJb/3ov4KNDYgMCBvYmoKPDwgL0xpbmVhcml6ZWQgMSAvTCA0NDIyNjUgL0ggWyA4
ODcgMjc4IF0gL08gNTAgL0UgNzk2OTQgL04gMTMgL1QgNDQxNzIwID4+CmVuZG9iagogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKNDcgMCBvYmoKPDwg
L1R5cGUgL1hSZWYgL0xlbmd0aCA3MCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvRGVjb2RlUGFybXMg
PDwgL0NvbHVtbnMgNSAvUHJlZGljdG9yIDEyID4+IC9XIFsgMSAzIDEgXSAvSW5kZXggWyA0NiA0
MyBdIC9JbmZvIDU5IDAgUiAvUm9vdCA0OCAwIFIgL1NpemUgODkgL1ByZXYgNDQxNzIxICAgICAg
ICAgICAgICAgIC9JRCBbPGRiYTIzMWI5MDFkZWU5Mjk5MDgxNWE2ZWYwNjEzNTQ4PjxkYmEyMzFi
OTAxZGVlOTI5OTA4MTVhNmVmMDYxMzU0OD5dID4+CnN0cmVhbQp4nGNiZGDgZ2BiYGA4CSKZc8Bs
YxDJKAYmv4FIy50gUuUxiJRXAJFpsiCSaRmQZHQ7BWbXMDAx/j//CWwCA+NQIQFZxwqwCmVuZHN0
cmVhbQplbmRvYmoKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAo0OCAwIG9iago8PCAvUGFnZXMg
NjAgMCBSIC9UeXBlIC9DYXRhbG9nID4+CmVuZG9iago0OSAwIG9iago8PCAvRmlsdGVyIC9GbGF0
ZURlY29kZSAvUyAxNzggL0xlbmd0aCAxOTggPj4Kc3RyZWFtCnicY2BgYGJgYC5nYGZgUHVjEGSA
AjCbhYEVyGR54cDAodC2d8quQ74njwZGGCh02DjwxbCsFu07mOdmlcDAwD599s3d3yco+pSsZNHs
m6rbAWOZnlAMWrpxXY2A04yXQTeuu3mAuY5cyUu9k2OaRLWipZ4fBOvoLX4oqdDqNeuJwDKrkOt4
LQMCZQZW1WogzQnEwmCRbwwCDAzmh5XeymmlqjNscL3C0MYqIL6QwahxD0N7ARfDxtgWhkUqSgzG
QLUA2nFIoQplbmRzdHJlYW0KZW5kb2JqCjUwIDAgb2JqCjw8IC9Db250ZW50cyA1MyAwIFIgL01l
ZGlhQm94IFsgMCAwIDYxMiA3OTIgXSAvUGFyZW50IDYxIDAgUiAvUmVzb3VyY2VzIDw8IC9FeHRH
U3RhdGUgPDwgL0cwIDYyIDAgUiA+PiAvRm9udCA8PCAvRjAgNjMgMCBSIC9GMSA2NiAwIFIgPj4g
L1Byb2NTZXRzIFsgL1BERiAvVGV4dCAvSW1hZ2VCIC9JbWFnZUMgL0ltYWdlSSBdIC9YT2JqZWN0
IDw8IC9YMCA1MSAwIFIgPj4gPj4gL1R5cGUgL1BhZ2UgPj4KZW5kb2JqCjUxIDAgb2JqCjw8IC9C
aXRzUGVyQ29tcG9uZW50IDggL0NvbG9yU3BhY2UgL0RldmljZVJHQiAvRmlsdGVyIC9GbGF0ZURl
Y29kZSAvSGVpZ2h0IDI4NyAvU01hc2sgNTIgMCBSIC9TdWJ0eXBlIC9JbWFnZSAvVHlwZSAvWE9i
amVjdCAvV2lkdGggNjI0IC9MZW5ndGggMTQzMzYgPj4Kc3RyZWFtCnic7Z0PdBXlnfdva9ZEodYQ
JNEgCdEgAYkxioZ/r6SYJV1Y5dDIZoHTHN9sRY1seGlMKNKA0KxkAdmwLxT6hhYVNJw3lrwnLHii
Jz1xxQYoImhCUrJrjo3HuHRJffO2dXXZvF/mt5kdZub+vzNz597v58zJufe5z8zz3Lm587m/5994
PMExWWHq1Kl4nJaWlp2dnaMwadKkW2655ZskMHCuMjIybr/9dpxM/E1KSsL5zMrKuvnmm2+88cYg
PxNCSCxwq4LTFycSIunp6QF+0KLR6dOn4zHsiSv/vffeW1VVtX379ldeeaWtre38+fO9JHhw6g4c
OPDcc88VFhampqbCp3LCYdWvfe1rVn1vCSHRx20Kw8SdQKl+P2IEnnfcccfMmTPhUCh13rx5W7du
7ezsdFpEsUlLS8tf/dVfJScnf/3rX8fJHzt2rPVfYkJIVECfuhq/PoVJ77nnHij1zjvvfPTRRzs6
OpwWTlzQ3d394osvIlyVTyEhIcH6rzIhxGHoU1fjw6c33XTTxIkT8WDKlClz585F3OS0ZOKRTZs2
JSYm4lNISUmx71tNCHEC+tTVePPp1KlTEZni1czMzF27djltlbjmvffek25rQkhsQ5+6GlOf3qOQ
k5OTnZ199OhRp31CrvLXf/3X9n+7CSF2Qp+6GqNPc3Nz77///ry8vPz8/BMnTjitEfJf7Ny505Hv
OCHEHuhTV6Pz6fXXX4+YFMFpQUFBd3e30wIhehoaGpz6phNCrIY+dTU6n6anpycmJt51112cDhO1
PPXUU/ik1GmqhJCYgT51NVqf3nnnnR5l3Ybjx487LQ3iiylTpng4iYaQmIM+dTWqT7Ozs++//35E
pvv27XNaF8QP77333vXXX+/sF58QEnHoU1ej+jQrKwtRz8KFC512BQmIjRs34lO74YYbHP32E0Ii
CX3qasSnkOmsWbMmT57c1tbmtChIoCQnJzv97SeERBL61NWITzMzM++4446VK1c6rQgSBPX19fjs
ZPUkQkgMQJ+6Gvg0ISHh3nvvhVI5ptd1fOMb33D6AkAIiRj0qauBTydPnvwnf/In3/nOd5yWAwma
ZcuW4Tt43XXXOX0ZIIREAPrU1cgKvXfffff+/fudlgMJmp///Of4LcRRSYTEBvSpq4FPIdOMjIww
7wael5eXToIn/AHVN998c1pamtOXAUJIBKBPXY2MRyosLAzzqj5p0qQREjwTJ04M88zPnDnT6WsA
ISQy0KeuBj6dOnXq1q1b6VNHCN+nVVVVTl8DCCGRgT51NfBpTk7OK6+8Qp86Qvg+/dnPfubhrBlC
YgL61NWIT9vb2+lTRwjfp21tbTfffPOYMWOcvhIQQsKFPnU18Gn4g5Ho05AJ36fd3d3fVHD6SkAI
CRf61NWIT8O8pNOnIRO+TwE+RC7sQEgMYIVP9+7dO8+MwsLCsrKyHTt2DAwMRLbEuAWX4ohc0unT
0IjIyR+r4PSVgBASLlb4dP369b4LTUlJOXHiRGQLjU/g03HjxtGnThERn45RsOf7TgixDut8umLF
Cl16X19fU1OT3EwZf4eGhiJbbhxCnzpLpHx64403On0lIISEi50+FXp6epKSkpDh2LFjkS03DrHa
pwUFBZkkM7OkpIQ+JYT4xn6fgtzcXGTYu3evLr21tbW2tnbt2rV1dXUnT5407jg4OHjgwIHq6mrk
qa+vP3funDEPwt7m5mbUobKy0vQ47e3tUPmlS5e0iYidkXjmzBl5OjAwIE9RIgpCcW1tbWpm7KtW
o6Ghob+/31gNlLJ582ZkwN+Ojg5vpyJMrPZpRkbGEBkaglLpU0KIb+z3KWQkswOamprUROjMuPBa
WVnZkKZNGEZLSUkx5tEe/MSJE9Ke7OM4cAcSu7q6tDtC7to6Q6Z4Wlpamp+fLwdB0aJgyDo1NVV7
fFwPDx48qB4Kei0qKtLVAQEO1Bz6OfUCfWoPofn0V7/61aFDh+hTQuIEm30KJZWXl+NViED1CxKn
TZuGxCVLliCUQzrUKXpVdYlrWnp6ekJCwo4dOyBfxI9HjhwRryFUlDw9PT0iXHgQYSmeIk9WVpak
qHUI3KdJSUm41lVUVCDMxJsaVnydoICoE0eAOhG94ilySrCMes6aNQv7Qql4L6gn/opeFy9eHNnz
PEyf2kVQPv3www9ff/31urq6JxToU0LiBOt8CpGtuBZoRSJT2AdRnpofSvIoi7prDwKrigqlwRYi
w+N58+Zp88CkiEahNnkqptaqc1iJfEWy7e3tkhK4T4E28ATFxcVIVEsUYFskVlZW4nFjYyMe48fA
kCYixmP5waBtNI4I9Kk9BOJT/Efh32bbtm1PP/30ExroU0LiBJvnyyCihLN0fZoSimoNK1RXVyNd
AkMEmx5FxBCWrutTRcJVtQ9URXyHMFOeBu5TXOi0eVAuKoBoVNdyC2Wj8qjh8KhwUUldHRCtaOsQ
KehTe/DtU/xU+/u//3v8oHrCDPqUkDjBOp8uWbKkSwGhJaI8GYNk2o0ok++QXxfPSsOpGm8iReoM
qSGYhaG045EgNY/SjGysT1NTk0dpgJWngfs0Pz9fmwc/AzxK3O3jvcvBUZbuvSCy9hhi8PChT+3B
1KeffPLJt771re9///umGqVPCYk3bOs/hUZlbA8sqVOq7xqqbby4rNXX14uXta+KVeFHPIUXjPUR
OarHCdynuuZl00QdMhXI73uJFPSpPWh9evny5ba2ti1btvjWaFA+XbBgQYBHI4RELfPnz7dtPBIU
JqGoblCuOMh01okpPT090B/iVjmaRJHY3eMlPkV0jJeKi4vlacg+DTw+NbY5WwR9ag/w6RdffPHO
O+/s3LnT6a8sISR6iXgjpI/xvTt27JBI7ciRI2qihJza6TOCNBSLm+BQPFbHFAlwori4r69v2Hv/
aWVlpUfTdykTanR9uNJX69unly5dksG9uvgaAXJ6erq0S+Nkesz6T1HcgQMHTCfVhgN9ag/4WPH/
4/Q3lRAS7djpUyA9ibiAq1aqra2VduAhszGxUPDwaPyo9oEK6lRWWWDf9/hedWytKE+7moQ6lti3
T4HMfKmrqzO+X5Q+PPqDATXXDpoaGp1EoxsYHD70qT0gPv3ss89aWlo2bNjg9PeVEBK92OxTxI8S
VMoEk2GNzmArRKDaOZuqmPAXMaAcFlEedsHfxYsXe5SBTHIcdf6p5JE5qhKNlpSUqBWA1DzKSGME
jIhwm5ub8/Pz1R0ljzefqvNPoVQUB1njAZ6OGTNGGpDVubQQKAyOOmAXGfSL+kf8xjr0qT1o+08v
Xrz42muvrV27NsDv12l/pKWlPUkIiQlMx/CEg9/1BsVo0JDafnvu3Dl1JSIVpGh7OaEnUaoW/BjQ
drxCXqJmLWVlZdpoEY8lRFXBGYB5A/HpsLI+km6ZJqhZO7EUkpUYXAu0bkWnKn1qD8bxvVeuXDl/
/vyiRYt0s02N+D35+DE2YcKEVYQQlzN58uSIj0eSie0+9IEL1DEF3QK8sn4vdIy/eGzcESo8ePDg
egVI2XR5hKHR9XuBtzV+pSzJIxNagXH9Xm83lUN0vHfvXtkdD0wXEkTdUEPJg/oMWXMzHfrUHnzM
P/3www9bWlrq6urwbQrZp5wvQ0gMYMV8GWIb9Kk9BLI+0tmzZ1977bUf/vCH9Ckh8Ql96mroU3sI
av3ezs7On/70pzU1NfQpIXEFfepq6FN7CO3+Mu3t7T/+8Y/pU0LiBPrU1dCn9sD7nxJC/EKfuhr6
1B7oU0KIX+hTV0Of2gN9SgjxC33qauhTe6BPCSF+oU9dDX1qD/QpIcQv9KmroU/tgT4lhPiFPnU1
9Kk90KeEEL9EiU/7+vrWrl2bm5srS+WnpqYuWbLEeAc3ooM+tQf6lBDil2jwaVtbm9wZ3KOYFNd2
sapHWe7edHVcItCn9kCfEkL84rhPoUu5D3hZWVlPT48k4gqG4FTS1du6ESP0qT3Qp4QQvzju04MH
D3qUu4UaX5KbpiFWZYjqDfrUHuhTQohfHPdpbW0tqlFaWmr6an5+Pi71unuu4fp25MgR9Y5s2nuk
Cu0KeNDY2Ch3ZMMRvN1Crq2tDS9pb5CKMBmH9Xartb6+PuTHX5SLym/evPnkyZOhvffwoU/tgT4l
hPjFcZ9CWKhGSkpKgLfbRrZp06Zp30JCQkJ1dbU2zyQFMbVQV1eHv1lZWbqjwbO6dOyFA2qPr7sV
+N69e+WA0hzt8RJc2wN9ag/0KSHEL477FBer3Nxcj9Kuu3jxYtjKGG+q9Pf3q52tiAoHBwcRqMJ3
SIEH1WywA65R0OKSJUsQY+IvEqUU3S3IIWIkIsaUp6Lg9PT0gwcPoizYdu3atR5llBSeSh7xKUSG
bHh11apViH8jf14CI2Z8unr1atTh1KlT9hQXLPQpIcQvjvt0WGlBLSoq0tYK/iotLW1qahq6tq21
srLSo8hUtzu0Ah2rysOVGdlWrFihzbZjxw4kQn/aROSEdmUcFHZPUtA1L4tS1WFR4lPspcvmCLHh
04GBATgF/4ewqg3FhQB9SgjxSzT4VOjo6JApqNrqIfbU9k4iJESisb8S8kU6TCdPxafNzc3aPKLL
lJSUoVFHy3gnqFyeiiglmNUibcI4pjZbfn5+hN53WMSGT/fs2TNhwgT8xaczODioe/XSpUv4CEx3
9JYecehTQuKEEc0WLNHjUxVEK4hMEYRCFh4lVkUEOqwIUeq8woBYGDqWI4hPje3GcCXS1WUiUASe
HjhwQJ5WVFTgKQ5lPL6UK2OWxKe64NcpYsOnBQUF3/ve9yRKhVW16Rs2bEgZ5dChQ2r6li1bJigg
XbuLRdCnhMQJI2ZbgEShT1V6enqysrJQSRluBD/6fi+q47z59MiRI0gvKSnBY8gR1zFcjdWRvao3
vSEHpE8jy6lTp3A+29vb8XjZsmX333+/+hJqhQ/o3XffxeMXX3wxISFBOlgl/e233x5SYluky2Pr
oE8JiRNMfRqgWB33qbhPO11FS0NDA14tLi4eVvpJPcqwpQCPafQpLozp6ekyoRVhqefa7tTy8nKP
ZmySN+jTyLJ69eqcnBx53NLS4hl165DizY0bN6o5Z8yYsWbNGklH3KqmQ8FWd7zSp4TECb596tuq
UeJTtetThwwiUmenSgvwiRMndNlwBW5qalIF6s2nw6ODixobGxcvXowHHR0durKQrtsFrkf1jh07
Jk/p0wiCczthwoTs7Ozlo+DcPv744/IqatXa2qpmxquLFi2SdJkXrKYvWLDA0nrSp4TECYH41JtY
Hffp+vXrPUonqdGSPT09Yka1i1NCSGmwVRkYGJBJNOoAJB8+lcFFRUVFiFKnTZumKy5BQVcTRKwe
zQAk+jSCHDp0CCe8qqpq3SgLFy6EX/r7+4cM3nz00UeXLVsm6YcPH1bTly5dKp61DvqUkDghKJ/q
xOq4TxGhzJo1y6PMQEFsiCARwtq9e/eqVaskGi0sLFQzQ3kpKSkeJWKF9QYHB9va2mbOnImUefPm
qdl8+BRIcaC+vl73kjrbFAEsLukorq6uTiSLQEny0KcRBPacP3++NkV6ybdt2zakeBOqlXR81ohk
1XRp+B1SIlz8A2/ZssXSelrt05cTEkL7FnPjxi16tolO+3RYWRK/rKxMtyqRGBYBqW7xXmhUBilp
gXNlDLDg26fqBFJ1vqoKrpyVlZW6muByp22Opk8jBcrFqTaOzl2wYIH0qMrs4BdeeKGlpQXmxVM1
bkU6HCrp+AeWdIv447p1jn9PuXHjFv3bfx83znGfCggGZblduBVxYkNDg3q7GR24xDU3NyMn3Ld5
82bdkkfDSneqbkleLUjHq9qeUx0QMUJX1KG6uhr21GlX1u8NcHVEq3G1TxHyL1++fGBgQJcOSyJd
aoX49NFHH83Ozv7ud7+Lz0UyIH3dunVLly7VpVsEfcqNG7cAtyjxKQkBV/vUL6iV6dxSb+kWQZ9y
48YtkO17ycn0qXuhT23gd/39cydOHPnoI+NWkJb2z+3tYW5333ij49cBbty4hb9l3XorfepeYtun
q1evPn78eODp1mH1eKScG25w/FLAjRu3kLcoGd9LwiG2fRo9cL4MIXFCCBpVoU9dDX1qD/QpIXFC
aCYV6FNXQ5/aA31KSJwQgkZV6FNXQ5/aA31KSJwQgkZV6FNXQ5/aA31KSJwQgkZV6FNXQ5/aA31K
CPELfepq6FN7oE8JIX6hT10NfWoP9CkhxC/0qauhT+2BPiWE+IU+dTX0qT2E6dOLZ89ePH2aPiUk
tqFPXQ19ag8mPh0eHvnoo4Wpqb955ZVPdu36dOvWS1VVv129+nePPfb50qW/f+CBP9x335fp6V+N
Hy8DBZGBPiUktqFPXQ19ag9XffrGGyNz547gQVpaCMt79nV20qeExDb0qauhT+3hP+NTKHU03gxq
Q6zq4+TTp4TEBvSpq6FP7eG/2nt/85urUWqQPr20Zg19SkjMQ5+6GvrUHq7pP/3qq5Eg7zDef/Qo
fUpIzEOfuhr61B5MxiMF3Pb7H4mJg88//08dHfQpIbENfepq6FN7MJ8v85vfnEpMDDxK/WNe3qU1
a4yxKn1KSGxAn7oa+tQevM0/zZw48V+feCLY7tQvMzIul5d//Oqrv+7uFp9Opk8JcT+pqan0qXuh
T+3B93oOA/v3/3tysnljb1LS5VWrvsjJMX0Ve/3uscf+/IYb/iwx0ekrASEkXCZMmIALchpxJ/Lx
0adW43d9pH/q6PjDffcZjfl/Fy6UDP/c3v4vzz33+wce+I/rrtPl+VFCwl/Qp4S4n+Tk5PHjx99y
yy2pxIXQp/YQyHqDv+7uNrb9GpdF6uvs/HT79uGHH75y442SZ+aNN34rKcn43dQehxBCiNXQpzYQ
+Pq9urZfH8si/fr8+YF9+6DgMWPGpJn1n3rrfiWEEGIF9KkNBLUevtr263tZJBXT8b2BjGsihBAS
QehTGwj2/jLS9ut7WaTwfUqxEkJIBHGLT//3KJE6oJ3Yf//TYOfgEEIICRNLfQpfZESIJ0aJ1AHt
pKCggD4lhJDYxlKfRhDVp1YXBN59910bShmx0qcCfUoIIbZBn+q4fPny6tWrv/zyS6sLGrHepyrB
+pTOJYSQYKFPdbzxxhso5fTp01YXNGKjT7UEIkoGs4QQEiz0qY4tW7aglD179lhd0IhDPlUJ2acU
KyGEGKFPtXz88cdSypNPPjk8PGxpWSNO+9QHHMtECCHBQp9q+fnPf64W1NHRYWlZI/QpIYTEEPSp
lpqaGrWgv/3bv7W0rJEo9qmHPiWEkCChT1XwRp64lt/+9rfWFTcS3T5VCcGnFC4hJA6hT1Vefvll
nU//4R/+wbriRlziU5WQfUq3EkLiAfpU+PLLL9esWaPzaW1trUXFCe7yqUqY020oVkJITEKfCu+/
//4TZnz88ccWlTjiWp/6hcOZCCFxCH0q7Nmzx9Snhw8ftqjEEfqUPiWExBD0Kfj9739fUVFh6tOa
mporV65YUegIfUqfEkJiCPoUvPPOO6YyFS5cuGBFoSOx61MhZJ/StoQQN0Kfgu3bt/vw6YEDB6wo
dCTWfaoS5nQbipUQ4gro08uXL/uQKbDudjNx4lMtfkXJ9mFCiEuhT+WGMr6x6HYzcehTv7DjlRDi
UuhTuaGMbyy63Qx9aiSosUy0KiEkeohzn6o3lPGNRbeboU+N0KeEEJcS5z7V3lDGN1bcboY+NYU+
JYS4kTj36eeff/7ba1EL0qUzPnWEMKfbULiEENuIc586WNAIfRoM4cy1oVgJITZAnzpV0Ah9GhIh
+5RuJYRYCn3qVEEj9KkFsO+VEOIU9KlTBY3QpxZAnxJCnII+daqgEfrUAuhTQohT0KdOFTRCn1pJ
aD6lcAkhIUOfOlXQCH1qC+H4lGIlhARONPj0q6++ampqeuaZZ9asWXP06FHTPI779MKFCwc0NDc3
h18WfWonYU63oVgJIb6JBp+WlJTALOvWrYNPx44dW1VVZczjuE+lbpmjzJ07N/yy6NNog32vhJCQ
cdynb731Fqpx8eJFedrS0oKnH330kS6b4z6dP3/+hg0bIlsWfRptcDgTISRkHPfpL3/5y+3bt6tP
IVbU6h//8R912Rz36c033wzXR7Ys+jTaoE8JISHjuE91bN26FeYyLpbrrE/F8kuWLBk7dmxSUhIe
fPrpp+GXRZ9GIfQpISQ0osqnzc3NCQkJjY2Nxpec9am0Qm/atAlifeutt6ZOnZqXlxd+WfRplBPm
dBs6l5C4Inp8euDAAcj07/7u70xfdby9VxuQ/vKXv/SYNUoHC33qFsKcbkOxEhIPRIlP161bB5lC
qd4yOO5TLX/84x9x6g4ePBhmWfSp6whnrg3dSkhsEw0+raqqGjt27C9+8QsfeZz16aZNmx5++GH1
6enTp3HqPvjggzDLok9jiaDGMtGqhMQejvv06NGjHqVr8hcahoaGdNmc9SmqhEpKx+6nn35aUFBQ
XFwcfln0aSxBnxIS5zju09LSUmOtjLGq4+29kOn48eOTkpJQvZKSEo7vJUboU0LiGcd9GiCO+1T4
6KOPjLFzyNCnsUpoPqVtCXE19KlTBY3Qp3FAOHNt6FZC3AV96lRBI/RpPBGOTylWQlwBfepUQSP0
KdHAvldC3A596lRBI/Qp0cDhwYS4HfrUqYJG6FOigT4lxO3Qp04VNEKfEgMh+5SqJcRx6FOnChqh
T4l3wplrQ7ES4gj0qVMFjdCnJDDCnG5DsRJiD/SpUwWN0KckcrDXlRDHoU+dKmiEPiWRg2OZCHEc
+tSpgkboUxI56FNCHIc+daqgEfqURBT6lBBnoU+dKmiEPiXWEIJPKVxCwic6ffraa689ERhtbW2R
LZo+JTFDmNNt6FZCgiI6fXrx4sUAfXr58uXIFk2fktgjnLk2FCshARKdPgUbNmzwK9OdO3dGvFz6
lMQbQY1lolgJ8UbU+rSlpcWvT995552Il0ufkniDPiUkIkStTz/77DPfMq2oqPjiiy8iXi59SuIN
+pSQiBC1PgV1dXU+fLp3714rCqVPSdwSsk9pW0I80e3Tt956y4dP33//fSsKpU8JCcqnDGMJEaLZ
p59//vmTTz5pKtO1a9d++eWXVhRKnxKiJZy5NhQriSui2adg586dpj59+eWXLSqRPiUkKNjxSogQ
5T7t7Ow09enFixctKpE+JSQoOJyJECHKffrFF19UVFToZFpTU2NRcSP0KSFBQp8SIkS5T8H+/ft1
Pm1pabGuOPqUkGChTwnxuMGn58+f1/n0k08+sa44+pSQcAhnrg2FS1xN9Pv0ypUra9euVTW3ZcsW
68oaoU8JiRAh+5RiJS4l+n06cu3tZiJ+Qxkd9CkhkSXM6TZ0K3ELrvCp9nYzEb+hjA76lBA7Yd8r
iRlc4dOR0dvNWHFDGR30KSF2Qp+SmMEtPpXbzVhxQxkd9CkhdkKfkpjBLT797LPPLLqhjA76lBBH
CM2nFC6JHtziU/DGG2/YUAp9SoizhDndhmIlTuEin165csWGUlpHsaEs+pQQH/i1JJuISVRhqU8f
fPDBDJKRUVJSQp8SEnHY90qiCkt9CpUMkaGhzMxM+pSQiBOUT6lUYjX0qQ3Qp4RYAX1Kogr61Abo
U0Ksgz4lUQJ9agP0KSH2EOZ0GzqXhAN9agP0KSE2E85cG4qVhAZ9agP0KSFOEbJP6VYSLPSpDdCn
hEQh1g1noovjE/rUBuhTQqIQe3xKq8YP9KkN0KeERCdW+JSNxnELfWoD9CkhUU4IMvWWgf2wcQt9
agP0KSFuIWSfcnQToU9tgD4lxHVY51MqNVahT22APiUk9gjHp1RqTEKf2gB9SkjsEaZPadXYgz61
AfqUkNgjIj6lUmMJ+tQG6FNCYhUqlajQpzZAnxIS89CqhD61AfqUkJiHgSqhT22APiUk5mF3KqFP
bYA+JSTmiYhMHx4/PjU1NYW4DXxqaWlp9KkN0KeExDwR8SmumeOJO8FnR5/aAH1KSMwTvkxzb731
tttuGybu5Jvf/CZ9agP0KSHEL7cpOK0FEiL0qT3Qp4QQv9CnroY+tQf6lBDiF/rU1dCn9kCfEhIn
FFR/OLu6C9tDa3uC3Zc+dTX0qT3Qp4TECXNqLsyq6Zr//d451ReUrfuhjb8IcF/61NXQp/ZAnxIS
J8Cnc9f1zF13YW51z5xne+dv+gVSZtdcmLf+g4c2bvS9L33qaqLWp3s0NDc3d3V1RVZwNkOfEhIn
KDLVbpBp77z1EOsmhKuzn+2ZWdXrbV/61NVErU/xr5WSkjJJITExEU9Xr14dWcfZCX1KSJxg8Ono
VtMzr7pn5rO/nl3Tg4h1TnXXQzVndfvSp64mmn2KyFR9+uKLLyLlzTffjJDf7IY+JSRO8OrT0W3O
up7Z1T3z152dU9M9u7pbO3KJPnU1bvGppPzkJz/Bg9bW1kOHDu3fv//xxx9vb29HypkzZ6qqqpYv
X75t27b+/n6kNDc3q7sPDAysW7fu3XfflafYfdeuXXjw9ttvI+b97ne/q+4lYN/vKaAUScGrOMKp
U6eQuGXLlkuXLgX7dqz2ac4j9X6/xTG8za46X/A/foVtdtU5xyvDjVuA25yaHt3IpdvSJ9Kn7sUt
PkV8CmugIDyG2rKysiZMmHD//fe/9NJLhw8fTkhIWLZsGdLvvffe7OxsZIN58dZEfPAjjrZmzRo5
1IIFCyDflpaWxMTEp556CnvNmDEjJydHMsOw2BF/kT8lJUUamc+dO4cj4D2iROwe7HvZc3TA8W8u
N27conX7r5FLdz74GH3qXqLZp7r+UwkqxadIEbcC/PupXatwIsyIuBUxKSR7/PhxJEKaOAhUO6TE
qtj3zTffRB7VjDgUotS+vj7EsChI9gLyFGGs+DTkDlz6lBs3bgFsFwp+cIE+dS/R7FM4Th3iC/3B
jwhFxaeIEyXbqVOnkFNtywUbNmxA9IoH8+fPR048QMT6wgsvIFt/f/+hQ4fw74pEBLZIQZ5t27ad
OXNG9kU2RMHaocU4P1u2bBGfIqSlT7lx4xbxbU41/nbPX30xu6CUPnUv0exTXf/pokWLJMaEJefO
nSuJra2tyAnfqdkQxqIyeABRQrtdXV0ISAcHB5EImcLRULPkhJ0fffRRnIGrQwjmzkV8KpHv3GtB
NcSnKCu09zIwePnO6Q9+evlL45Z5133vnukNc0u+7a75685y48YtSrZATVrTM+cHXTOf/bUy3PfC
3GcvpN8+mT51Ly7yKVSISHPoWp+iaJ3pVq9ePWPGDDyASRHSIuSUzMuXL3/qqacmTJggYeY5hSGl
iRgpCEsRh7744otqr6vw5ptvIqoN06dD1o9HSk6746Gas9y4cXN8m/uf6zl436qvju+du+6Dq+N7
ry6m1K3OSOX4XlcTzT6VhlZh//79sAaEOHStT4GMEUIEKpZMSUnZsGGDvASx4unGjRvxWI4ARJfL
li0rKCiQxwMDAzgPiGfxRhCfSn6AeFa6U6Pfp5wvQ0iU4MekVV1XV0y6Ok2me07NB7p96VNXE80+
1YJIc+nSpRCf0aenTp1C3Ip/QiTChhClGmBWVVV5Rmet9iqRLF6Vl86cOSP/utgLQSv+ysFfeuml
q9NPcnKgaRxNemDpU0JIgJh0jyIIre6ev+ns1Ukxz3bPfvYDbyv60qeuJmp9eu5aRHZCf39/7+jg
XgECRRSJCFQdWSRgL+yr6rWrq0s7zxQhLRT5k5/8RCaxavc6fPgwxKoucogj4DgSAocGfUpInDBn
3QXdKKOrywzWdM+q+fChjfoFkXTQp64man0aY9CnhMQJ8KlulNFDq38d4L70qauhT+2BPiUkTpi9
rmvW1Wi028e6996IBp/29fV1dXX19PQ4Ww03Qp/aA31KCPGLgz5tampavHixzB8UcGEpKipCuiP1
8UZ9fT10U1JS4nRFTKBP7YE+JYT4xRGfIhqdOXOmWgdIAdfzlJQUNaWwsHBwcNDmWnlj/fr1qNK8
efOcrogJ9Kk90KeEEL/Y79Oenp7U1FQUnZSUVF1dDbeqL507d66ioiIhIQGvFhcX21krH9CnhD4l
hPjFfp9CTB5lsfSTJ0+aZjhw4IDUrbm52c6KeYM+JfQpIcQvNvtU7r3l8efKxYsXIw/+Gl/Cxe3E
iRPHjh3DXzz2cZDBwcH29nbkRNjru1YwO7KdOXPG9FUfPr106VJHRwf29fbbwGroU3ugTwkhfrHZ
pyLK/Px839na2tpqa2uhKm0i/Lh27Vrt+CU8Roqxp7Wnp6ekpCQpKUnNmZ6e3tDQYCwIsTBeUrNN
mTIFRUsEDUtKHlOfDgwMlJeX64rYu3dv0GckPOhTe6BPCSF+sdmnuHSg0M2bNwe7I6Q5a9Ysj7Jy
XXFxMTSKv9LTinStUhFmSv8sXFNaWlpZWSk7goqKCu0xYVhJnzlzJrKJgnFM2d2HT/v6+mBetYjq
6uqioiKpDI4T6rkJBfrUHuhTQohf7PQpTCeFtra2BrtvWVkZdoTptC2rJ06cEPfhVUnBpU9MB4f2
9/erORGHiu8aGxsl5dy5cxJdauWuutjj06dLlizxKMGsds4s8suvhSNHjgT77kKGPrUH+pQQ4hc7
fQrjSKHGDk0EmF1mDCk9pDCj2PDgwYO6HZHiUYJWsWdTU5NHGTlsXB1i1apVHkWC8hQRrsesVxQ2
lEp686ksrg6MfaYIVD3KZJ8QTk5o0Kf2EJpPO9/r3fV6D31KSJzgiE+NI3/27t1rWj2ZTSPShDuG
DAOQkCI9qohA8bSiosLjZa4N9CfHFNXm5ubi8Y4dO4w5ZSasN5/W19fjKXY37tjR0eFR5H7p0qWg
zkzI0Kf2EJRPz3f1Nh7tfWLXf96cgj4lJE6w06eq0YztvTDmJA3qGCHxaW1trUdpwjU9rHSPwnp4
XFRUhMeIPU1zyjFFlNLYq0pTi+/xSOXl5R5F7vMMqItUaCfVWgp9ag+B+PTD7t7Db/ZW/rin8Llr
bvZEnxISJ9jpU0RtYrG6ujrfOeEjqZ6IyfcMUNGf+FT72IgcU0SpfWx6QG8+XbFihd+zSp/GGL59
evTt3h/8tKd4k/k9iOlTQuIEm8f3Svzod76Mzqfwr0cZhWuaWaJCGVZUXFzs8TLIFjaXY7a1tQ0r
JsJj07WCUT2Pd5/KyKgoWc6XPrUHU5/+0+AXMxb/8M+3mGuUPiUk3rDZpzJeyGM2skiLzqeyFy47
xn5JpMioWjEjTOrxMiKovb1djikjlyQIra6u1mUbHBzUNQXrfCpyz8rKMhaBfTs6OrTjiq2GPrUH
rU//5Xdfvfb2vz7e8JFvjQbl05xH6gM8Gjdu3KJ2m/7tHziy3iCuId7mlUCRMqxI9anquN27d+sy
I8WjDOgdGBgYHh3ylJCQYBzyJO20amgsk09TU1NlRxXEuVK03/G9xl5gyZmSkjLkc+GmCEKf2gN8
+od/u9J6+ndrGj92/DvLjRu3qN2m/Zl5b6NFqIsheJQVBWFVMdqQspAglKTOAM3NzVUXapDpLToL
47EEp9oGXmn+RRHaWTmqJdUGXhQ3bdo0MawsxISykE0m5vjw6fDo/FPUEzGvmtjc3CzSr62tjfhJ
8wZ9ag8zvl39rQ29jn9VuXHjFuWbzT4dVpQqHZ3egJhgMW3rLq5p6i7wLIJNmfACioqKhjTxoOpr
mLGwsLCkpASykJy6cUqIYbWLDQrYxe/6SP39/Wrp0LG2MviFMGRXcDpMn9oF4tPf/Pbf/lfbpdJt
/+z4F5YbN25Ru9nvU6Gtra20tFSNRsWAiC4RJMKJxvy4rO3YsUONbUWspkvmIuBFxKoeGYeFc02H
8iInioNDIRTkaWhoQCk6n5reTxyuh2dVU3uUHlXkHLJRpsP0qV1o+0/PffSHnf/ns0VbLgb4/Xr3
TK/vLfm2u+avO8uNG7cY2CZmTbVTAUYgNVkNKaj8gdxwHF5GTtPVFbztjoun+DHAW8ZIZXSdsLZB
n9qDcXzvv1/5j3cv/L+8v/ifutmmxs3vyR8zZkxy2h0P1Zzlxo2bq7fb77jb5vFIUQICWMjIOL63
tbVVOmqH7I00Q4M+tQcf80/Pd/W+dPzqakj/7Qeh+5TzZQiJAey/n3iUIGsY4lIm01GFjo4Oaewt
Ly93sG6BQ5/aQyDrI51+v3f3kd6V2+lTQuKUuPXpkGaAU1ZW1rx58/BXnupuABfN0Kf2ENT6vW+f
7qlv6v3O3/TSp4TEFXHr02FFqQ0NDTNnzpR5LgkJCfn5+faPKQoH+tQeQru/zNG3eze+5P/k06eE
xAbx7NMYgD61B97/lBDiF/rU1dCn9kCfEkL8Qp+6Gqt9Cl9kkszMgoIC+pQQ4hv61NVY7VPiG/qU
EKJCn7oa+tRZ6FNCiAp96mroU2ehTwkhKjb4dHBwcNasWWVlZWpKfX39+vXrTRfU1YE8yKm96zce
r/fC3r17fSwSeOnSpaysrBUrVhhfam1tlSP09PT4rg8O0tjYWFpaOm/evClTpuDvqlWrmpubhwxT
bHbv3o3ijLeNiyz0qbPQp4QQFRt8CuMkJCRoTSfLyOvu9mKK3NtFK0G5jakP4DjtndpUjhw5glfr
6uqML+Xn58u+a9eu9VGZtrY24/1ohGnTpunUCfPibebm5hpVG0HoU2ehTwkhKlb7tL293XOtEIcj
4dPU1NQVBhAFy5vC8Y0LHEHrHrNV7k+cOCG7eJRbgZsung+6urrkXqvIWVtbCzsjdkawXFlZKemo
Un9/v3YXxMtIRzDu922GDH3qLPQpIUTFap/CcQhOdQFj+D7V3o1US2Njo7yvzZs3616aMmUKokvj
LuJZRKay3uCBAwdMj1xeXu5RblNuNDUiU3gNr1ZUVGjTEZnimHjJurvP0KfOQp8SQlQs9ak0sS5Z
skSXbp1PQWFhoUdZg1ebiOgSido+XAHRKGJSj3K3UylLt6OK3Hd1x44dpq9WV1fjVaOvkT/Adxoa
9Kmz0KeEEBVLfVpUVIQitKOJBG8+RWwIUU5SKCkpOXnyZAg+RaTpUVpltYkNDQ0es9gTKR6lqRax
JIJoOSemg5okejWGvQJ2QZxrfEf9/f0Iz300I4cJfeos9CkhRMU6n/b19UElSUlJRpWY+rS0tFSq
BEfIsB9cZ8TIQflUjpObm6tNLC4uRmWM7a5y/MrKSnkqPbAwo7fDwoytra3+37yGmTNnesx+VESE
SPk0LS1tIgmevLw8+pQQIljnUxmNY9p8avSptItCvthLUhDxSROrJxif9vT0GLsyEXvikmWsCTLL
8dWAVOqMzMZOUnU8kke5vxui4Obm5kA6RiVeNp2nEz6R8ilxEPqUkNjAOp+WlZV5DEN0BJ1P4TsJ
SHWTWeA7uZOa0acI+rqu5cSJE5CyHBl7aUdAHTt2zGPWvCyNyfn5+WoKNCrSbGhoMFYbRSDs1Z1A
pFRXV/uYZyo3LoeCfZ2sUKFPYwD6lJDYwDqfSjun6WwRnU87Ojo8yu1HjVGh2DOo+ac4DhSmPYhE
iO3t7abV0A0xkuPrmou1tLa2lpeXy75akGg61VTm4wArulDp0xiAPiUkNrDOp2Ictf3W+JLq0927
d3uUqSjGnNIOHIhPU1NTEWlWVlYaF3OAHFNSUnSJ0KJHkS9sro1z1Rk3Rv/qQGa8u9LSUmlh9piN
ZB4eHVoM8MD3AUOAPo0B6FNCYgOrfWo6ekfnU2l3Ne0SlQ7NoMYj6ejr60P+kpISXTpSfJ8ZiDLA
IgYGBqRx22NmYbwqL9GnxBT6lJDYwGqfmi6PoPNpXV2dR+kSNeYM36dyBF2YDMdJzyxC2nkGZBwU
MqjrHeFXAcqtra31VsrQ0JC8KWMexqfEN/QpIbGBdT4VKwXS3tvU1ORRpskYc4pqw/GpxKGIUrWJ
0oyMEk37NHt6ehISEjya8VFSDZmm6q0gVMljNupJ9aluNcKIYLNPz549u2/fvq1bt+7ZsweP1fSW
lhYE5nhw/PhxPI5giefPn39Fw9GjR7XlBstxhQhWLyLQp4TEBtb5tLi4GMevrq42vqTzqSx64DFr
HJYJoeH4FMbRjuAVZAF843JJKjIvVR2Ue/LkSTld3tZHQsArA4ON8bh01Jr+WggfO3363HPP3XTT
TcnJyffdd99NCrCqvPTAAw+sXr0aD5YuXYrHIRwc3sTH8eqrr+rSZf1nLYmJiStXruzu7g6hlKUK
IexoKfQpIbGBdT6VXtHFixcbXzLOP1VH1WqH+MriRZ4wfCpXY91dY9QBt21tbd52lEku4MiRI5Ky
ZMkSjzJ+Cb8QdNNOz5w5I4OZ09PTjQFvfX09XiosLAykwsFim08h0+uuuw6RqTyFziA1pCBg7NX4
NOT4VD4pRKC+0zs7O1EH2Oexxx4LoZSojU/Hjh1r45eeEGIJ1vkUtvIobaTGl4w+RYgqU1DxUl1d
nYybhbxk6GzIPhWn6260Kgvg6xYk1KGu66sO2UUNp02bJictKSkJAkVNSkpK1BmpuCqaCloanH30
vYYDzs+tt95q9QX/7NmziEaffvppbSKUmpOTg/fVq/EpAsz9+/erefAY6XAxfsNICk4REk+fPv38
88+vWbNGDUhrampwlp544gmdjk09K83v0sIMcHAUgaPhB5ikHD58WFsNVBUW7ujoeFVBTdy3bx+q
h5qgPmpmZMChUB9UNeQzFhT4EHF67f3eE0Iij6Xr94oicbnTpZuuN9jV1SVdkCpFRUXe5ssE6FNY
D5rTdnqqojRtiNZSUVHhUQJS9SbjiJ0R6qqzY7QUFxebLumAoiW/6S1ZwwcHz8zMtPqCD+/gLUgo
aoqxvRe2Qkg+fvx4pODDQkQpIoPXsrOz8Y+xcOFC+bgl5sVT+VjVNmTB1Kfwu0f5iSJ1w8GxIwpC
cYsWLULizp07ExMT1Z5W5MFTSFNt78VLd999N6qBp3l5edgRtkV6WVkZ1PbII488/PDD2GXXrl2R
PI9moCbjxo0z/acihLgLS32KK57H7CbdMBTsabpYHy5ru3fvbmhokIknUBhyakfy4DFSdOOLvAFl
6wZEQXAyz9Tv6gpSNNCtMoEjoG447ObNmxEoHTx4UBWuEbnDDn4YBFLbEMB1OCMjI7TOxMCB8vAu
fGQw+hQfPcSkhqUIPFFP9VAQnKQjP7zWG3B7rwpUiBLPnz8PFUrRvUqgCrdCpkhH6du3b5d0SBaK
7NX0nyICTUtLE+FKoI0aIqRVW7AB4lYcJJzhT4GAKBgf4je+8Q0nrwKEkEhgqU9hvaSkJN/DYmMb
6XXVNThHEFyKEe6pLZ8WEYJPEZzigTouV1po4Q7dobAXzNgbvE9hQ+x7+PBhvApvqgUh2JSu1ZUr
V86ePbtXCQARaUpTsOpT1A2hqHo0kSZ2ycrKUg8lUbm23dgKUND1118vs7cIIa7G6vuJy41BTWfN
xDznzp1LSEgIfChyCMCn06dPNw6LjSwyMMzY3qtOkzH6FH8hygeuBfkj4lNp70X8uGvXLjzQlSKi
fP311xFsdnR0QOWQr+yo+lTCW11Z0mKsO5rVPn3hhRfwFr7+9a87dgkghEQIq306ODiIaxd+9sdh
iLpixQr41Nh9HEHg06lTp+7cudPSa740nxoFhND44Ycf7jXzKX5FSBOreoTOzs5eQ6gbmk/V8UgS
n2rDc5xttfU7JyfnueeeU+vW6z0+xQ8GeBPx6X333acm4jjSqWop0k1PCIkBrPbp8GgfoukdW2KY
kydPyuQaS0uBT8eMGfPtb3/b6st+VVVVYmKi2u8J18BHCABhtF7v/afq5JSnn35a+iK9+VTuiaAO
0FXR+RReRkyqzpeR/tO//Mu/lFchU5SCqspTyFTuAq8KV9t/ih21/afl5eXSwKuWhariDVrdln7H
HXc4+f0nhEQOG3w6rCjVohtqRy24Djc2NlodlcOn99xzz+TJk60ekoTjQ1v4h8nIyIAxISPoFXGi
vGo6vnfRokWwG/7Onj0bYpKxst582qt0iRqjYON6DjgUZKoOE0JcCb3m5eUhHJbWWkhWXkJEjEpq
15fQju+Vd4Gn2QoSPsOq2GXhwoWFhYUoCEa25GyOgkJTUlJQDQe++YSQSGOPT4lFwKcIwaZPn25s
KbUCGVAE5e3cuVMEJHhbb/DVV1+FkqBd7VxRbVWlzVYeI0TFwV9//XVtibr1BnFA7VxR9ZioT01N
DcJb3e8KHE0bYGrXc0BOuBjVg+hVBct7QXD9/PPP+5gfFCl+9KMfeZSZy05fBgghEYA+dTXiU/xd
uXKl1Rd/EnHuvfdepy8AhJCIQZ+6GnVpnYyMDKtnSpLIgnh83LhxEydOdPoaQAiJDPSpq5F1dSZP
npyTk/PMM884rQgSBH/6p3+Kz44rORASM9CnrkZ8etddd+FvZmamuh4RiXJaWlpuueWW7Oxspy8A
hJCIQZ+6GnXdVwlRly1b5rQoSEBIz2lycrKj335CSCShT12N6tOpU6cWFBRkZWWpw2VJ1LJr1y4E
p5mZmY5+9QkhEYY+dTXa+5Lg+jxu3DgEqmz1jWaOHj0KmeLzkvscEUJiBvrU1Wh9CplmZGTAp3l5
eRzrG53gp87tt9/uYUsvIbEIfepqdPfNRIg6Y8aM3NxcuQ0oiSq6u7unT5+ekJAg8SkhJMagT12N
8T7U8OmcOXOg1OLiYkap0UNnZyc+FHxekyZNglId+bITQiyFPnU1Rp96FKXOnj0bV++8vDz2pUYD
x48fz8zMTEpKwl/Tj4wQEgPQp67G28V5hsLkyZMzMjI44tdZ9u3bN2HCBHwoqampiYmJ9n6/CSH2
QZ+6Gh/BDkKhSZMmyYjfZcuWMVC1n7a2tgULFuD75eEAJELiAPxypk/di+/GQxnx++CDD+bk5ECv
zzzzDHtU7aGzs3P58uVpaWk33HDDtGnT8MC2bzQhxCnGjx+Pa/J44k4CmcM4depUua02rIqIdeXK
la+88orV90uNT86fP79///5HHnkEv1HxtcrLy8NnlJSUZP33mBDiPDfddFNycjICmRTiTgL8oO+6
667JkyfjAa7z06dPR7i6ePHinTt3vvrqq+3t7dRraECgOHv4fbJ169aHHnpo4sSJGRkZOMk4wxMm
TODQI0IIiVXw8wmxqqz54FFCV3h2ypQpsAAMe+utt44jgSHqvP3227Ozs3EO09PT5XziHKampjr9
ORNCCAma/w//iH3pZW5kc3RyZWFtCmVuZG9iago1MiAwIG9iago8PCAvQml0c1BlckNvbXBvbmVu
dCA4IC9Db2xvclNwYWNlIC9EZXZpY2VHcmF5IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9IZWlnaHQg
Mjg3IC9TdWJ0eXBlIC9JbWFnZSAvVHlwZSAvWE9iamVjdCAvV2lkdGggNjI0IC9MZW5ndGggOTAx
NiA+PgpzdHJlYW0KeJztnU+I61qa2L+FFlp44YUXXnghSEG8MMQQQwwxEzEO1KIChpjggQpRwJBa
eGFCkfGiFoKYYBIz1MKLCvFCECc4YIKH8YAXlcbdmMEkHigSJ7h7PDNi2v3a89r00/So32i6NcPJ
OUeyy1Xl+67sUpVUvt8PbqkkS0enpN89f6Tj8wG8IPov/u1/Hi++Nt6er/U//sF//OfJl1lAfEB/
hzt4KN9/nsnEf/ijX5B35dd//tXvFsQA7sepY7/vffSE8TSL/+TPvg0kGz/503+fCOamnDCh9+3v
z34VWEZ+OmtGg7oxJ0rIfYt8zwo0K/NZMbh7c4qE27e/83XQefnluI3NOB8JtW8X79xL2Mv/+D7W
qf4RZt/+TbB16YYf/CEK5xsh9u2fhkM3Qr7/faxS/SK8vv3dvww6H1t+vx3wXTodQutb5GdBZ2OH
72Ev1SdC69s06Fzs8sv/h004fwirb//4r4POxRP+ZzPoG3UihNW3Pw06E8/43/hqyxdC6tu/DFu+
fogFnC+E7b4yqG+Bv1d4wQ/xmYgfhNO3f/DroPPwgodC0LfqJAinb/8l6Cy85FfdoG/VSRBO3/48
6Czs4U+CvlUnQSh9O/uroLOwhx8dO8RcGGWPPDKechajuLtMv0ycpt1VAPLHJL5J+B0JpW//Lugc
7OOr0nFXONIj8pE3Z67wxUYLaU9Cdxr3raQfkzj6xjH+W9A52Mev6kddYHmuP9Mkwn5Ed1d2cLcL
fLuuPDnM9e3JoZrGf1de+BYVdhICiMGTVXEn8c02eI93KKH0bRx0Dvbyu0dd4NubJNdkXOWr2XGL
9OByScxbKsSNSabNLlTH9BO6hIsFsdoRiA1sohdgbK/5U7+EnoDkhJhNmlCkZ5N5jiZ3NSfmNTRN
U6dJF9e2fq6zCn98yU9TXxMyOYP40CaLCxDuLLKm54/3bTKlFbB+ZRkPNHGWMNs2z7L80QQrPhj1
3YTSNz3oHOzl4chL7BRLTed5imwPz3PntiKkFk0oWTKU7BGorHTSRpC1r4SzWRuak5igGpHE8jrm
JCDBvB9LjGlCw4kk1swz0Ff56A05i/V6Euhq5HopCXNaAGdtfsSlkYXkTIO7+5jYMMTyUoJLkoTJ
OCGqRhyozEWWOE1YmI0TkTpLcJmPquTN36KE0rcwdk9f65uLTGgfYMCerVyaMGTjnHqPvnWGdFmw
I3cPSRCTwqbKo1pkmQkZIidJhm6YqaBTuUSaMKtPdZXXpzX6r9XnR2TO6Y/OCHrTM5bQ9YoWYKlI
lnpL964CqQGvT2nCMlds3gT9htbQR7c0PRNK334edA728tWRl/iZb8C+9Kvr+opIVBQA9dG3qUm3
L0k6uSD6bRp2fFPW7BciF8mS7mJpzkdPfUvYOWHtPpW+aA2XZASZJVncpiA2JavOOShEZwe3gbCD
Hd+UFdtdG24TfGNC6ZsZdA72sj7yEu/xTZMZ4uKZb5Mu3x4FIafO7PSOb7QwBMe3PNsjuc83GNwV
1k4voWY2S0maIAhyfWbTdl26NiZFxZadg3d944O/un30LXT451uP9Q8KmtC5p8vBCK5YIXM/gjar
suVupEEb/YKh7PjG69EskSXCakqttNe34rpz65xlzvoZoxE0SzQhS6nQuhImWorQalXoXOz6lmEJ
C0sVfQsdr/Ot67jDfcvYmlxatSBlNuQ6rfaypCk3VyNImlqusOpAfVWSa7R8W/TzTgIS9OeFwoz5
tSrl2mZqq0dLLzPfLq2rOIhr230gPJxlUk1rAs1VMafaZ0W7nFOsIgwWRVkzJce3Rf+cJTyYF/KD
VRx9Cx3H+ua8FnB9S4/Yz0xPf6jRqi8z1Nu0vwDKdN68oGVTuqfPVAGEmwd9SFUrjO6cBOIQac6n
FzQhofag92mR1GXlHF1PDkdRmnSkw15itDddmniXpp8fioJKE5IByhN9Qos6ka72aGZG7GCaOEtY
VGcLTXpM8I1B3zxzrG+fQRv5ltTk2rek3gr0zTNh963SNsL/LQv0zTNv5Fu55lNCjWHOp5TeEPTN
M2/k25cF+uYZ9M0H0DfPoG8+gL4h78nfBp2BPaBvpwv6hrwn6JtnvpGQV4PtN89gf8EH0DfPoG8+
gL55Bn3zAfTNM+ibD6BvnkHffAB98wz65gPom2fQNx9A3zyDvvkA+uYZ9M0H0DfPoG8+gL55Bn3z
AfTNM+ibD6BvnkHffAB98wz65gPom2fQNx9A3zyDvvkA+uYZ9M0H0DfPoG8+gL55Bn3zAfTNM+ib
D6BvnkHffAB98wz6diBXsZfb0DfPoG8HQux+6XkUT/TNM+jbgbCLZmp5YXcb+uYZ9O1A3Ou2vN2Z
pRV98wz6diCPl25+I7nb0DfPoG8H8uTqjZ3eA/qGvBO894C+Ie+HqaBvyHvxUEtg+eYdnI/rQJ5c
vWUjje23g8D+woE8XjqjLbvb0DfPoG8H4l43q194fMuAvnnGP98ij2GURQlAev7S55G4GzEmvudV
JCV6dDzm+KdC0aSzxyb5An7VRuUnZ0LfPHOUb5pzrPxkI48e6cDiBX5HVL6R6i61Fx9F28ADp94c
LEiq8ZjwC9y4cn7g9BCegr555ijfkizC7Wz05B3ic9/kT4e9SkvOco9v7Egpe0wMSXX0mPBzBCN+
aHKfpLEn2iD65pmj69OKQf+XZyV37bya476lKkp849sZi0oPchyEi+oFdTOZzFb4fWdaREsViflG
PyvSmldKxpWKBNEqkePUN5lUpRwrReJu9Kx0mSchFq+LEbqav75kKe0knNUeZJ7wY4Llq03uctNj
/0pvoG+eOTr+qXEFPAgzQ+ivO4sH6lvT6g7MglufXli0fZa1E7GZrs1nMdBmpnHJdqfVnrScdZdL
DSLjpTZbJECdLPtzK5t+IKNzWp+OyIMy6NFd231+gluj27OGIM4etIdlHLpLbWTJsJvwvW6MWMJx
uk2fx0GdrvpzM+Nktt54pVCfAX3zzLG+3S5YbeqWbyUzAZGZDrJNb3DVEB3fhBVVsjWE9jQCwrgN
mpUUeBVMteiMBUhaGtzO6Wf3PVDtFAjTO24qa7/R+rRoRUA0CuyABIsZXiCxgiWAMCzGWbjwVu1p
wqw+pQl3+bY+TTAJwvzOyexEfqVQnwF988yRvkXMq521DiuKKjq05rRdd0Fkt7/QHIOwLoHRoltb
a9Am7u5UC146DjWYd+hnTQtUFsRZ03Z9E9dlKK6dNqIAkXSNSEm7X6LNQtGYlCW69UnCrm9mmf5e
sgV16iTIiJlPW5q+g7555kjfylZkZ403/C900EydUXR9SxKpsBaBrPjWxxi8VAveH6A6kLXzGbPl
mW9wO4LBrXPEtU4WfSJBYWzbQwkyfZM85J4m7PrGE5aJtEmQcdk/7o/0DPrmmSN96w5213j5Vtbh
bszWItvnIZObXguAF4UReOIbL996GugsWHhE2OtbmqRtpzN4QUoiZKlvUYgUFz26EOX75dOEXd+s
Tfm245u2Wxa/BeibZ470bekElU84Dz0urQRthelQYH6UyNnGt6u5RVtavSntLw6mT3xj7be4oUGb
tt+gO9/xTXR8y9P1h+mDc8ANq1YbRKqs6N6dYZYkaTPRhN5kJ2F1zBPu0YSF+3vY9W0lHfdHegZ9
88xxvkXIBV9u+qe9tTZZUE00s9u1b7blW8Sa0U8lfa6NjcwT3xL6g7ZcaLQ7udBGZm6rh2TPCsy3
pV6jLUJSdQ5ImUP1fkiy0flc61t5oKfrmpWnCZfJOM46vjrrwiZ3fcvMjxbJI+ibZ470TXEeoBY3
Dz8v1OJZkS5ztRrtSsYVAL7HOX8gIV6qV3Qtd+7ufE6PipZv0rkc/ayksodyafYZW88o6TRNSFLy
7FnK5oXX2fVNHoopllJVYs/Ybq7TzxMuKHGWsKioSmQnQZpk4ai/8QDQN8+E+X19qxd0DjyCvnkm
vL4pSzMVdB48gr55Jry+JZRk0FnwCvrmmfD69oFA3zyDvvkA+uaZvwj6XkFECjoHr+ZbK3z8cTh9
+zaQGyTePg5ZVEggWTh5wunbN4FcC4lI29/Rt7chnL5t22+5zCv+NuG8ds2frWZrfEilVL1mzzJi
5Rv2XgryNxWJfXhddZ4PiyVSktjmctzxLSLT1VS1Sg8SZeFCvXjjAR1fAiH37Z4s7/JH3mZxstAG
tgqgGZ17MwsVq9+1ryBrjLVVT4Curg3tPFSNTtfm713jEzJRxPtVZ2zkmG+R8TgCVbvXYy+pSG/S
s16ONEcOJNy+xXgfy+xcRr7zj9hPcU2PaizgwqYFVGcUtxQ27FJYUGviq3KcjZZs1mBRoYWZIxKr
T2trWrjdLgWFcN1S9jnAuZ2QSBOgbH/6212IN8Lt29nQcjZY91fHfB8vke/ocMsGPkagZLGvGogp
UpZledQXVrPKGf1guNx+64r5Nmqx05KMQoYG1fXaYF/CsRSJveiXd9p3yHGE2zfqSaljuBsP/TJe
RDOt6b0OWpevut/UksmSDYfsQqpjkvk5xFpLsnSGojHfnLElRFbIhFajoFp88GSVdyXQt9cTdt8o
Qp4qQWvVQyuzxooaWnXLt2SZl2/RK5nwPgOtU0HIDdcQFSDZIqyk476NWfmWZOVbpGLS6pVLGgf0
zSc+gG+MdP2hc+ifNhhQV8e6035rj+P2Jfu+oMjab5FVM0PSbHikaNGyLUP4S1GJLmor2n5rrmj7
DYTJWEiTAvMsh775xAfxjbIt3oRlX9k/58JTSqTbnA1pG5/1T40M7Z/2erTPkDMm2nIWhS7tmFoV
qNi9ztpxWTT0qjhadUZmnj8PSVrXoNr9rnWL5ZtffBzftsh0B3tcPfvs35a+rkiiHGHjLdkASPYo
jR0UK6sF9oglX2NP1ujWWt494EzJbp6/xWVwJvhIVa+z7Pkb1T0qY//0tXxA3xruTrP6ax4GI4Hw
AX2DXGPh7re8e6fLhPjER/SNkrwZ8x3H73GNEP/4oL5REuWhRWpvfoEQX/m4vgF7GLx96SDdfJSv
FXzZfGjfdqgSsmjmcABH2DkV35zm3LpdwEcWoeZUfKuM3OH6lreHwUgwnIpvALHLvvvHtHy/Sohf
nI5vFPGivaZH5z+/JxIQJ+UbI9eYbnsNMew/hI2T822XzpEjg5E345R9E9hIzSNHBiNvwyn7ltqM
DJ7gw+CwcMq+bUYGMxY4liQUnLRvjHT9gaVo40O5UHDyvgH7nvPIxoEk4eBL8I0Se5y1reNhZDDy
Vnwhvj1yRnBkcIB8cb7VnDMcP00E8hq+ON8kd2Qwnybi7U6D7OeL8w3ckcGMxZueBtnDl+gbbKaJ
uH3r0yDP+UJ9A/4weDsjSQRHBr8TX65vu1ziyOB3An1jdNhJcWTwO4C+MTruZfA0TQTyCtA3jjsy
mIGdiLcEfdviThNx8EO5jFL67KDOTejC46CdmeKecndfosIm/qAnWMjE9wV92yV5M7ajBx5za3Tn
y88N6eTzsR5L5Q5A32PGnkTTo208Xy/I7z7rP/r2jMcuQ93TyOCCmQTh4XNfCXuVbyNtv2+C9KJL
zSaNjXnv9aBvDqGIn8Vq18+PDO7zCabTIKmSsyFe15pnINxc0DuvpiBS1e5y1LdCXavTolO80jSV
CqEmbrQ6XQoVrSmp9IOLO01xHwIKSltr0NRYilFVKugPVdDLbEf64fmdVqWaVVO3t/SUksqhleit
didDum/Q/Qv0zDdaK02LOyXV0jYNhOi11srQ1MtamwUhFmta/YL5dtluv9+LPfTtUyTdvHxmmojl
pdJvZ1hRIfP1s9WgrJkZqJkSDKaCOJtVmlZeIsZdfTUGGE+r14sHAKLf1fUpQHd13VgSCRrmTWXh
RvIdLKrV2VLkwc9pwej4ZnbVKd2mms3qbBIBfTEaJ4nMfKubU1DMZrlHctw3FgB9Nb5qWwVQlvNG
y4kuAdH59OrOzgkj/Vo1miCMFpU7g/rWWdWu329eM/Ttk7gjg1l22p8OekrGY3Vgy9v17j39cTcC
YXxfMSS4YkEgblsSm8mpQKLJKW3in5MYEFom5Ukiy2avrhBJsmlxmLB4CPLohOqbIsmNb0592qGf
k1zCLtEdVjXQB9tK+nYZhzvm1Fzl9Sn17e6B/heps1mIaTejPeIZqy1pTu4aJYs2EnIkW2DLFoEs
4WdLw/uAvn0XbGQwz9B3+Daht3bwOHx43VMUpW3TY01C3eg4ZRZX44zN/5vIV/p06bgk1eb0wyiR
Lgk9StEbThox+UqjOzzxjbXfiFwkrKztDkCvbnyr8oDTYrbUWG99m7NZ/ZMkrazoUnV8GziTFN/x
rK6um2zWdtp+qxnszEbVr0v2GdC3z8CnifiOgSQGu7VlfbtOxhqDGjCzswDDTegamfsl9u2HTuvR
N5VWqSAQSTH5UWW2r6CRWa++3zcnjJw24us80SIvFEvGclifbX3Tr5xz8pgTrm8jp0+jsfIXdFVj
W88IqGt+5oJvF+y7Qd8+j3jxeDfKz0cGj9r0By+mHHjRcpYDaOptPQItdlvz6sa3iplg9enWN8UU
2HT8UpGwxzA53h8usMotxXy7dJY7vuUJ63zed7a+5Uymlmixsy62vk2YWzJJ7PrW6dMf5zeNGdvf
LF+z/0O0v1A1+NzZ7/UmD307iJj9fGSwQquzuK5C3H34qq6TEJne08aZHNHbINs5EMftjW81IwLi
8NG36LolxsZEiqzvBOohb7+VSAKEDt1B11hZJ0Ovt/VNXLYFyNPGnutbctVkh0RJmQ06oL6tReZb
xaAd49EEdn0rWBmIzG7TLAyFasbPbAXEewJx64ZFBsP2Wyi55Nl7Mk1Ew56Yw8i2fyp0rIkxk6LL
FithCqBa0/UktvEtri9Hyzp10F2H3IJYTbZcLad2nacQma1GetO8BMVeGU264zWxNr5BdrmcMkNc
31TneskNezy77/chZZFz6pvQtifGVHriGzSsyXoUgbI1W6wuWEU8W49o9Vww9JlVea8LiL4dRH5P
ALmEzBvs24evkpxh8cjZaiLOGv8Z99GsIAm0XS9HIREFdz2ahISYInHW4Jc3b6eErByDeIwdesZ3
PEsLCSY4P4glQFOO8ESjEkeEMzkJUZqjaDbCn/cmZFZiRVgeo5t043wbROQszypNXZRYznPyoe9U
jgd9O5DHAHKmD2M0UyRPS8T553c8FdC3w3GniTg4oNc+6tbSnH36acvJgb4dR7r+sH0JJLxmZHAk
I70+Nx8H9O31yDgy2DPo2+u5JTgy2Cvo2+uZurn2aZqI/J6hR7lWc9+u6fOdlZ3uS7roR0beAvTN
B3YCyPnwHrL70jfJvt87zH3zaI3vs9PLVfWX+4YD9M0fNgHkfAjoZbwcJS6T/V2SXd92x06ib4fx
8XwDd5qI1zfisjO+SCuX3Qs4a/aaEqQ1osqFwnU3C5lWjw3TjNb67RLz7VzrOnWnRPdJg9TstVKO
b1k1CWK1175gw1yk214tFDNno29+ErnY/lo6ds5g1RmUpKz0Xjlj9pS2mea+aev5QC5Yt+V7PQaT
UblmVkA1Z9U7woXjvqXNQfnOvmC+ZcwaCOPZ1Y1xA7Ixr6um9681vCHo2xsxPjaA3ETmCz5UcshG
z3X6vK7UDFpALVXaL3hoAKFily6pb1GA+zY/gO3TZ4ONWgvqW3JFW5JlI8rek0ZlNhDgeuXb3/YK
0Le3IeaM0zx8moio6RzAh0pafVVVB4bj24iNV9PohukIRmaXPfJT2eBJ9/tYbB/jiv+SUI3VnKre
1uneTXIus9FOyrt/N2Yf6NvbEK0eGUCuNHCWfGgHuXcGb258y5IeW29ApDI0bdXpL+z4RljXNkUk
lTTMa1rcLfjhOd6VQN8+zcf3DXYDyB0S0Eu7cpbctzX7WkIqu/UtxkfIZdPRggBiw37h24INuyza
Edp+q1hJaLHRw5GLKPr2GU7CN9hME2Ec0opbuT1c7ltzKUF03t36BsNpFJKGmrBpQXazfuZbXGCD
PWMPPdZfECYTIctGCLcM9O1znIpvjFyjsf099VnzUpuvSnDfIl17bk7ij77FJ+bM6ghwZS10o/DE
t9iKXAka3f8+zp+HJK1rtttydQ7o22c4Jd92EIzPBpCLb56iRJzhnJLMBiuxcZEx5zFwUpbYIppj
gyb5UMrN9+kjUpSNqWTlIxt5CfEEm0iR7caHVUYkX/+WI0Hf3pE8+9u+7ABy6Ns7omAAOfTtPdkJ
IDf/MmcMRt/eG3eaiC80oBf6FgBsmoj3mkAhZKBvwRDbfgXv7IsaGYy+BQ0L6PXlBJBD34LGDef1
hQSQQ9+CJrkTQO7i87t/cNC3ELANIHf6c/Gjb+HAmSZCDjobbw76FhqEfHPbgsucagA59C2UdE41
gBz6FkZEfltOcZoI9C2MxDcjg09umgj0LZzsBJB7r6mc3wX0Lbw400QcHNAr1KBvoSZ5M74POg++
gr6Fncde6uwERgajbx+GFLsyH31kMPr2Ybh2L85x00SEBPTt47AbQO7Ft7yuP0Y3Fn37UGwCyL0M
6LUgtx+h1EPfPhp8mojG861petWmUgDZORD07QMiXmwjNsTckcF1dtmM8Nep6NvH5tIdGexOIBz6
OhV9+9j0+fUyf39z5cJep6JvH5vLTQC5DSGvU9G3j85jADmXUNep6NsJIPyrJ1cvzHXqSfl2VnqL
r3GKHsODpqU3OLk36k8vX4jr1FPyrWmNV+Mjowyol/u3X5d4mHgvjNTjTu0Di+cXMLR16gn5liMZ
iCxePAn1hr4naJW7Pfy+pV9ewbDWqSfkW5bFEuoMAIo8bDbEi+n6BYjlxjWbBTJarZ+nz51IZrlz
2ua5bNTYUO30TeNShOK6neMHCcV6oyxCRKHlZFxh288lcl5m29IKw42QdlZrlGgZEr9uVKLOapr5
Fq046+9Lfc8lDGmdekK+MTLrCi2TnIJGXuuTu+hsVu+ZWUisRup0PnIiS2kjEMeLetfMw4XRqutD
aJrjMjtGGM8at8aAlmkSn/Gbbq9JZNW/XQ+goGla143qXLC7jWUXMsZYnS4lyJiDhr5WQVpO1PvV
u3/jIC7t46dm+PiDk/JNWJKxCJBwShiZlGibbkELqtYUbh8EWtk++lZb0e2NBWhdgGQ3uqlPM8s4
e2a/9c2pT5sAJcIT7c2c9uGqTvc1z6Y9pmgPRnQpWSr0xrTMG/ReLZAv2EHfxT0YJ+WbeJadPw6/
5lFVHoa0DmyS6IwKAs1H3+7HdHudJKp255J96W7bfoukitpz32QW2UViCaycAbYpwl9gRllYIbgy
wWaV170KRoemqhnH5d5v0DfPHP/8LUe2r7L5LPC6PmLEeR2rPvo2c7anoTyy7J648U3s2KthZ49v
fEPFzGySltjC6UkUSJwvNRXInKd6dO59BX3zzFG+lVkRliLbR3Dct4cW/RE7EyZsKhhavtWYb50R
DFnQgmhSkOIgluzSxrdrM80EcvQqPPOtYG3a4GeEdUlu0jbrfVQNMNnTFFa+sXgwCekoPXwHffPM
Ub5dWrRo05YCZCW+zn27WdPWe2cB1VUc4qsRlKwEX16xne9W4n2PhUijvjlhhG4XAgj3RIgRBYQh
8+1661vWfJwDdU51Pbel/iQC0XkbtGkEUrYK7UUMhFFIvlGFvnnmKN+ErtGbL3OP/VPmmzAwh/N1
jn04XNL+QnRujFbtEQgda/Bg5GkPc95fjUQYWrzjmTKn2qJNUtC2xzqtV6FjDTe+3ds6g6edXc8H
VL/4bDlYTWJ0qQ9WUxWik/VQ15OfyuHbcbVn4gf0zTNHtt8yCp/jxS3fovJmI+9T5hSJhQQSC6V4
nNWGKaXIupzRgpIF9tIqy/eOl0oJyMXZ7imRJiDmsvx9liiLaZnjnCpSuGSPPYS8wp/bCReX8SQ7
raycBzHNDLH7pefnRd8880bv67WQtOT9h100U3s6Iyv65hn07UDc67a8TT9uQ98880a+uSHPTpDH
Sze/kdxt6JtncPzbgTy5emOn94C+Ie8E7z2gb8j7YSroG/JePNQSWL5555u9A2yQT/Lk6i0baWy/
HQT2Fw7k8dIZbdndhr55Bn07EPe6Wf2dSfTRN8+gbwfCr9qo/GQoO/rmGfTtQJwewlPQN8+gbwfS
SL/chr55Bn3zAfTNM+ibD6BvnkHffAB98wz65gPom2fQNx9A3zyDvvkA+uYZ9M0H0DfPoG8+gL55
Bn3zAfTNM+ibD6BvnkHffAB98wz65gPom2fQNx9A3zyDvvkA+uYZ9M0H0DfPoG8+gL4h78nfBp2B
PaBvpwv6hrwn6Jtn8PvOPoDtN89gf8EH0DfPoG8+gL55Bn3zAfTNM8fHz3oe5i/9OIe9pAKokve0
RADFW9CznZOECPTNM8f6Fl0+n6FX0be/svnxPYaWZFz0AUaap113ThIi0DfPHOtbz/iMbwegjtA3
3zkt3y5nDeZbVXZWE81RvUJViNSG/ZLjmyrlWN0nqmeQvBvdpQAKhZuBE/r0sjvq5Kk87OhqOj3S
1ehIuxr08xBVOc5sMFJzpGVpUaryRCHWHDXYSUR6kk/EiA4I9M0zx/kmGWlWKMHYaU5Fl/fKnamD
MH64qq7qbn2aIWdUMjOSMdtKy8yAZjz0uG/1VVXp2iknTLOuOL6Zg3LXTnPfVnrEOUlfadmp6Hxa
rpkNiC5GNBl2khk9yZHBpd8G9M0zx8UzGtd4JbjhWhcAujqUTVow5e242357qAP02zDs0l06Q+qb
O2OaxmKvrZWNb059OqO/L1kQNqiaTpiiuynbt8rjp16Qs8qKHt7RoWTGWHDC53MUBQn65pmjfLuZ
CE9867OIWGUd2jotneqk4PpWXUDMyoHVp1v75k4MkPhFRbOe+cbab3xD0co7ezFdKYMuv6WXGguu
W9ShtWRlIIvwGxrQN88c5Zt9r2kPK20bLY3LcqGDpmuMnOsbla0yp7+N+NZH3+r2VKusPuFbziy7
u7nB4JyehKH02VKmJ1k5JznSjbcAffPMUb6xAoY2uqTNeouZdK1Dk1WKkWJ08zykd0srXljd0K2p
/NY3idDWvmBS3xrOcte35GPLbHhHf1xdt9lhCZJvTtiqDuqCLsXSnjB9gYG+eebo5728Pi06k+9l
ae2W0HVI29cgtIytbxdrmzazGusUxBfdrW9JUqCHkwp0Z1FBJQrc6DHB9S0+70UlSeL9BcVIQWJV
zdHExf5STNuXNBkdzmzqcNMMU8Ak9M0zr/PNrfLgyloafR3g0litV7nt815hOaQfCm2iW/exx/q0
ZU+X7dEdpJam0RsrkLVIxvVNcXLlvLto2LrVFuDKWBkPSeckd/QkhfV6vbp4jR9+g755xqf3p5Gc
88hMTKeFl5/Gck97kwl3byEjOUdLew6iRHO81hQzZ09OIuw9SYCgb57B9/U+gL55Bn3zAfTNM+ib
D6BvnkHffAB98wz65gPom2fQNx9A3zyDvvkA+uYZ9M0H0DfPoG8+gL55Bn3zAfTNM+ibD6BvnkHf
fCCUvn0TdA728uOg79UpEErfvg46B3v5w6Dv1SkQSt/0oHOwl17Q9+oUCKVvk6BzsJdQfa/uoxJK
3/570DnYx7eVoO/VKRBK334n6Bzs42fFoO/VKRBK3/7eXwedhT38JBr0vToFQukb/CzoLOzhfwV9
q06CcPr2e0Fn4SXWvw76Vp0E4fTtN8OXrR+HaRaOj0v4bizzTQjfG4b/E/SdOg3C6Rv8dtjm6f+Z
HPSdOg1C6puwCjoTzxgHfaNOhJD6Br/166Bz8YRVKugbdSKE1Tf4o6Bzscvf4LtTnwitb4m/CDob
O/woEvR9OhVC6xv8xrdB52PLV1KwN+mECK9vUP1V0BlxWf+jYO/RKRFi3+AuHMJ9U/7OK4gcQph9
g2oYqtSv80Hen1Mj1L7Bb/wi6Lz8zZ+dBXh3To9w+waJHwX7HO4X38Oeqa+E3DeA3/ppcK+2fvl/
/2FQ9+VU+UszfPzwSQ6F3/55MP8pfvnjfxbQTUECRfjN3/vaemfZvvnJf8oE/XcjwZH6nd4f6Ktv
3qF0/flXf/KD/3qDvYQviP8PSnqkgWVuZHN0cmVhbQplbmRvYmoKNTMgMCBvYmoKPDwgL0ZpbHRl
ciAvRmxhdGVEZWNvZGUgL0xlbmd0aCA3ODk1ID4+CnN0cmVhbQp4nJVdW48mt3F9318xzwHSJlks
XoAggHx9diAgeTdsB0GUwM7/B3IOv9lpXqbPjiVA0o44zepi3U6xqjq+Bfz9zxH/qD29/emXb3/7
dlUfP/3+b/wwvvHvf/vD2+s//v7Xb7/6Q3j76/994/9vsbzF4OXt73/+9pf7J1ZT2340Lepl/KiX
cK8J3OH1H9jh1z9/+9Xvw5vlq/Cv2t9+/su3+J3ezh3C28+/fPuXEKz+69vP/3X/zxjrFUvPsU2L
PG2LrFw5m9c0Lcq/2xa5XbXiWXVe1LZF1a6Qvfn8JI/bop4uSyGE+UnB1kUpxKvnVpJNi5Jvi5Jf
oeRQ40zTb7ZFlq5azFsQNCVPF5hXLc9P2piZarwsxta62q72K8SYo6ntertSc2/zovzTushwdu69
ugk+WcIBt2a+EJ63RRkHXPCOWdBkxa9qBcIiWGANHI+hlaxo6pBU/KP4LJmb0OUUL+8l9vns0kZ4
zvmqMeJhM+Gb0OViV29e6yLjG+EZkllitrqc3a/Hot/9/AMVy/2TI/j+W6D//bfK+lsQzDeQ/v3V
NoKKh8tbThSmj0W7MBUoXcvQqDwtct8XtaumGMrypE19QR00s8c+P2k/uFLDFVOMy3a70oE5V+uF
Nm3abju40hq2q83jvOj326IOfQo50CDei/q+yC+rUIMitqvBLk819JkFu4BDkK5SW0ppXvTbrx1m
jf1k3I9FgJxs338r/rSfSbqix0gbdy9K58GlZKEti3Z21wwm5RTKvGgXppbAJLfU1XatQC1r6mFe
tIsAFLzmNmzcvcj2M0mQk+5WBOE8k+Ch+EJT/wfOpD2cSXhL5f23wu4vU47fhXs7EtgaGMEcmk+L
Tn8ZaZhDCtOiXSQjbK416z5v964BP6QxwoHev3W82QM/+GaIVB4igZCv7qmkOC063izaFfGrEJF7
0W4lRkxRvYY8LdodRYRrtlRaTPOiPVwwu3JFuBVmmsrOyHC1UGAE5ycdi9oVLce6PGkTW4YwkEBG
W9OTfrMvgr7BkpRlu/1JJV85pVBNvV2FvlWLLSpmVkhA9ugzTbvzii3ADdZoCzN/vS9qV4OO56Bo
6hUs6JaboImxV+jYbX477/uidmW4k+VJuxIkqBMExde3O6K4eIEDKSRxLCnB5IDfrsSXoV6DU/VZ
fPdwAXp1hQC9rELoEuTJrJaeFJ8QNGZIyvqkzaJA467eYQeq4hMiy5g9tEV8j8gSHK+InF0RjgCt
wRZbUIQ3uHA8qUfF8Q5bkHr2Zbs9aISopAaBVfJkAbaAnqcLPln0qxvktwkZN0hBaLW7IpwhseUc
VzXf+GQM9WqikRXbZchTMitZvR0MfYObS/OiPdoF/LhS9xznY9mjXbz9BSwDEyXEF0KJeIDhnjAY
BoOBowuLZB5vB4ORoXhdiYoBrDlMjwe1XYeatx6jUk6EsQgaQrLFbWxhao7AYQVwZhaV3YghzrkS
TE9LQjIRWSMkgt9Q2gLQe5UOVVAsyNaBfBFeB6HBOderJ9h6UzTBtwQ4V1uOZUcq8C2QS1CuaCqU
pxIWz7nLeK54O0j44jmPY2nE9QgMmqIJkXpPgGFRHIuHgLervopv2RdV2EwvpiIMxMSMC0pQb+cR
/g6imFwcC94LUU9pi5faj8UhBTHUXpWjhvVC1ANLvrBgc2UOKTCLwbPik/sF2Y21qu28I8ZEhN0U
C4ANGgBNMaHmDikIZtaK4hOkIMJxhq74RLxmODuld9473q7UxW3sLCiQgmK1LW7jgIcRgR+MWJ63
i2Ff5BDfDAwsjqUkg/jCSSn7hNeC+ELLlfUFpodyNqB5wYLC4KH21WbuKlVgC9zwIBNSAFxwQcnh
goT1LYWujLGYertKV+YWldCVSldWU1X2qTAFBPAXVJxZGDwA/C0h5AntK0JtBORKWxA9MtSGxAjx
RWjMUHu14+98+iFsqvGT4OVLYKt/bLVJZURwjAC5Eo70J6KJNeHohhL0J1mKiHg8ht7m7XYlQJh2
wTYPxby324EN5LvAqlIJnreDfNfemOIU22X4FQRh9OT9SSpjhtcErokLC3bM4vCaIZU4s+DALExd
OUCpZEENCB+z1aiOhVYuW8ySTw3H0vsIjvuTEkDZYJ4D1olFQDTALDADdV70+30R4l6vxYtgQYIQ
QqZqmTl+RPVwiECKNSuhgybRQw2H+Hh2yQKctDVqr1gEDFy9rizYt0MEXRKM6sKCA2x1sADcXI5l
iwxhvoE0trM70A9NYYypzNvFPfmO2AkhZkpVMRP2Ej4stnnRnlNJLRKUtpSFjA+wheg4VyF0A2yN
XKB4O0OAlTNguSLcAg0Gonq1ncH/VhjNIreDaw0dYbbcLjIsinl9ux3YEJElnGBQTzJEF4CbFoW2
DNjmiMVdvZ3RqpRWghBfywhpK6InvYimJ6w286AJ4msgKbvQYIP4Zm+hNMWCEhkThNSFthAlQp6Y
pJ8I3/FmrUxyDE/+aA4NkgmjEVZbcABAnF3pcbUqGwsQDEDNQbo6FlgURKsxF/V2gO3wnN17FvKE
WAc0ASpXcXYZQR+UpVTlWzJTuQ1wWRn7AQBxyklZXygm05StLYRvgSjQNixdC4s53PM8GaF/aiUu
5vAEgHbxTrMrE50LhM54psI+ESVCnGJVDmigRKjwYuwPmloFC3Ja9G4P+ggl4chSUl5qQEmExtmE
qBBKGjBSUa5sQMlUc1KEw15eGdBuiXrOJwGRwWa6Cmgclo5ZpWrq7YA3W0XoV9R2EDom35a44CA8
5ytEhFlKERxwJND/VEU4095MOgQhBQ73ijizrnHBjoELxBdLTOmdwz5BQXOJ6u3gXnN3RP/qSTBi
Bfhvsb6+v10vMPZQhyDsE979Ghdti2Et+yJeyrfuSlQKbxot9KT83UCuIbWmFIHItTnMq6knJeae
8I6L6dkvG425pxoWb36gxMzcU0tL0H4s8kR4a7bI+AFKA11ZluI7kGtIOS6KsKPpEYmZLw7owOUN
4T8sRFkkc88VjCDL8sLM3URXZrRL9qTMYQ39yhHq0E9F+ALe/MSPfAVvIiB7OBJe7jF6hF+5F+2W
d4DS103yvei83EtMVAfI97TdUVUEEAFlgqYImgZybQzYJ5r2qiL435YLA/Zp0XFNCFPYAe993u5A
rkA/GbhmfrvjLpGptwrZbIoFTL3l5iufduQ6bgA7POK83XFNyMgQCN/V29EUFqwydXaNkSEOpqnt
gFwzgvqQ1XZEriXXmASfeAPYOuDWciw7sIlw0pkhu2DmQK7gaIpCnl7ItTYp4y/k2sP6djtKNIP2
4OW6YAFvAFtsaXm7o0SLoBQWY3m7g08EpXAsbWHBjvAR1SOCzppPBZKZEWXPLDivCe0CK319u+MG
EKYwBZaeqEWwBYjXquRTH5mQHpSoGKL6+sqIikWjzKOwrOGZBcSbEZB6lcwdkSEKG7WDJkRl4E2Y
w0WedlF53QB2WyTzgG28AYQby1mICkLCqwOQFckCb7QFvFF+FhUA8staLJpPBWruwIozC9KOgWtg
sY8vfNpr0LDVNXKLyiOw5C8OdVHHQijpVpvyCISSGaZt9VL7DSCvCc2YDHo+Fl4TAmnBnItjYYVh
METkTRzLuCYsIyaYWLAjMliVlEm6OLtsELoI4xsEM6HiOGAAwCDUPMP0IPyPK8ePu8R6FahmXmT8
AIBAGnQJXdEEL9WjsWTg+YBZP9mbsy7s2SPkli5slhfJPN6uI8yGS7SitoOXAkDKvSrCe7uYzfUq
nuQhXR5YGiQId7gyQoisbMH7hSOC1nm7TVR44QhewpcJwhEYw4h5XeTpRImQTC+tLubwuHCEZCIw
yk0R7kPo4BYVTQyNSiiL3u1hthdW0cbqyin6SMV3AhtBE8ukewyL3u3i6w3uFWqciiKct5JwnG1R
hP1YGPUAbXkUKlWYr0/RahbbgUXXAD9ZEF4Q9cDh5yVcO/Bm5CVRKGmxdPsdWUpE0y6jw8LQCLtl
ExwvzNd3iG8R8lQQalvFUmV9ET2y2pb13YKZzksiRNFNKGdxXhIFz0pbAOqulhLvpp8DmsIKKof4
KgfE0mVjvkQFftA4uNe0iu9BOITOE0tgFZ96BwsGLp+etJmeGpiphfgqwDXKZGtZHdC73n3pfvPg
7pfwpj2inxDgf0NhSGtPRzJdgk6LNq8ZmZ8Djk7Lov1KDjS+V7hPi3ZgA02BsWRZxb3oQInAmyFZ
YpxiT9yOxosPZx5zYsGOElkPUmqymU/nTWkeZfAtTYvSTpOnq7C8yNR2XqhOvCyenrTfKI/IMA8M
/LHI9mNhAZkFJoKm7fZjAYiwABSRFE1tVJ0Ha0oKOu/IEmvnhRR0Fic3i0lJAZtmwNGFpgOzBKYm
3BehO7BdZGoCOLEKKSAohfUqro4lQegKDi91IQUJcAShBWsMnqUAgoRYPKRV7/btcrhixfPifMB7
PS3gSHWEM0VIQRr5ORyLCykY16kBlLuiidepsE2tKJpgebGlLSw4aAKICKyIUHo3bkpfxVqC40Aa
CEBKLILjBlHxDGdXxXbGyBBAMim9swRtYbGL0jvE1zi70EzpHUEpIp7aJU2MDGOu3oQivHq+IMBR
yDiR60BtUWgwry6hBr0slu7oHosI+mpPC+E7KGW9WmxsNDye9EOHZMuJ/yNujD/6oRv7WGS7eZ48
1Meis3ECrh7gj69/Lzp6IhA9E/zZtOhMdsar2ailnQg/nI8DssVhw5+3Y9q02bDh93Y7C+7GiWnR
7ld4OdReSPp5O1gU9pAy7/RM+JQ2FU+C5Q2Rhe6CcDZOQOXizMwzI3qnTZ/PjjdILYcyi8qOfNg4
0cxjnd9uv2MZtTwNtkJxfGRErVpX8kS/ghB04N9HmkaZjvWy8OmzMh2P0ZuSp2T0deau5GnU8gAm
mnw7H9067H18lnHAGdY81WKKJoT9cIc1LRz/pCUXsUrLVTGTYb/hBBeaDufDViw2hiiOI05hgjIu
8rSXVYTRY9NbFywYyc4KDZ6P5UgswmAYRCFkcSwj2dnz8OQ3Mw+/QiNWhid/5DisK7Slsfnt2RZY
phGDNWyKcOe1TrBVVA7nw2udyAYTQRMMBlFdXI5l7x2peZQ2rgbjyIiyKshaUaaHGdEOx2pByDhU
94qpdDchdMZotTagNiFPMDo0hxAWQVNGCAJzGL0LPmWGtBUB9EL4nqKMMGKwvi0LwnOiEQMiXVTq
aJyAZEJQlgM+FiFaLfD5i1U5M6Js7GolKhMNPH417zXP2nJUlsBLdYMnU5YuF3Z/gahFMn/aFwHb
OduXhQZD3sAC71IRcnMgsoqgQj0JIS3i57h4zt2VjWRnY/QglNMhTwWS15OQAg+jgTssx3IkzNgJ
6mw0EpIJd8hWlbj4uzMjylJZ+KpFCnaaUmOryrgHfjw7ZwUzQvHUhC0YGdEWWBLzzHFmRLPF1Ut9
lhF1iMoiT59mRCEqi5f6NCPaoHbKIzAjGs16TYqmZswc90Xv9iZmJjuBSYNUqZHs9BoXlToWRZZV
tFRU1AN4dJGkJRg9mjkQ0MDnuStFKAxoOH5BhZDMY8JLFVNeqjBWab2ugd+eM0SsEmJtTYUhOFxW
T7VsQhE4giEWllIKt8FOfhjonj6RzB/imE958iX00z7EZI/qA1tnfJQLfCw6skWIU5zNuW1atA8N
GOgnsap83m5P3xD9dB9u7GPRUVc/1YPcNO0gIkdsF1uNM01HPQhb+2xEhh+L3gHpD/kWfX70PzBZ
gHXQ70QfPPqYLHAv2puqIxSAFwIxTIsOhAiP2fDyeXnSJ73uiK+b3q4gUkUot263n1sdXfOxuqKJ
pZ8v1Dpt99PX+JbgGu7fOrnNrjP+dcg2rLMC7ZD4ZdEBayGRMG1sgL0XnaAdZhn6b3l+0tFbwwaz
xibK6Uk7t3Fu3hPvWacn7Yz0kcINCNTvRSeKHhV4lNp70aHeBMiBdQIzTUcKF1FFqRxH9bwoBSB7
XtkufNpvHx6OKcV4vslXDBfbi94P93mUxb3oyA/coyymRcedQbySZ+bk7kUHt+9RFveig5H3KItp
u0NMXjagLDQdoyyIeNjfPG93dFd9pG2mRZ/I0nvaZlp01KgBQRdncbvgEwvZ4ghjBZ9gKGA0Wdw+
PemzjEwmmlHbMSPTY0o2LzruDNLVc8UJz2+3Q/8xyqLltvBpT9uwXLel6lm8XWK5LgI9W560JxFg
URAuNXchmXCUF6xAL6YI50Vs81Al4XeNmqDprlETb3fXqE2E7+VnkAJH9FmaetJdo/Ys41ONmmAB
rwNqrHWWpzPZ8hpAkZtaBFuQG7BhE9sZbAEAQc6zjJ8ZmX6xs7coUYENvBifJhcGg5VlcKtlIfxI
tiBChXLWGoUtMESoibPr9KKP8rNnvRuVZQOJCoNhnIKXI0v3BZ8AZjKkwE3xCWDGOfxmMT19X8RW
8ZKrEhXrUM7GKWGC8NGkxAE5iqZpSsWzYR3lZz2aV6F305SKZ48wmpQQg+cimMkmJYbEiy04chZj
SkWFlKu3Y5NS7m05lmMyH3BvGu0w06JjMl/xC0GKL8w8+ARbgDCEUO1ZMplHSbBOi8s/K8ucpaic
+CXeDgYj18jpfc/yxGQLqCb0f5Ynh1WBNayrid5rr3h/CJcQlDkclWXgQ+/igFlZVlldl4QtGKMs
ENBmxUwf9Q0R6F8InfOSEbKy+paNT06QFdjpIgyGjybvGuSxOIcYwpivx7K/He8PG5CICrKYRwFC
TNKweuVszWSrR9gzMpCngjiyKm0ZrUW0F4uxP1qLWE9vMSpHDUZecZeCs/+oset69S1na1GiwfA1
XNszDYntmAVyJ96upMzZN2UR3z2VNLqGsKirWGV0DcGqxKIWjWFZodvCgmMiYmCukFeWz4HfqAdD
lJXqKZlfyKOkkydfgiP+GPrfzTf3oiNaHXNvavJl0TERgsmWxnlT03ZHHoW1z4gb+vykY1GBwHFi
z/ykoxgK59at5vnt9iPBU66cYX9nmo7QPxcW1PDaZNpuxyxj4inv2+ftjokQMIXQk2jzok8mQsD/
BgLAZ5qYdC2p95njB/qpLJAGw+ftzgtioHt4Aw/qgFmr6gHwRxGOOAXBRaDOPRPOCTrgQVM0JU7Q
4X4zC3ZfN4BNrxwD9rzdADYce5PE2SGQYSE5U8rPZ8c6p95Hue4zC0adE4cYKHlinRPoSmEW3z2h
mGh2Wo0ENvd2O+E0O9ZSn5m5JxQ5oy9FYNeZT3uSM5WBpiHAM01Hhw7sZYm5z8w865wgdFbDst1e
K5P6mPlYl2OJv/2avWJ74cHdHxeKwqm0T2bc/vHb374xHPARicL5/vKNIO/7n/779SdWBY8/vZZu
f/xY+5/f/v2f3v4HT2Tf9tiYQyKxXQDqmB/0p1++j1b/1X+Et9/+L8j44+cz2d+X/dCE83zfT2S3
hAzlGvvEp0VnjQ87UxzCNC86WiPZJFAJDe5Fp3XmlDvjYJhp0Z4Huof6TIuOaiGWFgJz92nRaZ0j
Z19XMFgQznx5A9fivN1hnY2Sy5kv06KjCpWhXOuhqO041Aexx8LMz0x4NCqdelKFGQBjzBThLXFW
QM9RMbPzor2yylrQNDoJOhO0zywYk3+MYzhnwg/Dy+qzyIGtahFrIkc0+0wT006IQjiC8lnoRv9k
GSHvtN1RhfpRLSS2u6uFpicdk39GrpPdMtOioxCIVxleq5LxUQhkkM1FfHebClGBG+89CFGBfsMZ
lO5B8amyscriqi1HbopxA9B7U8zsjBtGBl4wszcoQmUb4vSkPecSRq6zlyr4NJoswYAShFUx2CfY
CzpN8aREZItorgk+MRXWLOfl7HYUyVE8EXFKl4TD9Bi/khHEARur5DNnFApmAjzBaVpbTM+RVCsQ
OhZ0KjXnlB2Oo21dHQv8VYscTqDejiVFkN60sODIcnE8f2C3jNiuM2saGTqJ7TqzpglHKJg56o6Y
nFfGfpQUefTFKZ51RyzcsJUF5ygeFm547kqlsgVe/bIQaKJp7w6F6YHBr9kECzJHryeHMxPKmZ3j
y0pvSgoy0IgDaa0G40iFQeheLcliO5ie9mpJnp608wlAAzGlxZmmPQ7llJ1QWSOumAmgkRLvEYU8
ccpO5GR15Vuc6La2sEQYeyjubPWZD3fvNB69kza+diG2gpjAfCUlSiMLVseEkue3HwNd05hQ8ixK
TmAL4V6Ci7NQiAM42+oPj/QdMStMXFCK4oWd5Ah7Flux85FRUcPrdbUdAx6AFVehE7NgFjnFXZiB
kQUzFkUqjrcOmwrHIvnE8ugC27Tw6ZPWScREwG2CcJYcgeEs/p50YG94ZOukITSeadorQEbJEW/j
lHiP1snGSgEh3qMuCdIZ1LEUmKbCQbvqWEZdUvXUFYYoDJ3gV11FtKxLYllCLeJYmCqDr8ldqV0p
lV994dR8cXbVv/ehPotvgdA5IHlWuIbzY9urr1mwAELXcXJrAH30V3JeeucnNp6NHD9DMoodVeTP
/soY+aGsmU/7xzoe+ys/CUm+klLscauU+QyP3osOuHLj0XvROc/nA49O2x01LmydHPZy2m6HULxa
sHE/KmhiVyQrWfu83VGaxSnZiSNPBeEs0YTw2Px25zwfZgtTXd7uIHxMyTbih+lJO7gfU7Jzr6aO
Zdwa9JSrIvwuXhAc76M8K8KoPhM+voEWERcVwfExhQfGIGZB09RzMj3pGA370XMyEX5gv4+eE7UI
dqAHROKKJppCmN82i8p+u5LYap5Ht/1E+I7Y2PDIQaVZCN2r5wQARWnLq+dkWLlnoRtQk3mCJg54
QE1A7tLU2bXxhZjao2ImE4HwT/qA+UUmoIw6H8v+vanvKHIRuqNHL7BHoDEj/rwdoWYPo9v+mU9j
VA/Lxrpgwehe4cTpJM7u1ZgSwyJ0RzvJaExBCNKEqLArsr/SwWI79zEwMS56tzOzcCZM4EdNBJ8K
Z8IkF4IyyikaIEsQloDlFAhqV7k8gWZlBq8GZVaN7diERvOiY3hQZ4I6ELJOi3awQgwZIZdqO/au
5Aa5VO7nBTQbq/CeDTQxJD/wtvLpgIcwhq8Opmc+DQz56mB6loGBIV8dTOLtYHgyLP1iU463I9CE
L/ek3g7ooMCXL/p79q6U8Q0kW+RyR6MDaI5vIIknVWY3Qo6Lm97rZRqzGwhFJDP5ZRAE/t6EJUD8
ecGMpdWsHjUX9fsEtGnRMYPHv1eXPRMO8MALtJgXp7Fjn8RhtWzjEm9HIMm+buk0gLLhNDJOT7Bg
fBnE4c6UP5g6TsTbsc+WseGiLXv1BgxPZWo5qe14+fmqUxPb8dtj41xmz7JD0sa+SEC3qPjED5Tx
+jcK0+N9hOu82n1WKaLNwOBJHQu4yALgnpOQglFzYYk3pM+SWfgVM2D3JXo6wAg/UAYftMQ8ZxcM
b0jDJgU79hk3pLFIZo4PkUTzkoQtGB8iAZpczeFOk7O6LLQ1ZD9aZRo/x9sXQHLwiUASpHYVHo9B
PRXwXhmMASQhZtLf8VOVIH4Njw9Uzo5daOdiMPJXvwwSPgmCvoTs7OlIpmKRe9EBkCIzFwlWdVp0
IrvC6Sv8gK7Yjs13NJd9XrSjKDbduOWU5aIb2dnTkczIzp4OF89gpzWH6otF9yWiYMF9iTg96bgf
/LhEnBYd8I9FY8YZF9Pb7cNqB/xLYeX4cYl4I7vHA56R3ePbTdMEnt9uwD9vSb5dGpPGuhUlTy/4
x6YCIU8v+JfyIgXn/SCEDr+a5u2Orz7eBe7PzBzwz0qsTYjKuEQEXqGyPrOAyA6SFxeh27ejbSrF
1ycdo2x4VVNjVioFWeJXi0cC5/ntxhAxmPuqmNkZ8TRLVbBgILsxtVpsN+4Ha/WqjmV8hhHylBY+
7bdVbJxC5JCL2o4jB2CgrKntjD2RHOAgWIA4/OLg34Xwcy4Br2ripndHFTzCbJg7V+LLS8Qy7mrU
k0oYla9tEd8dtvESMbS0yNNBOD/VwY7eorbjpFYgyaYMBie1Yq+RnrqfdABAfjgCBxOEtmTYpzGW
byH8+J4HIp7C9gRh6Vgq3yMHIYi3Q7ADS5frYnqO+appzBBme/8zCzi8gFwqSb0dx7nWzvb+Z8kc
KLEEmBW1XYbNNI6oFMo5xrmW4FJbOM6VX7ovXTGT41wRQ/ZFzY96en4TwgYufya88psQ3qqKVQDc
ecvSZfAw6ukRhsnggTeNDSIugwfOJQANbOh6ZqaPqCeNJOXzItin+pqs+cyC8amO143Gs2T66Ece
kzWf5Wl8quM1WfM5eBgAML1yfc8sGPPpX7m+RykYIwfGMDXFAla/wh4WyQImvVPhoGHBgjGptYUm
WTAmtbKlS23HSa2JQq626+z0gKmb3+64/Aps4oCyq+BhfIWju1UTNI2vcJQ6rj4+Fh33f6x+tZ56
Fnr3HdvFmfC90rQYhK54X6Rgv+EvnE9v4yvHE007tiNsiy/wfm+34yi29TWYAmXECkfP86tpCzN3
FsCVVeC21WbuLOCnOlpP2YVk8lMdMVaTgV/hfPrSNge0I9fXENayxL7nRyYZP42ykonjX5w5ByNy
Mm5UxP4/5BvhUmVuZHN0cmVhbQplbmRvYmoKNTQgMCBvYmoKPDwgL0ZpbHRlciAvRmxhdGVEZWNv
ZGUgL0xlbmd0aDEgNDcyNTYgL0xlbmd0aCAyNjA1MiA+PgpzdHJlYW0KeJzsvHl8U8X3N35m7tzs
e5MmTdMmaZoUWqClC6VQaVgKKJR9aZFC2TcRSgFxQYrsZXVDQGUTlVUCFCyLUpGPKIrghgsIqKC4
VFARlbbJc+YmrcDX7/fzeZ7f7/n98XuR9H3PrHdmzpxz5szcmwIBADWUgwBpIyYOmzymsmA5gOUz
gKhlI6ZPda2c/OF0gDY2AFna6MljJj6QtOV3gKZjAcTAmPseHO0eM64aoN9PAF3XjB01bOTxnOsr
8I6HEK3GYoJponErhq8hEsdOnDrj+MYyPwBpDWBef9+kEcPIiFVvA/i7YnzTxGEzJivf1zyJ+dge
uO4fNnHUG2RMLsDzCwFitZOnjJr8447SrwFSMV9VD7zv9IOfHp5/cfVQfe7vilgF8M/Gb5KSOd17
1+63b+ysH2Noo+iOUSWWJ1IBvMrbBXtARwPc2BnMMLSJpDd+xCY8RWyClzwYASJQMEAqdABgGmxX
ACqLVKE5jQjQT2EIKwML4m55HDwgDoBCsgAG0a3wCIcQB362HaZg2a0Yb4/0AK+L5fsjziNyEQMQ
9khaAWIYoi+PY9n9vC7eYzK/j0TLYJDCCZPEAaF6bG+leAxGI9ZieCP7BjbLcmAixjdhvcMMIJuX
wTorZVthFaY/h/kjMG0t0kKMb8DwYKyXFgkr5UshhlOEDNOb4n0WR8abJLwBrVhZ6CscSxHe8x7E
fGyjF9LOiG5YJgppB8QCcgwWkmOhjZiPFOZg+wt4OqJThHbF+8zD/Dysl4jxORi2Yz9kSPUIN6IJ
3Q451AyHkKbi+AeGx404BmP5mBvHhP2P9Om/ItzHbjcD23wN4aE5oUtIlTf17XbMuQ13CxlQjnQC
IhbRm56Aiaw7EOTXavESCBwomZxP5xB3sZHQA+ME+9lXrIQ1PI4okFAWqmfPwXrhGrTGvIdkK3Ec
I5HfLRHXIZX+BM1lXpiF8tUJ7z8bsRbveVmSh5HQD9tvgTSDXZJkaD5iCbZ1pYFPnDcYn43z2gfb
quMag/X7IrrgvJQj7uP9wfZTOc/5vJMBwRwsexHLDObAdKsEHDuXSV6H18d7eSNyuPFvChuxzFLk
6wWkDGHhfWiAJGcRYN5beJ8YhAwRh2iBuITYiJiAaIN4FdEE2wZsV5DkFWWGy6YkHygb4jHkIfZN
ktnwGNZK8xnWmQ2Re/F23LLtMCECN78n1xcus9iXXQ335jrFZaaBSvI9gcs9+YWPk8tUI0XdYz9C
F94HSQdRthoo1zvsM9eHlbQ/LES6BuV4DpdZ3r8GyvnCZU3iCepEhObeNNY0SUeQCgCeiKzPaaAN
vGikY2ET3rNENhxtynroyqZCV+FxGM6uQiehKbQQ0zANx4NlA/RH6KOohgycy54YX30bXcUh/4SM
F6txnNuQn5/A88jTUvYJTWCfEFHcFvpeBPKOuI0+KoX/C70dpDqcxynHzXn/u+n/J6CnxW1oM7eF
fhA/CYVwPE9wnZD/SNIQrgaK6bsR5YhkRQpZpZhAquT9wSDDtQ0xifmhjeiHbFaN82NBO4+6gOn9
xa/gsLAUFrFPQp+Tciinn8B8uQWG0ZVo07AtehrmcPD7I518kxzdInO3y1IDbZDX2ym3+RGZciKV
of69H8HFCK4jfkc5eoGE28jm9llaH9BGI+aH5TV0o1E+34EXkS5ukM/b5HTCbfKpuV0ub6fS2oL2
vUFPsR+LGsbP7SO3cdxGcjvH7UxD+dvpTfUr6FaUY26HT8CgiF4nRHAP9vHriO6jHcb5HhgKyTqH
XpZVhjYLptBmWTqGP0OIoZdx3DMa19TCUDCynjZtWEvD6aBuWEfFDJgYsWebJHvzKzwlraMDpP4p
ZTthlliL8442UOrv+ogOIj+x3xNYCfJ8DSzBccQIC1AfMR0xmPNEmgsAG18X+JooPI185mvRUpgj
nEF/gdfNAKO0XuTBQOz7O1Iarqmc8jRxIGyU/QjprD/a2moYyeeKj4P3h8+9YhpoFRa0E59AS7YF
y1hAheXWSzzww8uSXPC6E9AvQl7IR4AcZbYHluH32yDV8YMpwo9NEi+k+uiLcPnivMB7yizQR/In
foR1Yn8YiDq0QV4OG2T9UecssBnv8SLW68/7gvXs0nr9NNyL+rUQbdNCtDkgyf+gUK2wDcczA+06
QihHHm0Dm1iOPJwgjb0TC9vYBVx/hK3g4zIiexrtMPcnnoYKlgL5sgmwFNOWimgnsd3FmDYX9TcN
dXcR1ndG7DZg24swndfN474M9xG4vsj9ECUrl/wAkPrA/RRsX/geNgj3wEKU4/aKp5EP86A5rhcE
ZS8e0TIMKf5oBEvCkNIMYUrcggFmSukZ8CHdKqhRbvkaup/NhnFsAKQLLSGGGaE5+wB19S94VtDD
UHYcnmVVsITHWRQ0EQI4/kr0LXn6SejF0+mHGF8Fg1gu1l8I97OhUCbsQtn7GFRsNM411hOXoZwk
Yv1f8b4RkG9gkDAAdWs+hv8KbeflpDYqQwM5WFdoLtW7CVJfG3Bbn2k35Ns9OKfYXx6+pb/Y18Z+
NvTxH/onjZPfF+vxMuxZwD1D6CzCG6bB3nQpbEOsp19AR6EAHiSb0cA8B53JJcRzEeyArhLdheiN
a3wWeQTRgmXBq4jZGG6G9HXEznAcfbcsOIOYh/d+A+kevi/goB2gFaeYthaxCvFuQ97N4G39U/rN
EGPh1vheKOcg10L1HLeXRz63wvZasbuQnwiUxRUcslkwSD4d5y8J0+PxnrfFsZ10thfG/7v+/DuQ
k5Am8TAM/81jbJgPpNH/Ac7eRF2cRtaG/0f9+z8Bzu8sRLHE35/BEpEhHTkNCUgHIB0gTIMZHBhv
jvGiBn4S3P1K2AxPSumN8xdOR1nBLSXcdXv67fHb5/XfxekeePFmNMhBozw8AXM5WB6WR9weV7wD
czlk/8K8f/3XOHv532AQJAtrpD6BJGO3xWU9cc1E0ETsq12qs4SjMX4SdRnBy0r1tbCUQ9JdBK2E
cRyN+VlovxE38bUV5yu2KeU3zE/DvNw+P9g/P3sfMQjXivchDWlfpO0baKN8R+zFLTLfOyzvjXFu
Sy7dVuZvnfhbN07yteaf7/n/J6DuHEccQ7z1f7stbmW4jTBwO3EW/ZA89CM/Qf/kXpgDUI+2pC4V
8RLaoX5IP8U0XL2DTRFaDBsxbQzS5wFqf8fwFEz/JIwQZbGwPuJXxmDavkhdReR+fcP1a98GuIES
dWNnuH7tVsR4DP+CmInhL5G+gXQVlv8B681FeiScXz8U49MRhzD+I8bvQxRieAVSC9JmiCiECeuv
5OD+yH/Zh/6/Tv95//GfUvRZRmA/nfzMC+kjt+8h/mPaMJ//ht6+12iY/39HbzozuI2G+YB7pq/R
7wvcvPf5n/Y4DRTnM3gzWP9QPfqUGu5Hc1+W+8+S/xih0v5N8mOxXQBzA+W+M/dfue/M/VekG5Au
lIlSf/rzfT7vF0hLigSHpBCg7IMxDKkKgSlb8TNYfgwKreFRMossJ0+QDSRAzpIQLaLH6Dv0S4EI
gqAUPMKjQoWwRNggvM80rCcbzIayJ9kz7Hn2AtvDDrLP2ffifvFN8Qfxmkwji5U5ZW1kfWQTZBNl
pbJHZfNlq2SbZFtkO2XvyT6R/RU/L/4vl95lccW7Elw+VwtXmivD1caV62rn6uSa5Jrl2uR62bXd
Lbqj3NHuBLfP3cLdzz3E/bR7cwJNkCXoE0wJlgR7gjOhaUJKQteEYQmjPNRj8Li94KVejdfgNXtt
Xoc30dvMm+nN9d7nLffO9S70LvE+6d3g3e7d7T3gPeQ96n3Xe9L7ufdbX67P7+vgK/GN8I32Tbgs
XrZdbnOVXm1ZS2tdta1qc2vb1bav7VTbs7aodmbt4tqna0N1w+vz6n8N1oXqQiF+Qg3rJc6tJzvJ
CXIDOfcWcu4zARo5Nxc5t0x4gRGmY73ZELaCrWRr2Eb2Cqtin7HLYkA8KJ4Sr0Y455b5ZSX/yLmr
8eXx610aV5TL6nIh55KRc+munAjnxiPnXkDObb2Fc33d97pXNHLOiJyLSYiPcK4kYaTEOdd/w7le
jZxb4V3v3drIuePIuc+Qc20aOTfKN/4ykThHrrJagpxLrm2NnPPXdqztXDug9qHaitpltXV1Q+rb
IefKOedC36BgPh0y0+P0NSE1dJa+hxqhR4l8gjxAJpApdesxPo7LbDAlmBxsGmyCwUfgIZgO98FY
6A7t6r6sO1t3qu7dugt1H9ad5CXrVtetqttetwG/T9bNqptb91jduLoMgG+KAb4+Gz7VvzAP8fRX
916Ye+GvrzZfeABjryLQrl6ouDDzq2nnx59/8MKBb5pdWHZ+8/mV51ae23huMcC5l3jd89ZzpefQ
Mp9LO+c/l3Eu8Wzns/lnc8/mnG11NuNs2tmmZxPOxp41nyVnfj7z45nLZy6d+ZrXOvPWmcNnXj+D
rZz515kXz+w8k3+mw5n2ZxLPJJxxn4m3V9tv2L8yvI6e3uvyl+TPy5+TPytfI18tXyV/R75DvkG+
Dtev72XtRNydCiO47pJWtz6noN+GcUv8qhDdEBdGwv/wEXqgpfnnnGWItegR9WB9WAnS4TfnsiGI
0WH8dx/Wi4P1icR6/E/9uK2mjzVpDCf+jyVV/21O91uiArwAc2GeMARWwrcwH5bBYngetsAmdBEq
kK1z4Em4Cr/AUngGFsIROAtXYC1shd/gV7gGG2E7vA1vwQ4YDiNgBYyE4zAKjsE78D68C+/BCfgO
RsMHcBJOwSswBn6Gx+Fj+BA+Qln9Hn6ERTAexsEEmIjSez+sh0lQCpNhCpTBNJiKMv0AXIYZKN0P
wsMwE+X8VdgAs+BRKIfZ8AP8BPvJSvIMoUQgjIhQC3VkFVlN1pBnoR6CREbkRAEh8hx5nqwl69AW
bSBKoiJqoiEbyQtwHf4gm8iL5CXyMtlMtpCtZBvZTnaQV9BmBcguspvsgT/hE1JBFpNKspfsI6+S
KqIlOrKfHCB6YiBGYoIL8BWJImZykBwiFhJNlpDXyOvkMKkmb5AjxEpssBMCJIbYyZvkKIklDhJH
4sm/yFvwF9yAr+Eb4iQu4iYJ5Bh5m7xDjpN3yXtoM98nHpJIvMRHTpJT5APyIfmIfIweQhJpQpqS
ZLgIl8gncBrOw+fwBZyBc/ApfEmukKvkF1yrfiW/kWvkOvmD/En+IjdICqkldaSeBEkzXMeAEkqp
QBkVqYzKqYIqqYo0p2qqoVqqo3pqoEZqolHUTFpQC40mqSSNWqmNxlA7jaUOGkfjqZO66BLqpgmk
JUmnHpJBE6mX+mgSbUKb0mSaQhfSRaJBNNIrwmxhjjBPWCAsEpYKy4UnhaeF1cLzuHK+KGwRtgk7
hJ3CLmGvsF94TXhD+JfwjnACdfUD4RPhc+FL4SvhkvC9UCNcEX6hv9Bf6W/0Gv2dXqd/0D/pX/QG
raV1gkpQCxpcXQgOahN7kb3EXmab2Ra2lW1j29kOXFV2sgDbxXbjylzJ9rJ97FVcZ/azA7hOH2Kv
sdfZYVbN3mBH2JvsKPsXe4sdY2+zd9hx9i57j51g77OT7BT7gH3IPmIfs0/YafYprlKfsy/YGXaW
fcnOsfPsAvuKfc2+YRfZJfYt+45dZt+zH9iP7CdWw35mV9hV9gv7lf3GrrHfyTfkIrvO/mB/sr/Y
DVYLu2A3rSCZsBf2wZu4O9oDlXAUHoM3YAHaop5CH6GX0FvoLwwQBgqFQl+hH/xOvqPV7FE4BKuh
BjXzRXiC5MFy0p5MJ4/jevEkeQCqyCOkhvzMStkUNpuVCUXCIOFeYbBQzOayaewBNo9NZ/PZg2wB
W8gWsQq2mC1hM9hTbClbxpbjivy4tCY/y55Dn2Ytejar2Go2k61j69kGXKlfELKEVsJvAt8jygAa
HhQTihd6m9nBTIGJMrlCqVJrtDq9wWiKMluirbYYe6wjLt7pcid4Er2+pCZNk1OaNW+RmtYyPSMz
q1V265w2bXPvapfnb9+hY6f8zl263n1Pt+4FPXr26t2nb7/+AwYWFg26d3DxkKElw2D4iJGjRo8Z
O278hPsm3j9pcumUsqnTpj8w48GHHn5k5qOzymc/NmfuvPkLFi6qWLxk6bLlKx5/4smnnl75zKrV
a5597vm169Zv2PjCphdfennzlq3bhO07XtkZ2LV7T+Xefa9W7T9w8NBrrx+ufuPIm0f/9daxt985
/u57J94/eQo++PCjjz85/elnn39x5uyX587f8R3v+I53fMc7vuMd3/GO73jHd7zjO97xHf8z39Hf
vr0/r91duW3b5LTOzsrMSG+ZltqiebOU5KZNknzeRE+C2+WMj3PE2mNs1miLOcpkNOh1Wo1apVTI
ZSITKIFm+Z7OJa6AryTAfJ6uXZvzuGcYJgy7KaEk4MKkzreWCbhKpGKuW0v6seTo20r6wyX9jSWJ
wZULuc2bufI9rsCJTh5XFRnUuxDDSzt5ilyBGilcIIVXSGEtht1urODKt43t5AqQEld+oPP0sRX5
JZ3wdrvUqo6ejqNUzZvBLpUag2oMBayeybuItR2RAtSa32YXBYUWOxWwezrlB2I8nXgPAoI3f9jI
QK/ehfmdYt3uoubNAqTjCM/wAHg6BPQpUhHoKDUTkHUMyKVmXOP4aGCxa1ez6oolVQYYXpKiGekZ
OWxwYUAYVsTbMKZgu50C1ocu2v6O4s1NHQsX3JwbK1Tk28a5eLSiYoErsL534c25bn4tKsJ7YF3q
7VxS0RmbXoJM7NbXha3ReUWFATIPm3TxkfBRhcc3ypPPU0rGuwJKTwfP2IrxJTg19ooA9HnQvdtu
9+8PXQB7vquiX6HHHciL9RQN6+TYZYaKPg/uifG7Ym7Nad5sl8EYZuwunT4S0GhvDoxqzJNCUnEe
6tankbOE98hzNwpEwDXChT0p9OCYWvPLqNZQMaI1FsNPEcFagZE4I+MCyo4lFYY2PJ3XD4he9BEr
fkfbXuKp+enWlGGRFJnX8DvwIJeTRlHD/IZwICUlkJzMRUTeEecU+9hOimc1bza9ino8kw0uJMg+
6IW8HVbUJhXZ73bzCV5c5YfhGAmU9y4Mx10wPHY3+FNTigK0hOdUN+RY+vOc8oacxuolHpTkSmnX
ZwkofI1/ekN0VP7YNgES/T9kjwrnd+vr6dZ7UKErv6Ikwttu/W6JhfNbN+ZFQoGojoVCLI2EaKwg
5aJQDm4szCOFmgDz4p9MEuqRVXIFSqWUQlydA4aSruFrkcrt/g8rVYWu8loS+btapJuBNim3xtve
Er+le5oKATvMfLRbv0EVFapb8lDUwg3eHSEo8dCv0O3qGID+qJle/KsKVbfmKIoN+JFlHXkBlL9w
UiR6S8HYSLgIP1w6mzfrjIauoqKzx9W5oqRiWFWofLjHZfBU7KdH6JGKyfklDYJTFTqwODbQeUkR
8mosadO8vQf0ghWuIEIIAZx4TUX0RAxFLEesQ8ikcjxlEmIW4jDiqpTjF6y7n8jwVyFZLJE94+9L
l6LDwtHBxVJ0z8CiMC3oHaad7g4XaxMu1jIznNyiQ5gmNQtTkze9nFOVNr26fTS67qcQFCbjldCj
oCcEnLBesEAAQQVZJMUvmPYk+tLXHRYYoDsgEHRLnaFqgezWGtPbq2iIXgETOOnPtCacQ2v26Izp
69rfQ7+GnYjDCIF+jd+v6Fcwi15ADdDjNQ+xDnEYcRJxBSGjF/B7Hr/n6Dks9SWkIvIQQxHrEIcR
VxBy+iVeDfQs1yfpysN5CErP4tVAz+CwzuBVT7/A0Bf0C+zaR7uzc9L3S4GU1EjA6Y0ErLGRgCk6
vYp+uPuvps4q+s0eV4pzffs0+jEEEBQb+xhv/jG4EL0QJYjJCBmGTmPoNJQjViDWIwIIGdY5jXVO
Y53jiPcQpyEN4Uf0Qijoqd3YTBU9udvXwdk+mr5Pj4EVmXqCvi3R9+hbEn2X/kui7yCNR3qcvrU7
3gnt1ZgPWMeA1IA0FfNF+saeRJMz1N5IDyN7nHhNReQheiKGIpYjZPQwTdg90mnCmxyE4wrAkrvh
e4m+BBsV4B/v9Ps6ooy5+MXX5i4M4WWda52P+n0rV2OUX3zLnsAQv/jmLsEQv/gemo0hfvHdNx1D
/OIbOR5D/OIbNBRD/OLr2Q9DeKmia19NTHJm95xAXO319AHk0gPIpQeQSw8Aow/wL/zFeN+e3Z2c
jBxb409pmuwsP0DKD5HyPqR8IykfRcofJeWzSXkuKR9CylNIuYOUx5NyPyk/SFojK8qJv/KWaI7f
RsqPk/IdpLyMlPtIuZeUJ5JyF8n2V1H37rszJJIvkT3tuV4hvatduh776EaOulGs3aj2h/F6EhGS
Yn4s5EoIF46J5zRhT3JeON6iTfqk9l3pm1jxTZyGN+E8guEEvYli9Cbe5E28gR6veYihiGrEFUQI
IcPSCdjx5dJVj9dURB5iKGIW4gpCJnXnCoLCpEgXd0odS410uieP0Tfxm4BfN3X74wwOQ4qhq7Dc
QfTxpGd8KJ5mQzTf5ZuMCiPu1vb9of3zDy0o2yvpMroc4nAiVkTo8t1/xTmryKrdvoPO9hbyDMQz
lDqSAz7iRdoayqR4FjgUnGaCg25Dmr7bMQCr6Xf7mjkPEB2vtc/5l+Oi83tHFcXgZcdB56euKkZ2
Oz/BlG37nB87FjnfSa1SYMohXxVBcsAlFd3vaO3ccVwqOhsz1ux2PsrJPudMRxfnBIeUMSqcMaQM
Y369s49vkLMr3q+TY7jTX4b33OfMcwxx5oZLZfE6+5xp2IWUcDAZO9vUITXqiZdu2D+7ioz1N5Ov
lBfKe8pbydPlzeRuuVMeJ4+VmxUmhUGhU2gUKoVCIVMwBVWAwlwVuuBP4QfAZpmBE/7OAAEmhQ2U
X/lZMbdrREHhHghECd1ot74dSLdA9QjoNtwVuN7XU0VUuICKng4kYOoG3fp1CLRO6VYlD/UJZKd0
C8h73Vu4i5BlRZgaoAurCK5+VSTEk+bFcld1PxBinLc0ltMm85YWFYEtenqeLc/UzpjTudM/XEoi
15S/P7ZbwnGBld36Fga2xhUF0nkgFFfULfAk92X34/75an6n/biVRlJUuF9oR37N78PThXadioq6
VZEBUjlwkV+wHErML1I5RTy4eDlwKeLD5daEy3mxPpZL5ATLKZXglcp5lUqpHCO83K6yxPxOuxIT
pTJWF5RJZcqsrpvLHPdiGa9XKhNdDselMsejy3mZQDupiMOBReIdUhFiB4dUxEHsUpEBfxdJjRRZ
1FhkkdSSQP4u4wiX0V5oKKO9gGVS/tPPqA4pKWRP26IRg/k+oMSTPwpRElg8fawtUD7c5do1oiiy
QfCVDB8xltNhowJFnlGdAiM8nVy72g7+h+zBPLutp9MuGJzfr3DXYP+oTrvb+tvme4Z1KtrTpVdm
9i1tLWpsK7PXP9ysF79ZJm+rS/Y/ZGfz7C68rWzeVjZvq4u/i9QWSDLeq3CXAjoUodsp0T1UrUJ5
LYl1F3WINkxuJwlvW7ft0dgDjL/Yp0YvXIM7Oi2CZzVv37w9z0Kd4lk6vtmLZNkebeuOPUA2R7IM
mGz0dICUqdPKpoEtf1yn8F8ZfjBp6jTO8PA1pey/+2BePu7bOpVNBegWSO7bLZCHfu4uuRxTS/iQ
Am0a0tTqfHQ3w4ktMLENTxSExoI8LZenKZWRgv91/qdFaEeuBeX04B7ijydToaxICMR360fRFPSL
eNUH0F3iy0NZEQ6wjKSQsoZ7SN2GcBj4eBswdVokFOHD1AgN18IqZQ3saPxgHTRV4gGIQdjFlyGG
+cAGEPoOcZnT4LjQZZ7PKf0BC1dFALAZdpBxsAMOwxFyFfjJ3n6oBO7xdILn4BF4ChbgKjYIUxZB
H/yKmP4UiQlVQipswHVsA5zAsgPhUTgA0cQW+h5mwTzhI6w1D7SQAO2hF0yCpaR7aBoMhvNsDmRD
d7gfJpPyUGFoWeiJ0CZ4EfYLb4fqQQ12GIHfE6Gfxc9CZ6E51ngaVsN58oRyL/ixlXIs+TxMgTVC
MSOhMaEb2AM3PIB9YFAAJ0g1TcG7j4LviI08InTEu7wQCoSOYikHFMNYWAMHSBbpQt3i4FBB6ARE
Yxsz8K6rYTfsw28VvAZfEI14NbQpdBVioBncjeOphPdJtRCsnx3M44xGLjWFHMyZBK/DMThFPOQN
OknUiOmiX3wo9DGYoSX0x96+jDW/JX/QR/E7S3iLdQ51AB3y5XHObfgXfEXsJJX0JANoUzqJrhWm
gAJbbInfkTAO+b0K734OpWYf1dCTwgtsG6uVxQUvhHQ4Iz54Fp6HN4gWR+oiZeQxcpp8QzvSofRZ
+rXwFNvCPpQPw1EPgYmwFLbBH8REWpPe5F4yljxCFpDHyWpygpwil2l72o9OoFeEsUKp8BrrgN++
rIzNEeeLi2WXg4XBo8EPgn+E0kPzoTfKw2zs/dOwFke2H07C5/g9D18TkaiJDr/81Lc/eRi/j5Kl
ZKN0Bl2JrZwiX5PvcQX6ndRSXFipjMbyU1b8eugUdCifos/Rk/g9RX+ifwlWIUFIEbKEXKFImIS9
WiCswO9e4StmZydZCPmcLq4U14mbxW3iEf48Tf4YLunv1b1Qn1x/LgjBhcGVwd3BytBXYME5xMUC
t1C52Pth+B2P870SJW4nfEQ0yDs7SSbtSHfkzFAynpSSGcjJuWQNeVHq+yvkEHLpU3IF+6ylDqnP
LWgW7UB74ncIHUVL0fd6glbS0/SGIBfUgl6wCMlCF6FYGCVMFR4UVgoB4T3hS+Fr4bpQh98QUzEn
S2A+lsK6sKFsGlvLvmPfiYPFd8VLMpVsomy+rEr2Czox7eS95L3lxfLl8n3yjxUl/BQV9sKrNz/q
IBeE2UK+sBeW0QwWgzuW91Geh8JIoYCipNLNZCGdSSppojhD1pa2JT3gKm7tn6Jv0XX0Om0rFJBu
pC+M579U5R+ZmfFffueyN6GGHcKxvY93niHTkEfpFZkGdhPpd9PkX0IaSxHehS+E80TONsAZpiJW
UkNfFnqhFLzG2omF4Baeg1eEUjIT9tJ8AFWtYgnKcQ+yFe1CP5JO/hRC6PX2QCnKFr6BOTCBfgY1
qMcL4Rkyko2BZZBBHoHv4CXUiqbi/bJkmYW8Q8exChpFKoGyLfz3zCSRCKIZ5pJiYY3sCv0cpsFJ
poJzwnbs/Un6ilDArop9yFjUgJkwH0pDs+FBsZB9SMaAQAaAl11A6/aIkM7cSGehVRmMNm0favcB
tAPthQJMsaHkdEe56I8WYg1+V6GdYChB41DHB6IVex8qZf1oFYwRdQStDgB7N9gHBoVegtWhMXB/
6AlojvZgQegRvONmuATLYTOZF3wYJuPO8XPU7e5iZ3pS7BxqTivo57QvXXnr/CK3vcQGP+D3FegM
7cSDUME+hb6QF1oS+gSluwla2NUwHP3TizjKn7GFrkI1ZAR70F2hzsJkHO956B16OeQkKhgbug96
wiF4US7CMHlKpIH7/jfwE/Zn/E34GmehCWKktCFvhPTLlCkoT+sB5D8DKLGM8uO/oUpD/Pw31Lhs
a0aHocU9tO49AD2uUoYPAYyDEacAonyIQwDmsWFEYzx6OoAtHSCmK4Adqf1sGI5VAPHJiLW4Rx0E
4JoLkDD132BzGIk4Li/W8x0FSPoToGkHgORcgJTtAM1wPM07AbRwAaQlILCvLa+B9NPbTEzL6gXQ
6n6A7BYAOdiHNsiXtpMB7sKdhB/Z174aoCO2kT/2Dv5voPMTAF1eD6Pr8Du4gzv4/xxr7uAO7uAO
7uAO7uAO7uAO7uAO7uAO/rdBifTAReRv9cuhQyUlF2XyKrraHwUiuyiASs4uEohRyMSLVDhEW4KS
rCYtwJZiuJ5bn9vDcC23oD4X8jBsqMNLyzS30W304oUAgzqXUF3n5y/Zu1g1f9b/SLA3LRE/AgPc
5Vcl6QkYTHKFwVBFMvbAOp0Cqd8oX6cbAoJBcAmCsN34/BLeVHH99RrD9RpsJw+bIMXER42Z2a2y
M2Ry/FoMhJx/+v2CQYdmP5h0lyeFpAR7HyJ/Et3PX9TXniqqWHnwtaAz6LqtfU0T2sRAlSoDAZOS
90C1TiC8B3pYJwzR65w6qttu+uf2ozxgzEzy4Tcj2hptMdD62SQlJeGupIdmHxpUcDLYm1wgXx3a
v7Ji0Ie19V/8HPw1qMDWtwbPkTlwAlTQY68K2b1NVkV6+X1EyKWUqEguqKiAEZC1lrfpCUNhEsyC
9Tg169UbVmEvrhVfu2ioyTUgu/nVUGOoryFGU07LtIysDItZJk9q1Sp734leA9NzWgknTpQu9hXE
DLsX221Pquh4OhFnuJk/ZjKdLNACUoBNeoDaxclYIIZNXmpL6WG4WGz4FlILalqmQSkOMsttaU+b
kqq9e/ncHcDLAuy9AF6/jfLO5oa7uBPYesxfz6ReXi8uRj7VhDt14MSJE9I7HqHvaA7yXYC++0EI
ndttzqFVoXN+lznnGYFQYZ2wU6DCdCBm/jNCguVUwmWgl3E+tmDjbM9DeOdcw7UaQ3gOFogtUopn
Go7yuUhJsZAMQrasCBbGiD/d4Hfg/+uKycVqiIfv/K3aim1lB8XDsoPyY4p3HPK7NUWafroJmpG6
h0wPRS0yHTJdsl+KvWrXHFa/GkVjDQ5DnCHeIHs9dBXkoQugQKoMXfXb41UGhUx23GE3Oxx2hcOO
/VbYHYI23lBFN+3paSTGKmLbq403ixBfRQ/69YRqVGXWj7A/frcnkxyks8EFBtLarzHuzaND6SQ6
izJ6gCaCkyzftVjiHY7wegofqKRSeTX1xReNJmsO4ZcFuhYpOhx0eM6hNX4Iv0AxKZ7itbh92Tj/
rVplZfo8CZIwZKRHo1iggsjkTF6XTa3eF9Zc2bz64ceeI/uj/vzgo+tdXz6ycXD8jh3tc0dUP3r0
0ugJTz5XEXXy8x92FG49tGnhsJbIyQGhb1k0cjIFPvI3EbXR2nztfC3LNw40To8V+kTfZxhvHhk9
Tfugeb62wrwo9kWtSnQJ/NUfNf+5J5MTj1ZDOIP8eLODhD/Y1ZKsSo3GwmwH6CaIoWP9iZZ4h8ji
m2pNZUNdk1zUVS4v83GepfkI+Aw+6lvR3FZFWu+O+Ygc4P8nOVTtV2O2C/xAYUWzKvJEhH0pNZyB
xaVIJSlEBiL/clJRVTgjw3xEoUHOFSPbSqOyo6Mz0sMsk2c3Bhu4x9kn51fwJPgGVDqfnjBr58aZ
Gd3NJnVZ1fzx45aYK90/vDLj+ITRIx9bEbx8+o0QmWNbvSDw2CMbzGvpjJkjHps717X32JjdI4c+
1yL+tWXVwd+/xR7bUToN4gG0A1q45m9lKtSM1azRbNG8oxG7C921TzHBhLIFGpkgF1VqQQ4ajVZ7
XGBmQWCCFqhGy+TCQXoQFGi+1/tV/N8VajRwXMWq6OhXRVHlj3NmqqpItl8r9yd4MuXl7iz5Cj1q
XLVfqzVnAjVQFxXoXl0VWSJx7qdi5F5KyjUUvW8N3J7noWG/nmvM4RzLyVnQIoWh4On1euSd9FKG
FnXYlKOtCn3sV2fkCAnNcwQWF5fLX5YoQs5iGb9Z41fnaMp75Wj8vhxNggNp8xzpdYoiXB6ySIYx
w+IxCkZCV9bPpc8/+dZblcEsMvRFYV/dPS8GN6BqPF0/AYWmf+g75hZfQl3+wR/Xzf5gXEXcyqiX
o97UnNaciVUoo2y6ZLugTBPT1AdQXQUUPUOUymKKijqu05t1UWadXovy54/SqeItft16tOo6vd9C
LBaHCdX0VT0jH3HZROX1e1i8Q2scaphkmGVYbmAGlEObJIc2AjaDjdpWuEyHSBboydMoxa136/b+
kzw6b5XHvyWSG26Uw7walMhiIwJN+MUFihYpIjIXJK2WFJqUFt8smCiNUW6LW0CJBItZLkNZ7P+a
ZfV9j1XuWDJwSZMty+jn9a/2nPt4NVFMXXrt7XpSbqhYfHTjmt0986LpL9uD0wcHr39w7PHdF/iv
swuQmxbU5zhIht3+pAkxpJPcb+kU08k1yNTPNUEYKR+pGG8a6ZqqmOaYp5jvOK34ONooR4WuTHJ5
XG6u2cYm8X5tLy1FUYolHw3lvEMlVorxsWJCvFmLNru13wJ7vWUGiXe4vhoMBmpY0UzFmRVPcvyq
POtQ6yTrLCuzVtHEPSnHwtyqaeBURHUllU0trmlgC1dZOS66qKto0riGmrh98ySA0ZDN9ZWYb+Ka
ULvH1uzuCQPa9x9O2x8aU1n/wKm5XwUvPr/o8o4v67N7LusxZdPGhx/ayvrqxqcVpLX7+eyIkuAf
H1bUPEq6kUfIljc2H6n7snhrUdXaVTt38jVlGGpttPgy6uxkv+6oljD8owqmRI3k5j6NEqbUaMsE
gfJh95QMvEDtekWZ8kfoSYaSoVTIQzKJzCKMxOgiUoIuVHFpbsG1mh6G66UpuQV8heO2P8eYEzb0
XBpwJZaBIJN7WplM2cOEvUuCNd1a6fcLj/22iN3YseTpoClYW3VmB/mBHHuOz/J+7PB85pN8utZ+
FxNBJldSWS4TcomM4cqdCnlAuUe0QRHxLUp5u7i+SgqPfy3TonABFxD7cREXik6cqHsZF3Ma9mKk
e+tgnj+1TD1H/aT6BfVVtQhq4lNlqzqrBqhGqfaqvlbJ1SqdnLcpz5XJRB1Tb1Nxj8cj5jKpG7PR
9ZTJc5mqtbqNmMryGHUxwjboG7qUiw5PveTqcItUX19jCPs9UifB8A5nDkwpbehoowt0IuIENfS6
wRXC8U6Gr1lbxt8uHuTXlNPlDO0MQTtLD9JB/PVUOmi36Eet7gUi9tQC22Tb0BHNlYFd4RKJOE0+
cBD27dtinK3cghqISbXX4Mdmj/SKry4opSSL/7G2dVkCqQsJ79LZwWF7SB7J3RMczednEP+v+egP
xUMCzPWnLrEvjqWP2B+JpcPto2LpBM0wHR2ETgptpeuko7ExCjkDQ5LRCNqmZhKP4rbT73EnuHOd
KmduQoIr1+2OhyHx96uGWMcnGoa40BUZ75H6iTqFbus1zjd0Geslx/F6rmSALhqllbAYP1CMDnUW
96fb0ZvXP8Y5qqNyzlvyGYmPbpl4sPWmB8rW2PbH/PHupwQGzSlsZadVJ8i4RNP4gjZtU14c3mbc
uhWro0988cNLJRun9rin5L7gM1xqQvU41UW45slBR+L9I1INaYYxirHKEsNCYYXhHfEtWbXhqkGt
EIvIANrLMFYdMPym+U37m07JNEzLdIJapRQZQ5dCIZPLNRhWyDRydCxdco0ZE6gguJjGjCWU8aKo
iJcJsio62a8EheZ7P//h6gGiBkLUfpPGBaPkQp9e7CQ7z4QVKG9VhPjVvTTV8vMaYYWGaHjcoJef
lNNZ8nI5lT+pP/1pWB5jEPhnw7m2xxhqasCWl2uvybsocbeGO6VoyBe0sKVEvDTU4ZwFhqNHdUeP
LhDDFFneLaDu2y0Q33tQYSXTCwr5AfQwIfQnN3FFZEppsQfdWY/gFqLcgi9JJhdoxge08Mtt9c9u
+Jz8srpzgiNDPHCjMzkU7EQHkZX7H1i6GHVxJUrU98hfo2TZZ/t7MdbZM8Az2lOmnKuUjbNPEycr
UVXFOWpZUrRSsCUlx0fHKZVRpvjk5KZNwREXj1xyxscbQWHzyfp5fRp7s7h4F+E2ojil7WBJmKQd
3/WCmgb3FIGShIKVm5NqzOH+Vdi9QonKMLpv8p901EPc6WHn1OfB5T89LGoYXkl9m98tGz1m3vKB
5W8sCT5J7prd+p5unR9bGzxDJg7xdRzUpt/TS4I7xANF+0cNeSkj6VD5mF0lLYU+xujRBXdPalq7
Xq5pPaFznwdbcu0eHfpOnI56FQdV/pIRdHwc2rh07QjU+qlx5TA3bgWsEbcJL2r3C5XaY9pTcDHu
tzijzhRnjIsTkmVNjMkOl7OLdoB5oGVAzFhxQtzDpsWmNcJq3RrHZrKJbjZ+oosCM9gNZoOd8Q3M
7iY5hHtVSU1yDHogLDYqXiPExjOlwae/B3wuQojdafW5FEQREz9icNjaF3BTX1zQsMyF9TAlpbi4
FC3HFGKVMU9CInLHlIgqaJX7uEJSi9nElzZWeeSu4JuXaoKfPruTdDxyljRrezjjyJNbvhk88dv5
L3xNacsrtW+Q+z+8RPrvuvBu8/VPbAxeefxg8PuKQ2h11qIODkIZ0SN/5vp9LifpqAhPvNEQrwcF
dlRJlHZnnCEy7/F/zzs3JY2T3jKt44P+VkKsXCFTiAqmYLIYm91GZWqVRqVVCTJLtDk6KlqQxQpW
NzHp8GJTONwkWmV0Qwpuz1OS8TObSEJixQ00LuMURcTrTo9sYHCNd68lf20b9GjR1LIeDz1+Yl5w
F8l5/MWW+QXP3NdjR/A98YAlrvvw4MmjLweDW4al72jVMv/7l779IzmeS8FG1AX+Nq4a7vVbZGK8
QiGXg8D4QFXKeDUo5HzOHAZTpryfcI9L5dJSlV3LlJFRa9reG54ofrQhTdW1iym3Czzub43olEWw
kSXWrRVS6j4R5ooHdgTztge1O3hPNmNP5mFPlNDNnyz1ZLmcNHYGO/Ic7nbUlNrVja2r2g6+rfWL
YYeAu0K3t7xZ+LLuEg3U9+KtttlRPxrvMBF1YD/qgBc+8+fHmmMttCSJDFFEEZOQmAhuk5V6AVsn
Mmu8TnDHy5SE+JK8ibjKYV+SStBnmVKeRJLifC4VUcX4RtzbILUFhmIUhQLsAnfLJNnlzJCi4b1V
DvdXUDQ6MU+sw+6IcQgyjc/gtficPoWX+TxemzbODdH6KDcWNke55BhLEL1u4lCjjJiNeIlXut2Q
KOBFencbZYWv+Y1vYnOpQS3J8hpv0ZJoq7wFRTXhh0FmE0NFyTYK3enE5cFT6z8LrqvcQ3qdWUfI
E76d7uH7Js078oC79QJCH3/0ajuat53UX5hStp8M+ew0KascU/VU2uTygt5zey5cdzT4Z/mwbGLk
M7kJdSdBkqmxfPeDKh9lyWRCvFK1XnVKRVUipWoFKoNLLpcVl2uJlqrDE8pFzYJlUa5cWuJCx7lE
O1nL2hbZUopLcdMlKVfx9Vxp24USllOcKmkYScENktGN8OB10xF648iRepl4oP4lOuhGZ7qnvgBv
fhi7Nht7JcBTe7k8URGb29P6rkyJZmSGafO0MG3SNEw93jCNiw9Tm12i/lStIdMlrhB3iigLuLYu
h/UQAJaK25pecB6ugmhyYeIKbG4jO10kmQbc6e0ux5W1uKh0Sm59ccM88S0kF9QM4+EjfLXCvuIK
JfbhHCTz/C2FhOwchbJNkipL1krVRTVQmC98Ksinqz4XPlcJTcQlrELcyn5QiCpGsthpRpV846E0
uTMFF7+g6d2jyTHx1D0YV0Qo4zROotV7TNE8/Zz/rhhsyeu9S6GMibkLJUSpUipUosCYS1SZcbOs
VOCkydCJkKlUIFJGqFytAIVKoGr0B6toG78+TSTrxYBYLV4QmXiPgqep0+TEhe5BQC7Iq+h8v1rt
ihiPzZKvgLuX0hruVXPxzeVTm5vLgRrD/QR+joPUJu2r5QpDriIX/QIb+gWx6BfsBxb6rHWRtCw0
/BDCb1Qm4EiaxeQwjoTYHJyzc/uiMRidI+MDVZtyFAnmHOY35/CB7/Vi0JJz088YirhKkdIpxVCK
E8Unh7gJ/smNK4/Qz4i8fjV9LAT116+ilDWln9a/UreKfvtDUPrdFvcvknH2RMjwawhFyRdBwb31
KvqyXyenQsR8yW5aMr4tDlvNsCC4LdjKhygMv+3AgqsAZHq8n4FM888CqleYaayCTdfM17ytEZSa
uzV364WmzKttpisU7mXTtTN0C7QKNRUVOdpWup60m4DbVkWBtoNOtYquFlbKVyo2Cy/LZSaq1+nS
RIoTSxUarTZNVGBQoemj70P86AYq+P8hU2u1Op0BFEpaYio3UdMBuhm38y13iy5FFWnpV2mUKpdf
M0tN1AfoAPRX1ZhDq9B5VOoJuPSTDcRQRQe86hJLxHJREKvo5j1Grs8x/Ii2ONeGQ5f8QwzbGyMX
i9FbRAkw3PTFXYPkNS6YKXmNSHD38Ld7+BpoQrWgCJ1G//m05B12C2gwr4kkItrQn7t0Kp4aOZH5
eJ87R9fMLZ3K7MvO0aVnS8G9zTE1cvKSUoT+Jc6+tPSSaGurbOJG+0I8xLiKJJJ706JjsnCLKh4M
DtgZLBQP1P76eNdezwp1Nzqzd2uz2IVaF5cF3GKKTmlV+2GXSc0tRxYaOAX3weUKVCQFbhkEhZJR
qpQrmODCvV+xS01c6l7qEvVkdblaVCtwuZNMowZrRta9sEFJkexh6bVGg2jih1DoR7MWYQYRrg2V
Cn/nHDQD1fs65yj86eFgeo4cVYT7ZftiMJgeDvJUT/i4We3JkevMiCgev7YvCoNx4WAcBi08+Oeu
Rp2JaJ+0EBWhCBNujInxuWMCPXCsLojsmc1mIWvKa8vRuxqB6+6X4se4K46FWf4Su56YDWZzrDU2
ljEDM6ut6li2xbpP95ZOsFptsdQV5zf2jOpp9dsLxULlQEN/49CoQdahtgH2gbGLraupISZeEEzx
aqXF50KnwV4eR+L0Ps6rGMfNrmQx9yWl1Zh73uhDoiMZZQB3OuNulbRKZhsgIx2MmRRdSRhBFpJW
75LO2yqD+w6fDB7Y/DaJ+/QMiX3w+8ffD35Kj5OJ5PkjwRfPng+u3/s2GfR68I/gSZJJYvcQ9ZPB
SxD2I1k9zr8WbDDQnzXKOMFMuxm6me813Gtmak08qiBYbWEPx+RT2F12gn92mzZiI2Ju3k6UFl8v
qGn0cMJLX2T/YI1Ht5e63UYMN3qFtOkTBfc9UfRz8J3gQvLwobXF3VvODS4SD+hMo/ZNPBisr98u
kCWzBs+xaLGnG1BSceuA/Uwg3f16k1pHTK0cg5yjFROdzFQV+nqPyZ6J9OqehKRMI4/HJWUaIlQf
oZj/2Z44XzgfyxsilOf7yzDg1d3juMfVVz3YMdExRTlD96B+nmqh/hntFn2V/rLuO71Bp9G4jHqz
0ag36jVKUyx126NVMpPRoNWINqUy2mqPibdawZ0g8cxm0+t1inif7jlZsStxcmJ5opCYYIvwzsPX
lwb3EOc+5qKN++XcmkRYyA9MclKlhwbhZwZi44OSyCd8PqtS+PU5ekMbo6kNl29SKpkRHaqJPSbH
iIpkQuj8jhwDLiqGBCeiUTOKbtreoQMf5RFaUJwdjzRT0vmbewOtOPreQ8c/KmjSv3vo2pH+9w9s
7u72Fdkwb2WPZ14IpokHer794HOn47yJPaYFS0nLuUtaq+X104SM7Ae7jJ3Prczg0HfsR/Rj0yDo
f26EMIKVCVMZ8yZlCTmOjsLd8u5x+c5OiZ2T+gpF8sFxA5ssitI10foSaaKQ5G2lz/R08uanDnIN
8PT33qcer52gG20eZXtQ/ZD2If1Mw7TEMu98oUK9SFuhX2qYlzjH+4R2pX6lJd6bqNOqRTfuimIV
chkTqIx4ExMwDZ332ObLUYproqG5gbhIL1JCJpMVREaqSMDvbR4fHy2I8c2VsT77PUofNCVN7elu
n4n4TP0knW3Z6EhfrDHcugPkDycQ1/jxEc4ZPzggkZOkUtToqOx4mpEe2RclJvl8WZnhpxORvaHF
bI1mVmk2ZKjtvsGvaoe+PXPS1r69BrcN3td73JhHf33qhb/miwf0O7YENuS0Jp8Xlj80v/b5Y8Hf
VpNPDfcvHdihrFP+GI91WEr2C6MmvTFy3HuzdYuXzb63Z0bGhCZt906fdrJs6vc4hjTU+wPSGU5P
v1ak8cgekP4Vk7KKlu1xhY9SXpW5CE0ViIDhvSTsAmOuYt/qsM5z0TXUXyz+1iA9ycxreGicxfcz
NCoYxyqCsaJ2x44bv3Ep2IBWlfvdZij1q3z6QlaoeEfBovnSEY1LRyZrq+jM7lFM178kXtbLNUCN
/DDWIVOafbTYFU1c0b2iaUn05OjyaCFaK+1peF0l1lUVW/iag3OSUsw3N8Wl18OGVDJBqCUkwxgx
oFlo+cNny0ZWcmRksPbj94M3Jh/psmPm6X3igbpdXwbrXlhGtN8LPet2H947/Ij0HBPXRxA7S895
fvd3TRVJMjQRvKpUTZqmRLNIsUi5QlOtuapRuzS9NJTh9gF3p0qXQjTjPgI9ahcVzZSKSkLF710q
9FZGKcgoquC9VzfJ6aUg5YoVCowT4tdSf5OcoZQsp+sopTzF6BJ7iTQNPZQV6LZeFUX0UhbuUZds
DnsppReLS1M4bIbwI1V7TI0t/Fj1phOssCdiRm9jN+iRbb/sVpoIJ+isVYV+bt26dcQpaYLFWklO
CfD/NCOtQ2jD3SQj7GNkENq+/u0PycwWzoTmZMlb9bgnqP20fPKMGayptDeIAZBP53aaLPF3ago+
Y1OTz5YDrYw5pla2u6GL8W5TF1shDDQWmgbaDKsUq/RUYOjiyeTIK5Vao1FqdXq9xhxlMvH/LWuz
VIVy94hgc3GqMRk59Q+yoNeBHj5F18NMCNhEhSLeYjNbLDaTRqmMt5gwaDJq9HqXwWg2GIwmpUZh
s4h6owHlSrRoRMFm0OuVuGGgaKdtJpPRCAq71Wo3tFeS3uACDV4tCD+IpPc+Fz/+iYmpIot3RWy2
PaagHj3CentMva1H/qhO3zZa7gaPkJttfm7YAPR7Cm72D28laIkX6AxHj+Il92hD6OYLzo0e58bI
p9CkslWFrocnzIuJyX9PWMTn1GHKHo1f9LeW5nAKn8Co8ARGmZBEZaCjyI8kCVkbfPjY+UR7axWx
/vBhT4+j+bdvBu8/GHw3SW41B99Blch75ukfE4Vz9fbgT78trhReQTepeIlrVJfaF1AzQl8Fx6Ga
/4gbSTvuJvL4ewgQwzq2l15CaHgHQUCT4GRbguMee4x7HfeELjMHawdNIJvE+ZcptcrkGK09uak2
ORn3BJbs2DbJdycXa4uTx2vHJZekVWjnN10T/ax9i9byUszWJvtiDjY5GnOyyYeWL5soOkUTp9Vp
S2mWnJnDcprdzbo2G6AoShmtGJcyXbNA847mL+1fKcbsTB1hhtTETGu622wb2nRSU9rUkarL0y3X
rdOFdOI63U7dFZ2g0zkEaxXd6o+2PW12OOSQn6RKdwjqpsMMw8DrTqyi9/oNSX7+INvlS/Pt9Im+
ljlci53xnsy0nOocuj6H5Fi9toTUxMOykzLqlOXJqKxla/4wjJ/do5peL665llt/6RK3ThcbHmpj
bmn46CXn7ycP3L338nVAWiWypW9WZlL4UL8dlZaNaIvFHG31+AR+uo9BflzSKkvIHbl//M5DXcq6
Zk34YgzJyF8468G4gO3+U4sWbu1lUFoTDjmsw49OGpw+cdzYjb64Of07b5vXY3YPs05rT/Sq7m9+
V1GprXRxN/+we1rMuFo7767W5MsmDkOTgtSuJff2vOsBnMH5OIN832CAODjt305EjT5RzBLzRTHP
GXBSpzPBkeHo4JjsXOGUtYnKjc61d4/ubi9WFGsL9cXRQ+zjFfdpx+rvj77fXu38XPOF9YuYr6N+
sv4U803cBWfIGeMSU/Wp5jQxT+8Xu+t7iaPFL+J+ZzcMGoNFx2QUYh0ouSqLQ6e2JZ5SE4Paj9uR
cjVTT0XHHjIEL6XVBFf09SRArhLmJHmkJxFITHyX7Mhjuin89Is/k5KeltXk4Z907C1xHrOh1O3B
lQIXZ/RcDeBJSBJwbW58Ikmav1w5ZdfwnaX+4K+vHZpAM/s/Pn37i9Omb8f99u/Ley4/Xha8Ejz9
PFl5uP/iE++eeusEWsZeoctCDUq9HU74uyg1xOnoGNXR2jeqr7UkqsT6LH1WWKPdZNhk1yi0Marx
dJwwXpymmawt176k2avcp9qr0UTjnvobKugShuon6WfpBT3hwnp3mnSqUwKTYQWshwtwFZcrvV6N
S7zJoZbbHEzt0BN9oi4hFnuRqE5xosVEe3a3w5J4Uk6c8jw5lbeMzTwqreql/MntlMi/P9uPCo5G
pWbKtZopDaeExpxUAzo5xRcbnBpiDT+4zTRxV6bRk+HMEnJ3xV155YvgH1O+X7TjrHNnzKxBC7du
mjt+GZlnffUkiSOq7YTO3rkhdsJ9b350+shjKFmdkUvnI08/Tvu3qSjTerWZ2k5aMcuc5RhI+6n6
mPs6xtCR4ijlCHOJo9r5sfhJ1Jcxl6Iuma9Yf4y5JElQtNOZYudi183OZVDegiZqW0S3oVnabjRf
29l8t2OgaoB2jPaS7LvoG+SazkAsgk5t0KNkqeVGQNES1LYMAl6j3mswnDISg9FvLDGWG5lxqinx
sPyk/Lw8JGecdz3lgjwmPrNXRLAK+HGR9EZX7kXJA+H4W7S4UruzuFKjVocZxg9vzDc97G496uis
T6aN/3hOycrUPfWu7dOmv7j54Rkb5q9dUvvCOiJU9G5PdTc6U9N7x99464v3jiLPuqE2xqNkWZBn
5/wjneCw0P5CsVis7K8eJUwQJylHqRUGMBADTTJ9Lt4wX7fLW5raxLR0tDcV2Ns7epsGx/RxDDNN
tA9zzJDNsFyn120GiCZ6rdXaK5q7XEK0Q7/CsN5ADQYW61DJgQuekjwdhcJl9WslPywpOTOgJVq7
kx/ZeX2ZnPrjuGV0Emd0hiFR7k9MzryJZRFdTCmov4ibx5SU66UpktdWH3mvIre+NDfyDDu8kySl
UxqELbwNNsvdkitH3NK7BDJhyIFmP+//PniFmM9+QnSk7rJq97wRS+q/oL01rQcsemQLGWB9oZI4
0RZoSJPgueBfBtfOA2PJ0/M7jn2J+3lRuDyV407FCnv88WYl0cekxqTF+GMmxzyreU67Rauwa5to
AzHVMSyGj66J3ZkZp9AKGr1DRSw0xRzFBBmo1pmJORTlZ1YvA4E+QaTzkT0tW2dK5yQqhzNzBbb1
gi3mEDkAbrhOVGDD4eO2Dn1qdB3Qkasp5g51rvTmGPoO0lm82WCUKeUyBS4pBtx6glGmjyUpJCV5
9mySgoI1JcPoycrgT39RrlAPuRpa+Js5u9eti7LPmd59cGzr9D6dTp4U1iwpnZDZeaDpeVXnkuFL
6kajDHUI9hZ+QBmKh2S46i9Rq0VzM7XX3F2db5Yp42Limql95maeHHUr8z3qzuYB8kL1WPUN1e8W
XQtPs6R2nnZJ3ZNWNFvfTN7K3appXrPO6s7u/Kb93P2ajpOPcI9oWtKsvNkXSZfdP3uuJBmt0TJL
Fd1V2cQRJZcsmMGFGxJuv8qhGk4Bl66Z/vaiw6FX5Sc4NKpoS4Y3Q+W12U5ZicHqt5ZYy63MOlVP
vJDgTDysP6k/rw/pmVOfp++JVjEmpdlUN1fIlB6SQl7j27JSvlW5zt/buRh5dedieHdQilbMyh9d
SWtnEkoXDWumNQt3CtL6G3WTeo7eqU7vOHXmQpuOTA+cuXr/B0sPPfTSqDPrX/9h9UszH9m846EZ
mwvtvb3pIwdlBxaT3C9XEbJkVXnd+D9PztgmJH9Qffi9N996E2d/AYBwWdoN7doP0fx1Los108uy
hHzhgJZJ790lWmMyrQqjxmgWRAJ6hyg3q1Uar9Kf0SozpCTVSqLsIW2frJmtMgPRV6Pp5Oj10YHo
UDSLpmZv5IEFFr7K39t0IWcvAIMeli69wpY+cj6Xco2/qQOSpTLyd1Uij350Mp3cq5NpYolWgYIG
/BBtNqQUhx9nhF+qM3qMEldkFuOCykerp7/SrXLahF5Lc3EZ/PWJ4k3P1Q+lGxY83HfZzPqDKGML
UcVypWcccpjpL+6pXKFcrwwoq5XnlVeVclA6lZOV5cp1kaQLypBS5VTiWiVnVFDKhEcJyEQZU8nk
XhGkf0McYNXsApNVs6uMAnOxUxhjrIeiYYRTcqU34HBkpMEP51Meec8ER7GwsrKS/XjyZK2F+Wq/
QOUPbQz2Jm2kPppgtb+AiV6xLcsQ54uiVSGKcsYoE6OAaNVUMGuYUVTLeb/UMrnDqF+Beo97CI1G
61WpVqiJU52n7qkW1DFR5h3uLg0CKT1362Hgm4ZSyCvgvof0vK2xi8aMjAUGRfjRrE5h0PsUBlUs
UerksRCeBP5Cb4aFhN9y5PtZ/ibZ/Mrg2IRWzuxWlRntn7mbff/BB389vFp39xNscO36owUjuXVD
/gt/Ss9t3vPb5bIBskFKQa/9TbwuE/r/r9a+BDyO4kq4qrpn+piemZ5Dc+hs67YlS7IsWx4h8Bjf
GFtgyQbZFjAetaSx55BmRpIFDphwGBIWCNkskN38XA7HJru+DyAsDgE24VicBZJAPoL5MAkkYePd
38u/xCvpf1XdMxpj59jD8nS/rq56Ve+s97qqZ7hxmbitmoctwZw+6K5rk+B8CM5uCyuYxQrCt0KJ
lectvLVdWgncsc6Vr5bHuVH5Xe5Dq/C4FVdZa4UaMWRdJC22d9l7+V7r1UKv9CV+wvKg9LL1n/mf
WE9ZPxH+n/VzscgtyxaO4wldypFEuIB8rMZYwOF4vsZY1JFB8ryIQb70t0dEmw3JPP36PUslJMzO
cJXG4pfie2HqsdUgUgNxH4I8pAv0LajYP5i1cmCG7+xxzUjueY2ZsMH07A/RfJnPreTQJR0BJCB2
cuxobJUMy1JjWUgSy8o66SLNgTK6VvPWAY2d9s8yN0SyZ/IjyPzGK+v08QOz2CPtAz56+sUBla3w
wIldKey035Z7po/NFSL3ezwWvT7ozevtZAdo9dmBAG382/0lRnXc18uCVbb8Mx9DRieAQuO//WRq
G37+F1OP3ATJ2/fwvqmxyX5Scf0U3T9+C6hBO9Puu55GFpiU2hcZC4dtC4xzyzzjXGksLIZrwCs5
LRWWhyzvW/guOJy2cBWWYcsuy7SFp7+3RzjD0VBMzOEUwwz0EMLHIQwlBV6Hz9tkQ4Nhlcz5phkl
lIJbDpmri+AZrbUwE1Whl59G0vTPwktsdvCMp/hT0gf+jzTL25bPNOIXtSopUKJJHFdVXmotKrWB
CWJrVXFQlU/UYPrbHKQGbNFRcy/bzt13OFBzbwkuASgcRGR+VQ0+gTCNl0kFotrCoWB1zTG84+CM
oUKOMHmKLgCe6ZtkOT6kBWzxb7GhSi5/4Uq5Q/F6ar2KqwS77UU5d0mjFkpdEXvM52f7uJnPZJNz
ofd8pPXxbWP3V9z4yv/524NVWy4Z/stDV/dffnMHX/uNddduvfqZvUcm68i34td2fGPP5P3kwI4d
V3zza5PvmPPIL4FbPvRa2GPhrB7ypHpM/ZD7lec095nHylObnQcMnFDxA+qJwMnAdIDXRK/D63PD
hIKtPrtsdyiOahubVWwY/tvWBZgg6awSOB0gw4GHA/sCxwN8gCPzi3zmxOI+b2Lx5yaVM51GpgvT
Cnsy2EldXH5e8VldkizKgsxZ1VqX1VGCnbLbZBjdFADGw3S6aKGZ4hYwbPejo+9d98gVqnxozvZV
mSf42vv3Lh9e2/qlyQy5PZlYct9rk3R3zDKIh+uAJ3YURN8P97kFOaistK4SN1p7xUFrTBTb1A53
h29BYLm6xr3GtzywxbJFWq/2uft86wMJS0LqVxPuhK8/MI6LJKvFvpnrsfTIm5U4p1t0Oa7I/lJe
cIHKeavZ/hNPdU1bi4CRoAoahLbz3qeKBuVBGvwC7KhGYahCFY2gecU08GU7iiHo7fusr68hv+ZD
swNq/lK3pVvaatkq8WDjHrYjFpn7YwtjkWV77nzp59h3w2+++v7Up08f2H37gYO37T5APLju7rGp
DyZf/82XcTm2v/bqaz9+6dVXoOvdUzF+FvDFDVHeG+FvK+pc9WJ1jcov1vZppEKbrVSVtRa1ll1a
Nqzdq4kd/o6Sy/yXlfSKm5Ut/i0l28TtSkxN+LeXHNfe9L4XeK/4zfJT3lPlJ7VpzVfFN6gNRQv4
DnUFf5m6Sf3I9puyKdXmckDmQJN1qw+SdeQIVp+QsSqH5evkXTIvZ7FnPpnvrkHogul6BaTr+EL5
OkvYXaHCdN2TMzJfkZfQoK3OxRWwaveejvuG7jixbfT9Gzbd0+R6fGzHd57IZvZPxSzPfeXKK++a
fuCxqbNfvbxj8iy35/UXX3371Vd+CvxaNRXjTgK/VFSK/iH8gI00kDmBi8gaMqFYFxctDq4J3lv+
cLmlzdNWsrh8mWdZCSTzJVFPtOS68l3lb1nfdv/S+ony64A6m1QqDUUhskBZTVYom0iMvKP8PPCh
75PgL0v+kzgxb/cWQ97psHohnUIOv2M+olmnE6vOsPM65y4n78y6LpB1lpWfE+caQe6ZzvP5g0aw
y0zSF5qR7TkpZ+Oc+zc8N/W71Js3vjTy6OSs7+7IPL53bPSxqRgRL1qHm7Dw8NQtj9/9+6Xc373+
+g/+8a2f/CONJm6DcOll4I4L3RK+qNmDVR5X8W38Ur6bH+CzvFVyiZIo2T0uyY44EduYGiBZqr9X
xGKl5sEeUun6g1Gqe+WL+Sj1lNp3Jk33TlGiQrlXGZD6o90Ots7el6ar4Ib8jbxHAF9x26OXxBZv
vuaSSy+96BpvOV/7yMiqjifqVi6+Lj35Fh3/4umPuf0w/hb8TvgGvtJb2SFdJi2r3lipV+6U7pZu
rX7c853GFzi75C8O+FvWNP7EbykhGwhRW7Ec2CJukbbIW2xblC32beI2aZu8zbZN2WY/VHuozknX
dqpnL6zeJPfa+mv767NV2epd1V+X/0a5r/7+xm+07JGfUh6r21N/sPalWl8ZXc52l4c2iXU1iswX
a7VFvK2prJgmRqUVwcXBruC1wb3BN4JWZ7AimAq+H+QrgvcESfBZsgEyfkTzJ5XuiFDxCYiSsIoJ
3ch40OtrYxsayx2uNoybtpTFy0hZaZHAlzbZKopxcXUw7Am0BY+RzQeE6jlQ82hp6MQcPKe4lbaq
hWz+utbjrWRx665W0qpijKuRVu2sfD8fXM3LJfAja+nbXOl1zOnTHP5Mg/m4aATS+Abw5mlmuOlT
+e1lfmMqCNfNLa+CRLPWpbpVj8pZK+1aCZLqhRJsmQuHci9cznJUlaDKKrsizoYwuL5Okq0NfAmq
UMvopGFsKmMHtsg/p+Hmm2mWMkLD/JmXL+pq65ogr1vYft56G/zRxWmW6C0+4Lzzhp07FtR8/eUH
u5YsmvO17i89t8m1T8nEdm7z+ZpLbn3+/o2xl7/0xjv44tLtaX3ZxVWBmtbVN69bOVFf0bDqhsHA
+i3r26tKyzxy9fwlO7dseuiq71JNq57+NzLH8iDyo11PI5lu26qlwfTx8BIAdgUhw1HsMuaQT5Ua
nDK4Ss7mVCtRJba7axQ8LYjLpeXXCcPCLuFegUcwxzws7BOOCycEq/AM2YYCeOH+AcNY2GuFkNWd
ol7gU7oiR70AJBRsh31fQ0ON33j2RJ8UuNrZeztsNYyoxZd3bo033nrrwcOHPQ315Y88pF6iP0qi
d2EhPvUXd01+fW1jMaXlFrCak+w7U597GhXT5z4QIRLN46OL6KfDs93etgYPrhY9PgV7fDYweBeQ
g+b7agJ+FmL48XE/9q8rZmZPQ4zi08VkuPjh4n3F08V8MeS3eYcAuZ+kSScgE+SldcF82vppLroA
z8Ce3XaGzBcsQKWKedVhd9rpehLd0QoxBq+UILvoMpKnOXNuBo8IemI+hKurZQmUn6kJS6a4xTvf
vuaxLtV2yOZKXnnl3Rcd+ptDqxJdCzLkvsmDfzFv5ZXd99xBQpAsYvr2F/cx8ELG1xxdACl6pSsk
U2u2u0IShFdtIj2QY9O/PghnbJ6hxs/CUvmsNlQPB7j6OCxBtI18cICrd8OH65vakAYHpzIb1Uu1
cggtkFehlfJGvJH0ildLA3iAxMSYtAON43EyIe6QxuXdeDe5nbtTuEP8ivQt9ID0Nfm76FH5OXRU
2C//CL0kv4veln+LPpTPojNyo4wscgD55HpEX/LoQpDZWMJuX5slDIGiDElWjSR7JUlGHIF8iq2w
QR6GZGO5zCrIEoewpVnBSqUYDochZyfSMVxyOAxpAbEAFJY0EsaVtl//MxXZp8XByb7JvuLAp6f6
zFdS8smXK3Terim6sW1mhwPb5JBbvfJAlvP3U/F/OFVTEWj47dNTSb528tbBVM8YuYNm75j+dIHl
KEjETfaHVacXz+Fny+Qy12bX3S7ORfVTqpjVppaWGdlt+O8qqtt4qyJ5rCVS0G3hEW+1STaH6FaR
h/MKpWKJrQyCtxphjtjgaEMLhA7xIscybqU1LKwV19iWOle6LnNvdq53bxf6xUH3hPV6ISs+bX3G
ecT979azUr3NVY/q7XWOemedu9m7CLW7x8XbxQe4+5Un8JPkSdvjymF0xPqM44eQFb8jfcx/7PyV
+4z191Kpm2NLooJFkmXRpiiy6nKBfa05aEFu7dj06vCA7HRoP3AJoia43O4GiwCpsuCQFaXG7vDa
7Q7R5XQ2yKIXmtN1UlOKiGDBzYtOl+Kwyy6Z59x2RaF7qqlY3U6620f2fqbaMd3YusvO2Y/hJ8Ky
1iXjlHyTTORjZENY6nLhlOsmF12e3xC2qRZ8HcsHORD8E4fxZ57PBti0EFx7pq8vAG4f/lMF6Atc
eI3U1AgXO/4ZS6SCQ+2kHwrTz5p9Fd1XH7Jrika+N30SYfg4pk8cQi1OzX1s+iReZP7rXbOvrRtS
cnH6xH6BvoYGBbO61+ybz9Y5xOmT+wXNKHWbm/boFpoTR5waxS0emz5xQGihGA+gReQZo6c88nw7
P2vnmj55UNZ4jb7Z25t70dIx/dYRdwg1woc+MPCE2OMClgGzfXxUyZmOe/xsfZar4/CaqWefeWox
P/+ppx9acPGRvVOHnn1q9k9B6f/6lOsVkpx84NXXycDZd8nOw//5Bv1lBfBH/wrar+Lxo043dlYG
je2kR4KhTc6/4v9KfNDxTedxy3HrceFVp+QM+0LFnEcqsherC3CH7WZ8t01sdl/F9wq9tqsd9+MH
5AdsR8kx5Ye2Vxyvqe9yb0s/tv9c/Uh2u61WThAlCVutkoXnYLZygtO1Y6fTrtrAZxO7jVNU2eok
Tll9Gb0sEbUGSV6EJI7YX7Zje43CeRWFkyVI34lVtYMWIrnLjd2r7TcqlbIzYpVuDMvgSI6GrVdY
d7FXgJaGHRp3I6nsAkJXu3a+aL5kzXwLuBb1I/XMp2yb6oyKsXfLTQXqM1/MDDmdu0WmOMYRTlSb
8k95DjkCZSEb22JYFlIq/SEOPvT6wKyQyh7fF4Vw5ayQFC7Nb8jtZTkrfSAD/mm+n3qqdvo8hqvD
Tnzr1IMfPNZU2lhz8KdTX8Nffe/djqlPSD2e+nxly6Xzz04pk/+EL+ud6qPea9bUldy/gPyK8e6D
zlLspKPYUxqq92507pW5sD0MDNXqW9pUehAUye2zB9x1tjqlzr5QWWhf4HjQZat313tW+XrdvZ7e
opg75okVTVjH7BOu673XF91m/4rrLvddnju9D8hP2r6nPut6xvtr+Vfef7dPqp97p0vLwQUoKvgT
8PxBr8dT45a9cOFUwGHU2GSvzSZ73G5FsVm50qATlaqlpLn0+VJSeowsPuz0hN1h7zHSE7Ytdofd
5Fr3827iPoYvPeLElWh5iUxvuZ2aLRzWlBalS+GuUKYVokCNg81OIJYsPlSi7QTnURxUJ+nLWSBV
ut02oJ45FVRPQeJXHFA/ZRAK0OAmJ2Kx8LkdlfFuJlDwDA6wyABY5LNImf4Y2aY/xgX26J3+xZH2
kFzZHnLAJHy4KOQyd8WBOJlJgjw9dcayQDvbOWFOQfQ1/KrKm7wXNXau8rtqLbapxAvvNVRWNHx4
aCq+pLpl58a2qcGn1Prqku3OMr5+8sHRm3eOke1nf7j30t5uKud6sNO3QM4OfEfY7j5GfiQSN251
++mj138KSwDgS8rZg9gXwpcBMJvUS81qCIfk1XgFWSGulrrULbiH9IibpCvUOI6SKKQgN+CseIP0
VXybeKf0OT5DXzasxbPFBikkflv8KRao9h5Vi9oIeCCJvu5dB6E46ZBkIspyDSYwQRBM38ojEUsD
kChH7Mje4JDJMew8BJOExUr3PzQiodL+sAMjR9hxnWOX47TD4sgi+UaM9yLchVJomj5Kc6rZWdRE
Zx680uT0FFvdMl9e/Aii04/YwqgZAaiOFxuMffIjfcjcKn94Nq4VaT5jsEWkTIKrF45S9lAeGa+W
jPTiPiZTEezUSakzTx8fLQlJoq/kYjrdH/DTov8Iy74Q8cKn2DdjwfMXYGsV3bmGhYXzZxXVkz2Z
q6e6uP7J76cmtuHf3MeJ1vvGJ6+5QfprSH26uf9LNlneRDaI6H8W3vIQpGfkd8LvPOR94X0PeUN4
w0OeF573kL3CXg95SHjIQ+4R7vGQG4UbPeSseNZL4mLcSzaJm7xEERUv8XpEwa84bYhzfu7gPicO
O8FKpx110jewrwg3e1LCTcI9kPFjzyJvp8OudMJUHfYXtzlGsbBI7CQYdXLcPQSTYGDkidymUvq+
LaTO9EsoGIQW0226kKkVvnprvH1LswOUHhkZwSPmP9yHi6rYi6R+q1WYVQBj7/e1OZsb29s4/Jc5
iH/xx9++vfOK2Sv8m6+agYBTK7lPyDrLjxinfh5exzh1WjztJVjEXnJSOOkhJ4QTHnJcOO4h+4R9
HvKo8KiH3Cfc5yFfFr7sIcPCsIfoou4l3WK3ySmnYuOQ9zseyhvFDixzALOw+B2BFrRgYCBBnRg7
nJ0K8KvO7r9EUeyUXfZRQrhOBCyrQ3RH1zbGLbqV0Xg7mbIKdPQU26/+qfG1LLnzuczK82mEvrVs
rMd4BeOl5fkF8FXfr2jY3LhwAfezHMD/BzDooitnr/Rd2z0DUa8Q5z7BFzNeZcO1bwofCmS/8AOB
/JuIvy4+IpKM+GWRbBB1CMFFLAIHTILLGcHYBiSjPHWMvKDyrYm8MphUTRZ+3QzKiZ3KvZCEnRca
LR3jAXQnX8X9HtnhotX8Og1EtyeR7cm3xqamjhydmhp7i/t9+q00QJgczbyZNr47fQW3jv3eMP03
Zf72MMUo40tMmCCH5RcmzKFrLMdNmC+oY0EBy7+YsBU5rOUmLKAXrY0mLKJaYacJS+gr9j0mLPMv
sJ4pbENbHU0mrKABx70mbLcesp42YQfa4viM/foh/XeTc70JQzLk/FcTJkhwLzFhDjW7W02YL6hj
QYp7tQlboX7EhAW01T1kwiLyeFQTltByX7UJyyTi/LEJ29A8X8yEFUiov2nCdm6T+xUTdqAmH/1e
H8xzMDbFd5bBFoBVv43BVlruL2GwwMrrGCwyuJ3BkikjAzZkZMCGjAzYkJEB8wV1DBkZsCEjAzZk
ZMCGjAzYkJEBGzIyYENGBmzIyIANGRmwISMKywX02hgtKxmsFJQ7GO1XMViltPgHGewB2O0fZbC3
oH4RxWPCvoLyIGu7m8ElrC8DZ1lBnYoCuJrV/waD5zD4MQbPZfB+CosF4xcL+lIKypUcLT1oAg0j
HQ2gCIrCWUNPwacHDTF4LUzCSfhkzVoaWgpXaYDpMQLlMVZDg5I4tG8CaBkrj/wPMTXnR6ahbrgT
Z7/jbdTJQNlqOBv9zUMh+GtBc02olZUugRZxOK+HNoMwhixrtR7wZeCTRmNw7GdjSMI9HSXyI0lD
vxrUipg9GfVjwCENWtD2FGMSNbJe6J0I6ylq4opAidEywTBSCoZg9AmGMQZ3sqz2EOuLcj1r9pBh
FEZZ2yy7n2RY6JmOKcXGEDNpGWa46YiibFQZ1hu9Q+v3s7Mx/lHWm8Z6KBxVjOHPwv0kux5nuIfM
3nWzborhMvrOlccZ7qzJkShcGZz5Yr0s4NQZV2JwNnBHzZJRxmkqqxktSTG5pBlH46w9HSnVjoTZ
KtdDlLUfM3uNmZTSewY3Z7gwADUpNqN0hq8xk7spk5IYqz/KrmakmmEaG2eju7BO5Cwnk6eF3ksw
fDM40tDPdnO0EZP/UabTmqn3OZ71s74HWanRfhzuxEwZ0jpxkL2hIyk4DsK9MZPbBoYZW44wWRna
oTEeRk36Y0xqcVZnmNmZoY1J1tKgpFC7Y3nN0uD+DlMyCTYaqpuG3DKmJcfz40iwqxntzX7B32S+
QF/U7GMrwzDKON1/jm7qaATKc5wdZb9claNwgOm2xnRgB+NthuldlkljMC91OnbD3qktNeatKWNq
2Yw/Mu4mmEQi6HrW3hg1xRtld2c0zei9n3FrmFnJRJ6KXN+0/Ti7H2GcSJt9UBsyuJhl7XMjzmEf
ZjqUYD40N7am8/xqxzlSo/5ukOk/lW4H2mj2l/O11FcugqMGeeRaJoM0swfDjmYX4FoLej1z9fdM
z9Om3ScY9u15Gf93fb4hl0HTE+qmf5vxUwbWDTAfaOgK1l5Dtay/tXDsgr4HmObmOEZ1M8O4PWRi
a0LroF4PzB4r4LMUKKJwF5TS9ivgeDkrXw4l3XCkNrASuLgc/tay0h6IV2X26WFam7mATmv5cmPE
huSGTdnO2ML5/DHmvBTwIM20Y4jVztGT8/w5fdrK7k5A/dF8n9G8DzV4N8razvg+3bQO6qFm/LXh
J2Kmb86YvmOQYdHzvpfyttfsjXqRMdNnb83Pekaf2T/CmZxujee9oG5atp63nTTzU1nTbwyYen8h
fuWsnXJML8Ay4y3O76/f1C+qy1uZBzZGvdWUTNLEfCEJ1TGqzuWU4fnP14rze875UOotIyyiiUCv
cZPbGdNX/aG+m5juJwv8+cR5stDNaKbQcoxZIsJGNMw4S+etGLO3Py1zzdTFZIEPzfVLrb+fcTpW
MFulCyKuxnztdIHezsQIf5xTdHQJhj+nV6lz8I0z+W9n0iz0Jjk/PFMzBXUNPzPKOE7xD+XpMcZV
qN0J03Mb/DesatjUjxkPf64O/TGKZvRjNaP9fMnlYjw6t+lmJGhQY8SVUSbV5BdkkP4Cv2cwU/pS
zPP3m351jMVg46gwivvT0s/hM2xSN2ONc2fkHL7z5WhwayYyjjKc59txTmKRL/B64L802hkun9/D
uXHFuSPSzWg5CzNkDgOdZZZA6VxE58ZFqA21w3yowXEeXM2FfKMNPi2I5pwb0BqzZgv7Fck2+DPg
djQfPrTVQrQAchP6odiHWEwyDP01w984+2tic/u5Fh9lnu8PzRMUWsasczyvF8YsGDO9LR3Teuah
jTl0nRlnpcwIntqnMZOm2Z0Yk0A3HGfmDapVNLOiccJ/bdzNrH4C+mqGY5Z5CCqrZjb3XMu0xIgn
mvI1/3d7GGcxgFFX/1/pJXev+Qv6mMfdMzGsD0SiuvaU1jOka2tTyVQWirSlqfRwKh3JxlJJbTge
bdKWRbKRP1GpmSLTulPxUVqS0VYnod28UKhlLhxam7Ql8bi2PjY4lM1o6/WMnh7T+5emklk9QZGk
J7RMBBpBeWxA69czscFko7YkHYvEtSjUisTgZiKV1rWh0UQkGctktehQJB2JZqFBJhuLZrTsUCSp
wb0JLTWgxaCX4bTer0f1TCaVzmiRZL8WAfyj0SEtZqKKJbXsaFLXxmPZIWiuQ2mqn7amcDwCfUD7
CAwmV5Yd15PZmA61owCMpieaNMaS1JiejgB52bQeySbgFm0QHQUSM7SzTGoAhsmGMDAajwPIxgrd
J1LQSSzZP5rJMlIz2Ym4XsgJKpwM7UVPJ2JJViOd2g5oIzD+6Ch0lGQj649FBlP0/vhQDCgc0uPD
wJGUNhgb01kFJuWIFgd2aAkdeJeMRaF6ZHhYBzYmozp0YrA7Rpml6TuAmIQen9CAtgwIOU5xJGJx
xt6sqTcZs78otNiqa6MZvd/gpj4ySgc7GqX81wZSQDJgBKKy2VhykJKe1kHu2UwjFVMGWMb0CC4T
kcHI9bEkoNaz0UaDadC8P5YZjkcmaBe0dVIfzwxHhmFoUKUfhpiNZShiWn04nUqkGLamnK52GKSt
1wdH45F0x0ZoR7W2tWlRq1a/NhZNp6iMZrNaa3vY6UmtJw2yT0TS2ynFf0zzgZZBUEId9I3pFFTd
0K1dEclqtVrPWq1rYKCJDUyPZ/TxIajWtK6rZ/WK1UuX9KzuWqd1rdAuX710+bru5dqSleuXL1+7
fF2PXbbLPUMgihynqVgoYiAOqM4yKeTHA5aXGkxHhocmWD9U+Smftk5oE6lR2jJKNRRGN5rsZ9oH
OgEKxfQadCIG2gzVI4NpXafa26T1QrOhCKhOais1PWiZPWcwlFvjVAV1ELZOpZPWo1nQjQHg/cy4
qNhTgzqrwtQi3w7ECRq/dTQLqGGYKbDCAoLqMrlBgfLnWZFvTDVUG4vERyNbQSsjGdCqwtZN2oYk
0/OJHBVAkykcMImIlhnWo7GBWPR8yjXgYpJpKG0b6e+PURmD5qSZ42qkxWnGW+YRvjCoeCwRowRB
J6zeeCq9PWMoNtNhVpgaB50Z3RqPZYZoP4DLYHcClBvGD6IantAMhTc5dG5HjB+rB2aIox5vZFTP
sG7AV0b1dNKkIG2Om1XODKVG4/2gq2MxfdxwceeRT+uBJHXwGv0zbjFPIwyLOeNodkbGlLCIOeqB
C6NlQ843MH2FiQj6iWQ7aIUN3Uu0uVr9orb22Vr7vEVzW9paWiRpwxoobJk3r60Nju3z27X2hQtC
C0J2eSibHe5obh4fH29K5AQfTSUKbULXlqUj45QXYIIwKMC0PrUVLHQd+KwUOPhGaqTpWDQW0boj
zDYyMGMtav0DuJuHsol4cyKbjCT05kTm2gj1E0208M9sMK7HoVT/003oVbPJR1YbgqEUS4NpAJJk
gS6kgNgOk/k2uP6EhQK5+90sWKQhEQ1a+rlvcvu557jn4fM09wz33QJcERYY5K4/YLj1c/rSz8HG
8PHl/Dx+Db+SvxiOIagdYSlivxmODOF9+BEOsRCPPoRJs/CM4kDo/wPM8zcQZW5kc3RyZWFtCmVu
ZG9iago1NSAwIG9iago8PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDM1MCA+PgpzdHJl
YW0KeJxdkstugzAQRfd8hZfpIsI2kIeEkIAkEos+VNoPIPaQIhVjGbLg74tn8pC6AHRm5o7nMg7L
6lCZbmLhhxtUDRNrO6MdjMPVKWBnuHQmEJLpTk03wrfqGxuEi7iexwn6yrRDkKaMhZ9LdpzczFa5
Hs7wEoTvToPrzIWtvst64fpq7S/0YCbGgyxjGtql02tj35oeWIiydaWXfDfN60XzrPiaLTCJLGga
NWgYbaPANeYCQco5FxlLeSK3WQBG/8vvSHVu1U/jsDry1TznGdIJSZZIglPuQHRAinKio6doe0SK
JeaSE1KxWUhysfck9rGnpDzhPLeT9/c5nmMX2IKXNMGOTkEvXFB7SYeJhII5zSMxKKlSUmVElTK+
2/GfWFDwSCVkPC4wGCV3c+iDesYkT8j4huQF6YqYPJY3V+TD/3B/MR7bVFfnlkXi7cEN+t11Bh4X
zA7Wq/zzB9wEsPtlbmRzdHJlYW0KZW5kb2JqCjU2IDAgb2JqCjw8IC9GaWx0ZXIgL0ZsYXRlRGVj
b2RlIC9MZW5ndGgxIDM0Mjk2IC9MZW5ndGggMTgwMzMgPj4Kc3RyZWFtCnic7b13YFTV9ii89tln
eqYlk8ykzplMEkIqkEAIRjJAEkrozQSMZEgmyUAaKUBAig0woKKoYAUVEdELoRqwgF4VG7arXu8F
Ea+oWBCuIhZI5q29z0kBvOX33vu+P77PjOvsdXbfq689IQIBAAMsBwr9ymq89Z87Zj0AYElE+EfZ
/Cbpqh9cbwKkvAagGl9RX1kT2T6yDsAVhO9DK6tbKt6o+XQjwDB879NQ5fOWv1x+l4QzPocwqAor
gszaQYifQ4irqmlaGJSrHgxAEExnq+vKvLDqsaUAAxz4fq7Gu7BevVSrxXZ8B6nWW+N7cnifBICq
5QDRzfUNvvoH7/NtAEgYC6BeDGzvwnvf/eORjftmmXN+0objUPx5rOGlg6zce/WuYxc+6ajUPqHN
AAF02J/wDvjUDO0cDyO0h7C9UPsEuEADvX7oc6wPfQ4fuTADVDjaAukwDJfri+tSENTKVEJ2NzQK
fyUGsRFmIfg10XBYNR0eISuJKGyDPwnbAutoNHwnPg3t2Lc/1s3Ccr6QHdiA/e8UG0k6lgsR6hFK
EG5HeArhF4T7EFqxfzMby+bohkYiap1Qp5oe+CuuV6w6DAcQZiJ+rfg5lKizcR+HYTobKwLkYf1M
nGuyehvMwPpybH8W64qwfB7fSxFfi+MCiL+KeKfmNgI490HEz2D9AJzHiLAd972Kvoh9GwNLhW0k
CeecgZCHazRiWY0wB/uxcwxk9eQwXE0OB7TYXoD4IFx/BO/fCOU4x7eMZkgTNn48oyW+L0f8UdzH
RhECHYgDQqLwNMwVbPCc8HRgKp5/s3xuhMPwHDtz95lw/8qergR5j3N6A665pDf07O0KWH4ZHKAZ
xIrl/QgehKHCEagRxyL/Pocxqi9gCgMtyjTSaQae8bRYDtdrIfAn3Od21R4ch+/d0AiF4oMQRM/B
YGxbpL4X/on1IPRHOA9PCN/BHep4eBbl6xqc/z6Ep3HO+VwWymEqjk/j83wBEYg/gsDWTuiiE6MN
aslmzW1wA9L9ItMYHP8xwkfkMNEiAI5fjusvZDRnfCfTO07hPJOwjxfBhfV1HBrBgLTaj3z9J8r3
xzjXKkUOr+0p4VpFbruB7aELuJwpwGm/DY4gHEJ4HeEo0ux2hFGIj0NoQ8A+RItrO1COEri8oswg
HRK4fKBsMPlnvOIyK5+hiMsY1xmiwvF2nGcDwpPqp2ExwlMIT2KfU0xfmMyyfXbNzXSKyUxXyeV7
LuwVtgkh7JxMprpLpnsA9d06iLLVVTK9Y7LPSsEDg7GcTjMgm8ksk7euktGF7x/1kelEd9lz1gDu
z8vLD6FGkfXlXSXTU0aL7nItXMPpvQv2IF4hNsBsejPki3+BcqET2lSDkZdzA0vZ2YRvYYH2EDBL
OgHf77us3MBA8yGZozoE33N6fggPYTlP/FCIFT8kKtVTga9VQF5XPSUs5fgV5eVADsltrGTQu+1/
Wv+/A8JHqqegAvFvVB8GAnieu5hOaL4l/RCkrhLrdyEsR0jSJpMN2rmkXTMNLGr0bWqmCx4YovJA
lngIcsVQtAMA8Vg/TXUcmultcJX4LfjIcvQFHxKDJhR9wL0QztYSPoKbGLD5sazvJUeXyNzlstRV
dsnr5SWz+YpM8VLRvSW/U2ajTBLmG5h95v4BbTQHLq+B2m75fB1mYzm6Sz4vldPA4V7y+R3O67hc
Li8vuW9B+96lp0w3us7P7COzccxGMjsnZJPErv6Xlz3jSQbqyX3cDh+BGYpu342wDqEM2xJwnydQ
/xczW4ZrfaCeAGXqV6CKRsFs9Qxc7zsoVWdAJJ77+26fel3gO8WfDujypYxO2P5dlx9V9QMtt2dv
wTXc3rwFqdyP4t6Y/1Q/Dh3qMNAoY88wPeQ6OA/ymW8UK+Be8a7A13iOh+lepDfWi9fAjbwNIIee
DRwRZwdOMZ9I13EbVC7eEzhJT6LssbHXBWpU78OD6qugvHs+1gdLVsf2r34BvhLxjKonuc9f22WP
Ge+1KwPfaI7h+V+EL8RnsE80fKV6g50FaTCQn6mYj300sIzNpZkeeEb8GspU+7EOgY+5PvCtQo/p
vWnBZZjRAudUX8t99kHVe9hWBkc1JXCNZjauOw++0tixjq11G/I/DcumwBvcXy9H/5YK5fQHlK1q
LotzVDcEXqHt4Ozyw/Qw6t1NgY9V12NZicDOzku0+6g/PN5AGVHvwPiMxRPr0MfHwXr1ZmhRvwMt
4i/Qovoc+w+EXHoG9UhEvCBwSrHb+VSN9T+jzUX5lmMZOZ7RjAp8rN7I18vne2BxSiMsoWfhGuEZ
yEVbMkm7DWXlWu6nV6P8fYrwvQzwEkKuAqNlEIKw7T2U0UX4vpFayNWI3ytkwNvCNjEM68zM54o3
gF+cDgNof7QjVowp3oNHya/wADVDQHwDHhDb4a/kV/STIfATbYMpdA9c5PXvQB32yxPehxxxA9rv
HKThKjglzoJldCdcoB/gGSrQ1uM41e3wvSoOUpHuD9AfiJYB+Ry+odPhG/UKeICtx/ohPIfzz2Yg
joJUPq4X8L12wWV7FgphIR0Dt+B+v0T8vkv2i3vt3ucq+JLv8Xf2x/fB5sVxrI/4ANwEEDiGEC+X
nZN6lWH/BRzrVUqsRJ5uZn5BvRRt3kdo+4oxZgnGvAk6MbfpwMyg4xnsV4Tld1h3FeJpCJjndOqw
bj6Wu7E0IVRgPfYJvIx1eWIk6opspxZj3Rxsb8f6N7DEnCuQiuVhgIunEUwydNiwvBPheoS7EAoQ
QC4vfCLvJzARS8yrLuJ8F+/BMT/jewbi9yH8inAGAfO2i6txzHFsT0EoxPeFCFVMtq+Ia/6vl7/v
z/7bktkttk8sB6MenrrcJ/3XZRc//0N5ue/q4v9/KnvFoJeVMh26ztHLl/5bn9lV4hT9egPa5qFo
o3KYXWa2kdljbo+UkscBsl38hvkQLFeiHTzHbDGzh2iLX0V7eAOWzViyGPRF7DO/a18sKVYgSk59
NRfxDTGdAKLmBMjJNcuil5Jl5A5yF3mEtJFjJCAUC4eF14VPKKGU6qibLqWtdA19hL4tBokTxGvF
WeI6cb34kPiYuFt8Vvyb+LVqv+rPqm9U52JuiflVMkuhUowUKyVIaVI/KUMaIuVIQ6U8qU5aJm2W
npCedqlcIa4wV6wrwZXmmuq6znWPa2usEKuONccGx4bGRsQ6Y/vGJseOivXG+tyC2+J2xUO8EB8U
b4m3xTvio+Lj4lPiM+Nz4qvjl8ffHL8qfk38uvhH4p+O3xV/IP65+Jfj34x/J/5v8V8m5CR4EoYn
lCaUJVQkzD2lOiuc7X9BuCBdGHQh58LQC8Mu5F2YELgYCLCbC9jEKbCJ7CBHyG9IgVeRAh9T6KbA
zUiB2+ljIhFN4iTxOnGteK94v/iouF1sFz8WT6naVM+q3lWdjVkes0kKkkIkuyQhBZKQAgOkbIUC
c5ACjyEFtl1CgSmuma613RSwIgXCY2MUCpTGlnMKSP+CAhO7KbA2flP8tm4KvIEU+BgpMKSbAr6E
OafIWXJWvECQAkkXBiMFPBdGXChgFAh8zu5JAjZyHZlE/hw4RkrR+piRLglgQPqoL27Cdz+Toc7k
zqTOvp2JaLEsAVNAH4DOi50nOt+/+MnFYxffvfjm5yUA/zgm38mcuAXhns9mnrj5xK+fbT2xAN/Q
4p5Yi9B6YslnzZ/O+bTlxIHPDp24/dOtn957/N7jjx5H63Z8Cxv7qf34vOOz8K3fcc/xjONxxwqO
5R/LOZZ9bNCxjGP9jvU9Fnss8pjtGDn6/dFvj546+sXRf7BRR189evDoC0dxlaOvHH386I6j+UeH
Hx12NO5o7FHX0ZiIQ5YXUI9f0GzRPKR5UPOA5n7NfZoNVL5j6oRLfoTtMlzy3i4c775vSoF/8UMj
EN6gb1OkAj1+ScvfEf4hw78c/RYD+rby9sa/7nnFyEfp5m5807/s1fr71fAY3Ay3CBfhXvgSVsDt
sBoegidhM1igFclzE6yDs/BPuA3Wwyp4CY7BGXgYtsGP8AOcg0fhaXgNXoU/wWwog7Voe94AHxyG
1+FteBPegiPwFVTAe/AOvAvboRK+hzvhA3gf/gJV8DV8C7fCHPDDXKiBaqiFTVAH86AeGqARmqEJ
5sMCOAULYRG0oMddAtfDM/AILIOlaFNvgG/gO9hP7iXriUAoEYkKLsBFsoHcR+4nD0AHdBI10RBM
TsiD5CHyMNmIOv4I0RE9MZAg8ih5DM7Dz2QzeZxsIU+QreRJso08RZ4mfyLb0Ra0kZ1kF9kNv8CH
pJWsJnvIXrKPPEPaiZGYyH5ygJiJhVhJMJyAz0gIsZFnyXMklISRNeR58gI5SA6RF8lLxE4csAPa
SDiJIH8mL5NIEkWiSQx5hbwKv8Jv8A/4nDiJRFwkFnOi18jr5A3yJnkLbdHbxE3iSDxJIO+Qd8l7
5H3yF/IBHCB9SCLpS5LgJHxBPoSP4FP4G/wdjsJx+Ct8Qs6gqv8TbfkP5EdyjpwnP5NfMLb8jSST
C+Qi6SCdJAXtPAhEEAQqiIJKUAsaQSvoBD1JFQwY0RoFk2AWLIJVCBZCBBtJE0KFMJJO+gl2wSGE
CxFCpBAlRAsxglOQhDWCS4gl/ckAwY0ZXZwQLyQIfYREoa+QJCQLq4Rb6Wb6OB1Ms+kQehXNoVfT
oTSXeugwOpyOoHk0nxbQkXQUHU3H0EI6lo6j4+kEOpFOopPpFDqVTqPT6TW0iBbTGXQmvZaW0Ovo
LFpKvXQ2LaPl1EcraCWton46h86l1bSG1tI6Wk/n0QbaSJtoM51PF9CFtIUuoovp9XQJWvRldDm9
gd5Ib0LbfgtdQVfSVfRW8jk5id5uNVr729De3wE7MctvJZmwF/bBn8kXsBv2wMtwI7wIK4XvhNPC
WeF74Yzwo3BO+Ek4L/xT+AF+Il8Jh2gwPAf3wWnUlcfhLpILd5BhZD65E33MOrIA2sn15DT5nqqo
moZSjfCz8Ivwq/CbcIE60N8YaDjV0whqpJE0ikbTGOqkEg2iidRFY9EbxdF4mkTTaDrtR/vTATSZ
ptBUaqUZNJMOpINoFvp2NSj33VgK+BAu03h2Wy6q1BqtTm8IMprMFmtwiC00zO4Ij4iMio5xSq5Y
d1x8Qp/EvknJKalp6f36D8jIHDgoa3D2kKtyrh6a6xk2fERefsHIUaPHFI4dN37CxEmTp0ydNv2a
ouIZM68tuW5WqRdml5X7Kiqr/HPmVtfU1tXPa2hsap6/YGHLosXXL1m6bPkNN9508y0rVq66tXX1
mttuv2PtnXetu/uee9dvuO/+Bx586OGNmx559LHNj295YuuT256iT/9p+462nbt279m775n2/Qee
fe75Fw4eevGlP7/8yquHX3v9jTffOvL2O+/Ce+//5YMPP/rrx3/7+9Fjnxz/9I8o548o548o548o
p6f6jyjnjyjnjyjn/ztRjsfjyR16dc5VQ7IHZw3MzBjQv196WmpKclLfxD4J8XHuWJfkjImOiowI
d9jDQm0hwVaL2WQMMuh1Wo1aJVKBQEq+u6BUaksobRMT3KNGpbJ3txcrvL0qStskrCq4tE+bVMq7
SZf29GDPist6euSenu6exCLlQE5qipTvltqO5LmldjJjUhHit+W5i6W20xwfx3Exgb8Y8cXlwhFS
vqMqT2ojpVJ+W8H8qtb80jycb6dBP8I9wqdPTYGdegOiBsTa7O76ncQ+lHBEsOcP2SmA1oi7aotw
5+W3hbvz2BbaaHy+t7xt4qSi/LxIl6s4NaWNjChzz24D9/A2czLvAiP4Mm3qEW0avozkZ8eB1dLO
lEOta9otMLs0OajcXe69tqiNeovZGtZkXDevzb7opKPnFScPHlG0sndrJG3Nd/gl9traulJq2zSp
qHeriz2Li3EOHCvEF5S2FuDSaxgVHem4EbZ9dhT5UD53PqspnSO16dzD3VWtc0qRIRGtbTC5xbUr
IsKzP3ACIvKl1qlFbldbbqS72JsXtdMGrZNbdod7pPBLW1JTdlqsMjV3mswKEmTsjfi62zjGuzOs
cHI3OQnbkXs0ikGbVCbhTorceJDB7OEbDK1lg7Eb/hQTHNVWjmzwt+lGlLZahrB6Nr5NFY/BUetP
aFpL3ae/u7TGq9So4y0/AUOZcHQLGLZ34W3JyW1JSUwuNCOQkbjHofx9YGrK/HZhkLveImGB5IOJ
RTiseEg60tzlYlxd3e6B2fjStnxSkfwuwezIXeBJTy5uE0pZy6GultBprGV5V0v38FI3iu8eHoWE
tmkTuv8zW8JC8quGtJGwf9Psk9sLp7gLJ80okvJbSxXaFk695E1uH9zdpmBtISOKaKSgYEIk5a0o
idd2d2YvRUFtYjz+p+aSXN6u0aIo8hoiFbRZSkfJz2K9y/VfDmoPnGWjeNEzTNlm25DkS9+vuuT9
ku0FtVLcsJggFE6d0dqqv6StAO1Oa2uBWypoLW31tgeWz3ZLFnfrfuFx4fHW+vzSLo62Bw6sjmwr
WFOMh6giQ1IBhgXDMmEL7EA4iHAGQYR++JyAMAuBgkfYsuuODE87FrN4sXv8pAHLWTl23AD+7hkl
l3qjXOqGyGW/DNZv8+78hex98+4BQ+T3pP7ye1z8gGXDLMJm5PkZ/jTjMx0hF2EZgoiLb94dGi0P
09nYsMd2R0QOMB8UHsMej+G4x/gWH/PosTl4gnqCRjgzLIt8i7Nt5M9l/DmLP3P5M50/zUrrN2x1
/jzInzv4M50/c/lzAn/W8Sfvjy7tNPkOP9/i5xvyjScYUgg4iQXNupN4UojHiTGTjhh2ZTrvbCcG
T1amM00a4RyAkCGNdKZg6URYnDTKmYrgSspzZmF4TkCHmboW7HbUgWCr1tNOnn6mc6WxY6URdO0k
d1fSWOcwHRkCB0S23CCE+xHEXUkNzhdwtMRfMcsTntrlvJDaTqbvcv7mbNeSXc5fne0C8YQ4f3Ge
dP7sfNb5k3OM8/Wkp5z7sdf9u5ztznYRe21Kahee8pidq52TcXMnnQud1c5aiTdVu7DwGJxlOGhG
0gxnEZoKXGW8xFcZ6cRp9jnzsTEvqZ2QfU6P81ZnRiofOoAN3efs72xwpjn5cinycn3lvSWyYp+z
Dy4Wy1fJd04z6oy6rLXHNGu3atZu0axdqlk7TLP2Ks3aQZq1AzVr+2nWpmvWJmvWxmvWRmts2mCt
RWvSBmn1Wq1WrRW1gha0tvbACU8yy/5tagsr1CJ7ihy3COzJbkSQXALRCjAG2kJooVA4ZTgpbDtU
BoWzpbbzU9ztRI96qHIPJ23BhVA4dbijbXByYbsmMLktK7mwTTNxZtFOQm4vxto2YVU7galF7SSc
Vd0SyfzcfuRq+C23RbIycMttxcUQNj/XkRs81JpdkPc7j1Llmdzz40i+5KdwYst+5HLRbo3zag2+
TsHXtex1LXt1RLfdWzilqG1bdHHbAIYEoosL29ZNka4t2o+R/tP5efsx5MeiuGg/TSHb8yezepqS
V1xciKzh/VDst7N+21mB/bQfQS7rB7naj3g/kcj93Lwfip3cL0wCN+/nDpMu6RdD/sT6JbEC+9lP
QAzvF2M/0avfzgPu/LydbnfXXAd4nwPyXG05vIvTiV1cTt4FVcXJuziJwLsU9HRJVbqkdXdJ4ytR
0tPHKfcxSl19jGyl5P/qxzc8OTnfz2RlYtFOLQwvRi/AyzBL/VDOd2P40McjD8D79FswoCPUYyRl
cA+H3FxHsiWHpKuD2tRYpUFgva9yOZZGHhCBbOW9g7DaqDSlDksdxppQelmTiYVkSpNj6VWuyANk
q9JkwWorrtFrn01NzfgDjnx/Xvd/jcpPs1I2QWFb0pTCtlx0QDs1mnyMUvKKsa5fV53BkN8eOCRX
pmFlDquktLtjd51Op3REauybkEImOEkWbqE4uRG3ggv1pmBTI6gOQDiHLRAhJoADIPAVwilWdvoD
37O2zrrAPwR2j7BXAfnnOTgIazBH2YKfnWAhIubiLZjLr8Z85RtoxUz9TrIH8+pFmNk/Cs+S54V6
mIF5tB3z7T9DP0ID72Iuv4QYQQ3BmL8fgelwZ+AOEgIGCIcRmJPvp6/Rvwa+JwWkFu1EJOTBZNhH
v4ePiShcrXKoGgOpoAIdvApHhLG4byuEQhaMhvFwLe7pCdzrK3CUJKpGBD4FF3hgCq7cArfDY/AG
uUPwCc3CZvqaalrg/gCugjNpIQEKwI+9GmEB3I/nOIO5ewhm1V9Qh/hg5w+dvwbYvUcfyIRhkA/N
eJqX4U3Mhr+AX8g0UoH551RaL6rEykBYYA/uORoGoFUbA+NgGpTC9bAMKfYQ7BQeo2s6X+78GS0f
xU8q7joLhuD5ZyCtjsDfMcsPxzy8DxlFphA/2UQuYMacLdwgbBZ+xjwuET+D6GN0L/2Efkr/KY4S
F4pfqg2BxEBhoCqwMLAxcDDwGdLUCYkwFue8Fq4DL55qAdwAN8Eq5NaD+HkINmK+uA/aATUc/oJZ
/WfwA/xMTGQAuYrkkApSTRaiAdpLniHvkPeFEsErPCocwZxwBq69GbUhT5woNorvd0Ln4M41nTs7
3w6YArsChwPfBTqQmk6keTxSNBWKwIcr3wJ3Ypb6ODzFbifwcwCOwjH4Gimnw4+F2IidxJG+JBUz
/0FkIplEZpBK0kRayI3kdrKW3EceJG1kN+7mBfIK+TthV4w/IGWQzIJBMAtOIVZIEVKFNGG8UCms
FNYKTwt7hefw867wgfCxcFT4AnPmXzF3teEnlibQUXQM5vd1PFdfSp9Cer5JT4gi8s8sJoop4s3i
4+IO8R3xW/FXlUF1u2qdaoPqC9UXalBb1FerJ6qr1Peo29V/01DNJE2FZqlmmeZGzT50e27t07AL
tWMnnrTXj3AtPAJ/IS/AcbKF2oSnyEThCXIvMVEHzKUPkPdUhXCrkCO0kXFCGP0RM/j5EEqfJOfg
HOwTROFjkiw+QTbBc6hJa4S5wkLRTK4RnxQ7SJP4PqbRJ2GL8D1bR20Tn8DV5qNjrSFDEauEGnhY
sMGbGM7dAvPgJXhYrRPWIt/vgARhFAwkoxlvhDPwLWqHleTCHNSTDvKYqkl4hCyip4QgmE46hE/J
VaomqEBXfgPZLYynb5KTqHnPobwUkiohm8yGDviSPEq+FKbBOOEmeEysVH1APiHJZLyqCuUPxBN0
NK0QQoRnr7gV3AF7UBOOwFj6GlxL7kLtPyIkw2ihDh6iz5OvYQ+5XqykVbjLhYJIbkJdeBp201Gi
AYbDHroHXiBb6UckGXaIC0ktWRfI7yiBn9RbxO10p2qQGBV4o/MYeZy8Gzgg/BOyAm/QaZ2V5EEx
HPXyetTeBqSQAZ7C8Q+ixdgCWsTiUR9vR3kNRdumQy0vQMs1Fq4jP6DG3IRUGkQSYbwQC3OFYRpJ
bQPQ9Ok+TdP/IbQp8Bvy8ARy8GEAuu1SEA8BqKbKoL75P4Pm7zJoP/5/H/Q56B23AgTdDmDEs5je
BjAfA7DejTH2RQBbkQyhaF3DXgBwtAKEvwYQgWOiMFiMngMQcz8G1cEIPwDEFsjgfgkgPgwB50j4
7g/4fxr6NPwBf8Af8Af8AX/AH/AH/AF/wB/w/3MQ2PeFKvxgBq+BMTsF8ixJAzVohKxdoBLbSdoe
CnoNQ/YSCNeqVaxdAEpG7NbNfMGRbDmf05Ez3nIuZ1xHDuQibrmIj/79XFaXNR4fBES4KNFDFz3s
V24klvqyr5PahT8JNbim5LGQxSDsoPeryA4IF+cPdyTjbONOWs6fhPTT/fuFZLk0sxKExHjSvncv
jg1sCJyio1V/YXdv+wR2CacXhhnIECDketzVEOzyI4ikluQBbq7j9LnTuKtc3JCGZJAqanvo4ncO
1be/heIZ7gx8Ja5QHQIrxEG9J/Qa2wLNCg3VWInDYbRmhrOHuz1wajeWEpaedERutdzsEhIMLZYm
F811ZLh8Nn94pVsVI6lVYZLZGJwL4fGRubqIhJZp7CDnx51mp8E9nM7Fw5CSkhJ2ewvzSkIyg4cK
GQPCQm0aQaN2xwpZNntYxoCsQcEDMxPcsWoNfu6sW3XXbdO3fjb+2s1LH3n88x2pVy/0T79+SUvZ
qCXZk3IyyGcHyPIvb7z6t+9+/L7zy9vmEvr6yrH+WSsE1eaH14yZsawD03dC0pG1H+EpDbDKE1Mo
LCFCMSHZ+lFktH6qUKRX6Q2GA0Bs2BWZfMFjovpEncqQCEF6vc5gaCfg0YOOEN1E9l1Pu1C816gj
FrAfIGNIErAvV3JI8iLLP4kjvQTRdAVnKOQm53BIP71SlZa8xPIyowCe3RWiVmUNissalJVByOlT
93aejV1JNMMT4/ydR8Qp80duHrR9WGL2bx5ccSGAuAx374JNz4w3j4/yR1BTe+AtzziTNTNIwkcf
c1xEfFQ2HWTODvZED48pFmoMVSEVEaWRpVFl0bNjFguLaavQStdFPq5up3anBNGRVouKqqMi1KLo
NEo2leTEU+5zQZB03m05gKe0ksMeA4TH6nMdEe5bt/di5LnTli+5lOeettqz7dnEGpzNDoUsLckY
KuCJ8KMwsM+gQchfxmC1Sq3WuDQLo8o2f3N7ZmGs/Y6qyvtdOyMuPLvkzYoqT+drK25yCWvdN+3c
+Oy8QeMLM3J8t93xcMSfP6t6rvyulVN/nrMqZwv7/eOnUF5XIy2iIQnu8YQOiRoTJTgkM4oqe/RJ
kuX0hEcKsmZaohZbW9wLklYmqVzagdEFUAktllvtt7o19jBoD5z1xBusmRAfA4kSPW8fE/ZehBSi
ckl6o/2h+Fz1Q2ERKTG5xvDkdmHFzmmyRp5mRDjXcZKLcse586f54ZMtr3Ox5lJdQviR2YlRoAdm
ZnEJt2sSGD3U1IbyPUihDnlw7PoxT/z90TWv7ftxfM7Ow0vufcG41TR33KTN86fd783bMGdd1cK3
6eTc3JMv/rrrPmL4+ZPv9n5b++x2y4I5S3/u+Pr6Jyvfr1rxCPsK+heUkD+rtoARrvGkNRluNgiR
YrGqWlVhWKq6XaXW6sxqDZhmqojKbNSp1JJWI0KQMdeJQ58jH4GJDCMDmKk4V4JayljLz1WCkG3N
yOjfr6TEhTyFLBcaIjUVKOnrGF9C0vZ3xLvp1tjvd70z9u53L5Azu7Zsea9zX+dNnRuQU63IKT9y
KgbS4FGPaaC6QC2sSCUOLQosbQ98tBv5JWDp0SGSKCHjXOytAJHm8KaIlrj5qa1xqkhNijVbO0pb
pV1B1AS0wcgybYJTGysZzpMx8F5UEvJMlKKM5CFnrvkhCE9PyA2L6Neynytmj8wqPLP8LtOSS6Ak
JCuMm54sNfKtTwIyDtkY3GWZEkK6GYecMwmt26xzRlcV3zR05m1jVsxZ8+jqN/adnTjr0Zsf3/Di
F+t8hXfPKWgZmtNU1p9MtC6umnHzz3lDZjQf/WXnhs4fz5/5uvP7G+c8L5xt3Vzx5typa0d7rn+E
eZ5i9EFXqw5AMERBInzoGZkgWayZoeyRHesPPRx1OFoMSYyOSkwIDTGo4voaQhKjoqNjZLNlC3El
JvbpA2JklIuUJopCTLQrMRi09iRtu3Cvx2hKgrgJcaVxy+PEuLh28qEnJlrHflcgKkoXHb1YZ4Z0
9k12QV9u1gomdZm08Zaz3KYtGtdlz/g3j2jffmD1HdyxJHdATm7yOXwiWdNzLB05iqUDfEdS27M1
OTmygcggrgH2GCHUptYwo4CkxgqZqC7qGoC6wjTDVYxu6tXrc2avHHPLrQvmr/7its7tpO+Hzw7x
ruh87TQZf0taSdPwG/Z2rlEd0FunrStuae/X5yF/y/EWOmrVjUNn9L2wTmcZtzS/ci6eaSZSdRdS
1QwS3OUZY5dQfqLYA2ySrZ+tzSaaiVkSdMQQ5SSRUU4pnaRLmpEqIlksCm2dkouQREEIyba4Es2g
jUjSToq1tBONxyrTrcBVTwgSjtENiVRCUOJKZFuh0OckegALEki1UnEBaCZKSub1IoiA1lHtjucS
iB9Gkz5IiZlkADmwcerCbdPn/un5G2bf0fnXUw8tGjto5JCxM68vHXlvZ4fqgN258fu7d3Z+8smS
GPuW6GB36pjZFzbtOui0485mBE6Jg8Sh0AcGwoueSTNTSbw+3uAOik8Zgq5Lna7N1l7jqnSJmSlJ
BjE9McFIzWgP3YnJNMSoHxCRmJycojfa9HpjWJzTTuyTQ5wRmgT9ACc12IvMYSSsnfzZE5MuqRMG
maUYKLK4692COxDjsQZnQowlpi6GxjwnLIQsSMAnU8cvS5LHnS85beFK2XG+hAcFaEpLTq40pSWb
FKHJZsCUlAkP/sddZklJPFNN1MxBg7jjHJjZp8fHsF/N1FB1qM3uTghBWpqQplxjqeW67WXr9kxa
4b2aTBsTmpbb0nCn65nBP+5/pbEo/KqosGfMVydcU/HwjcP93hlbSm+eVPinlcW3TgkOMkWP6Z8b
N8BXYnl463UF9dPqO39ZOmHAdZnkS7NFZ0q+Lnvs7FnbmEfKQxqPQgkLATdc9FREMIccwx6ia0J8
c2ir9Unrfqu6rzU9Pjd+ZOj00IpQ9SIXocG20NgQ3GQwjYqjameIILgJ2FAnhUQM6OKcTrUmJBH0
DqfZoJOCc6MIRKVH5UZNiDoTpYqKaicHPUGgQ6HkahwS0k4GecJ1/YBFHDABZrHv+qfHcXWe7rtM
nRtQnz9j+qzo8iGGL5Lb5o24tmh3fRTJSi4pJpw7LH7pYAJ8uVavNL3MfhRhZrKcQRXfZ6LIqD6a
EA3nQXc0l0cG7K2ZvmbsPYcnzl9689X+TalJNeRG76yNFTfMmr05q6/qQMe5CcOOf3DbNxtnpdc1
vE72xK66/RYSsWDF3esfakZn1Yi0DkN5joQ1Hn029dsqI9erRQdz+NOYndSvtgrXRvot1+taLPdp
VWpbmK2vbgQpEoq0anOcaYqBxPWDUljL/kGzGOw0aMKdogGKJNKPCOSsKUzSJESZi8BkMQmmwujB
hdyDlCjxq+wd0YmglSs5aek4qcSyeHy7IpnBcez4sq9XBJC69uZd2PSnv7YS8vhTr+0ijdfVbJq5
sKjoEXJTyOEXT7y+nUzc8eLGIF9Da+dXN65atQIlqhpP+Tq3WU7Yuh+iAyd24+GC2SlnoVzpqNok
RodTf1C7cZ9JE2ayRffVuENHmq4xqW12kk5c+pTQ6foKvWoIGaDPCS0kw/VjQtUOsznIYLDpgiDS
qdOYTXqbUzAY3zIVBb1lMc8y15k3mUVzO4nb57JIqgQpYT+Jh56op2TcSdmFYtSXy+z8SotpCed9
CZnHuB+vUIDpYkgGcROb7E85700CtTzw5PrXN55Z+Kpv4Z7Ot5/o7JcyZ8zi8hU3lw+b6x91/65P
P3iJDNt0ULjqtwLyfN3yacu3/bb09iGrP2IaNgfpMQy5Hg6xcGg/uJAOOiSIk7nGMEaVIkYVdWLs
asfqcNERPjJC0MDe8FfCaQJNMSyIWBkhAusLkRFAg4nVHA1xFlJKBCAWMhERkUwRIyNSrGuDNwUL
wcGi5AzS2FEygtuFuzyRNkmb4I6WzB67lAlmi7ne/ClSamhcwlBZPJJl+VAiDCYcLAPsKJl3kpkw
Zr9eT2ai0jCPBRsoKyJSqltYbBqXWpYU4lLiQjqxLaHzzPPzX6l8hMA9L3xuuviDeGtZyZ7OOGEq
WTW36SDxB9/0Xc27t2wnIzd+99b4yc7wex5aRBZFBa26cxNqSQmGEyMwOwyDlzyVbg371w+GbM2n
IZ/aVA6SEDwomIpoYsRQGhwaFmZFHFRBhiBq0JmsYWFuUKHTU5kkHbEJKTQEySFSdRiaopAmG22y
CEQIbgoN1YWFFYFObMKkKF1Oimx77Lo316CpUYIDFi2c7JUJnUSlST8p50M5FvZhGQQzKl1mPzjb
8rpGZcnJ0VjkgGEeWv2MEHdWBg+iMYZmVkSToXHTkhcfjX7U6choLMu/yXXt0IFZNscb0W+8SO9f
s35e+bDohx0DyxrWXKxg0jOw8xrxZpSeWMgg0fshQdam/u1yOYDJTy6z1v1t/QXRka2bluBLWD5Q
FZ/cb6AQHxwfmgs5ThGjlRS7Xa8PTzQmOsLD3Xo7ekU7iQOw4BLtwu2eDGO606ZxJNrViU6jXu2M
NjscuvDwIh32Q2Lp7MvsxGlPty+3v2MXZ9kJoD9tF+L36NySBdrJO54oQbrDRVyvWBJy9QT0RJ+Z
aLfo7fpMfcIspKolB214suVQyTzyJfrNLywdyYt+wBiigYSj8VZM+Lu84BTHqvB0cDCR5CQ/jZLK
nawKqZ3MBHOlyfKyVjbfXIOT7XZ1mJx/Z2X10uasDGoSZJENwfy8x6KbhCHPCLHx/cdvHpWeGHzb
xkf+9tR3S96bF7flI3fDm7cs3z/zq9CYurzitpo75w6/fm5WqXXoUGvYtOyD0+84/bfdJOW+V7df
CDz5fNXwZZPDhSk1WeMmLSHqBTc9MPLON9j9SB6a6KvQCjqIzbNgpEgSNMQZ5DRiqBavHU0KtNfQ
ldq3rZpKzSLtIvSxz2qftapFg2gSbAYb2hu7QxAcDrccwumCgtxGi81otISgX2Ue1ogCrdNhfZFR
d4eFWCy6dGOucZnxHaNoMU4wzjLWGUWjsV1Y4kmNQDerczhQ3IMxzCOXO9lwHQGLEf2s0T59KP9F
Sybcvb0tCj8Lobs1odvXKi2WLoY5eq4LejQDSwfzuxqTrBT40wAl83p5Ww11hyimQ62hzMk2+7Zf
e/Nd0k17V0aPypu9y5c0C13rkdnTVjcMvrfjNuGmNXGZwyt3H+4cjMJ7NSpJHNKZgoake/RP0Ffp
V/QnKuraA4c8Y9MHZ07QLde9q6NOXbpuo26H7qAuoFODShQJRVICoYmCRuMWiY3VlDHaYqqvSRT1
SDWNplbUWTjV0IywCR044XLxXVEQPQZzptisxRBFVAinEC15XjJSAuOQvaJnXFouH6bLTcgVPUPj
+dvuwgS51jTMhbW2RHwEu+Wm6H5yGZUul3alq87Gukb34W+7wl25l/wuZvEVPFLsFHt2XdwwpdGo
elmn5HkkK0NDQjIoyU/ek9yZd3zvcfH0kSMXQsSEC39nMlyAMlyLtDWQ4P2gD5z1tBgsmZLKo5op
zhFXixvE+1UanUjM1E0f0X+h/0mv8utupuvVR6iIrNTptHq9ilLRIIhqFRW1gsGgCDQVqSBmqPQ2
lUqv0+r0WrdGbdNo1OzfJKG5NgahKjBWqES1IVGrQVlvJ+2eZL1Ylq4iqjW5XMSpUbAYihpY7tIj
0NODMGacvoZnMjyRYQnNuA7+UsJiIX75k9NNne5oMC1Zi0TCDMfRg/SEi9kaLRJOm6PNYQZnHloc
Hi9iokfcVEMLSMaeFwTLmc6rSPCrHxwbozpwsZH82tnUUSG4Xuh8iNFyEMppNJfTTs+0UhWZoFqu
eldFtcSpSldtVO1QHVQFVBqBUoVEPI5GLUcxpLS2S3mD4SC8A8JyeBdF32PAPKVKlKPkWd33eCiB
DbIAgscRnAtdAghMAPmbKSoL31DwgAkeq9rtypJLFDjoEjhgAsdrUeBAkVxWPjOMNbqDL5XCbjG8
4vaw19XhvAakGxmESt75turAbwVImREA6uXo4ZLIaM/VBVaS4tHpMzemPOs+mPKO/XX3V4L6Pvt9
7u1h22N3pDxrV+ebpmunma4JrjAtS1HrSKw21jRQm2Eq0KpT2MYnGC2ZtG+SICQlMUpiIpyNXh4J
Gh0T43ZKNolVSMTplMzBwe4Qm83GKmwkJMQW71SHO4OCuIVVJzljWAKT0k7e9xhtZl1wkc0CIZYQ
AXOVuR6jM9oSU4Suz2lxCk5W4wTBklR0iSgmI2Mki9NmCWEGQradMsiCKculjPbGXiYWHmjgT1e8
gSknSiR6OZMim5eiPfY1mRnYZAw7MjTcvNp/18j2xkcc3xvv21hSdkvopN1lt9xiv2PvXSHDcyZt
LXFX773XMixz3JNzYv1iwo550/3XlZctbeg/r2Oq8ML0+Myc2Rsf7+gQjox2Znpm73i0U694vWzk
pR3OeCbGaQZqBLcQpx0kFGinC9cEVQgt2oXWbdaD6Oze0r5uNdEwO9oGKtjtnFceS3Y955Xi8CxY
0WAhit+j7aTTYxUEok4MshuNGGMwx4WW4ZldQUUWLDzoAkmP+3tWWIIxt0AO7LIXkXZywBPSizeO
HofHrzswPcBiHhbc//EYLyc5NwfCLScd3JspFGf+TKY4Mw0siZTT+26KX0Jr9GfHN/eZe8B7w7qI
lXtvCx2dv/pvGZViwv6a8jXNVy3rWCI8Mjt94PDXfuwMRoUux0xhMlLPBBIs3A9WjO2mYGwXyS/J
daQ0tj5WUKsiQ20xtNg2I3R6zHRnXWipUz1CRZos822LIxbF7KGqKKeoweTQYJbAk5qeCQmucAk0
Fk29hmoaYxN8vbLC5O6vNZhRw3AMTxZiyZKPIfBAP4sF9+xaXImZyp9Z/9Ohb+/uPLP++jfn7l1b
N6Rhdn6o887aaWvmDSTrSNZbW8++9UznK1vnvHTnvQ+kly4eWTZz7cZJD76D5i/wbadfHIXns4IL
fvPE5juni9eZZ4TONauGhA505ovjzKNDVfFimjk5NEvMMass7JZ7koldeeGj2LGQtDhuJevhF5c6
3JEQNJiMIpWWKoda6yLBVoFG2wWrVTGfFospWo6V1HanyWBNBJNOioCIWRFCRLvg8sSx2wed1Yph
0SpuWS0sDRirg9hEZk4hVv/m0F5hK5HD0pIrQx5mcEuwPK3EPfKFgxUzzJ77BpQSFBIepWLCWYJu
o0tUBH5dS5XAtCsuDSUZTzhL1k3e8Frtps3TD/oX7rSGNxQ+eOiG0vz5vuGdftXzd3sLP3l7S+eZ
LeNf6jhIRy9IGzaRzHpm5brRd76PcuRHOs9FOqP5ge89hgNBZHH4rREromkMSxuQlCEsbbAiEhF2
FWSbJsBMmAPqWGbiUzMyWekZbY/KVMeExVxjwljUYjGCLShSMJnNbovRhq8sCTclGtUsC7ckmk0m
k85sLrLo6o2orkhMi8WSa5lgmWVBJpIyj0Vnxazc4ko0Wix2i0uP6XkC9KbveMxAWUbQTdcr/cjp
nsCyO+NiScDL8uXsPH4P3iuPD8PQnyfy3RE/+0JO+OGB2+9+64F/Lvdu7N/3wc6393ZuuNE7+Ym5
K7yzRpYMTFy49rN3XiWeTTW1f/5tBB350PpVxLLsxruHTlzfpET1dCZS1gznPIt1dIVunfZOnag2
hhm3aA+LX4u/UXWCkCgOJoOEUaSF3Eo0JrNADQLSTQnli7RqgyKYZtm9I93AY7Jk8q/oghnP+rEL
HszMSqEeHf1ZtFey5aIw3cK9/Zv7SU7PF3ecauhZR7B/aQTIQ5tLceImO/ppY5jsvFPtvNwVo/jt
YiWYT/7d+L2H0F3yi+ahy8jJuSxF47YpdfJDkwdNGJM+eNZr2TPEhL8tnt9na+wHnac7pzN6jUeL
RpFeKfDDXkOS2ZrpVL46oUwCwxG5x/ig68FYOp8uCr/XcE+QaGCqLily6mK98hC5ha52bDZsMYoF
tMWwykCTguJcse7BQaIUZKDRGANgKRJ7XNjkEIgjpG+EM0SjcvY1RLMvpy1NJIVdhehIkcSSH8LS
fY8lld0Jn9VKEG+JF+LPhjGKWeP6ZkKYJUw4EUbCXkyb/qJsLOcljztX0nGyBNGG0+go5nXfpLGL
NCv7ElG+6AU5FZW/mAnJ4pdI/KY3rg9LQAf1fJcWiirPPvxrhNg+CdP29rth+sKFcfGdnyWOyHtt
z2vviTvF5c3XVaXGLHl30HTv4ZXtN9xA5hrG1xaUDktPSloc3rdu1NI9+9cHldZPHzAgIWLQjMwp
CyZsmDlzJr9p/F64S7UVImCVJ2mMucI837zSvMF0X8gTuraoQ1GnQtBZEwrhZgg2pFiDMO6hBvNZ
K3rYXZam4AOkE0KEyN22Il1QuxC5y9hkeE6IRGGNBB0SyRCXgsJq0d2ho7p24Y7dkYN3s18iKEk+
d/Ic0oM95bu2jpxcK78WYdITr+n6ZopdiYRkUXYRIt8dkW9jhl1d7ekXccMd0XdkvTNpV8zOxfb4
pJx1d1sHJua7lwr+NUS1pHPpmo699WFSLJ5vOcrVfDEB/XunpzlcG667x7BPs0//VegXDg0mFLqb
g1Y47tHco3+KPqnW9tFnOeZr5uubgpod6hSSbsm2jraKoeEODDvCwm1hGGUsQ3aHhbOwQ6W1afth
2KElKpUWtOFhOq1dnWhGMxfu0KsiEsPCtSqLvSiMBRRmR1FuOLGETwifFV4XLoZjvr07EjWcxSJR
QVI/FXlXdUJ1VkXTVbkqQRVuV9lVEfrBLyqGbzxT2nGnz7Gr2XlY8MgDjSFLTU5j7JGTIzsPFnqw
aw8WAPKkxNT9HUyXvcvCLE65h2NfwOCbm4YffG3x+tjle28PHj1y7J1+V1h06d7jTxz6+LaKEY8J
vo7iaek5I8YsnZ7VSt7EdI/ARozDs5CmESTUk/BFODFHfRol9A0fGb4gZAVdblgRdGPILY7lEet1
H9q+0p3SnwoxRfGU1ZXJSs8IzA0t6AisxiCDwRQaZrfbHOEREXaW06n17C9NoLOLAFOI3RZstRoM
9jK9ngVzIaYymy1CXRYB+pADQjnYBN8zEVF2e0RwkfUA2Q8GoXz3IT3Rt5P9u4Uigt67fLeZ6TB5
0aMzo+sOj7xtDVPTk/PGnZ/3paXjfEln+HlHR/j4fF/el45xlvPfI0FPI21P5/Cbu9P8+o4EZ1vZ
FzX8Ivjll7Hoel72YEF1csk8KHHRjJAQFlAjeVmZxe6JaUIftYYQU932fiGCGJOU1vGKWysMmHdy
b8evzyWKQt/BnV+JCZ3uznMxMytqfEJSx+mWN1Z8T/5x4e9C3ZCtc6/vuJf9RkwHxs3jkPZmYvLY
gi1WySr0MXusE60V5hbNCavayl1y6lWZal2YDommRvUV1BoNiKquTJti5BxkMpkNBkGn06On1pp0
aiKatRoNpYJajwGhGRPpsWp9mYFF0jrTWGIuA22Z5oAQC2rBsJvdfzDVJ8S21wJ1GEgcIO+AhdCd
TL9/Kjl5jn0BjamI/FTuQeUnS6EZJbVINO3Lphy5REymovZljUX+EpV/RbMftIHzu+IGmtsD55HZ
mVq9g+MeXag9U6MPtmdmKSmlm5AMNJM80e6T0IdQ8nbnz6/NGJBIBnzSOZwEvTYnNrnzZSFSMDw/
x0tWdXzV8ePH+RWdS1g01zlJXII0tcEGzxQprJ/BE+QJW6lX6YIMxjCdXZ9kGGxUa7U6o8mkARIK
IURLzRZLhsZk02hMRpNeY6FGLUq0Xq9Ta/VUCmERjongfyZ9kY4cEO6CUCQOCp/lZPrpdHQN/OtA
mR4oXfzioOvOUo5XeI1FfJndI2BAaM1S7ispkyg8JPMFhsEDs2JTMofs3DXRYSVHn++YOXtDWW5n
xTZLuGtmldi346uNG+k1F8a1NTAPm4iSE46ntMI2T/4KodUoqA3NZJm4SF9vPGVQBxn0eiMViEgw
MyKimCF/IapvYmKjydCqSZzZjOFahlUfYrcX6ixNVpZQ6Vle1bJL08RtGbrQHbiUx2DKhDPBZ/j3
SueSeQZ77iTLXM+dHG9h2ga547h2ncyVC/aF8colTAJW9lInjCOyyKAstZv9PgZRawZluDSJ0cJV
VxfeMLizWaIDHR2H+nvXDyaPutYIN+WNNq5v6GjJKtVtZL8LBfQFIUu1B3RQjN5aPUgtaNQ6qkX7
Auo5mnbhxt2QT2i7cL/HjNYFDGhI6A4hn+xAg1G4Wz+zlbmqcx0nx8v7zRnHxPk8+1UgtAgguyp2
L4b0QcaQoclvx8fe4bXO7yN+dWTPI/cETXDt5//GbJa4COS/LNz1F8Uo/7f0evZv/jguQJDqe+j6
C8TVqkMKLgJ6IQVXgUN1UcHVEKXOU3ANvKwuVXAtJGjaFFwHrcaPFVwvvsRXZrgBZptmK3gQVJhe
VnCjeo8mTsFNcK05qfsPIi4zr+j+/wqpLPFd/2MgUAcvUXAKg4IrFFyEoOAHFVyF+M0KrgZT8FYF
18Ds4H0KroWQkOsUXAf5YQ0Krhe8FpWCG6B/2DMKHgQZYacU3EhnhDgU3ARp9kj2F5uRvQKY7NMU
XIQI+2iOq3h9nYKz+jKOqxn97bcqONLcvoTjGl7/iIKz+ns4ruX1Lyo4q9/LcZ3CXxmX+SvjMn9l
XOavjMv8lXGZvzIu81fGZf7KuMxfGZf5K+Myf2Vc5q+My/yVcZm/Mi7zl+H6XrTS96KVAettytkN
WC8pZw9i/6co+98UXIQo+xGOm7Bea/9JwUUc+zXH2ZdGJodOwdn8HRwP4fVuBcd6h53jtl40t/Wi
eSjvf7WCs/79OR7G669RcFZfyPFwNo9jnoLjPA4fxyN5/1sVnPWXeR3da93oXus6+TyPKTibZz3H
4/g8zyo4m2cHx5N4/YcKzupf53gqn+eMgrN5Pme4thf9tb3or+11Lm2vcwX16h/Uq39QL74EdfFl
KrRgVuiDCvBCGZYSPIkwFao4Pg7ddi1Ck9JLghH41oA4e3qx3s97SFhTjePTEMvj9d7/w5nSu3cm
wRRsqeZ/0U/u04h1o7GU1+sP2fjpB6kKNoDXDsMR1VhOxjGVuIcmPmoyzteI0ADz8VnO91CLbT6o
6d5JA64rYS+vspLc348UknAEG89mrMUclK3CWrx8pTJlLi/WyCNr+IzsBFW4+xo+ox9bmnjvKr4W
o3qTskIjP2EZH9vE22v5LKxke6rje/ArZ6nnc7MdlfFdNfLVWAvrX85Lef/NfDWJr9B7V34+fxO2
1/L3BXzuKmV1n9K3js8lr91VX83nblIoUoZvMmUu79eEc/o4VfxYynOXKTXNnNKMVz1SUsf50sAp
Ws3Hs50y6ahRRnWtUMbHz1dW9SsnZW0yNXuoUIE92WxybQ9d/Qp165ST+Hn/Zv7Ww9VGLrHVfHe/
LxNdmtPYfRYf/xfobL6eORpwnbnKbr0K/cu4TEuK3HfRrJyvXclr5fELsMWv8JD1qeZ/04KNqMNn
JbbNV6gtz9Cjy17OK1k6JE7DMuX8fs61at6nnuuZLI21fKR8kt7S7e+WLAnbFyqcqeG7YbIp861R
0eTq7n3U8Lce6W26zN40Xna+MmWN2XyGZk7p8ktk0wfzsL6Lsky2y7pPWMFlW+IysJDTtpHLXRPn
RmU319neZX1nupTSrU2NipT12CO5tYZzxAuL+Hh512zeMt7aI2ny6uWcWvVcS1q6T9G1Nhu/gLd7
OSUalDWYDslUbOLju3bcNXs9l6EabkO79pZ2hV0dcgnXmL2r5PLv5Tsbzc9WzanN/kKJvHqX5WWW
czA+JcwCxvE+DVw7ZK3qe8nMvWfqqU+9pH4c6kJP23auGw2KrajhO5rbLRf/u35C5mWlYj19ik3s
sW3yrNPQh0gwkY+XIIGvNw6fE3DtCi7tXVRm8tzIOVSlzJYG47HfVDxZAcIIPBHDJ2AtG1+Az7G8
Ph9rpuCT6c1IpHw+fsbx2qlgBD2HqVzSG39HD6TuennHMrfrFXno0Z8r6SP7yTqkQQOXqCreu+s8
Xd6iSwZn89YW7N/cvWZZt92VadfMx/bYS5+iUcyq9dh42bb4FXveqNibSj6Lr9teM9oWK6sxyzNf
sfOzuz2lvGbTv6FMlwQu6LacPsUa+Lr1rYHbtibF1lQouvJ79OqyEIxivl6z9FiYK9crV+SLyfJs
brXlXc9WOFOrzPx7HOrDT3UppWRvcaVUXLlyl91lFtbLoyAvrlqtULtRsW//au00Lvu1vXxAyxW8
8CkRUG/NkT2Ll++onlOW+To/17f/zHNJkcXaXna3a12m/eWc0v5eHq6hV5SW0t27oZfc9sQV/55S
bHc1fP4uuaq7ZL4FnP9zOTd7W5Mu293Tsw77ynammVOczV/VfR55X72lu0ax9jL9Za2qV+Sjxytc
KkP/7kQ98jGan/1KznXFhcwf+pToUT6NHIuWca7WXsaDhsvo3TMzO18d9xblil2dz+O2BdA78vvP
3O+aT9ZJnxKfXOrFu+a7ko8ytXqi6TI+55V63MUx72W0rvgf7baHyleucGkscumOfEqE3YR+tGsG
5mWGYW0qMA86GDIhC72mhM/++JaKOUomQj9gefk0KFR69sPW/tiSqeBZkIHARg2CgZjPMGCzV/E4
ph7XS8fPAv5J4/HApRpfxi3fv/ITDMvj2rmgWy5kL+hXrC3b02RuoWUfOl6JzeqUqJ/pp+xJG3iL
n3NgCj57/AaTKpaNsWjif7bvdN6f/T33dHw2cQvBeJXOfc8sLiVyPJHW3fP/7goLeAwg9/X9X1ml
qy39MnnsnntqS72vwlvmk56Uplb5pHF1tXVNWCWNqGuor2vwNvnraqX66rI0Kc/b5P0PndLZZNKU
uupmVtMoja7Fcf2zs/ul4mNAmjSsulqa7K+samqUJvsafQ3zfeUj6mqbfDVskoYWqdGLg7DeXyGV
+xr9lbUp0rAGv7daKsNeXj821tQ1+KSq5hpvrb+xSSqr8jZ4y5pwQGOTv6xRaqry1krY1iLVVUh+
XKW+wVfuK/M1NtY1NEre2nLJi/M3l1VJfmUqf63U1Fzrkxb4m6pwuA9r68rZaIZXe3ENHO/FzXTV
NS3w1Tb5fdi7DJHmhpY0iZOkbr6vwYvHa2rweZtqsIkNKGvGIzayxRrrKnCbfAsVzdXViPK94vI1
dbiIv7a8ubGJH7WxqaXa15sSjDmNbBVfQ42/lvdoqJuL03px/2XNuFAt31m531tZx9oXVPnxhFW+
6nqkSJ1U6Z/v4x04l71SNZJDqvEh7Wr9ZdjdW1/vQzLWlvlwEZncfkYsybcQD1Pjq26R8GyNyORq
NkeNv5qTt0mRm0ZlvTIcMdsnNTf6ymVq+uY1s802lzH6SxV1eGScEQ/V1OSvrWRHb/Ah35saUxib
GpFkXI7wtcZb6V3kr8WpfU1lKTLRcHi5v7G+2tvClmCja30LGuu99bg17FKOW2zyN7KJWff6hrqa
Oj5bWpesDpGPNtlX2VztbZBGN3mr/WVDpuNwJrwD0gYPkBLH+csa6hir+sqd5U4cT5XxcVP521Zp
agNKRY23YS6jxb/TCTxlJYqnDyWRSxt2nTZFmuhtkhKkqeOkCRUVaXzLvupG34Iq7JY2fsLU0QWj
RwybOnrCeGlCgTR29Ij88VPypWEjJ+fnj8sfP9WoN+qnViGTunjAGMYmxmMjPZo4f7r3gzpZV9ng
ra9q4eswtWAUnN0itdQ1s5FlTHZxd8215VwuUVpQ1LjEo7T4Uc6xu7eywedjcp0mFeOwKi8KVd1s
ppQ4sumSzTACLmDC6UMx8DG+NfjKmlBqKpArPftiAlFX6eNduMB0j0NGoy7Mbm7CqXGbdaifvQ7U
p7FrU6gW3aToHsxkV5rvrW72zkZ59TaivPUenSZNq+Ua0NJ1CjyTwhxUFq/UWO8r81f4y648uYRU
rOWyy8Z6y8v9jMcoJg3cpKWw6gZOW24rLttUtb/Gzw6Ei/B+C+oa5jbKIs+lm1fWLUCZaZ5d7W+s
YuvgXDK5a1Dscf/IqvoWSVYFhUKXLsTpMbqi53DMFs5r9jXyZdCKlvkaapUTNCj75p0bq+qaq8tR
Vuf7fQtk43fF8Vk/5KQP7Ul5j8HsPiNui5vpsqYeHrODeZVdV/z+tHzL3QMUK6JMhOt4m4awDtOm
DJNSpcTBmVl9paz+g1P7Zfbrp9NNK8TKfv37Z2biMysjS8oaNDB7YLZRX9XUVD8kPX3BggVpNV2M
L6ur6a0TPimvwbuA0QJVEDeFM02um40aOh6tWR2a/hSmpA3+Mr9XmuLlutGIvmzwgH8xd3pVU011
ek1TrbfGl17TOMvL7EQaq/wvByzwVWOt7z8PYW/pCh1570suR0bwMLuRB77eS1rm8pZFcPpftMhj
etcX9qqv4+Fzc+92uok+S5+mu+l+uvNfXNDI6UHvtjwyCcumy/Zc12ud3z8NS8p/b28tPHy/fPXP
lHDnktnECHGE6BGHiYPFAb8z1+9QhvTrPsncS0ZMhDri5UlK7WU7ruXJjR++4VjvlnycaxEP670A
8L8AryYwu2VuZHN0cmVhbQplbmRvYmoKNTcgMCBvYmoKPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUg
L0xlbmd0aCAzMDggPj4Kc3RyZWFtCnicXZHPboMwDMbvPEWO26EiSQtdJYRU2k3isD8a2wPQxHSR
RohCeuDtl9hdJ+1A0M/299my80N7bK0JLH/zk+ogsMFY7WGeLl4BO8HZ2ExIpo0KV8JXjb3L8iju
ljnA2NphyqqKsfw9ZufgF3a319MJ7rP81Wvwxp7Z3eehi9xdnPuGEWxgPKtrpmGITs+9e+lHYDnK
Vq2OeROWVdT8VXwsDphEFjSNmjTMrlfge3uGrOKci5pVfN00dQZW/8uXpDoN6qv3WL1O1XzP60SC
Ex2JDkjrHZIskDaSaEu0QWrKSJKLHfa8uhe/vW6jCYkiQU7yibrsKLinZiUGoy/a0wSloOAjUvFA
wQaDBemKI/622+sE1DMtIB3qtl118T4uFq+JG027NBZuB3eTS6r0/QC3KprJZW5kc3RyZWFtCmVu
ZG9iago1OCAwIG9iago8PCAvVHlwZSAvT2JqU3RtIC9MZW5ndGggMTQzOCAvRmlsdGVyIC9GbGF0
ZURlY29kZSAvTiAzMCAvRmlyc3QgMjMwID4+CnN0cmVhbQp4nM1Yy27bRhTd9yvuMlloOO8HEASw
4zhxG7tG7DYLQwvGYl2ismRQNBr/fc+QljRUKOuB2OkiFjO8c8/l8Jwzd2gCcbKclCAryGuykkTA
kCLp8KNJBdwyJKS2ZC0J7RDkSFguyXqSQmI8kFQIwgypvSUnSFqvyEmSAXFOkeKKE6YqqQU5Qyrm
cZaUAZRzpGzAPB/hEB9ICyPJc9IS+F6QNkKRl6Qd4pFa++BjvUYIS96QUagc0EYbTt6RMUjuPRkv
1C9v3lB2Xk1H99dFRa8u/inz7PzomG6Nfk1v3za3303vJzUBI/utHM3oKi4Hp88xdfwZUnb5cFcg
TX5TzLqT/GIOoGNwO7Od6NoR1f60Y+JxMMxTn+dVgUS2nd6HdHhK2dm0us3HQD0AQvbpHYKzT782
f7/Ev6efSFN2cUB1dV/Ms7z/Vn+4qPMal9c55s3z5bPieArM7KAq8/HpJWVHxey6mIzySR1vNEug
5wW+n1xPR+XkhrKTESot64fBR0Ddf60bkAiFAi6nf0xKBBZY/fRJGqD1wO9Oji4eZnVxezL5a0ox
6PdqVFQR7tUc7jVln4ubclZXD/TqYDT9WryO+Hd34+I2Lh1H/ibT5fTDydFpfrestMWPT1eVd/W0
imxuiluUj2kxJBYrOzVnX7AKHP9c82bBbueYV5JDLkMSAqogpRTj3Hlc4vVepSHJrWS0mwPKAUmN
ZeC70lBdgFS6SSKxvGLBawXhJLHQp7UsBClA+OTSScmEdQHyTC7TWMGRPiaE9BZISWyC3wFJwP3y
4VK85cRkGt+ijt6AoBXzkLyxWCvbGE1SguON5ng6li7lspY1AckDLy9jwuS/yXMOoxFFz0lWIb7y
5D03k/txeWcVhgRfE66FEzA8AbNLuQSvu0rrGJLmOoqSa8SowOOSDOeyOojarSlww6QDnAOr87uP
RXnzdw07NszHeuRc5TUNpBAsCM1hm9nxOL+ZRfOIrD88nH4DzsBazYyJ1dAArs0cdw19ufSsfTrB
lWOCB6AN27nH5RgSMq1vNCNn+W2RaP2kzsfl9cHkZlxEy7qA6v+EXTOP55EmFV8i2H7rGLS51liX
29u63JbWleC/uIP5H+Rgtsve1dvwIptyGC/6aq2uh7GsZxMofy5d9qgS2RpVfi/BH6o3ZOwIzgjH
uG/cMBWc4F4wgz4IzRfHMBoqpVcEZ3sFlzA01d0g1tUqT0LALsj4cFtK70N+X+e3ZZ/mHN9Xc8pu
1twC+KXF5sTOYovs6SGLxGYmwUaTksVazqzWBm96SRYEMbPGl4W2j0yax4nIYOyRSCyEAnHidZch
yqwyZLGevZaMNp4ZZQSYtSUx0AtXZVGdFf+eX/R7slN788Nv5scq/ovTRO9ME8s54+Gxu1llC5yK
GREaXizZYpxgstksE7Yo5JGPKm4pY7qUkYLptnscwMmY9biykL6N6WW0FQ5LtzyskMatkmZ1kXu5
I5DNcqM3msqmMw0zLnCN/cbue7hJ6x0cTsejNczcu1vQfDdmLop4cXru3jLsQ88gQc/WNranp7ZM
eetiRzFwOBJoHdsL7CeCwR1jMiFBYRFNb4Wh4SmGLha7n6YwXmF26Dq/S/1UA+r33gy13INSP68X
9btvj89HLLSf3b2SI5lq7HKgHPrW6HcGGJZpaeLRRuAsxdrDR4dZWmxk1ubuyhimXDwg7UWxJ+m1
916q9Y70+onU+j9tqavUsg6m1XZzAxwBWGj55JcTQS14mUfQCrXUk9TaTCsRmJNNj/ckrdqvk2bx
dVK2lJYtvGz3PNk6qFrwaYtvkSvn4PX7qt97X5VbnAi66C9Ozv3O4MNIpNh+LT99edc9qz7zZx3p
WMNP11qitrE1JORR6AfjDiu4xkG58doOb+V3Z4juG+jfZdFmyvYgu5as/wEMNq+yZW5kc3RyZWFt
CmVuZG9iagoxIDAgb2JqCjw8IC9Db250ZW50cyA0IDAgUiAvTWVkaWFCb3ggWyAwIDAgNjEyIDc5
MiBdIC9QYXJlbnQgNjEgMCBSIC9SZXNvdXJjZXMgPDwgL0V4dEdTdGF0ZSA8PCAvRzAgNjIgMCBS
ID4+IC9Gb250IDw8IC9GMCA2MyAwIFIgL0YxIDY5IDAgUiAvRjIgNjYgMCBSID4+IC9Qcm9jU2V0
cyBbIC9QREYgL1RleHQgL0ltYWdlQiAvSW1hZ2VDIC9JbWFnZUkgXSAvWE9iamVjdCA8PCAvWDAg
MiAwIFIgPj4gPj4gL1R5cGUgL1BhZ2UgPj4KZW5kb2JqCjIgMCBvYmoKPDwgL0JpdHNQZXJDb21w
b25lbnQgOCAvQ29sb3JTcGFjZSAvRGV2aWNlUkdCIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9IZWln
aHQgMjYwIC9TTWFzayAzIDAgUiAvU3VidHlwZSAvSW1hZ2UgL1R5cGUgL1hPYmplY3QgL1dpZHRo
IDYyNCAvTGVuZ3RoIDExMzAzID4+CnN0cmVhbQp4nO2db2gd193n54UgBsFqQTR6qFp1K6jTun1M
7MatZVm1E0eJ2zhYTZNUjbuRUydRijerPNpYdk2wg7ummKIsLriYrAIuj/rggEBdBC44rIq6OKAU
QUUjW9n1C73wC4FYBKt9/+zX86tmJ3Pvle+Rzp2j0f18GMTVmX9Hd0a/z/zOnDkTRQAAAAAAAAAA
AAAAAAAAAAAAAAAAALBZ+N73vnfgwIGDUAWHDh3q7u5+5plnQh802Ao88sgjjz766OMQjieeeEL/
1KFPBNg6dHV1hdZUkZBMf/CDH4Q+aLBFCO2TeufJJ5+UUkOfBbB1kB2WoWp+EBP6oMEWYQWCYlYN
fRbA1gGfOqGv6/vf/37ogwZbhNA+qXfwKfgFnzqBT8EjoX1S7+BT8As+dQKfgkdC+6TewafgF3zq
BD4Fj4T2Sb2DT8Ev+NQJfAoeCe2Tegefgl/wqRP4FDwS2if1Dj4Fv+BTJ/ApeCS0T+odfAp+wadO
rM+nx1apxRGE4hLaJ/UOPgW/4FMnnHz66quvnjhxwn5Kpj/72c9qeiihcIT2Sb2DT8Ev+NSJanya
aPS1GH3WTyvM55hCUQjtk3oHn4Jf8KkTa/i0rEZfX+XVmJwPLmxyQvuk3sGn4Bd86kSpT9fWKD6F
NQjtk3oHn4Jf8KkTiU+r1GjGpwBGV1dXlItPz1ZgdHR0aWmp+u3cu3dPa924caPKnV69enW9Vc4P
fAp+wadO2PtlzJ7VaBSfQiWef/75S5cu/eUvf6mpMtb4329vb5+fn69yO3Nzc1pFoqxyp7pg2ECt
cwKfgl/wqRPm0xdeeKFKjQKszeTkZE2VEZVTm+R45MgRzdLPKrfj5FMlp+Pj424VDQE+Bb/gUyfS
+Wl/TPX5aa0jMxSLn/70p6dPn75161ZNlRFVSBWXlpaampoaGhqqbPV18mlRwKfgF3zqRHL/1EJi
9VmqNfG9BhBz6NChKJf7p1Hlptft27dr7t27d5OSmzdvHj58uDlGoknnmGmfXrx4Uducnp5Ob21i
YkKF+qnP+nDy5Ekrv3Dhgn5dWFjo6+trbW2VxLXlzH3Y2dnZnp6elpYW7VcftC+tohX9fAWVwafg
F3zqRKZ/b2LV12KxKl1d26cBDzRsQmrti5XKPpXRNKutrS0puXLlitJVlQwODg4NDe3YsUMLXL58
2eamfSrP6rMWS2/w+eef37Zt27179zI7tWHB5G5tcGBgQL82xMzMzNgCkmljjP59bL8SaxSPKlaD
7+Nz4FPwCz51otLzp4k333jjjbJWxadQSq19sRKrTS67mkLZpVJFuU9SGxsbs8WUpapELltcXLQS
ne1yogotgU37VLNaY5K9SKNaUqllstOMT5X2ai0rGR4eVonUab92d3erJkqN0/uN8CkUEHzqxNrj
IyUmPX78OD6FB1JrX6xU6N8r98liicJWVh03MjKSXnd0dFSFly5dWim5f6rkVL9a6+5KnNvq18TO
UYlPkyWTTZkuJeKopFuUKhbhUygg+NSJasYb1MV/ugXY+izhUyil1r5YidW2Z8+euZhbt24pOW1s
bNy9e3fS3GropNWSkuyxFNYHWLNWSnw6OzubzBIdHR0tLS3LqxloVOJTrZ7sK+1Ta3bOdHNaWlqK
8CkUEHzqhNN4+Jk+S/gUMtTaFyvl7p8qi1Sh9Jd++NSsJ/N2lWD9gkr798qhUrPcZ7MGBgbK7nQd
PrUt4FMoHPjUiXW8ry3d6lujgwgFpda+WKnQH6m/vz9TbiVTU1OVtlPqU2vjHR0dPXfunD6ku/tG
VftUKbM+J52BSxeoKfgU/IJPneB94uCRWvtipYJPFxcX29raNGt4eNhKRkZGolQfIePatWs7d+7U
z5VyPtVGtm3b1tvbq2V2795daadr+1S0traqMunHYC9evBjhUygg+NQJfAoeqbUvVio/LzMxMaFZ
TU1N1uornUlqDQ0NSZck5ZstLS0y5uzs7EqF8RykvMbGxijl5dKdPtCnly9fjuIOwMpVVRltStWI
8CkUEHzqBD4Fj9TaFytrjudgpkv61s7MzFjSKo3aB7lydHTU5pb1qd39lHMXFhYq7fSBPhXKi82h
tjXrPIxPoXDgUyfwKXik1r5YWXMoXUnQnkhNnjlVlqr8dGBgoL+/X3lieugkLaMlM6MjWkfc5LHT
sju9efNmehfJptJP6whlpqMxqpVS46ik8bkW4FPwCz51Ap+CR2rti1pjD6hucOh7Jcjnzp1Ll8i2
2mwOb3zDp+AXfOoEPgWP1NoXtWNiYuL69evtMRvclIzW0NAgNS/Hj69qyy0tLU1NTTZ0YU3Rrv9r
e/u/RlH9TFBT8KkT+BQ8Umtf1A75LorvdVb5hvE1mJmZsZH5E1pbWzOtwTXid1/5SnDB4dOtBD51
Ap+CR3JQRo0YGxu7dOmSdf3dOPrPkpeHY8bHx6t8hdzG+e9f+EJwweHTrQQ+dQKfgkfysQZUYvxL
XwouOHy6lcCnTuBT8Ehon9Q7jz/++D/XWZMv1BR86gQ+BY+E9km9Uw/9e/FpnuBTJ/AplGV98Sq0
T+odfAp+wadO4FMoy/oa1sLaxF4NkyE98MKWB5+CX/CpE/gUyrK+O1ZhbWKjBZbS0tIyNDS0vPoy
03Vz5cqV9AhLmxB8Cn7Bp07gUyjL+rqChLWJ+XTnzp1nU/T19cmnKu/t7d3Ixi9cuBB9ftjeTQg+
Bb/gUyfwKZRlfX0sw9rEfFo67LySSlPqzMzMujcuNUf4dBOAT/MEnzqhr6vv8ceDd3pnKvp0IP7v
C2uTSj4VAwMD0edH0JVkR0ZGLIcdHR1N32bVLG1qaWlpfHz83LlzN2/evHXrlr1W5tq1a5OTkwsL
C1qgdPCHyZga/XXVgE/BL/jUCX1dp/buDR6NmbbAFG16nybvQr148aK9T015q31obm6empqyuTZ8
/dDQkIWU1tbWrq6uJMK0tbXJp9u2bevo6EjvYn5+Xpvq6+ur9Z+5BvgU/IJPndDX9Z937Qoeipm2
wHRdPs1rYL2yPLC911prlW/qs7xjLznVf8GlS5ei1GvazKcy5oULF8bGxq5fv75S0t6rhfVrOkW1
G6z5jNNbCXwKfsGnTujrOvPd7wYPxUxbYIo2R35aqT9Skjleu3ZNqeX09HR6XS2zfft2+2w+zWSa
GZ/Ks/o1/V62HTt2bPzdNBsEn4Jf8KkT+rp+duBA8FDMVPTp6fi/L6xNKj0v09raKhsul3te5t69
e1NTU5cvX25sbGxra7NC8+mVK1fSS2Z8qq1JwYlAb926FX1er0HAp+AXfOoE/XuhLK4+NcLaxHza
09OTHs/BGnUzjI+Pd3d3Nzc3W7Ul023btmV8OjExkV6ltH/v4OCgSqwD0smTJ/V5fn6+hn9eFeBT
8As+dQKfQlmcNJoQ1iZr9EdKMzIyEsVJ68DAgD4rtdQ/QluMLWA+zbwItdSnMzMzKpFJtbrULJF5
/4tcwafgF3zqBD6Fsria1Ahrkyp9umPHjoaGhnQuqX+E0vz0gT4Ve/bsaWlpUSYbpToPBwSfgl/w
qRP4FMrialIjrE2q9Gl7e3tjY2P6Hd/WNbcanyqZTRdevnxZhbJqZoOhwKfgF3zqBD6FsjhpNCGs
Tar0qT2LKu+Mjo5eu3att7dXyWlzc3NTU5MtUNanpk7ltulxC+/du6d1o5LOwKHAp+AXfOoEPoWy
rC9khbWJkseuri4lm2svptP+5MmTsmcU90Tq6emZmZkZHh7WuvY86fj4uD5nUtHFxUUtKe0qjU0P
piS9RqEfO03Ap+AXfOoEPgWPhPZJADo6OoI/dpqAT8Ev+NQJfAoeCe2TvLGhli5evBi6In8Hn4Jf
8KkT+BQ8Eton+XHu3Dllptu2bWttbb13717o6vwdfAp+wadO4FPwSGif5MfVq1fb2tqk1I28A847
+BT8gk+dwKfgkdA+qXfwKfgFnzqBT8EjoX1S7+BT8As+dQKfgkdC+6TewafgF3zqBD4Fj4T2Sb2D
T8Ev+NQJfAoeCe2Tegefgl/wqRP4FDwS2if1Dj4Fv+BTJ/ApeCS0T+odfAp+wadO4FPwSGif1Dv4
FPyCT53Ap+CR0D6pdyTTzs7O0GdBbcGneYJPncCn4JGO2nP1S1/6l3/4h+GvftXjNuUgj1sLyLe+
9a3vfve7oc+C2oJP8wSfOoFPwRdf+cpXvv71r++tJR+0tiaB9Epb28Y32NXV9e67777++uv6R5CP
Nr7BgDz22GO7d+/+5je/GfpEqC34NE/wqRP4FAqE91gqk/b397/22mvHjx/XTx+bhNqCT/MEnzqB
T6FA+I2l58+ffz0FPi0E+DRP8KkT+BQKhN9Y+sYbb1hjr8lUvPrqqx5qCbUEn+YJPnUCn0KB8BtL
rbE3nZ/qp4daQi3Bp3mCT53Ap1AgPMbSTGNvciNVP/3UFWoDPs0TfOoEPoUC4TGWpht7E1RIirrJ
wad5gk+dwKdQIDzG0kxjb5q+vj4/1YUagE/zBJ86gU+hQPiKpaWNvQnHjx+nV9JmBp/mCT51Ap9C
gfAVS8s29qY7+nqrMfgGn+YJPnUCn0KB8BVL12jsTcq9VRq8gk/zBJ86gU+hQHiJpWs09qaV6rPe
4A98mif41Al8CgXCSyxdo7E33epLr6TNCT7NE3zqBD6FAuEllq7R2JvIlOF8Ny34NE/wqRP4FArE
xmPpAxt701b1XHvwAT7NE3zqBD6FArHxWPrKK688sLH39dVevjT5bkLwaZ7gUyfwKRQILz49fvx4
WYFmSrQYPt2E4NM8wadO4FMoEBuPpVLkq6+++loKs2em0N41g083Ifg0T/CpE/gUCoT3WJr2KcMi
FQJ8mif41Al8CgUCnwI+zRN86gQ+hQKBTwGf5gk+dQKfQoHAp4BP8wSfOoFPoUDgU8CneYJPncCn
UCDwKeDTPMGnTuBTKBD4FPBpnuBTJ/ApFAh8Cvg0T/CpE/gUCgQ+BXyaJ/jUCXwKBQKfAj7NE3zq
BD6FAoFPAZ/mCT51Ap9CgcCngE/zBJ86gU+hQOBTwKd5gk+dwKdQIPAp4NM8wadO4FMoEPgU8Gme
4FMn8CkUCHwK+DRP8KkT+BQKBD4FfJon+NQJfAoFAp8CPs0TfOoEPoUCgU8Bn+YJPnUCn0KBwKeA
T/MEnzqBT6FA4FPAp3mCT53Ap1Ag8Cng0zzBp07gUygQ+BTwaZ7gUyfwKRQIfAr4NE/wqRP4FAoE
PgV8mif41Al8CgUCnwI+zRN86gQ+hQKBTwGf5gk+dQKfQoHAp4BP8wSfOoFPoUDgU8CneYJPncCn
UCDwKeDTPMGnTuBTKBD4FPBpnuBTJ/ApFAh8Cvg0T/CpE/gUCgQ+BXyaJ/jUCXwKBQKfAj7NE3zq
BD6FAoFPAZ/mycZ9+tvf/jazzYcffvj8+fNe/LXZwKdQIPAp4NM88eXTX/3qVxMx77///iuvvKKS
X//6114UtqnAp1Ag8Cng0zzx5VOZNF34j//4j3v37s0subCwkP71Xsz6drrGunfv3l1jrfXtLgGf
QoHAp4BP86RGPn3ssccOHTpkn5977rl33nlHJVpMqatKPvroo127dlkFZN4//OEPKtQW2traPvnk
E1tLCa9+/fjjj+1XZbsmaK2rVWzdr33tax9++GGy01/+8pdf/OIXVf7QQw+99NJLiT1VgTNnznzj
G9/QrLfeemsjfyw+hQKBTwGf5on39l7x5ptvNjQ0JIbdv39/U1OTpPbee++NjY1JkY2Njc8884w+
yJ4vvviiFpYlFxcXVZ60Emst22zy68svv7y0tPTwww/LlTMx+iB1WkIqmWo7Wn52dvaPf/yjVHvw
4MFkXS2mHWnjmrWRPxafQoHAp4BP86QW/ZHE008/nbS7SmeSoFRov8pryiKTX/VBmePRo0f1WZLV
istxw6zkqJRWJctxQ7F+VRr72WefaePysq2rXWjvmquNNDc36589qZW8qSXNnqqA9LrBP9PAp1Ag
8Cng0zzx5dMPPvhgNkZpoz5LoLKkUs7lWGciWV5qk1LTW/j5z3/e1tZmm1KKqrU+/PBDbcF+lSu1
QStfXs1bd+3a9fbbbyfJpvJcFUq+Z1bRXJUoabVVMntcN/gUCgQ+BXyaJzW6f/q73/1Ohb///e+X
S3Qmdb700kvphaU/86nyTduUDPvcc89ZNvrRRx+9GGMLy6q/+c1vDh06JMNG8e1XLWbZqApf+jxJ
BTJ7XDf4FAoEPgV8mic18unY2FgUJ63LJTrbu3evNeomHD16VMlsMvett95SDitpLsfJ7DvvvNPc
3Pz+++8vx43DH3/8sSWq+ilrP/TQQ1rezGurGOkl8SnUJ/gU8Gme1MKnSjMPHjwo00lzyyU6O3/+
fENDQ9Jx95NPPtGSb775ZjJXuao2ODs7uxw3BT/88MNawDrrTk5OapY0agursKmp6e2339bnXbt2
ScpJn9733nsvSt0/xadQh+BTwKd54sunsl7bKlH8xEqSLWZ0ppxRSag8+FqMPjz22GOJB+1OqDX/
ig8//FC/Jj11l+M+S42Nja+88oo0KoFqv3Nzc8uxarWp9vZ2pavWZzjZKT6F+gSfAj7Nk4379M9/
/vOZFEowP/jgA8tMDQnX7mMmLC0tvf/++y/HaG7S19fQFtIZqLaZfshFC8vUWlGK1JLp0Ru0U5Wo
XLZN77G0AusGn0KBwKeAT/OE8fCdwKdQIPAp4NM8wadO4FMoEPgU8Gme4FMn8CkUCHwK+DRP8KkT
+BQKBD4FfJon+NQJfAoFAp8CPs0TfOoEPoUCgU8Bn+YJPnUCn0KBwKeAT/MEnzqBT6FA4FPAp3mC
T53Ap1Ag8Cng0zzBp07gUygQ+BTwaZ7gUyfwKRQIfAr4NE/wqRP4FAoEPgV8mif41Al8CgUCnwI+
zRN86gQ+hQKBTwGf5gk+dQKfQoHAp4BP8wSfOoFPoUDgU8CneYJPncCnUCDwKeDTPMGnTuBTKBD4
FPBpnuBTJ/ApFAh8Cvg0T/CpE/gUCgQ+BXyaJ/jUCXwKBQKfAj7NE3zqBD6FAoFPAZ/mCT51Ap9C
gcCngE/zBJ86gU+hQOBTwKd5gk+dwKdQIPAp4NM8wadO4FMoEPgU8Gme4FMn8CkUCHwK+DRP8KkT
+BQKBD4FfJon+NQJfAoFAp8CPs0TfOoEPoUCgU8Bn+YJPnUCn0KBwKeAT/MEnzqBT6FA4FPAp3mC
T53Ap1Ag8Cng0zzBp07gUygQ+BTwaZ7gUyfwKRQIfAr4NE/wqRP4FAoEPgV8mif41Al8CpuZf3Wc
XMGnhQOf5gk+dQKfwmYGn0IGfJon+NQJfAqbGXwKGfBpnuBTJ/ApbGbwaZ1T6xMA1gafOoFPYZNT
01iKTzc5+DQs+NQJfAqbHHxaz+DTsOBTJ/ApbHJqGkjx6SYHmYYFnzqBT2Hzg0/rGXwaEHzqBD6F
zU/tAik+3fzg04DgUyfwKWx+8Gmdg0xDgU+dwKdQCPBpPYNPQ4FPncCnUAhqFEjxaSHAp6HAp07g
UygE+LTOQaZBwKdO4FMoCrUIpPi0KODTIOBTJ/ApFAV8Wufg0/zBp07gUygK+LTOQab5g0+dwKdQ
ILwHUnxaLPBpzuBTJ/ApFAh8Wufg05zBp07gUygQ3qOoHHrixAn9NKV62irUCmSaM/jUCXwKvnjk
kUceffTRx2vMkwcP2uRla0899ZT+BZ599ln97O7u9rLNgDzxxBOHDh0KeA48+eSTT8TU7m8c2LUr
kenPv/3t2u2oiDz99NM6k59//nlfBxSfOoFPwSOhw0m9YzoLeAIcOXJEdcjhL/0fX/hCDnspIs/H
+Dqg+NQJfAoeWYGgWEQNeAIcPXpUwTyHv/T/Li7msJcigk8Dgk/BI6FjSb0T3Kc/+tGP8vEpVELf
v46CrwOKT53Ap+CR0LGk3sGngE8Dgk/BI6FjSb2DTwGfBgSfgkdCx5J6B58CPg0IPgWPhI4l9Q4+
BXwaEHwKHgkdS+odfAr4NCD4FDwSOpbUO/gU8GlA8Cl4JHQsqXfwKeDTgOBT8EiecWNhYeHmzZs3
btyYnJxc5On+GHwK+DQg+BQ8kk/EuHr16s6dO9P7bWho6O7ulljzqUApZ8+eVTVUsVAVMPAp4NOA
4FPwSK1jhfJQedP2JXEMDg5KZCdPnty+fXsUW3V0dLTWdSgLPjU8+vRGOWiLeCD4NCD4FDySQ6zQ
XmTPqampzKzLly9rVmNj4927d2tdjVLwqeHRp5V2oaumEydOKHZ52cvWA58GBJ+CR2oaKJSeaBdN
TU3z8/NlF+jr69MCQ0NDNa1GWfCp4denO3fuzOSnly5damtr0yx94V72svXApwHBp1CWA2/+T5uc
1qppoDhy5Ih2ceHChUoLTE9PHzt2bHx8PF04NjbW0dGhpEbrtrS0nDx5cmFhIbPiyMjI7t27bRmF
64GBgXv37qUXWFpaUgC3SK4UWHvRRrq6upLKlPp0cXExWUVb3rNnTw5t0VvMp/qGS8vn5ub0fTY3
N3vZy9YDnwYEn0JZ9p26c/DN/7Vv6M6+U7c7Ts3t/aeZataqXZTQuSqRaRcKp9WvJTNGcUorAw4O
Dkqa+rW1tTW9kf7+fltG6a2Wt55O27dvT9qNtWsFdhW2t7drAW1KNbE7tvpsy2R8KplK4irZsWOH
VtEupHL9qjp4+j7KUw8+FXaVki7R9Y9S12Mx+pC5HNLhuHLlis3VIbh161Zmg7oSU7nm6hzQQVxO
NSYrKdbBzZx1KkmOtS2gVc6dO6ct6NrMynUNpp1qgyrUApnbEKrh8PCwVenixYuZCm8EfBoQfApl
uW/S03c6h+b3Dc13/NNMZ3Vi9RUTSpmdnY1i61W/irUPZ+yp/DRKBerr169HsSjT9jxx4oQKe3p6
rMTuzMpTipBWMjMzo/woquxT20v6Np/yWTN1TTsh14NP5+fnM/mpvlK7XNH10p49ezRXv+oY2Vyp
Shc/KtRcbdCuynRMk9XlX83dtm2bLoF0JkRxO3NyPtiR1blUqW62gF2VJeU65WxTuqDSZrVx7Tc5
9KqbTstMhX2dGPg0IPgUyrJv6LZ8uv/MvE1VitVLQCiLyVGJSWn52RJsloSoVZJ8wdA5b9mNUpKV
WED6nGkiljdNl3aj1rLaJD4byimiCj7V6hY/E/8a5u5klVqwxXwq18yl0CHQ0bSWgaSlXV+y3KTj
lWSdOrLSk46yff9aUsuPjY3ZXOlVpkuOjg697Si5C6CkMoovn+zXKn2qCkxMTKiGdl5prix57dq1
pErao/ZrFVbddGWYCNQqrL8ic8KsD3waEHwKZcn4tEqxbjwaVGJqaiqKk81MuUWzDDbLEoTSljRL
Jcyzlq2UxjHrSCwDalYU33jNLKAYGFXwqeJkFCcmmb40iq5R3JLs4/sozxbzaVl0yM6dO5csZvpT
jpleV79G8eFbWW0rSF8y6QDdvHlzOW46sJvys7Oz6dXt6JsZq/Rpukqyqkp6e3vTq+gCTGeLzkad
eJqrX9NzrQ0kc+23PvBpQPR1PX30pY7TCp6374fQ4k+P/uy/feulf9a05+Sfg1emwNPpO2V9Wkms
/+bLe6Ja+lSByP7BM48fKiu5msKWsVnpz2ksAFoaG5XLecXg4GAU+1FpUdllrLysT0dHR9cIUGV3
54st5lN9V0mbg93C7u7uzpwA1jg/NDSUPg3s8A0MDGgBqTOKu4RZ/zGzZIKulCxtTGOO1s+Vqn2a
9rUZ01YvxS7nVMN0hVV/FUr96/yyUuDTgOjr6n7hP+z9xZ3O00xMn5vWkGlZsUY17t9r9x/X7iVr
QcA+NzU1la2Sxa7h4WFbvuw9WYvSCnQLCwuRo0/HxsaiuMGw0ogE7n96tWwxn2bun5qJ9Acup/oL
6RBUqkxydKyPd1IugSZ3ukv3srJ6c8GuuKr0aXoBnVrRanZcSjUV3gj4NCD6up7sPbNv6LMqgycT
U6Xp60f/y/9e/j8bDwiVsEa8HTt2LFd+lt+CgH02/2byEXH48OFo9YaatQmXPtBq2ZC5z/q6ZNqN
LQkt61OlzFbPzDaXlpZUmZoO77O1farjvmfP/WYQSzwN01OmwbYsd+/e1QHq7e3dtm2bVlHeuhJf
dJUeKUswrc/SOnxq7SSVHka2Cmdux3sEnwZEX9dTL/zH/afmrX2PiSmZOs9Ul6IOzXed+ezb/+mz
qMb5qXxkfVGOHDlSeldUc63nSVINy0OV1KQXU165Lca8lrQWppeR9RoaGhRp7b6q3YBLL7O8+gRN
pf691nszE4StC5Mqv/GvohJb26cr8a1JHTsdnSTNt4OekZfm6njZMtaamp5rurT00zoOZR5JtrPC
Dp/d2Uy6M62sdjVfw6d2Az1z4qme1sXXstd0B+OV+BpscHDQS9sFPg1IfP/0399/OOL+FPqeHdPm
mWKlrm1SCbfj9NzBd+c6h+7826/e98vGo8HaKJxatijZSXPXr19XHNNPxSIrj1I3oRQkrVDh1Oyp
eGVGTnqPSK+KcoqoCne2zMTEhNkw6eKSbEcRUnMVWhNnVfKpRWytpTTW/tGuXbtmO6K9t0qiCs/L
mEB37ty5HDdT2AVSW1tb8oSLjqN1ybYM1PLB9P1Nu7Cxg2W5pJLW5dVGD62lDba3t1uJ9cpOOhep
0HorreHTlbjdQ6do+pkd1VDng67QVE9tX+dY0iqiQsu7rcIbBJ8GhP69UBZTagWT3tn/i9v7T3/W
ed+5tztOf3rg/Ke21sajwQOR3RQhbSyjDFJJxlYKaPZ0TIJWzGQrCmIm0ASFu3R3TduOidjQNi2q
V/LpSnwTzdoVE+TTWg+RVA8+VdSylvzkkRnletae0NfXp6spa8NP2oQl3ObmZi3Q09OjQ3/48GF9
7ujoSDp123NV2qZWUeV11NIPs9jjLVH8TI0Otz7rTNDCa/tUq+tw20AiqpJMqp0mSa5OA6uwzc1U
eIPg04DgUyhLeZ+evt/16OCpuc7TtzvP3O48PZ9Zy0tAqAZZVTmgjWmjiKSIWukOmuKhwpeClYKt
EpOywytpGW1Ny5w4cUJpaaXxgaemprSYPWphXVYSn1o340wdtB1trT9GNcxhoP6t5FN9t5XGltSB
0FwdrMSJ8pdSSJlOvpMxM32BdNB1CCRBzZVJk7aIBB07raW5ZtXMkdKvWn1HjD7o3LsQY3O1L1Wm
9H6odqoaahXpUt9J5kpPJ4wqrLlW4eRJ1Y2DTwOCT6EsJT69ve/MpwfffbdT5afuHHj707Jr+YoJ
mwolNVJ25o6ttRlmniIMzlbyKawPfBoQfApluf88sny62tcoTkg/3XfmrwfOn19jrdCxpCbYYxrp
VuLp6WlrQqymW2me4FPApwHBp1CW+z69n5De72u0b2j+24PZpt2yhI4lNWFubs76I7W3t3d1ddmA
qyIzJs9mAJ8CPg0IPoWy7Dv9NyWkmpK+RtUQOpbUioWFBeWnkqndYuvr6yt9R8lmAJ8CPg0IPgWP
hI4l9Q4+BXwaEHwKHgkdS+odfAr4NCD4FDwSOpbUO/gU8GlA8Cl4JHQsqXfwKeDTgOBT8EjoWFLv
4FPApwFZh08PnD/fOTSrad+pO76OGmwNahEfLly40NfXZ5/v3bt39uzZBz6ocvXqVS2WjMBw/fr1
s+VYY1Ql7bTUC3Nzc7bi2iMdjY2NqcJdMd3d3UNDQ6V7OXbsWC0et6lPn05PT/f09Njr+aJ4NMj+
/v4cRqPanODTgDj59MDbn3YOzXcO3Y7HyZnfN4RP4XN4Dw6Tk5MNDQ3J8HGV3u6dwV7+kgwtuMYb
J4Xct1zyAjjtovRllAMDA7ZKpXHwFhcXy+qsdNDga9euqdD7Qzd16NMbN27Y48C6dDkWY6P7trS0
lB1bcsuDTwNSpU87T/+tc2hu/+nbB0/N3X9Zavy+aXwKGfxGhuV45PP0oOgb8eng4GD6vd7KIuU4
G7I+M2zgzMz9d6OPjIxkKqMQvWPHjsbGxtbW1uVy72CVmqN44PSbN2/a0LILCwvKgrVK6Qb1p+3e
vdvl+3gwdehTHREdxMybWXJ4Nd6mBZ8GZG2fHjj/6f5T852xPfef+dv+oTv7V9+JGfv0tq+jBlsD
v5HB3qWVfvXkRnxa9v3OV65c0Sz5MV1o0TjzTkxVI4pfBtfb25uplaHkVFmS1Fn6blZlo1olY097
I3lm5PYNUm8+1VcdVXgNTXt7uzybKdRFzq1bt6ampiq91V0LTE5Olh7BNZidnZXNM2dLmunp6Twz
ZXwakEo+7fjFX/efua3p4Ltz+099VvpqaXwKpfiNDEo9MplgJZ8qBp47d06yk7mWV1/2XY1PFT+t
5unbbd3d3coxM0sq2dFiEzH6cPjw4cwCa7heVVJ415+TKWxubvabotabT4Wk2dLSUurHmZmZtMX0
bZ89e9YaCqL4lXyDg4PJqWXH7tKlSzpGNtdeKZ5pUrB3oSY3vsfHx+1Va4ZOm/QedSboPLTBn6Mc
X52ATwOS8emB8+f3nfnrvtOfdp6+ve/sbNeZz/aXmBSfQiU8hgUpUhtUWEsXljpL57AljAk7Y6Lq
fKo4bGsl+YUMq3Caud0p2yr3tDRWe7T3pWaSDq1o4br6d29ZxTzeRa1Dn5qwpFQdshs3biRvcMtg
fuzp6ZEEtZj9mtwit/NKlzfbt2/XVZmunXQ+2D3Z9Ea0us4NO1W0HS0gn+pwa4PWqq8TI8ltdZY2
NTWpUDXUikqKa/k1/H/waUASn6b7Gu0782lnxXdJp3waK5WJSdOX978ZefWp0gdtMPMC7lKf2mId
HR32AkpFtuTF39X4VGEwige6T0oUJ1VS9n5cIlnbqX5mtqYc2XYtoSsbWiO8G0p/tLCWfOC3USV1
6FMFsYGBgeTV7fau8AsXLqQbHKanp6OSJgVTqmku8Wm6pVcS1NaSCy3N0l5UaL/qNJMu03uxOwLJ
SWJvIa/1G+RLwacBue/THxzZd/q+H5O+Rmub9O/TLz6z+6pMTDY9/K0fegwLior6d868pjnjU2WX
CnEKa+kwqFUUBqMH9UdSoFPiYEumVav0RBtc/nx3I3N08tiLdVhSTlSqy+Hh4eTBjShuOezq6lJh
2Rt2FuczSdBGqEOfGrLelStXtGt7E5DQUUjuTdt1TuaWty6ZVKhZK6vnVeJKw/yYtO7apZdtxE6A
0h7gMrIupeyzzlId/eVy/dZqCj4NiPn04Ltz+05XbNplYqpm+nLnzz2GBQuMmcKMT+1+Vm9vb2ax
6p+XKX2SRerMxFVreZbf04V79uyJKjTtSrKqmNKfJFOO4i5PmZx3ZfXu7QO7V1VP3fo0jWSniyLr
G2b5o50AOqPaUlijvTnRzivluentLMc9upM76ToB9Oty7EdTrZTd9nlsp7a8leT6l8fg04Cs5qd3
Dr77p31vy6rz1Vt1nzX5MjHFU+u3X/YYFixeZQozPrVm2NL2UmvKy/j0yJEjmfEcRkZG5ufnS7ev
TCddaE/ByFPpdU1bZXuWplE819asl0umOTH5MyN/7eT15lNdouhYlO1bq8sk1Wd4eHhl9QSQZEvH
9LAc1o576YlkDfuzMVFKuNY3W0e/7Dghtgw+rUPs/umB83/ad+pvdiOsSrF2WhQNfduOaZNM/+7x
05HX+6dRucQt41PFrrJh0MqruX+awdr00pJdXFxMOoWWZXp62paUOm/cuFH2UQv9o+3evbtsHWwj
D6xYldSbT60hN3P9Y1gKaSNv2EAc4+Pj6QWWlpYSEVfyqbXrai92RiV3H6ampqKSznIr8TmQfMan
dUhJ/95qxdp5mv69kMVjWLAeJpnCjE/tAVXlHZnFrMfvOnza09Ozffv2dInt4vDhw3MlKHBpVn9/
f7JuVLlzbyX1R+XS8HVTbz61G9A6HzJ9rRXZ7HuYnJxciXupRSXDO5iL7fZoJZ+uxA37O3fu1FmR
foRqOW4KLr1xH6XuC+DTOqTS86cPFCs+hVI8hgVrI8005WV8aq1wmec6V+Jn+SN3n+rfQalo5iaa
dYsqO+qCRWkFVeuVpMgcxeF0uVwXFJNv5nlGJcJR3Bl47YpVT735dGW1SVYHrq+vT4mqjrJyUntg
Kn1jvbu7O4rvltroChcvXrQHoEyIa/jURvwQly9fTpfbhdbu3btv3ryp1e1ZVG1zYmLCFsCndcgD
xxusJNbYp4w3CJ/DY1iwHDOJTkbp8zLW9Sj9sLzdVI3cfWp+TO/RMo7m5uZKj72YuC3SKjJbFxeF
7nS35MXFRUtOS4cdsDbJZLT/jVOHPl2JW+ntm0+QXtPDNazER0FnlHXnNqTC5DCt4VPrQy5KW/K1
33Rfbh3fdOsEPq1Dqh8PPyNWxsOHUjyGBbv+t8cZEkp9qhTVegIfPnxY8VA/oziyRe4+VQRW2Eyr
03KfNXynVChKDSSoVEXyta/ChsfRLGu4VoQv7d9rnq1+/IcHUp8+NZR4KkkcGRmZnJysdP1z9+5d
XS/pMibzHJYioc6WSsMMaq1Mv7UEG5/w+vXrpTudj1nXn7Ih8GlA1vW+tj913h9A6VPe1wYZPIYF
ywsyT6kosklSmYitSGgD10TxYynW4qfFks4h9mumO0opcl/mUVDtSCuuMbKNAqa9ly1x98LCwtDQ
kDVWG6pSf39/2dC6c+fOpLnYC/XsUzDwaUB4nzh4xG9kyDz2UmvWyFDWR6VB1w1rTC7tTLUR8Cng
04DgU/CI38gwOzvb0NDg1zibB/1dyqn9vvYanwI+DQg+BY94Dw6Dg4NNTU1rvAyroEijpaPubxx8
Cvg0IPgUPOI9OCwuLra3tyfPeG4ZTpw4sWPHDo93Tg18Cvg0IPgUPFKL+DA7O5t5bLPo6P9Of1Ey
ur5H8Cng04DgU/BI6FhS7+BTwKcBwafgkdCxpN7Bp4BPA4JPwSOhY0m9g08BnwZEX9ezzz7r68uH
Oid0LKl3JNMnn3wy4Anwwx/+EJ+GRd//j3/8Y18HVKfTS1A1L7zwwtGjR319+VDnHIOgPPPMM089
9VTAE6Cnp+fIkSOhv4a65uWXX/7JT37i64DKDsp2Q2uqGPT29upKRkr19eVDPfOd73xHV7Ohw0n9
8uKLLyr0SakBzwHJVHVQTUJ/GXXKT2Ok1IDnAAAAAAAAAAAAAABsQv4f/3EgeWVuZHN0cmVhbQpl
bmRvYmoKMyAwIG9iago8PCAvQml0c1BlckNvbXBvbmVudCA4IC9Db2xvclNwYWNlIC9EZXZpY2VH
cmF5IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9IZWlnaHQgMjYwIC9TdWJ0eXBlIC9JbWFnZSAvVHlw
ZSAvWE9iamVjdCAvV2lkdGggNjI0IC9MZW5ndGggNjk5MCA+PgpzdHJlYW0KeJztnS+M8k6fwL+i
oqICUVGBqEAgEAgEAtEEgUCsQKxAVKxYgUAgECsqECsQKxArECNWrECQN1yyyZFcBXmDIDlyITkE
orlwSe/CJeTCJQhEb6aFXZ79QXe6z2x3eZ/vR7B0OpTpdz4703/MACAIgiAIgiAIgiAIgvxZ/H0R
A8MoJbqKvA/yqUQJsoWPPpj6MMcbnTgCFcbf+Mv6g3G9GHAjFOjBiboL9bsTiW0DLPLRJ80Pc7xB
4ghUGIsIIfm5/DDf9N4qsm/EOpFoo28/kh/mW90qMd+e62whOXraFtPDtdsAKMyWg8dKkq0c5SE/
3jhVkDrr1YtW36zbLHd+vNv0ZHCS9OOV9tatW/bQm+Vg5FD87Wn91eqOfWrb00DpbeddAkp3vSIK
R8lIHIEKA33jJkp/ajClSln2Vvcecuq8CclFWVlfQ8UzdY8mO0aCLmVW2auZLPXu9u2b5FZBc67B
02njZvrt2zonPQ4hqes3jsay2B0p6RrtcULuDqHbl5MOgc4gIfe7HOUicQQqDPSNm8i+BeheAvIb
Xdfb/SsW7cnBt+s5Tey1i5tmGl770xQkCnPz2Lfn/daMNcsGqkfbsVRibbC32joH0CCwqeh6ecNR
LhJHoMJA37j5tG8A11ub8mDadPn54NvdmiU2oWrvFuWDb3fuou/84hsJtpZeF183R2EZ6Av7Q4/f
vDHbFEe5SByBCgN94+Y3fMuvJYBsprQE1r4lPJUW2bie0aVCKpUDpTXf+5bdpgDGgW/TY9+05U2w
OZV92Cy6JXpk6KmrQtC+0T9qiaNcJI5AhYG+cRPZN9Ngb5lv0qyjpJ2aNL+TTM+EVV1t7IyE25Tz
63LVScv3NpAn1l3mt2kwdxYsWpq5o77d64Fv8vTZMAy/Qx12lewqfz/R1f4A2mMtTY/f2uOk2u9x
lIvEEagw0DduoviWpUdd8GCytxrr57SeQ08ZQH9xyMSE8mRx38lC+sWZ0SzNudNPQXHmn59ai3m7
3oDCxOnclcCc180m25pmB30vRe06M3pWa80XHQWk9mJy1wTpfu508fw0Nr7Lt+Qnymqbv727n4fE
Eagw0Ddu3vuWbS14DtHfg75dPvH7RmWjSZ/xLasJ2unPQOIIVBjoGzdvvgWyeZ/z7VshcQQqDPSN
m71vr7J56Ft00DdumG/HslH8K7aXRCyBCgN948YF5TmO7/mHBn3jhrVvObI9Tto6F8YmjkCFgb5x
Exy/qQ3nLQmP36KCvnHzen5aHhyS0LeooG/cHF1/09srPwl9iwr6xs0v13tlc+Khb9FB37h5fz+L
njugb1FB37j56/16tfwN+/pbkDgCFQb6xk2U55F+KiSOQIWBvnGDvgkAfeMGfRMA+sYN+iYA9I0b
9E0A6Bs36JsA0Ddu0DcBoG/coG8C+B+hj/M9St8TRvSNExJHoML4X7Gbe/yeMKJvnJA4AhXGWuTT
fLvvuoGNvnFC4ghUGEKP3xz07YdD4ghUGOgbN+ibANA3bi7Rt/cDTpA4AhUG+sbNJfrmTO9Sx8sk
jkCFgb5xc5G+0XIfK0fiCFQY6Bs3l+qbd6QciSNQYaBv3Fywb95BORJHoMJA37hxwRR6MyYOfvl1
NlWOxBGoMNA3blyw4viaL2X23QVA37hxoS7yZkws7I53YN1JkzgCFQb6xs1lH795s1sFj98Egb6d
wdmXffccTCJI4ghUGOgbN5fr2/LuMIYriSNQYaBv3ETyTQ0ZnV77cOR6NRHlu0JwaLmHlbenEkkc
gQoDfeMmim/q8two5PdJjhHKT05O+Rkceo7wy4bjCFQY6Bs3UXzrbc855elx+lZ515SSOAIVBvrG
TQTfbvrMqWYwqXjm0e4XIc2mjyFq2+ul7eajfSephBHM+XdvkxRI9Zd+GUBp2fdPFkiNYa8oPFAk
jkCFgb5xE2F+Z0d9801d14zaTvNn1PL0vHedsN1qadFQTPP6canSVGnazVlLuTsuXbkm9PpGc2cB
sfPXS+HCkTgCFQb6xg23b9K4fNRnqhUA2TX2vvn96R1Ai00CXlhnWI7Cih7Q19I7HaA68+f/e7FU
j55SNgaiA0XiCFQY6Bs33L5ZY8OY3r8ep1cH88X2F9+oi2zav/QqmELSnxYVCmxi07RnsDkrW5bh
OY6zEv5rTRJHoMJA37jh9u2ZqrJdtfdLV6uyCq6RW8M73zTnNshRmdKXkuHJAMVVZksbu46VZX8U
4T+vJHEEKgz0jZtI19+YU1mdvWtOAMqeoXkpuGa+pfe+KZODkeq2AMlNatEEqdeFxQ1oriUtG/6S
YEgcgQoDfeMmsm+2f1VDX0zHz+MqdDfzwVKHoXcV+GZ6bMxpP0tlNVrVIL2YOUMV8suJ82JBYTFb
jIRP7UbiCFQY6Bs3n72fJemq/1cN7Dk1Z6qs+9fJdC3IL8PbklhIHIEKA33j5hLvn76HxBGoMNA3
btA3AaBv3KBvAkDfuEHfBIC+cYO+CQB94wZ9EwD6xs0/gm/P04/4T/c/zq77tw8//SH/JHJv0LfL
J6QOpfs4C8IB+nb5hNRhcSvqMXdBoG+XT0gddr1GnCX5GPTt8jlfh9Lqp41mj75dPufrsEhjUIq1
LB+Bvl0+5+uwS2Mg/IHj3wJ9u3zO1qHEHp9iz7z/HNC3y+dsHRb9IPyoSyLo2+Vztg67fhBWcrzF
CQV9u3zO1aHfnVKqMZcnDPTt8jlXh8V9FMYxlycM9O3yOVeH3UMYcjEXKAT07fI5U4eH7tTzhP9m
7POgb5fPmTosvobhB91ERd8unzN12H2Lw8+5iYq+XT6n6/CtO/1JU4Kjb5fP6TrMB4Odb/1Bz/Ox
F+oM6NvlE1KH31a950DfLh/0jQP0TRjoGwfomzDQNw7QN2Ggbxygb8JA3zhA34SBvnGAvgkDfeMA
fRMG+sYB+iYM9I0D9E0Y6BsH6Jsw0DcO0DdhoG8coG/CQN84QN+Egb5xgL4JA33jAH0TBvrGAfom
DPSNA/RNGOgbB+ibMNA3DtA3YaBvHKBvwkDfOEDfhIG+cYC+CQN94wB9Ewb6xgH6Jgz0jQP0TRjo
GwfomzA+9u2601Rf0+o6XFmUw8QMv6w5jVn+7UIeF6hgMlLRPy29Dix2ZUT86B/sW4uNIHN6lVIH
8PSPNuAYvy5+5Ft7ckPmr6NG008T27Ie3Z7EFtX1ue2+Yac/KhIvfoFuCCEvu0L0T4+MwztiRfzo
H+zbuGkYxulVhvMFvqU2tAnrZ48+7deWtjLZou7RF0nXjrabDEqg6HtHFXHjeR3KKo2ab4mangj+
sH+AhK7QV1lXj5MSr0VnafDmmxqUUdI/GlLxD/Ztk/T/WLr/J2ORhgrGFa35eoKsLfAK9w95yLIu
Lwiq2uyaEkg3XdYpJhqPBRp2+bZbP4T4I99u+omKwRbMIG3vG9z7U8+MPSdZcCaLF4WteRgp6nAx
WaSB9J3ZOhjHq/wobN8PZa1NJWq64e/eaDba1kAZOONlGlquva5AcTleEkl6mY9WBbCW9sofMbG9
cyuaTUuXYXtQobkf3JFbAXM0n9AthPLn+pbZEmeYo6H3KzO3bpjDEViENW7KPW1zvFmttdOZb7MJ
y6G6HXP8KNlDs+Nq0uzZHG0NaTQwHw9d5Ee+WZP507IHkNeCtINvpt+p0/ZNcmog9bt0DdUNuk8A
jTGQsQyPz/4nHq+E7fy+rPK6SF8M/z+m3geoLuBuKMF9r7DWoLRS1iWQJ7eFJf1nacEuDbnBoejd
ZwnqC7oHTLfqIgG5jWpudLheh3wr/Mm+lZxyqrXW9kvFKjVwt/ct6E/pgfyYNUXVpZ+p+UK7xHZp
Se3qt8q0a0tsjbJD+5nxTbCJD32jDWrCfZ237a++Zbd0ayUXnNGOfuOqbZoNL8HymMGGF4qwnd+X
9XZ2lCbnKsSBId0bCe6Y4VJpTc8n+v3kpn9D+4LptJl5LfrKoB/wMmS8qwA8v9B8q4o52h8WhPDn
+uYzNw/vrh9fXO8X33R6gE5XG+vgkCuQo0lbAWi8WLTxgalhrW3bdjvBFj7yrclW9+5e0w6+PfiN
Bq0og8XJ2ILTs+kmvS7ryY98Swu8hLEv66j+llRcjTptB2Z+RB4Ie62uWBFMSLUm3j0k6sOtLe+L
7jH1vDyZd2mPPLRZviwrJvp2jjTTaHy7X2rOq9nMKd/S6/1FiC6bACvbGNLXVq/BtJsZzaFO2V/J
+Mi34pI2X9Pr17TX8wV/4hlaUapHW5HbCV2jbw2Y0YZGu4M332rNM1v/BEFZld3RCe+Y/idUHP8f
ovBUo7spj0sb2tOWyln2X+claEESa2Nf9BktdJq1vtLUgjb772sm0bcw6jMJ0ps0BGdWNg1zw4Pb
KcDdsW+aczgArtJ/5MIqu02CNK3laEec2Rl52kVK471CH/km2cSwHBmegy51fz2ks78eongNtTsu
XbtVtqbhKFX3ujh6OvLtReB8IUFZ8xv2XrP9Bvx5kC7PNrQ5r5YmTdW1jKcXGA6K1U0xvbkxumPJ
aRu1jX9oMe5maOlK4y4rXX6bTa8bxqMjo29hKPb0acWusxlsyVyTQc9TNXc8HDqg76Zy4Ft3Q3tM
v0Kk/vSJnoS13Kf5QIZ792lG/9nZnyHn+QIorWGHtmDt4IpXO+1fAHu93muStFQfMBnpGumhBOXn
QVOCG3qSUPBbtp7AnQ8KlGmz9yrxWzntYdjWuxpt3Aa0ZdUfhi0FlObLU5G1d8N7lSbZ3eAALk+u
WOlug9LV6pDpDNuaX0yVhH/xn+sbPSctsysi+6tbKSMFSRkUIyvR1GRBYpecNEVlHeY+S9Zg+ZOG
H/S0kaDZ6cdeWx28n8XBn+ybYNA3DtA3YaBvHKBvwkDfOEDfhIG+cYC+CePzvt2s5n9Jyz6/vtWM
w7vSw5kt6BEn80XfLp/P+7aoJf+SZrw9KvX20I95bjO3EZ8LQt8un2i+JbL5GwWKtbIEebeuZ1XT
gMR1jV1rKdYrMvVNr1X86zD6C0mDXKnlA99yKZqjVmJb0G6v99f+ehFngkPfLp9ovhnLxUQjM2to
S+3Ny5U9GT/qy6f75Q1YU6s/l43NpDV7YTmvFtMbzem3nBbzrT7XoDexRj1q5Ox+6j+6AtJSXFm/
FvRNGBF926mQXykAE/8Glk0P1546APm1TBOgmTA2CdA9/4kQ2p92egDJXcq0mW5lRwbJKRleEhKe
3xMbz+83//myfi3omzAi+kaPzxouIWTR8X2r08O4EV30Mrfe2MoEx2/BM8bUN//BqEnV3HgtAMuh
+RzrKEfLfL/5z5f1a0HfhBHdt+bYoKR936gxDnvA3UhAsjbY5U/7tixts2ANWT79KMdEe7/5z5f1
a0HfhBHdt+IqAdCtHHx7pv1paiiznzgMm7/69vi070+hNZUqjgLSc+kthzZ7v/XfKOvXgr4JI7pv
0JvRUwP14FvKfWo592AtWp3Vcev1sLhNLp9bTpudL8hzSxpOrZeZ8pbDvBdY1q8FfRNGxOsh/hWM
YrMq05OEBGRZj5ioNtizSsXGjRasN/zLHcp1ka2iCVqWPboCUvmuIh/lKEX+nSD6dvng/SwO0Ddh
oG8coG/CQN84QN+Egb5xgL4JA33jAH0Txpf5ZrzePTj7fEhU0LfL58t843geKSro2+UT0bdc5+Ux
A5DuDO4USFiDB5361Hsq+EktFRKtQcf/JZgxta8g8zhoysw3qZEH9X7QVkE3y71u9i/b/d2yfi3o
mzCi+ZbZmEbHBX3dKL48S1NitB25NSldL4vyqmY8D2HQNZpr9nxIdtQv5De14mBIfZN6PUmed4z7
uWysB6VHVxJd1q8FfRNGRN+uADRPtXr0T91g2jT1LW3ParbqXUlKFmb3CuR9m2h/+nwPIG/y5ojq
BjfsobeJaWxlkD4epS5qWb8W9E0YEfvT2/5s4en7IZL81brnOI7rQHOzfi5Aabm1gxMFmmfK3o1M
01v32EBLNN/m+HkkkWX9WtA3YUTzrb4oa5qns1FwpHKVtVhGzgueDpcko7NNSJBpbPyxcqhvQzau
zqJizrRVBe6CkR3QN/SNfxXp0L7T068XClSWSdqTJjepRZOmDzIbjfa0mlsGaeYPhUNacDeWwdiq
tB28XqmFdRo0t4K+oW/8qwrrwYisctB12VilN2t7VYfcYjKdp6Dj2ssWVNej+Yvf4DW2j3LPGdGW
jfW7gx4017bbxfYNfYuySskF48apOdlfYoOaShn/ySI1n/CT9H1WjebUcvLbZxM5FX4L9O3ywftZ
HKBvwkDfOEDfhIG+cYC+CQN94wB9Ewb6xgH6Jgz0jQP0TRjoGwfomzDQNw7QN2Ggbxygb8JA3zhA
34SBvnGAvgkDfeMAfRMG+sYB+iYM9I0D9E0Y6BsH6Jsw0DcO0DdhoG8coG/CQN84QN9EkGOT8m49
Npu9bZ+Yhhl9O4C+iUDeHO3siV+8o28H0DchPL3trHViNfp2AH0TwtXrvu5OTYXwg3wr20d9/1+n
iftq0DchvHWovVOrf5Bv6vatXhbxfz36JobXDtU4tfYH+QbkrV5a8X87+iaGQ4d6eqaXn+Rb7q1e
Pjl43O+Avonh0KHWTq79Sb7B5FAt39Cdom+iCDrUjXJy5Y/yzTxUyzd0p+ibKIIOtXN65Y/yTV7t
q+UbulP0TRRBh5o5vfJH+QbtoFa+oztF34TBOtRzVv0s3/SgVr6jO0XfhME61MqZdT/LNxj4tfId
3Sn6Jgzaof7XucHCf5hvZVYp39Kdom/ieDp569Tnh/lGy/NN3Sn6Jo6rk7dOfX6abw3vm7pT9E0c
Mjm76qf5pm6/qTtF3wRy+lovo26ZZ9d9C+SbulP07c8k903dKfrGS2fxzfwtQmH/9cOtbb60rH8/
WzL0jRMSR6DCiHLAtfl4c1/K5mzJ0DdOSByBCgN94wZ9EwD6xg36JgD0jRv0TQDoGzfomwDQN27Q
NwGgb9zw+1Zylquzd73PkK+eSLzKgHX+/tIe88Mcb5A4AhUG+sYNt2/KughJ99xTZGcgpwS1DfTt
+7gU39IP9OXJAtNgS4l6uZuRaqSTpia2iHmVTTC16jooTdJOAhiPpArG1L5iuZUG6dI3VoJ6lL1y
iGE91YilQN2i+NuDKulk2Ke6bNrka3Jfo76VHrtlnqKROAIVBvrGTaTjt4Rbhgf/9ra+GbfTT6NS
bZWG8ZNBVqbu0WTHkOx+8c5Vc26lPK9lR/0Cyz1+Kt5uDX/CY9sszO+z1q5dmXShYpr3O4Pl6EzK
9XWq6pqVuQW3TqW2IlB1q5U5z810EkegwkDfuInimzJ6HRFBp+6ktrS9enjMryWQlgffiksJYNC8
XtD16X1/KjdkJtreN78/HQCU53SVtrjxt7yl7eRtjtmV2yoObdXuCTgVdtDIUS4SR6DCQN+4ieCb
Num9PpTN7LraOY6zstnE7dA/+NbY0sQ1Ufre/F47HL9lOsPl9hffaG/J5nhXxvevm6N4KfbCXGbH
b97ScZYeR8FIHIEKA33jht+3tNt++w0AE6S00ilaZUqXX8ykpzDfbqcskU3qfm2P9r4lN82svG/f
Rse+Sf3eYXN002l9m6WNoadv6ZHcDYFdiW2Ko2QkjkCFgb5xw39+6jT9v1qCvTLflE2JitZWqSVJ
2nrtCpDZGSkqizS7rb/Q9m++981YSaCtm7Au+RntysG3zujwHKRTBWl606fJtwt4oY3eC4EhPUOp
TzmKRuIIVBjoGzfcvt342S2wfYX8DrCyGs4nKlTWw7ljwsPanswMqK1fnBc5MZu+rK6gsWW/apdn
k+eJ/QB3W3tGm7nOphH4lvRWtPNts+0V3OG8L2mzqb0sQGoxmo8IpObT4apwoijvh0YjcQQqDPSN
G27fEqxz0xP79k3S2atS8B9FTRgK1QhSeUmT2VKaJWYLrO1K+r9TkXI5SaHv9Lys0lRdTdAOV05K
+r7vpcj54FN51mdL+ZRCk6VsXj5VFGd6lzpeJnEEKgz0jRtB97PsOH8E4NByHytH4ghUGOgbN4J8
a57q974KJyj6q3IkjkCFgb5xc4n3653X0gfKkTgCFQb6xo0Lpn1pbI93gCpH4ghUGOgbNy5YcXzN
lzL77gKgb9y4UHcujd3xDqw7aRJHoMJA37i57OM3b3ar4PFbJNC3yDj7su+eg7NiEkegwkDfuLlc
35Z3hzGPSByBCgN94+ZSfRtW3h4eIHEEKgz0jZuL9G3dSR8vkzgCFQb6xs0l+lZ5N7oWiSNQYaBv
3Fyib+8hcQQqDPSNG/RNAOgbN+ibANA3btA3AaBv3KBvAkDfuEHfBIC+cYO+CQB94+avvkm5T1T5
t0LiCFQY6Bs3733TLPdnzX/BAYkjUGGgb9z86pvR252fufHHQuIIVBjoGzdHvim14EFZ9C0q6Bs3
r75lOodIoG9RQd+4CXyTKvZbEvoWFfSNG+YbPUc4Tlp/9++vovLPcQQqDPSNGxcUsvs4249m9N0F
QN+4oe2bfPX0SxC23/37q6j8SxyBCgN94yY4fvtFOTx+iwr6xs3r+embcuhbVNA3bo6v9+6VQ9+i
gr5x8+5+FlPujG/StXUtnV4Fsgzmh7MSXxkf5fgkJI5AhYG+cfPX+/Xymfv1ZFIb9s8U1dE5RoA7
OfmHCEgcgQoDfeOG+3mk5CYBsvc2lKmkJ95Wesy3YMzLI3R/dMpgQEzQJd83LQHCIXEEKgz0jZtI
z79ldon9+L1w5zob4o9pT2Ubecu83V+6i5RON7n0/GEWrtzZugbpqbvqKVBwnMXIgvRsvuqe65Q/
DYkjUGGgb9xE8E3qbW4Bsjp7n95ooG2ze9/89m2kQJ/NeQS9Z/aqboo0lz6zQBo8wsKE1NqCRRPk
4V2E2uGCxBGoMNA3biL4Jhu19duxnZq/WRvHvlEX/WnY2iO/G72asUwpjy4UV5ktbdS6VsYrGkZ7
HKF2uCBxBCoM9I2baM+Tk8f9G2XoDqzVL76ZgW+1RTCMjD/tDBTYuPlpz1jSP5ZlbAmlHekreUoV
R6DCQN+44fYtO2E129kv1WcSSBsjvaPq/eLb1Wo/tIfBttwtsjOM6lz1VIC+lfSoi/lShNrhgsQR
qDDQN264fZOddup2nYGmP8PkzTKbJltD2TZyva0O2zst8C27aZmmfylOmnVSdTdBRjnDqcHzIHOz
tWAw9JcEQ+IIVBjoGzf8/Wny0e7Rw7fAN6llD8r1IhQHL5W2CjfDPBsR/+qmwDpM4mfRHu2nFEh3
9kuVNoL39mP1ChS6dBOhcvggcQQqDPSNG/w9oADQN27QNwH8Y/j233F8/X/+fnV/O89xBCqMf49Q
2P/75rL+75dVA4IgCIIgCBIv/w9bECS4ZW5kc3RyZWFtCmVuZG9iago0IDAgb2JqCjw8IC9GaWx0
ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMTE3OTYgPj4Kc3RyZWFtCniclX1bz105jt27f4WfA/Ru
XSkJCAKkprvneYICkvdBZoJgOsFM/j+QtbiPfTapI/qrKrTbZevboiiK5BIvyt8T/v1Txi9jle//
/Pdv//7tGl3/9P7/P73+PH/nv//tH7/fv/mPf/32539M3//1/31L33Pq8n1muX/zH//z279848/r
n9RR5o8/+jgu5170D5ek988mznT/BjP99vu3P/8NQ9sl+s/6/vu/fMs/SF/4YJbx/fe/f/vPKZV/
+C/ff//f77/NKV1p5IXFPEb17EfNq5SaZn2OStWNyuUqq6e+nqNac6NKulqTLBJ+q7Sr55lbMXSJ
G1XzNZsUDHjOuI1aVx6tLvOtNt2oNq5aek8p5ETvVxsiaYZrlHpJGSObNfbuR82rg6eSzbf8Do18
DWk9m1G9+FHrWrlLniFXZ73WHH01M+Pf/KhxlVbBsZCuhX1cay476q9+1LhmmcnS5XlfUr/WWLn0
iPqSIavgQ7KcGH5UuzJkdViZ+M2NKpDV0fLs0RpL6VevqdYWSWGp5Zp9Niv36W9+lFyrplbjNbZ8
4ZS2bKXwv7pRPV99ijjqPVf7ukYdw8r9NiNkdSYogBpyVbCPE7JoR3l+jX6VtGY1u939jJDCKmnF
cl+mXIIJi0RnuyxIdOtgSHQeayoX5oNIR3JfIYUVn6orHjUvHP+RQk7UDImuAtGPeF+hCxO+NUON
Wcu8cl84HpEU1grNNGeqIxzVIKsZ2td+y0lO7elaAttkrUJyoyA5eQj0WiSFFfqrlpFbzAlITsUS
rV71Ulih5drISVZ0tiv0l5SSnb73XF39GqNio8IZ14KF6WWEp7YlSGEeOOLRt1oa0L4rW4vsqW9Z
rowP5hVxtcE+lpVbC892g+Rgl5qVVX+GoJIugfGwsuotTGvQE62IPWnePsJOXWtB6bRwlCSssc01
wjXCPhb4PSWF1ENyBAqzhfvYIDkCjZNCfd9muVYvZaSQEytfGUbBWr5tjZCc0sGP0M/pkJxapDlr
5TwFGD3IPY5aivjVM9ZYJsQw4kQv9RopifXlvIXpFfI12xo1nBHapKkqD0dBm3SQZSXa86v3CWs1
ayzRXai/EhR6yK9B/QXn0crENqpTolMLPatOn2nVLC3k14K/Cql3VtTJqiScDtAxQm9I1M+R4fyc
7kc1WBja94hfAplIadUa+qvwVa8sOFrh2RboiQpAMq0VdfIl0BNwyUeK6YK3DRkT67l7dAJlA1sr
YjXTNiP9HDDfaqbqZ5SFGWu1MpHdbsuA5w4ZsJaveH7Rg5lpWo+v+t2GbwKXvFlve+MEPOSCo9Zb
pJlwYmHdsUHrg3z99fdfYMCRPhnfX/6YHut5BDkJjjbd8WFGeTABowfDV7oZtUEhQsc5lh7reToY
Ch3rSuocn+mC0esYpJBjnoQmwx2H/1+KWaN342CkLngbVUXr5yjv2sO3gTnL1X7LcTmfuAzDe5Vc
q117yuanyx/76R2QJjgCrVnObfBQGtV5nZYnftQoVOdNzd95Rwf2XWZWZ3qexDrPdI0CN8Xs1QZu
57yAWquVx21GHLfRocXKhxmjXYCZ/gFVoQ/yysE+HM/K4ac9CIQBSLNlGdE+EA4Ty7ca7QN2/ao8
WSniSsmQTSIMiTiMY3DBoQG7zCgPAivOXwa+S9EpLRXnT0qye7oBtwbji/OeazhjWzDkWMMMZ4Tr
kHH8Zo5OfBG54Gk1u8Zth+A6VJwBaeEODZyUNG9jcpTugjMgQj/XrNGZVdgauDTY7hLyi8ak0d5H
2hbuMmGU06MbvIPm7j0nR72HPtDJAxvUZrRGBbrwkSz1fo0VcAWC06q1KM6JgnHGDkGEV8R77M5F
M55XpPEqNHeb2MYSzgjtCXw0pIffgvYcs88ZcwLaE8on9RpyAtoTmgq42YzyMB1wpeNspBydDnjL
sHQwOznkF+GwANXYHfJgnkB34NfQjkDmL4hNmj1ao0LYQRXwHJXdjK1kurmzt4irBLoQruUshJ8R
ktOk5ZzDGeu4IBfD+SIeKjaALWhoJ/cepkMzwUefI0eaqfVxjTzXaiFdADV9LbG20u9Qg86ZNB4p
5NfADgnmDc92m9CF0Dkr9JHgucJrkFlypHMAEnndsqxMbCAw8bqlZSsTOxzmdYvcFzxHKex5AJKN
bGV1B7qFvhsDKOEoXrdAcGo4I+HwKsXpL3dqOyQHUl/tefRX4h3e4oIvP0MN0Dt2aIjk8Gx3+nVt
diuF6Tc/qgNirGIlepuRfl2HgamR3Hd6bJDC2J/o9Nj6Equjd9C8rkaHPjzbAgTRV0815AQYRb/M
6y8PKAmaC2yWhDOWeqXRygjtkIJmHN1mz6OH6QDNZQ14FNEZEvpMHdbIaiZ/MdCAWSB1PfS/pENP
YCPtPqYNWjM4AEVhvpU9JzQ44HXOxgkNDqRqpbB6mD7kmgAqDi86+ZKJHcKE9dMaf+mFiwUlfwTo
lnRyEp5A9z1qAylwl4DCCu+TH9/6FP3scF+qGeUBpd7RrTbKc9QeI4VxmbxHNd9yDM2VkYjSu13j
Fv2E8wJ3SQxdG8Si6pJW0wq/BaOXM5ThCKmXTGCit6iPb3mASEjaam+GE1scmDHSkfU2KZhR7/sg
83aN/mLgEUkNdnvSzMooEs644OzB/0qW+g3upavMNXnIzrxXUIjT33tEl4JCWvZwjQUGFIzXSNd5
HzX62eBWGa5uwITRzwGoU8IZGf2E69XCHdLoJ1yvElMP6Ah0CV0fyX3p9SoVWHWEa4QUwgCtmkK6
YECh6YFXDV3+W7w7zC3lGslqgQFd8H3rDOma60ov1z6gi6Dw5dqfZQIoAi40YI7VTMuP6leds6Ye
zYijD06kIlabeMAE+YJBrnNF/IJSuoASeg4lpxa4hPTaS7TbtTK2BuQYno4KA5qrDHe23UmrnVI4
9ArgrJmgk+Cg1bbst/7iQSFvsLM4fb8BTN5gl9Ek5ATka5Y2nER7usbA6UgKTAJOTLglNSsweYzy
YHXxnrvmWJNXAACopTRmpCcarOiYtaQa0dVgRVdt1erVDZgQOgI4tlB/NUgO9E4foe2AQQCQa7LC
NbaWLoF57CPaR5hirHGMmSKuts5MECiTGq4ROietlGILA7qhAfKahq7quQqdwys5ywkf1WiLV19D
xohOLQSeeQZDViSrPQFMwHMvoY7uGWAC/lqv0Rp7VsmZObQKPc+fbu9ZvnDILgY/ncfnIRrgXq1Y
Q47kS6OfU7LVq3tck5IDR2FGUgjC4Vl15w19in7Cr66OXxvcE2YjLDuj1xOMkWYA8lpD6sdkVlzp
oRT2Cd93jZIlXCNs2oBZbjncR17jAzBZn2kDOYykAkQXy/sNFCacodVbyHuBtQLYkxHyXqBzGi9p
zKi8/Kh1AZ+NmF/4CDhRRg61icAbgoM8W6hNMNuFo7wk1CbCK/IhacZ0Qb4KlIW1Q9nhIeEV+VrZ
aoDXRfqvIdpoH0j4GkQrRwCgaRRTEwjfozYopGkUwP/FfGsDctjCmqqy/T3Kg8IKpx3wPzczyqeL
VibgwAKZGTeYoGkUQ2/jHtRvsUim6UAcRjhjZ5pOW72HM1LdYAN5p/L41pagWngU+zC83+Aeky2g
B6fhxBZvHXRolyYjPuja4oFMUE2tGk5s8VaCrw6wUMM1EnyVdjuh5XTIFHyN3taI5AvyCjeuSryP
hXdQA06ooX4HX3B7eQldI1ktBfu4wNUc8Z7gC578sGvc6IKLk4H5pIecaHRomT9kqPff6pBVxVXh
KIHDMaAHwx0qAPdAl6nWkPcA9xDC3GfICbg4uUix/NpjbRNrHBoDPMsqo2itTL2NO9MFFcF4s/RQ
JmrSBGixsrq59pmJQekXMqHpoh3HNjyPTBctCYwwMrHFexpjubmvFFJ/R9G646qnvvH2svdmR3nI
0Xl7CcUeaiaNtY0pVpNvMwrvOOGbhvqegAnmS7NfAn7NfDH5scb7SMBUmtNfPmEJyoYpi8PKxBZZ
JWBqAAqGep+wxHRRaIFmT5pPWMIesuiiDcP7zbUnYBo5uRk3KJQYfZERapMG53jlKdY+7lCoMvoy
pEbnkemihakCEvGr9XXBg05phZyQqtEEWZEUglEaTbD76C1fG9AAVNEz5ARhVRs3yDnKKrzUCwhN
ZkwXrNWApOZQCuHmMWVxWD2xgRxA7UWEKRFdjLUl+IVdojPEWBv8+mVlYoNCpcPPYWJmxNVOn6kB
H4fypeALBreaUdV/C5ppQauVmC54Q1Dc2Z7HDZgwiqZsDbnKcp3aW7KWz88IyZEJoxBzAjqny8hW
vrZ4IqNoqxd7hrY1MvOo3VlbZ64SMAFpV+s9bimLAExz1VVSNKMmlTZIWbhGRtEWgGO3cu8BU4UG
6HU479HPWNcFo73SCGekBzN7L+Fua1JprmI5sUW+OrztySuMkKt36mkXs491A0zM00jzI1d/DZjm
J5XwNcDUTurZxLTaSQANYApGQUxxXrv51garijBRqKn5f49ybonW6sldSfEYtQGmcVUKczN0eZjA
vPPRNFHxMcpDDgKmmjRR6DGjXyOjVX0OsfzyAFNgqNK6DXs7CU0evFXNs2cz4waYeKtaZ5FwRrgl
goNRW7hGKhKc7VnDNcK45Lk0bedMvQImwZ7bGX2FWpoXs2tXiWQChgVqsN4q9SircLuuAfRr6dpS
3wogLfxLK4U7FCJgKvctzvtbPtYG5zivOpqha6t2Yw57gSf0abd/mfarNXyE80YKvpr2+/mnt3VQ
PbVfSQcrAJmUtAx/N+g01E0uxc7oodPgCaj+ZG61fUw1oRcWzrh4O5zEaR8vaUtle/Q/uguvtF/W
Bq5aR+7BPhy17OunpbfoLBMEJvVDorPMVMoMr6BaOd/gnab9TsmRnFechjrWdLvl405V61uX3a0t
TgdXHkYoWd23g8ABU9hSmeEaYVbhtmWn+zxUZCpllzIsXT5OB4dsVbmdlaOsvRIuk9shH6e7Ey7z
WCG/mEoJ45RKyImVeeqKlJCu1SET0EWh1WRlIZjVe4pOCkEgiLpvsI8y0SBf0Gle93kQWDTtd/QZ
0kWoCOs0Q20ANEa517Tys0QDCmu6ewk19w0Vp6aVn3fohoqr5BzyS8bPuu6AelYWThiemK5BF7De
2S5HmWiTsVv6uSFXF6+6pCfL1b/6UdSxbHsQcbUnjcqOFupYiBYrrO5Lv6NnwFRKGJG1Qk68YmvL
SY6HnZVXEXPlkBO9MnabUgu1XG/UhfBIQi3XITnwpO7gwPlb0Ez9ldp85r3WH/Zacgp5P1jF36o9
ad5/0NhaLa2H/hZja4A+zfHLj4Kt/HkFd+YEbOXPK7ijZtLYmsBGW8nxYCvxKqL2FHKVgHLl3kQi
mdC0zDla7OsSUAIx9xbqaAWUk9Xr4YysZZTsdOEepwPshJG0CMLLqtYyzqbdPs4njYASGGlWS71P
BO2wabBoVmN6ycEO8ook2x3aqNc4HTzxFXKCpSzSkrUwe1pmAWju2VqYDabTYxMpFnvuFY8NiGve
MeXjPg56VhNO+IrkfsDyZRJfPoz6dV1k/sTAr0Hrc7uZZyzy3LDlCa3P7WaeschjSfedLlpqNnRt
0TzWReJQSwnpYl0k5tNb1HOLGBwMVhllM2oDlE+Y/i65/WpFnfqI56LVAp9H/9k3p+bTBVeGPiqQ
POLS96i90BQokaH38Ry1M3QRL2ug5TFq7az64SkFM8JGAYJoqDWYEdph5pmIhN+jPpVxjlY1MPUe
VTxdYzBnlg2onnRtoVYgtZy0X8iDLi80LBQZWa+SH6O2O4HFEhDNXnmM8jXMh30tdPO3RX/prFb4
/i9x8CeHN+Udnnp+jtrzBiobPug9/2PUJjS8yYSjN56j9qTtzoYPes//HrVdcNXKhg8KbR4z+mud
x1l9jNpOIWuYcVSbmdFzgjXM9GLNjB4KZlalMDA6zagtbyAzLXWVFvKLl2WYr+aQX3pZtrRq4PEt
PyPv0xtUSw9nnGwCgsNdzSgv8guGp4067A75qytW8q6p0bnHKC/yzAiYzC+I1qgZAR1T2m/5ODir
UibvtyNZLXR/cHakhtRDKcGTSiOmXqtvlyYOB3T1wQqXNnu4RiZaw/Lbb21XfWzSUJLepwff0vv0
0u15/G0bNXGGIGEx9ay+TbmmFEmOtpnqRVvIneVer6IqzLU9HVuitTBlM9sd2q55stY9Frvb2xUI
/API60rhGeKVUZE2LfVbAjivjKpoMub5dGB5vHhMeUTyVevkFUhuoXwBUdJTalbuf/OXLky0TivZ
ffQ5QfCsoZlyEgk5AfgG+5OK1SZbJS9B8dJa/gf1WyUvvC6B+grPNtOxZy3FSaHnxOR1uXRp0dnG
qWbUUGZMPSt5C0633e0tHZuXLnmNEc2oV0ZYoj0d+8USL116khyd7VZ4XS4aOAi+VXmxzaqmiF+t
FbhepdXQwrTOhObae2g7gL+1tcqM18ga3S7SQh3NdOw573rygC7W6Na7nvx8trUZFWTCrtFrEyZt
l9Y0yhrMCM1UV9cWOecZ2YyqDIDe0IPhxVKFm+Oo9xc4kJy2lratPPOezagEglND34QXSwOqcIW2
owPSw2fX4o7z6eDFkpaTl+hswxirNkmh7ejQTNQTNZQcNrZiaoTVJj5Fn+nYaWbtC/Ae5fN4+iCY
wNfsPvrrJ+ZHprF+wVX4ORg0V+hPCMN9UAA5tMgCPxpadTm/0F81pMkL6FVDyREGBYsksfrLXcTx
Mmj2lp0u3PIGCi+ga07RbgvDfdC9tUa7zWse6IneY04wMNfxa8wJZhfA8o0V8l5gYQY74EVyL8yP
1EYw4YxD2FhUYi8NSpCVzxJ7acIsSrh9Dnf4q6yVwa+8auhP8DIIQFuDj2eZ4GXQhP9icdrLKnzh
mqd+WPTXoOM4KRJt7ye5qVM1Tmx/Xga9R20gR5tkpdvMnr+lV0YlDUPXx/R1nFg1s+cZqXihndVs
jNNGP/srP0YF/ZUD6huMS5Oqrv2ZrseVUbBGdmGG5Kg5G6djfXdhvtvJBDPKACdKr2aHNoD5qB1+
jNoAJnsFttHNPm7XCUxMh9fRZ8R7zbMA+hIrhVtDqcrGATfwfY9afhRbdPTbBB05oWCVKRQj4n3J
bNExb1h1nlGTv1K2nNhmZM7GKtrj9yw5mrMhLacScZU5GwDSJa1oh0pjQYbUPEK6mOReZ1lmt7d6
Xya5z9Wypd4DTGGpxdDITEAX1bNMESv3HmBq7fC6zdnPUfkvX9Nn2tRwW/SvtSevcQBNth/7p2//
/o0tTzr41ZhN8fdvBOY//uvf7v9ih4l/e417/v7nqP/17b//p+//B9+CC/6ak615+/efP/7Pf//R
Tf/P/yN9/8v/xcz/dOzE/xr5a9UuK/3wxYJbwfeo6FbwMSq4FXyPim4F36O2ezXmz8I8U3EEM7Lm
iGm9Zo3bLRd71UDbUnE8ZtxqjtirpmgJ2uNbWwodUyzmmoYTuzoGGuspLcOJrdmGNsXPJfWQX+xV
M2AozA5tt6iP7oKPGb2Re3QXDHj/6C74GOUl59Hu/szVZ3+/8xp5XV7gOrhvbdVEDIGDqy2S1cLi
xQ6ulmgfNdGOiZyWqx8aPgC9tiEh9aw5oqyG/NJEu0EJC+liS1nCeCM5PnW00KdurbbwdDDZbbzq
JQLq2dFG4NPkkC6mxJXaneRs9UuTvB8lnpGBllLFSfSHlDh2JktmtzcTzXtIwOUyIt4zdW0CsdnT
sdcvCe+AZwvPkKauQWBHSL3eQ8KBtbL6MXWtNW0rH8zIdvdwYMeMNICmrsHpTKGeYMOHsUYrMV2Q
r6kFmBHvNXUNBzyNkBNMShtwUFM4I5wCyH5fOdxHaDnwv/fQWukNI+zgaNHp4A2jZGDO0FoBqlwC
0bF2aGsUALQPwzFnqE20VyD+OklEl3YBfCU8nHW0NnxIaQwjOb9tVU5w7jr+foV0AdSM2VMNZUKb
4uNbTvtu9Uu8hZjaRiNYI5viM2hmZGK77xPeQowqPdJMbaRLI63Wbm+t8yerwsSdNE8XewXCU7cn
zd+/6z0kw2ahNnl1FNTWPY8Zt3tIBp3HLCWSLzaPEIhh69Hp0OYRLa3Yn9DmEblM5zP52zeWMEh1
fs5ev5RpH1ez8uV73929AksNvcfeGDLPVUrIL1Zzw3jPeI3Cpxlac/zaaqEYkyl9pJAuFidACFeN
zqO2heitjlCi2RZCZmkrlEJWOc1axXlDW1JaYalAqaFnxdQ1JlDH1L86Ck5H/YdaKIDh5b61dRRk
e4+Vs4SjtE57kwmf/MXY7RB91CP4lhYnjF6sRPvKJPpMYEULJfquckqSQxQgWkYgw1qYjS4tIxgz
tjAytGPl7KHvK1psABBgfZMtdY2JsNBN+YN8faGj4Cc390t3hyOfFO/zVvAxamudL8wr1Cz496j9
vo8XqCwUMqM+ZDTNKdqK+jHj1hSfqmt0bs57lC+NY0fBnJYWq79HbRCNt4Iza7bme5QPaCjA7ECh
5lv+Nok1WqksNf+PNXrq2XcQ1CbDrz3tBKLVAYgsv7b7PhhjbBEFMFjjYGga4L6GO6RqsKsAPuja
AGa6mJDR4jXqOyMrOcnZ7g6hBnEyLF0bfOGra5OJvmZGDzn4nlodlY0Cgm89OgoG33p0FHx8y6ed
VL2b1oqeM+9LHRd7VdUU8YsdBWflpaaZcbs71HTGmUPJ0TbzDfskIV2iDzJMGeEODX2QYVmu7h0F
Jxwh0ebEwRoJHedM9jxua2Rubr1fnzrLqkLHdb8+dT4d2vpipCU9kgmtesJCl/2Wr7xhogtrdlvE
L7gkl8aJR8SJCgcNtqWmGdL16Ch45sSzo+BZop8dBc8ywffUSpraWOFsFWpnVYrMFOp7TU6ZQ8H9
WZNrr8C6NKv7LNFsfQERzLEmhyxrAmGsTdj6okLVrRnyi60vhP0voxlbYjofDpEZtUE0AkwoCnse
t8obdhRsubnzuAFMpvOV7s6jp4sAE/5sDvnVoL+qFvIZK/qpzTx7bVht4mFVY4Xe1Jb1wYzQX/DO
tJ/YeYcIQ/lopNP3G1jV7oSzlXBGYY/MNFMNufrqTljsDvkkIzbbYPebHJ0OraCCQzFCTa4VVLKK
1TkbkEtsFpRaCS1f56u3cE2a1XIeyGU2CyoiM+JE53u2o44VSjShI47jyqGFYaLLYnK6RLv9rKA6
7/azgiqYkVFZGA8x/PJemtZZtb5KqFehUS84mMlydYOO7Ps82P8+pIvBgrbEapMNYDJ2O4Z2Vw1k
YvLijm2FQ7om/FX4vi20fEytgZ/JAQEnmFpTs3jvcet0yIu7sbpEkiNMIV4YG/JLwSoNTCgT2rij
4afDfdTUGiBa54n6NB1WUEEBxHZIwepI1WrMjxVUcEdXzAnC0E0mPrWszyV3qwt9J00ZvLgr2eKh
bUbCULhEJdSrfDOupeK87b2CiulDtSV7OrYKqsWHAPTFzjNdg/4XXKIeWiutoEp3I8OHtfoiPB7W
UfxD8LiejuKzOcl71F4b9W64//jWVhv1brj/HrXHXxuLP2+z8XOUb+4JQHgJb14M9VsPQziOHdLM
yNdj1Kf4K3xy3cIzXTD/g3lBLeQXW5iwej2H/GLzWMhDXiG/CHxhFcoI6SLwLaxMMzNu3+IDrlOr
RR4zbi1MYECZFGhlwsP2xVzLpI8pnteowBcWOZWI+sLS1VI1nvj4lgdfLEqF0ZhGvvaqDJVCbd5/
pl5fToNFzjP8FiHtLNpXKaCekJbFLiviPZvk05+1/Nqb5MPojZEtvzZQSEgLxWXXuCe6LGY+1tpD
TrDs7JXDEKxx8kGH1Ry/NuALw96zlogG1ENyEh+tMmv0hkqb5FfAnBFRr+3vmfuUIinU9ve1zFEj
fvFNNFjstUJOEKzi0C7Lr61+oBIADH3h50G9h2h8/HtU7Zt65ioh7YKwWuo/NfJIS5rV5DvwJQCY
2kLhMePWyIMvpy0nhftD4oXRvbzC83g38mCf+Ugm7kYeq9mTtjU+WZ2toTST5kw9o6EwoveF4pv6
D2A1VTaaidao0dAFYLIirrbCFkzlvpI7ckLrLbTXSjhjZTfaLHWGa2T7e6i6afnlY5Nw4wDHW5rh
jJ2ZIVmbXAQzSrrYvqaNcI0AABVyM0J93yA5dRbto/cYtcHQQa6uFOpodnPsK2vP2vMZaoAJcERT
aSEn2M0RjoBb41ZvQT3R9VHy8xq1myOOSDVc9a272c0xz8lc6MCDuV9Om9pJ8/EtD4/15bT76ZSA
Lu2TfT+d8h5Vt3qLxAyMPMNT+3o57Rdeh/Z8hCNgd3sD5KxRZQPGUH/py2mtVrdDfkatZMVK7dn2
nTT1RVxpll87DO2XdrOK16gx09VzC6lnzhqT/KzP5GOArN2AhpZQVgXeNuR1ztAv1NoNmTM+tVq7
Aemyp3aL22mrtpmcvt+ab7BV2yo5tI9skj8g9im0ta+X05qEXoe26CjD6ei9dmOwzU3voU17xTll
9JCuO84p1rPy+W8KHZmQGvML0FFYtrCiHRrM+sIWWf314sQXQGH+sJyvgcL+k1XBK2yPUR4mPEHh
z1EbFHqCwvO3ymRvRU0CfHxrS8oFrmcptaV+i3Nmvh+jVRmPURsohACuon2D3qN2UPh+he3xLR9j
Zqn+ukskA7oe76s91hi8rxbwiy+nMVGoh9Q/aiQe3wpqJM4zPmskzjt0v5w29IHl4Fv6ctocJUXU
M87ZtMnVc5R/0JWgEBBGXzoJvsVHtyGF2XD146PbvJqwO+Tjr4SOry5kj1EbdGT3vdaLoX5Pt6XT
nsTu4/buG+QLbs5MKZIvbfHPjKkSyb2m2wIL9RGOenSgDDjBdNuZapOQ99qBstQU834K3N5WnNxv
kdWG09Fvd/woX9opskjP4dnWdNs1b5N9lGg+FzDHynmFM/K5AEybw7Ot6bZ93sDkPWqLhvYLLia8
cjPqU6dIbOOsIfV8LkCbw0by9SPdtrdwjXe6bYt3m50iEzMrR8gJGGN9vzvUE/ro9itpMlgj020p
X1ZWfcsFFrrMpH3PzjOyB+SCf5lnNKNGQ4FCpUWcYDQU7lm21O+l+prCeF/cHa1o0/5HcMDMGvce
kGwrMXqJ6WI0NPFFp+co/7wCo6GNvQF6OCMAAJxHbSLyHrU9r8DnAtLMw+z2/qgA022TNut40OX5
RejI5k1GvrbnFSbv43O1M+4psryPhwtQwh3S8tPWYikkdMyV/Zsi+eqZ1upOhzzTxTgnHwJx53Hr
FMlesaJPJ5+1CeOck+2VSyRfjGCuOZ212iOYbG+UNPk14IRCx6x9rAK6+qCeKPZb3g69Ht3W1wej
UZXe4x1XOfOenpW+uh1JNMv+F8sDQ9+k07Mac1oPZksW1meR4IFZHb1FMBf010z2DO2JtJV9VJPV
5HvZPx9Pypo2fbaiGsFkJWuofTU2CYVZQx9T022HZIsoNhjKHpCpVetP7K+wVfZRbc1aZA++mEgr
zfv3nno+p/3jouBMvT6nfb8YGHyLFaMwRitHZ4jPaecfFwXnHWJB/4+LgqNfeANM9gcJvwWb1jHj
WpF8aXdHOOXWKny1NeD4yMCvAcx56q2RAROGlvg9R21Q6FH1+R61gRzes40+7Le2lM9H1edj1FbP
+e4F9xi1xSYHUyGmXeOWivqMJ85TmbE+nDCzZoUHdPV5DXiP6rS/OeEhLRvmQqEppD3zS+Ti4wp6
P/Omy18B6A1aWrOGdOkNWtFi92BGvUFr2i/q8S0vE1p1AKEPZUIBJjyOtcJReoOWtcrsMWp7dDtd
ArxXjUxstY58dBtQIoWc0Oe0Iec5RZzQ57RHu29C57EIn6CQ7RusrG7xxHcvuDNX9TntBms2wxkf
veAC6h+94IJvQXKgnu/09zP1jCdqJ/KQq+wFBx1de0jXYrxnij2PG8jho9si2qb/fGrhM1Lxapv+
x6itupL1KkvbN0Sj2B0M1jhFa9Tk15FrriH1kBz1JMJ91C5v+NYyo/bntAug9tCH6wNOvF6Hc7Lq
18iHAbABKdTRP16HG5YTG5C7X4db4UnT5NcEJBSeIX1Om9UVdpTvbUa493pi/TwjgVx+PbEejLoj
hd1K9A7k2H2uSizRWjf5IyH6uEZ9Tpu5+xKdNHhTsEOvhOgz9UxY7djHEtKlCavwS0q0j/qc9izT
aqY96siOl7XX8DyybjJDGTpN7veRMUAYZHuGtnjiEk2St2dob+YPN27AJOeIeo0BaiVAxK9OD6ay
81ekozv7Vsy8nGbaYoDaID1ZzbTBl6oN0rPEdPGK/PUMxFm+Oj2Y1zMQZ/liDHC+noEIuKrPad/P
QAR0CePVpSwzyl9NvJ7T1n6dASfu57T1GYj3KH81wSRT+GirG4n2VxMK5AaroiKv9sdD2VZj7u++
ZXbKyCX0mUyS6VGT6+twrOeQSO6Fl98TjnQ8o+ZNlWrP497yn4EaWCMrhb7TmOZNLckrOkPShPXC
xcrEBr4YKcTJtr7vRpemohbtEXyWCa2IXLBsVk/8w9cwjVOhfwQKsdDkNdnWj+wda3uM8jBBUw4A
c6oZtdUnMuWg6HtFj1Fbmua7Tc571B6R4zOAXR2hx6itH9m7LXYwY0sAJqJ56MGMj/rEx6iPlYez
2DXuIAcbDWNWDe99GgqhEMjSKo0H9VtE7t0W+0HXllr5bosd7NCjLfZj1Na9/f1Q9mPUloAJV6Iw
BhBx4oZCs/NgPKjfagrfbbGDGfVGqE8a0GBGvRGCBbX76COFWoA91eg9Rvk41KN59oOuDXxpNZc2
KDnLlzatmTBoVia2F9oSG/+uamTCQ+1nrC3gBJzjkfN0Er3VJwKQS1FXNeA9AFNiDtCKTgcBUxYG
7kK6ALULu7eW6NRqmiagfauR3Gua5suFPq9R0zRfLnQwI2HVhI+wIuph1HmPq53Zom8RfI1iJWej
XsHXrKtGkqOVh2X1LCFdWnmY27B6wqePdrYMg5SlSE8AqF5dc8xCrg5IYWdD5egMsS32goGx/Nor
DzOTALWtUEDXYq1207ZCjxm3WBtrtUXfgQtmXKz5mslqzC36kljztXKsc1pmRff9ruLZWrXMlmHL
a18POQprte+o9tki66tsTCku8ah3yudZvrS1zYIeyCH1jwe8z3LfOi8Kyi9kgo24YV9StrvtY4Ci
1Vy5hnKvQA7fcn7OJyCX7mdszt6QNsABamol5BfkC36jvm8b8J5xu1mzXeNenzgAqwDeW8RVOGis
idaI79mKagMcKbXYNW5AjvfxVdu1nfWEtraR1kdo3VmfiO3RjqpnrrLysMwhfUb8YtxOS+RatI+9
A0zk1dy3tjRNvoeVtagg+JbWFBbt13mW+7umkE+phd/SmkK4ACuS+z5h+Qab0oVcXbB8EJ8c77aW
yUgadrc9+CIo3OTrU5uctMnX/nYbW0bfvUzOnJDMltFLCxSCGbWYJusLxGfJeYLCs+RodK9W5yHv
6aPM3mu5hnZb6xO7aEjhrAG0PjGxQjGSHAWFTPsKvQ6tT8S3Vuh1KHQcq0hMPZNMe9YHlM5ex6s+
sbZPXscX2uR8cu6+BkPLEcg92uS8R0UvqT1GBS+pBaP40gATTKaha4vIwRjD4+sx9VRwfFszmxk3
GMr0mCLuW1uHVUbk5kwSckIjcktvHIM1MtbGYhtL1wYw4S5laBsz414HyAq/nEsJv6URucWH9p5r
3FI+talI7eFu890l4LMmdo3bu0tsF3KnVZw5obG2zvKkaI3aFbXcaRXnHVKAOYGOQ/lSgFmhnkc4
Y9N2IanbNW6PlPNGe2ovvbOslg4phFebLO+3WBuMy7prOQK6GLeTu5bj8S3f+ptxu9r0efuAej47
ye5QoURrmqbARzBr3KKhrwRMialna5t2d7c9f4uplXyp256OHTqy0+RL1R93+5la+R7lk4Vx+rFD
U6PaZ/n60e80hxL96ndarJbbZmQCZhGNhZw1EyNyfU1tM3E+tRqR65EEajQOTn2pIU18TYndPWa4
O9AkayVtMxXwarJNi2j2xVnm2YoG/5slPBktsWXVXN3KvIcuTL7Eblh5+FTdtzp88fD0a/IlQy8z
kkBNvuSNUGhd2IqGpj+2QZqiCfvZSjgjky/1XcnI6mnMDjDI6Qj/hDV7nVb4llYCt+o+du6bw0mz
j17CCWJKVQpPvz7mzRshwwnf+V2r+3ova0RaqS0+kS6txDMuYay6zlCTaHVfYdVkxFVN0eyAcSse
Bc07u742eKZeX1PCobQ2yJ80Tb5sXYY9jxuIY2K1zJSj08HGMNAmWqZxPrXP15TOMqFdTOso1kvY
a+34mtKslvoNUsEGZUnVapMNNtLHqaU4O+tnnIxn1WY9oW2NvGqvq88RrnGxz+wY2XzLX/cSxKV6
P3R9XqMwNynfD12f/SVG9mTdrXvO+kvr9trduieYkZ5Qvjs6ny0Ve53izOYSei/S2GcCACCmCzqH
15LODm2QKrHDeluhTIiwvrffVwlHmRBhfe9oeX04aV+I2X0yAD9+rIRgqX0JLLWTmBqw1E5KyYCl
dtpCA5bOo55gqZ22UB+pnXyZxYza6uMIltYdxfk5yrsSfI4Crv29he9vbY/UJqYlaXH/Y5QHXvqG
0NC33YM1an0cIIKl3pZL5g/7yhdQ/vSjcm4tvdH4+fPpqw9lf/7pLeGRbTBwLodZiYejfDpu1Dlr
KEWLLcHv7pXnPS0sLB5y338f6dKIYQM+aRFdCuhK0n6Gj1EeLhDQjZy7WaN3Pu5Xh5Z2YgqoJ1Tr
qa7wDJTGh+9ys2vcn8jVZj9i5WN/dUiTczVz+kGXh1dsxjyqvmp1Pil85oLv8ZUW8mtoRFrLtR+j
PJhmMxYWroUnRWOBJWvFU8AvxgL5Jouha4tHMcpX+MZIxC9Nnly9O4n+lDzZRJ9aeIzaHr9NFxxN
7Tl7lgltxlJgve1u+5TByoi0dLvGjfo7yqftOc5yz5YtEHp9bOV8Hl9RPi85nvo7yjdKCemScmF7
xJ6OvWULNDFL5WY4Iyvq+stR9nrxAddYKQOvNTwdr5Ytt6N8tIKsqEvp5SgfZYIplhnb2Eskqy1r
rHmOHo/SWPNaISfYjIWXCiVH1Lfa2HlPU6fOMsGnKRKvc0d0HvlELjC+JlgFnIDkYAXaVitYIyNz
QDzZnrQNrvVrgl0tlC+NzA24fjVc42BLoOL8gY36yYen4OVLOCPjdwJnP7QKbTGRHFIWWoUOzTQa
H7Y1dHk3n5lRo2Yr9x8TMbEB02omP4qZUTAdll97uiaksI1aQh2N8woLAxc4R2f7R7pmkmi3WXen
SUOh16F1d/jWCuX+jt/hUxLttvYEldrqimS1j8KHzbqUSL6ApVmn2K1F3rt9Zubd3HH+M10Adcxb
EbtGD4JXYTu55nZoGyXs2tpjz0pbtsw88id/8wHq4DNBQ9fwdLBlC76nT/6cvWXhJTh8DivRXu61
ZctsN0A8z6ielaQUWj42doGntiS0fML3HMdKM7R8Avnqr0r4gC4gAmG4tkSyysjc0reOo33UyNzk
VWx0HoWX4JCIEmIj4SX4qrEZErZ3b017zgVMXe2ar5az56PN4jwAstVDx509YkoW7Wl4XuJgKtao
yQKK/tVCv/yJhK+FFeW0PIOU36O2TjIPpCwnach8OIhP5g0zyuMlPhwElSpmxv3FDF7oQLXncMbH
844P6rdCP+ZqLX3u6zHK41ZeuQmj9+EolvBhoXrG5CSlbBwKM7XWCKl/BgzlJKb6YobUGznKSbRM
WPHMiWdY8bhGE1Y8So4+ychzYej6atVqyfXD9utDqv8fgpLYK2VuZHN0cmVhbQplbmRvYmoKNSAw
IG9iago8PCAvQW5ub3RzIFsgPDwgL0EgPDwgL1MgL1VSSSAvVHlwZSAvQWN0aW9uIC9VUkkgKGh0
dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3ODAwKSA+PiAvQm9yZGVyIFsgMCAwIDAgXSAv
RiA0IC9SZWN0IFsgNTAwIDQ4MiA1MzYgNDk1IF0gL1N1YnR5cGUgL0xpbmsgL1R5cGUgL0Fubm90
ID4+IDw8IC9BIDw8IC9TIC9VUkkgL1R5cGUgL0FjdGlvbiAvVVJJIChodHRwczovL3Rvb2xzLmll
dGYub3JnL2h0bWwvcmZjNzgwMCkgPj4gL0JvcmRlciBbIDAgMCAwIF0gL0YgNCAvUmVjdCBbIDcy
IDQ2NyAyMDYgNDgwIF0gL1N1YnR5cGUgL0xpbmsgL1R5cGUgL0Fubm90ID4+IDw8IC9BIDw8IC9T
IC9VUkkgL1R5cGUgL0FjdGlvbiAvVVJJIChodHRwOi8vc2VsZi1pc3N1ZWQuaW5mby9kb2NzL29w
ZW5pZC1jb25uZWN0LXRva2VuLWJvdW5kLWF1dGhlbnRpY2F0aW9uLTFfMC0wMC5odG1sKSA+PiAv
Qm9yZGVyIFsgMCAwIDAgXSAvRiA0IC9SZWN0IFsgOTAgNDUyIDMxNCA0NjUgXSAvU3VidHlwZSAv
TGluayAvVHlwZSAvQW5ub3QgPj4gXSAvQ29udGVudHMgNiAwIFIgL01lZGlhQm94IFsgMCAwIDYx
MiA3OTIgXSAvUGFyZW50IDYxIDAgUiAvUmVzb3VyY2VzIDw8IC9FeHRHU3RhdGUgPDwgL0cwIDYy
IDAgUiA+PiAvRm9udCA8PCAvRjAgNjMgMCBSIC9GMSA2OSAwIFIgL0YyIDY2IDAgUiAvRjMgNzIg
MCBSID4+IC9Qcm9jU2V0cyBbIC9QREYgL1RleHQgL0ltYWdlQiAvSW1hZ2VDIC9JbWFnZUkgXSA+
PiAvVHlwZSAvUGFnZSA+PgplbmRvYmoKNiAwIG9iago8PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAv
TGVuZ3RoIDEzNDE5ID4+CnN0cmVhbQp4nL19265lu43de31FPQfwtO4XIAgQt4/93MEB8gGNtBtB
HKC7/x/IGJx77ylSS9yr/JBjwD6u4pI4KYrkkEgq/gz4zx8i/qvP9PNf/v7j339cvcqf3v/7h1hH
4V/En/zP//jrz/tf/uNvP/741/Dzb//5I/xMMaafI7afMdT28z/+149//cEB5E9yT+Pzj17SpRSG
/OFs4flt4Ez3v2CmP/3+449/AWm7mvwTfv7+rz/iJ++zYZDSf/7+9x//NYRU/9vP3//387cx5qv3
WWNYqco/Wap59RAbvnmhqtFQ5XLV1FqMaqxuqMq8co0VBN6MtV6p5w6ReDP2cIU5WhlqrP9uqEa5
Zsp15JUqZEM105XTrKWsVDlpqgR5hZZbmkqqxVDlcI2SY1ZUdRiqUrFiIxipGnmlihl7CVlRlT8Z
qtavMfGf5n1j6vXKocysVijbGWe86uitqLGqkUQO7Sox1anX8TdDRc0poSe1jsVIIlNzWm09e6ud
qTkztKTl1QxVS1ePQwvVCiJDcWIqbarFLmYZMxWnzFZctc8Tn9iLFYQRaon4xAn1Gh5fJaULM2CF
lHqZTywlXqnWPoe3QKW2K0C7ynT5giQmlC4Eb4HKqFfHitf4QvS//f6NCSpzvvjo52cQzf2zuVsu
KPRrLY0BiwNzk+JKZfcF7VvEb2W/PlTm82KiQMvIfaXaLETC7kltiE36okrWciVq6ehjqBkt97lf
WOZhvtHOWDpmrFUW54sqmoWONWLGXroay9qk2OIVsYZDjZWNatGizjLaKK4kYEdCClzn9RutJPqA
DYeBU7K3+zVCtRptkj/jmFfrbUY1o7WVccKblTFG83QihQhbiX+ypxMpwrfUGEP0+ErQ3Qhz37s7
FrZ16gWfqrg3hoReo6SaZvK+McFWltmhh57sE/Sr11xid8eCIRlwMFoS1Y4FuxsrfPZwJQE/lbCJ
ZnFnrP1K0FUtid2b1atAC4P+Rutle6ZJ7Tm6M/YOzYlQnRfcf9qgeLJBaURoVG5VrUmI6tfp135d
g/W3mZaspOyu6ITkwoDZ93QoB9ioOttw90kO80J40kp4sTM9mcBK3l69Qbtmb9WRytGuH35tXXRC
DJUjFN39kgQvACvm7/icEUPBvgfXC2S61VBnTi5fhZFpH2bPTENVE6xaC9HV4NwCJNFj0RpcLRUs
ZMaUzdMPyABWLc+k19RGbdgNodRQNPdWErDJcbbY2gv9WAKfdFFtX+6shaphlyJoU1ItNqQJ2AOp
ZG1Ht5AmIjzq1h9uIQ00JwGHJNe+lzQuTNeL+40lI/CBfLr7jSUzBOxDa45d7QJvPtOY1fUCH2Fb
6G78UFq5Uo7J904FOpED9ptrIUsH8uk1puTKfgSiu1S05f7NUgGHVKxjcGUPnfgKc4+SgJbC7wBP
uisEF32VUbreQ/HPlqpeFQDDl1cFWmn46+auY02dmLkbb26+EQ7zmjC02odZ2deCKCPg74dnv2C6
6IGn3ml2hfB9WG3Io3jWpDIOHAAP0bMmFfoFmGF11Uq1w78BOmhvs8mrT+g9dDW7khiwAJNOyeUL
+oV4JKfhSmIifsCPa/T0q8HmVChGdyPPFhA/pFxz9exXi0Qj0UTEli+MAzSS+sje3m6ZaIRI19tD
DTanIJZIbnQNEA/glmPV3/gXQ1XhazfN2SRRyzWw3L16+tXqpE9r07UArcEWhjGiloTxoojbrgkI
27M7Y2/XwAJUf0b4NECnasay8uIpUAltvtqP30Y2XTumXwG6ANcnUBNgInqcFPtCZUFgANjC31O1
HiprnqOYwchDxZVqg8OAUQHuRfO1HfcBPABipKKoLLyDmsYB/ZsrlVXAWDJVvuqxNhC4wOGFewt0
KzZ/b818o+WrJah8wd5wqXhOBGNTfXkR6A4EOs2VBIEuRD+jSwUFnCUkLfv9sLJTmaMZy0IfAN0w
Smzd0xxwhFACTq16mgOGrtqwNYIniYRwvHMnDk9zUobsGxxR9SSR4BoB6HsJnuakgkCowRG58kpw
oDnDKCVPcxIcKE8P9Ddu3MM1wvgOM9YGO9MFHxv0N+4HsjRdgHaKe3uklBB6zQyvp6leHdtCfZIv
CbjGOmMcrs1JE4EQ/FBpnuZkuMYRS+rB0xw4nwtEeVZPczJsDoCwHDKcZQ9PhrAEwa+7h3IeCEsg
W8V93I6ToYWIyX15ZTjQCb8+urdCGQ50jtFK96SaYZkCUaGi+pPlvkJXsWd7cr+RoLCUMbvLfYMz
jnB9Pl8d9h56r2W/gegBZ4wYVMt+W8fJK5kYmmvJ80Ro33LQ9r782VL1CzFoHNPTQgRBV+1AOXo/
miCh8KIrwc+4+7FEhPYzG13dZkwI7QuiS8WXDV5KhiQQzvbpzpgLbPQoeXorVKDRsQVrfc0KYWNA
c2JN2VuhgjCutNSKq/cFWgjn3oJrmTAOjzmq9jCv7hg+Q8KHyh52C8DMOU2lE/awG1APM9Y01ArZ
w+4C/coDclVStYfdHwCzTFdXq0RWo9TirRCCKoCvUKKrOTWFC3pT83gx47eHkQiPAMHhCPSv3zyM
/Ph1rdPbJxW+ufXSht5NFobd4HYYe2cBfKFuI1YJL7TjjWPGWhMiE2Do7HzvMar+/HVO7uoKaC5T
e/NtdVu4GD7U7O2/2rBn4Ky1N7f7DxsBEp5x6h1vdRN6HkLPxkLasRAtMgWhuF6gzgZJwHroXWqh
j8BhRPTJ0+AWAfnDbLV6O77FibgGwM2Nm1sasJBxBtebN+ga407fTwscxljaT9sID9aYUWyMboSH
j2MUmww2sN/YMqPYXH2+CHThYKMbb7XOe9+ZuhupN1jIF17gN0vVGcXW5MZb0GVGsZI6cZYE3Cr8
Idbx1Qp9D4djdMycD4fTW3A4nUSl4HA6LU6E0UZAHMQknmcE9MkNoigr1XbTTPMaGQ4rKgsVaV4B
Q3hW4fCV29VLvEP5h68NDpcLKCRn9Y32HDIyfwRRhoRtD182D4ingrPcMP2hsjCdp4L1Ph1ZqOy9
L1S+hzaKptqgNYJh+LLur1CfF4LJacayxxoDwA0xuB5rkz2Cgjoa1kjJy4ItgOaJODE0j6+EoHMC
uY3kaaHcDmPzT7XaNlBMEboKJ9eqOyPvkEfMeh034Jagq4iieO971lXeISP4Kal68koASDCFt0M4
88UTxtRvyH9c7YSgM8DXal21+sXbYRjn3rqnXwnOGBHnzO5OS3DGMBOhajthwTwBeA+xD1eqBOAl
xTxcScgJYwnTtSZpTARFzdicbYV425t71Pq13R/ytncM/I83o9z2NvhPV6MzABKW2tic7ZaRd7eY
cWottOAUthBWs0Z/Rrj/COjTmzsW3L8crOsZt7vbDLsKzKxstLWYucZryJQ+1bxmm3fYetzbvG+N
Kd7B6Zn7zkyGmeLwdDUPcA/5GBtt13Ei9KqxtOJKFY59YIMnXycmAjSEs8P1ogVeFFvZ7O0dNCMI
jaO06a2Q3Moi6pjJk1dJCNAm4o3uyUtuZRHjFNeL8lZ2pHAf5x0lUaA58KK9RW8/FoAJeNExistX
45FlDUHrl8n34H1rCblrmxPfhDVmu2xBVYpXln9eBFX9CwnbcAlLWAc0XlFtAUei+493/NlPRonB
C4xJkDOUZyxLxSvNXrog9H5SGkS7CBIQpGY143b+zoSucRvxflKH2Ds3xuA19zKjccawDoie+73Q
/aSmAG/AXQgo+kplTxgZJCB2rjN4fCUgKq5IVjNuSbmQfYBYJaR++DJhXMoI43LuJXsrRMfOVNSs
uN9cI6/7ao85epJgqlbFJ/TpaQ6TsCD50X2+4BpTKfdp0vkbgWYzjI1eoc2kEgDAzxq+7BlwIpiA
sBVfe5IRgr3Z7pOE4zrybBqGXhLNHiqbcM/z5FgQEiq+NjfLC9lRR84u90x1Lr0mpfeb2+g8MZtJ
6/02IwLtDNtSmzvjjBKqVm0BTMI9k3kA0UJ5tYe+tVQllhdifgs1wl99bh9bA4AYCNJMVK2Has8W
Blgf2BdVUW3Xo1jCXAtjs4fqVTVEGk02/0O1I72BeH3UprjfTCqUpobZmKngzFgpmdBHdGesiIsz
AnYliS2LebkeXfiyyJjZwrWOombcspgRPfcMtKqkumUxD5gbhEBJjbVlMRPD9RmSGsse7KZQINUi
VRpnScA8XAVRcVBjVaM5KSJej2H06a1QQtwCDC3HT+cVSjzK+nCNC9WW4YutOIBmlebs16OIxGGc
9Vh7Vi5kP2rs0Z3xw9QXzb1Fsw3bOsCF+lIF+kfMlYLi3p43sBIFzionrV8W6XVxxuUbqQL9twxg
HzxdTdAcRBtGo/fr0cFcEikMOa82Lz6hwCO6fMnFZ8uzuBaAFTLQi2nkZWdMdKBMylAzbnU0cMZ5
yLXtebVhcC8IKwbXFsIZXAiKUw6eTvBKc0amRymqLYMVWjjTnNNbbcR5iLFn1Ctkc84Aipm3mZiS
4cgL7gx+MQ9X71fc5fAF/YKFrqG5kgDuQuBvbM6W3QnXCAvca/J0ogSi/yDVbwtfFiuxpKgOqVo5
88WSoh4Yvni7g5eV3EFD78cNd9EWpqQ1x6ZkEFF9pp043wj9ihUK1j3NEdyVm2SAOXwRdyFoN17U
XsgyZ7bOkZo7Y0NoXyCg5M7YWcfAy0PPRstlZZxtTG+nlZmYRTmirxMIewfgsZbEdlEVAk8vjZXb
riERDYXGsEPxZU5VK8+9Z556D21XUDz3BioMbmwi14qzpTQ8zak89248ofEkwZxZQP9YhvuNAJgT
psl4PnvdWYH+e5zFn7EiLoTyB9fmIIi74NpDjt6urT0j6oBvaC4VY6ZKF+PKHmAVsVAJrhZ+XP9V
Y5leX/+1WjxJSDZsDpK6ddbC+5IwVR1H71eJkwmEcptw1sLGyAoqkVwLIJeEzB1onhY2WCbsydCm
p4VySVghD9dvtxov8DZ1fL9JAv6xwe/V6EqCV4nYQt2XPa8SsZDZjU2YDYuBYnWtr1wlFqyT3kMb
1WC1VtL+0UYd2Nes1sraFtqIrwcpgDWxnL0B6Ewpg/Cr65E79CuC9/hqD71xLflqs78HMNNJTSO2
T8Z2FWCSTmoaWayASIgnCQ+VvYLClwEK9SxLmE5LCD8M0zXl+u+hSpYvGl5WWuix7MUeDW9qM2Z3
xsIwbkhWzcL9VuDPNPEwRB0eSViozWtJYKuuJLEB36Vo1ZmxAUyUGmpzuYdjz7Hf5jmd1JSnhAUu
KKtv3K44aZ7590PxZQE5tg9CvWw0ZytaBZhICC+LNyPw1JUQutTszSiQlomu+hs3SNsugPbRpicv
hHnQnDaK0ugNHrNYoUCvXXmtRasLlb3+W4pWHarC89Ipp4QO96Uy96iW5MqLRauZwldUG/AF5ECY
XYenhVK0ikih+FJtBCYI96anhXfR6hh6b29XnINXPXAurt7zVHWGOGPzdhqBL+x/0Hq/XY0FhBIB
oX1yqSKPX+4cvfOMGfYLmKoELVULHT+Aby2eJBTwPa62XBLyrse1Jgr4HqUqV4kZ4D14ei8Zv2Pm
Wl2+4P4ZxPXhzth4OZ5KdrVQ4DHTSbV+WXBPeMwlSq5UB7QQoEpbgP3CkdeS4z5GO+4hXjjOMKUR
w1lz5MKxhVFdrwD9u1K8U4CWsSwVgAkkG6aW1wZpoYURIDl6kijwfA22txRPEgWer2e4K0W1gUJC
Wrjk5HpRloF+po6cdwciOADyIc1hzloowBchobb329EEryU/2g+cfYdk6fZWomtzBPiyn0ZzuR+0
hQAwrhbCb0ALgxSnnTUH3p/l4knHORvci/DbCK+Ga1cr46+PqozzOlZeA8y7QYQzFjxfhnql4ske
2gD/mHPpnk5UXgNAC0P3VhvBHrxCLN31fAJpe6qzeqtNSBslD8Vb7drl2rt11zLBM14J6CS7lqkO
SCKO3lydqJMpQAhFXctUJ7Uw2gjG8jWZKJRHaJ79aoGVOmXqXbuBVSZ8zfyNt2qJRYYIc7q3Qo3t
QCZW2/VDTVonIbJyI5hWpClS1nq/FVIS+M4xpxvBCPBF/FK1JOxxQuXxywyjuHw1HgKGZDR6y45l
26qYtUfeCzwB7iviPvWN76ZVtPFKxd8DheXzV9mCiSCBdhJc/0W1gZxIt4HwJa1UexbqAgrLafvw
bnJiSuYSLlRbFmq9IlZQzhLLSR1YuokVTBLaf1HtpZsF7gxE6ht36Dgu5i5K6HX+Rqbsh3aHcedv
ZDJ+he0q7jcyGT+MLFDozFdn4kvIWUl1uw1lyn7lfZWa0XK/3mA+OrGVbi43mF9U220ojBI2WghK
XlufufUG85nR3hRKfing3PQksfYoWlZog3vpGtCvqsba4R7cBlZRQvuHaoN7AOQsJ/epmIUK1BS6
yz1cI/3ByJ7myD1nmfeZ3XE/3vec8Q4cH0nYrF04vYxgKWVPC+8bTChFc7mH00MwnvU3bqAQTo9Z
6Dm4spduQviP2h17nyDm7AXJsztrdI7M2YuSZ3fmXuBehgON3t7O0MKCP9X7cQMmsF+1Nkm/OkuV
/QK7NElx+ZIy0Dmb1i+bocmEHIw1tS3c7jnl7kjKsh15NQYvIefpct8ZvGB7JM8CSNpOZujoShX6
BXCch8/9eoP58GULdVmUCdeRo8d9geYAbvfq6hekcLGNXHdXSN1gHjWaRZkDUUJI7oxM0motaru6
54QyoXAEbeU2gMlyyzGTtl/bjCy3LFjt5M5YA/tk3rDquEJSbolYLmrru/XzaVJen4fLPTSH5fV6
p23wGOESW7rqnbbBY4B7EBnru0M0Hq3OkF07UXlEPoN0sVlmNNmx0qnno6vb+RsrW1TAvftaWJmS
F+LUWriDL3b6g60L3jfyPjGFYuz9q/tExLxDr9Cr+8TIEgZlJ6KVROPdNxP83LEI0cIsWe9ty5eA
r1C137YXD3Ww8+vd/dGZkY0sgIeKa6Mr/ND4qOU4y76x2qalYTzydjc5edsezO7Y7hP7VT6qNM42
uiXqF/xM9GwOSxMRKZTUXO5zR6QQpGpqGcvETK1UJgu37toJYEtWrLXs2vvGA+uJZXTjHGx9SKJ1
4622HjyTufYju3Fh66ysmEZX95tCdpJklqlnTRqPojt2UfV0FXEcDx1ic+PCHpgH9HH9dVxH3jq2
XMt8FQO8cVP4asneA4Xt5GbVTWE7LY66KWynDatAYTstobopbCdRqbTWdlJ5ldZ6nnFNa20nZY48
9eJhSVR8bTeFCJdGbLLJzvJa01rPfK1pre1kbtauPwv3FqItXX+WsTZQ+JQmOtwvpYkP1WtQOKL+
xr3rT2Kv5qi/cS9NZIZ5TCV4urqWJp65l6LDRrF6miNFhxHrpL5x6+cDzakjV38d19JE5xulrVlr
+hu3egKmaIzOtl3ejNLW7K7QXiRhx2KKRrwrtM+79k5+vSu0nRmZkY+xhpb9VjPB++p4Q+1nRnsE
sCa/HqluUNi/0fsbFI6p13GDVVEKuWJons2RJq9YxR69bwTMhpstWSDtUe+lyWunsXdnZHVSTtK7
5ayruZRLMlqUflnHLk1epWjCW8dcG8uhpc+Qwz1TZPtoWgs3eNzGNdOURrbn/ShNXolok8sXXHas
SRrZLnxtVJP9MULU3G9dfzrvvu+siePuYKcexI2paana9NEgty8luZrzUXRYp6uFJc4nEDpKogBM
VBjq7vptSZEt7T7mOMqe0BHoZabiWQCBjoltz12+YL8yFjtqa2Jv5Bp7TwFgTlde0jB2SPHoWQul
YSxsjuZ+S1jtjTZHnvBwuL/7+VRjmeyMdz+f0oY7I1Nka7OrbSEHk1/ZrKJ4fLHrDxZIHjM5a87d
z6cPY8lf9vNhEwYvBsAmY8J9KM3lXpJf431Le4wBJPk155imJ1V23pmA1tPnnmAVKDNmT++l980o
OQ+Xex63s+ZGrdAGtXmQjuhx+Cskya9DnmI5eysmv4YhwbfHlyS/9j51pGAhR4hSwmx01bYj5XF7
AQRzY7nG7Kp5V9I5MybG98N4PnsE0KSdw/2gwVkSLTOvBYAoehagQb9mgV9241WC1QDcO12pCgwt
9T6cfLjf+ugwY6Xn4fqhJtlVMxclVVvAxzvAlD7uq898DWCr/nFffZ6RMVP5uK8+WoDGmAnMB73a
JjbpiJlg7KfxVhtYbUxiDsZ+/eVNGBpeuYn3YOg4gq+lj85DtYGvpY/OQrXB0AWsjpOaKrA6Touj
wOo4iZ3NZwPiEoGO42Ru1uaz24zftltbm9Iuv36z3drrX28gskJyUD0jua1mc16VqYXBlcnSd2cZ
y1JhI7H9d1XrvhXeS/uxGZpehQ22JjakuqsLzysqJjjd1YXPWBY6sWZzsL2vp2lJ6g/mXfFwXPcU
K9tW1aikulUEIuybhVWb7oysP5i9t+nOKE3Kxuhqz30Ahjda3SVWJswpRe1HXTvu9Ne/fjf1IWmF
+RXzwgTC+1f2jao19eGh2tR/SX1YqOw2pkngK29TUVmDtqQ+LFRbUgPzNmekr3yodvPypD4sY9lv
ZD/qOCQr0OFLnmcKWY+1l2VXduVMs/pjMW+zSNSwcL8lSDBjruauZtyfZ2JToyjdA5xv5ClXm5J3
7nA/mNEUpfhxGcsW4bO3NVx4yC5fk74yhZo8SUg+PIJhzf3+1JNcOsfcPO4TYv0C2KB1YuvCzLiu
zMACloVqMyqdHTgk7cSZMctTM5J24nxjlqdmJO3kvIdk86chaSeLJOxJHgvBgaCKksR2ksesrdDN
au8dsPvFN1F68zQHWx8GvUl3x0US9ryPCRK8c0quvJgggSgkJU+/mPoQsd1i8nQiI9aX12Gqp4WZ
5UrwEFPvoe2Uiz3wgzh5Z0Z2GZFWwN43smkWoiM5yTt/I1MfEFdL32eH+8xzyBK0VG1UygePYAVS
6j5VYZKRtPxyuC9Yxzmy3rXWyfMsjP12e/W0kIXgg/BrvJjx27BNHkLqiCP0r98M2z5+XbTF2NMu
2KW/ZO0Dt9oF6ThUQ9Ey2V6ZrBfgYtT6uHde4UNzd9n7ec8V6HapdzrIQrVl2U/p2hyax5f0wq7d
2nR7ppd4BjqSv6I8O+OTWa173yhnZwjteGpxlr2Ul8ckj7uctZYnbKkNKVRdxvqndwOyUvm4XJOQ
+6hF5yZdr3+9ne91PgDbtYXcTk0bAvY4R3IjqdIRzAIoahuzpXPAjkr9fnDXYQY+vhun9tN2HSaT
D4t0tj1/Yw3MbG+pu/upMlpsIxl/aM+rGC2Cq+ZKldn7fcacgqfdzN6fYL+4cQ0TSEIsAjfO+6kS
ZrZakyv7KtFik1qz82pXiQO7lPmftbvythPOKbtegE89yfGxtj/2HI11kXStrndi2TpT/HT0s50V
8uQujGw88Iuy9VGntbGWe4kDEbO48UOTOHDW5HqnRnCZYxnRW6HGOHDwWN6zsVK2HkNPbnTNp54C
Nvcs3k6Tp54ixKqlas++mCjb6M/db2QcWO56lPNOkxz/yAp+L2KRsnUpnfDWUcrW412P8ut+mrn/
AMxSE/rKwlJ8/Ifm8aNRGM8IGRnwny7PrX9P9DyQ7vMRi/IUtkNi6/NK4DZrjGCL79ncVV6Qc/WM
zV0jn5DxVooJLonbZL5YKchH853hr+VFYQSHfICeT8W/cap4XDYf9pcvMVkgGOrVsWdlC31RbSA8
Smkx778Xou1s4DkudKhW1P9FZVu/rMeFD5U9bWdZBAu6hj/jUvDgzLgUPDgz8gaGZskXKvv8TYSR
weVrxfPlZL0Unj9TjSptWLsaaz/+e55bPo8lr1D1+3bCo1qQejlZVfbKZI7vcDUniYVO8qzxQmVR
LJD6bFleE3uodqTOJMwqXVfPqy0FD6EXQT9nvvhWFbOigrc55LllvuOqv9E+Gsxbk9JnU1LdSxkm
DwalCmsZ6/sXOD6wOaLYjz6Oi4S+LPRtCrL0TPig+7A8QYaAfb7/5VsbfJhpOytAvAwooSWznxVE
JklPYxG2N7V4CxxjDq6O8ESB107ZnXHyiLjIPeoy1lY7zyPimo2GWzQYeZTbpMDmrCMspgC6jEZH
tr6lic2nw3T3FLubduiq0aStDTcsFas89F5/8YQy6y2D4v7liUIJrWdXEjXxpbKuud8kAQxVgNdL
8lYoNzpHBPvZ5R67pU1E4K49k+wabPgRXakOYqg5SvP0K7PbcMYCaXnZMx8+oSzZtd43lkCnWoKx
QRa1IRJmtajW1S3fIvISrltrvLX0hmVPI2ld3bNrWGz4cZZ+njHzugweM3k6AQcOL5GMt99OQQpz
QYPkqDoz1sYMyB7dvS3ZNTVL69WzZZemcUDIU0UOWwM6WDkmxOuIZpuRreXKkDtsZx1h5QBxm/HQ
9hsRj5YeJWfJWUdW2LNCpXh8VfhxPsShfe+GJtlaLmXJWTpbAGbXYHdELdUNv7IUhK9ZTI97loK0
0aSc6rzTqtz7MKvEk6q8axVmLYrKvtD3gfe7/sYtP6U01vSP7HqryuzmxvtYz3cI3mdr6eHZL5aC
jDaCjnL3UhA+UzGj8Y92hRgn9prTdFeIBSPA1SYWfpGpAyDTomsn+JbVzLF2PaOtsL/xftcAY0Om
jCYRyCcdyVuMzmviPKa2mNsJw433p28niPfHR4fzs/1qEk3mOV0Pc+P9FFN0ZyTezyUMbTG3ghGW
9FQTTe75PBOSaFljh+05ZuJ9zDeGpxPEpSwOqm70Lfk8sdbuehjJ52G0ON1vlJdP+307dJYXXz4d
sxt5We7ZABjRV+kvuH8jU+eVaX8PU7eTUVozdR4qL1NnodrKShoCxyIPBz9Ub2fEMN2R2eaK3///
Rzav+dgetaDJ50uXXUl3K1XhVX/PRrpWboTzZRQt3b0De7vYj0tLd++tzscEY9Xc24vktbf6tlIL
FYx56vcBwjOW8/T0wv1WXgI433KUa7fjN67vYzlUMUiTI6binqUq5SVwRLJxHyp7NMCKPT76271d
gvjlokbosXY4z2BhVP2N22MbLC9h0W7w5CVX6kx6U3ztF++sZgv30cBZEnDdCTpRqivVzqtY0A73
G3mlPqH4iso+RJHY25MNxbP7jeztCWCbNF/bYxvsaSGVcg73GUFfTwBsSgu3GnqWhPQiHdjP38jL
cnyiPEO5fKOFkOwTIFmjLvd8CLrnrFdobwvHC6N6X20crbA0fAN8z641uRu+9fuK+iwvtnKb4waa
Z774wlQPUqqyzLg978ELozb0rt1A/mgXq1mzXiEr1VnYpUWaHDl8TerXkJrdM1+8sJaOj9PTQrmw
HjWH9EJe33ot6R/AWh7FyeO1tDfJcpyT2aBl/KPHWYcZN2DM6vRxH6k8X7W9iMX3ARDGaS3Y+hpI
m8SWXXuLoIxtEm8AetQCNqgbsDFDSdsmdxM+Tz6I5drbu0FdkCTqsy2SB6IB4UJ3uYcOT+un7bU/
L7gnQsbi6tMMbMDVh/YotvkZy0kSC0q8L2TjOR7s5+7puTwiDRNpNHgrOmGIWo1H2S+4J1OAkuZ+
v+DuDNZLDJ6NEcBbZ9Ve4FXH9fAJ847rww4JcaQWtVRtg7fK9/xCN/Zq66XOqvM4mvY7tkMCc5l7
kP5H570hTymn2LU/3ADv6Ey2k3I45xsBIrAjg463dig7L2iPNBA8a6H0Ugcym8r2baCLvdRTCS14
MwqUnS2YiOXls8x9DkW1Xf7Ks8xTOvqfJcFykq/ksTNf0BxEU3G4MXiD5uSZs9bVDTzX9hziPmNt
8DM/6V/H1ZbGc3Kf664QQernIe6ZLzae+zzEPcY1AlI/D3HP8uKzzJ+HuEe++CzzwF42tnC+C1Jf
hY/vgdRxEgK0hU0u5FGZh2oDSFJVl5IEBeMkBAVSv6g2GLW67YfKwqj15vc8ozTES9LVdOF+G2vy
zcIsSzhOiyNZ4dA/uVd85GW7QPCxrprvO/Bx2mRrvwJHqitUPH/jChXP39gnAtjZ9Tduhw00liwv
DK5O0FjyJajhzjh5Ro1wMXvcJz5PUap0nTzzJffDfMaye3zJ/XAZ9/Z5+NpgZ+dpfdbf+DKTu3zk
Pz4zbu8yThi4mfU37g8u8+EJPoHkUvF1eoTVc3o6keRJidRTcrmXJyVKG8nlXp6UqCNUT+95owps
OpNebcv9hAXoNF4e9xA6OwPf9wMPX9vDxoOdgdPs3jcK7Kzpzpw9aiEfNh7iqbxvFNgpLerdGdmv
ACodkqeFzNGO8C3JtYW8UQVMl4d6F742qkmYXoMre96VIm6UBm/n1QbWIEyXBm8Llb3DZSeCPmfU
+3GDnYngJRi9325UES4BLWnu934FCAlzk/ros10FcLuAv9Ms3h5iN/IIExy1t9rAKR82yfKGwEMV
//yevyzxlZIQb/68ZmFbstaDORs9/RUQJ90vH8FuqfBF7xuYgn4gmoNHGvjXdtMjprmHevlXaqj6
iXD5R4j47B+RSjp+3H/UGV6aP/vnH//+AwGLtKevP/8OGuy2j//3fz7+H1ss8/+Rbv33T6p/+/E/
/8vP/4uBSEzx3f/7h8hC8X/5+48rtdSLFHa8/lceK39Hgw//41/Dz7/953eHy4x7KeWPgGI7Qc9f
GW4PlUU5EdiemJDXZw/V5iCJ7WuR/ofLWDZJjJfe0PygqbYOuzz/LJ2h1TKj7dZLbP/xOMtCtYUd
8etxlodqb6bEs64sb2ctfG1pafnrcZZlRpsu1/vX4yzOjENKxcM3kmBb+RKikcQWnAB9zSj9/Jax
tnpTuSzN+hu3HrVBLkvL7J4kWED22a33zBcfeq69S1rCQrWVhvEsdQzZkEd5MS2NXVJnc/lis4ga
p9boLcWtyMX+GP6MTGicdVT1jVspHfsfsvWk4msrpWM9c02ShOLMyMe/gY/NN9qxeFIAfFz9FeJJ
geRLKEnYE/3JznM1m3XcAh0+btDYUnyd8evU8T5KfP9MMYfxQgzfeqHbmpXDz7L/s/bF9m9v/ky0
tv1js43jto/SkFl61yxUNqk4JVAl6dD/UG3VpcSDH72kHqq9spcVe1Dj6VOxL1XPyeerDj6bKy/d
P1TRPGvKml1WavDW3BmLkXiMkhu0fKM1bYNGi5XJimp7w75cItThURF3BfiDqMbaTRtkDzzV1Vhb
7M98MdqZpKi2UnrIHnZXjPw4bmg+Rfrpoo4rBGRGoyUv3S+y316BYkYf4i411vZqFp93RPDcuiuJ
D5Sdk0slR5JQ1ebOOJlzGaRl9kJlI/HAnJKUkh7LRryR5yBZXqc/S0IqVXOVxynPOiH4JreWoveN
bL/92Wp5oTLBDV9bQpBaWRV11nvWjYZyN4BdqP7ynnmR9oWbeXnPKjHR6HurtFA5Vumh2h9keKzS
Q7UHgo9VWsbaHot/rNJCZe3gYpUWKhsuLlZpodpCvMcqLdzbEG+xSo4kFqu0jLU1C3ms0vkbV6u0
UNnAZrFKzliLVTpzv1qlhWpLL3is0llzVqv0UFm/sVolZ6zFKi1StXwtVsmR/WKVFqotJeCxSmd5
rVbpzP1qlRaqd3e/3nq/tvvPUGTd/emt3f8EgdYTr7s/nSSqdv8TdtoZ191/5mvd/emkW2r3n8da
d/8zlhOTLFQvHkf52v0PlfWL6+5/qOy+Xnf/Q7W191l2/5F7tfsfKm/3H79R7f6HykYu6+4/z7ju
/vOM6+4/U627/0y17v6j7NXuP0pV7f7jN6rdf+RrjUnOmrPGJA5fS0zi8LXEJM5YPCQpWPPgUnUC
TxiA6ukET0Cx4eVK35HEhOxLG12PZSsDWJVXhuTWL1Q2MYNpfGUObQstX+yyymZbbXo6UXitXFPP
xVshJrKwI/icns1hdwc4pmas75seoVQlml/zCBZKv/YI5cS58ghfVG48+EXlxoPPWF48+FB58eBD
5cWD529cPcIX1eZdVo9wHmv1CA9fNgpaPcIjr+0hrMUjHKWqPMJRXsojPGM5KHUZy95arh7hiypt
R2uLRzhqjvIID192xtUjHDVHeYSzvFaP8FBt1Y+LRzjql/IIx29UHuHRrw3LLh7hGWura1w8wsO9
xbKrRzhKQnmEo0Yrj1B+1Xbl/soIvWm77MHca9vV3rJd7WhvVtv1nCB60ewz1vZCxGK7znyttqsd
7c1qu85jrbbrGcuLZh8qz3Y9VM4J20JlLclqux4qL5p9qOzuX23XQ7U99bfYrvNYq+06ykvZrjP3
q+06SlXZrofKi2bPVKvtakdLstquo94r2/Xo/RanLrbLoVps10Pl2a4z96vterjf3jJYbNczo7WD
q+06U63R7HnGNZp9qKxHWKPZh2p7lG6JZo82R0WzR6mqaPY84xrNPmPZOHWNZp+xtnrlJZo9SrWw
tKD2mJQF2Hp3tXKJWVXWZKse7uxORAm53zj4UnlkcxlvxhnZD2WO4c3IZOrPqsCzrkr1MNv8d09e
7PDF7gEjefJiAnTgS5JqrC2FODO3KUhZx9krVHZF77F3Nda7PrvWV873TZ/91q1Yf+tWrL91K9bP
90qrzz7ezCif/datWH/rVmyh2lpaLz77oXpRBPflsx8q7/z5OJby2Q+VdwL1UFkftPrs4zcqn30e
a/XZD9XWYWbx2WfuV5/9y3cuiWm5m/K+p/PjrTuXcTwvXnV+nG8aFp1/qLZEnkXnF6oXyTefOu/w
tej8OJ7orzq/UDk6v1A5Or9QOTp/HmvV+YXK0fmFytH5hWpDz4/OL1QbEn90fqFydN7hftH58cs3
DaLzm/K+qfNv3TSM44mY0vnndsC5aXiotnzyVefPKVurzr910/BQuTr/8PVu1gnrbDYBvin3t87z
HKpV7meqVe5nqlXuDtUi9zPVKvcz1Sr3M9Vqa84ndautOZ6IKVvznMo497vjfG622pojX8rWHE8j
la05SkLZmvOMq605nnUpW/PwtXVwezDxQ5Wd87xlLAcTj/Op34KJlxmdG57zN66YeNEJBxMvY219
yh5MvFDZ/O8FEy/cO5h44WvrQPZg4ofKpimumPisqysmPst+xcTLjHasBRMvq/2itPoTEy9Uzg3P
ebVXTLzIy97dLJh44d654VkkYakWTLzMaLlfMPEyo+V+wcTLjA4mXsbank1/MPEiLyv7BROf9+OK
ic8Wc8XEy4wOJj7r14qJF6qtv9WDic87bcXEZ0kA+17irJK3t1nuG3rp2vpu5dE98YVPeW7obDHZ
kyr03nLzNKdONtWZ0i154cueIczJlzSlVcsyo32lLfAluiTJ68tYWyEvX+XMRVtf2+uVL76FASJt
mWxhaq58+05qhzY/9G3gIy+3b07uzXjprTsEh2qNl85Ua7x0plrjJYdqiZfOVGu8dKZa46UvqhZ+
JU79x86Bxvjl2SR4eoHA/1lqdg6lNm+VyEi1EDz/y++A4saPvk4vftU/f7XX1YQrpdpYePpQ7XU1
fLZ6dt7gL1Sb+rDsKBa2zn6otstsOKIyYKOzorJHYyWBr5FpfhcqC6xYVzOTPLnkjMUHH3IYUc24
hcgwhvB8paoZd1WcbFYvBmwZa0u6DFdkkbSecUsFD2xxJ8HcQ2UPZ/kwU891sKX1mS8+P97gINn5
aVntra6Gz3z3SGe78LVdxfP5SwRYyVttPhmeYs2le6vNnk6z5j6it0IswYUKJs39lhRf+bz9/ZCx
Mxad2ixN6/2WItAIKYKYJ0eqnf2O6tS6uvd0YoF6lHDb4QsBPh1f0ntou/RiJ/coFUbLWFvZLDU6
m9XeQ3cW/UapFHNmzHyi+H50exnLXhsxMJx3G+WzvNg8OLC1hqLK21U8LACAmrY5+3PabP3PB6IV
91tXpMidNrR+bVdQBLYAJ716MxbYXWwzCbfPu5aNdaH1OSdPv0rmk0BTAoptrG9tdtGL8Qu9IjLL
/l/jl+VtwIXKeRtwpbJvykEIGZapqhn3qIP195HPbC5UW7YBHEIFW5CBxxfi3jYzY+h1LOvOar4Q
YvGZzXUsa3gbX+CCRwgu90CYHyWU61ib25ifJZQrX1b2HSrfRtTfuHEvDQNn0t+4l2POzxLKdbW3
9/y+2go6sl/aCi5UNjqW/g5jslJ5obJvZMvzny3yXYKVr63Qktun87WpdUZr6vmwZ8ywOJ4kpL/D
qHxXaf1GWzgI09UR2uqxtvonIKbBNvfZ00JxLqxgj97ukL76U6rJPe7ZVx9uIwd3LDYMrHWm4OmX
NAyEHIrifndB0BzsxqB1wuY3wE5grfkUsDNjxmojSCu+BYDUESQUdnhxVignthjCCkRvd8gbfHeT
sVVe1umVJG2nxnT5EnfGrmbO1s41fDacdlQiMyqJbWhx7a3w4YsHX1hWn7g9XRewOSD85i1jhnqx
69SInkJnAPJZegrFMwBs3BAQ3yTX5MgzePCMY7jyYu/BkviwraM4bO/ArlPdXWz6YnadmsXjq8TB
7qNFm/st0QMmZ5ZSh7uOBeoFe9O1AdiOq4hL2LmludxDc/LsfETIMZgFJgdx6gzTkyr4hiTi6D73
rTGCnka/zEYrXXqyxThc7tnNr2MdXf2Sbn4SOLorBM3JiBtTcb+Rj9q1zgdmnG/kc3XwL0Wbr/Tq
ubqGKaPHFw/uBpRsKirbkZYHd1hFHnQ6Gi3d/EpN1dXoygeMZssm/NpSXtjgpQOTuWNV6aOGGMb9
xsbnbkPM2gJsPf/gRCsCuu7y1YkSEFRkly8+SDxy8J1CHY3PZfL5NUcneFRYEYt3TWUfaUMAA31m
t2lHc1qYbEmSp+uQW8wXm2Jr2W9d8xCzl1FLdwOFxr7IgNA6JN9bzje2zekpulR8wGgm9m1wvII8
MccuNloLzTo2aWO16YQdiw8SV56kK6qtmx9sYYQ1dIOO1vi04mjJXW1AGXYPqdrDbGOxsQ3iqpo8
LWyDT3L10V0Q0KQTMzv0KBttLigbG2fdDz55msPwK86p13Fvcg+dwIw6QH6/yf14wcJ7mDAdUdXT
P3ClOvcPXKg29MLOgBW4OK9U9l2HyEYrqcJTKaoNOQ6+hHZj1XRSGh444nuTbNiHrxe5RLwmqMPl
XgxvhB91+WKjFUQK4hqfsTZ8+dVqfqXaqnryhV3Ro6ba2tbzvZzMlqwe97yJzmX27K7jyFcc7ca9
Z6lKl8FxG/GzJNiOJbP9vxpry8VvMBHyXo7DfeI7oQ0xu/pGe9TDvAP4qTH1N27dLgLf0MROdmeE
fg0oflBauFUusdlqgUK7WpjYbDWyo6y3jvJePGBond4KIYbgm0Clqf24dajguyE91+ruIelFCD+b
3NWWXoSxl+HuIelFCCMesitV9iJkmoarOYJoAXGG/sat3p1d4BDjBM9+SQv8me+w5KgT0ovw8yTn
KHtpgQ9D3/U6bo3yv7oMOt/Id9tinDyqdmR/9yL8OMk5f2PhC3ZQQm0nLIausIWdbZS8FcqNtjDW
WVxJSJfB1GN3v5E394WvJqsZbcZKxzfCiOXh2QkBq5hy+JKYvFYZuet1NNcXJcBbAbUXl3vpMgg1
1Hxtb4dFBKEBZsLlvkSsEKLxUjzusYQA9/hEn3uAiV5iCz73ma8j5Wr4evFm+xjV2In9RbYkGT4j
eZrDF9ngGdiN1OOrFXknSnsrezaJcJDvQhs7sWeGNF61jaK4t2eTBWAC3orZHAvVBrUJVtmPWK2Q
PZtkZgicVShKqlvOB8DEGHw/xZNEBZjgC3ZRa7Rtds9oKPeprcmWp3HD0GC8gm2lztv7GlKOPhV8
bWh5uja6Zr50ObK2mNubZqWxX2wxFnMDq4X9Yo3v2F9kG2w7V5vrYfjW2sSKDL2HLCC/weqIri28
wWqaxrvbb2Q01HLVWrjl7kz6odh0vLqt4+zwyBCrG3W0UC/Ec7O5Y8lbazndRxNHS94i73zyfTRx
jCda4p1PuY9DjyvEBvVYxpyrZ3P41hrMRJrVszmtsNXlLNGNCxvf5B2h6mh746vyDUuAANfXtsr+
4KUYj2xhO8EqX4jR3NvX8Dr7g+euY5OXMJRtRl/F5N/itjZeBXeSR/L/AEfggrNlbmRzdHJlYW0K
ZW5kb2JqCjcgMCBvYmoKPDwgL0NvbnRlbnRzIDEyIDAgUiAvTWVkaWFCb3ggWyAwIDAgNjEyIDc5
MiBdIC9QYXJlbnQgNjEgMCBSIC9SZXNvdXJjZXMgPDwgL0V4dEdTdGF0ZSA8PCAvRzAgNjIgMCBS
ID4+IC9Gb250IDw8IC9GMCA2MyAwIFIgL0YxIDY5IDAgUiAvRjIgNjYgMCBSID4+IC9Qcm9jU2V0
cyBbIC9QREYgL1RleHQgL0ltYWdlQiAvSW1hZ2VDIC9JbWFnZUkgXSAvWE9iamVjdCA8PCAvWDAg
OCAwIFIgL1gxIDEwIDAgUiA+PiA+PiAvVHlwZSAvUGFnZSA+PgplbmRvYmoKOCAwIG9iago8PCAv
Qml0c1BlckNvbXBvbmVudCA4IC9Db2xvclNwYWNlIC9EZXZpY2VSR0IgL0ZpbHRlciAvRmxhdGVE
ZWNvZGUgL0hlaWdodCAyODcgL1NNYXNrIDkgMCBSIC9TdWJ0eXBlIC9JbWFnZSAvVHlwZSAvWE9i
amVjdCAvV2lkdGggNjI0IC9MZW5ndGggMTQzNTQgPj4Kc3RyZWFtCnic7Z0NdBRlmu97xqyJwjhC
kESDJESDBARjNBo+ciWDWTILqxwmslnhTI6XHVEjCzcTEwaZoDBZyQqyYa9MmAszUUHDuXHIPbDg
iZ7MiWscPgYRNCEZ2DXHice4zJLx5s6Mq8vm/qln825R1d/dVdXV/f+dOjnVb79V79vd6fr1836V
xxMaUzSmTZuG/fT09JycnFyNyZMn33DDDd8kwYH3KjMz8+abb8abib8pKSl4P7Ozs6+//vprr702
xM+EEBIP3Kjh9MWJhElGRkaQH7RodMaMGdiHPXHlv/POO6urq7du3frKK6+0t7efOXOmj4QO3rrm
5uann366uLg4LS0NPpU3HFb92te+ZtX3lhASe9ykMUzcCZQa8CNG4HnLLbcUFBTAoVBqUVHRli1b
jh496rSI4pO2tra/+qu/Gjdu3Ne//nW8+WPHjrX+S0wIiQnoU1cT0Kcw6R133AGl3nrrrQ8++GBn
Z6fTwkkIenp6XnjhBYSr8ikkJSVZ/1UmhDgMfepq/Pj0uuuumzRpEnamTp06b948xE1OSyYReeaZ
Z5KTk/EppKam2vetJoQ4AX3qanz5dNq0aYhM8WxWVtaOHTuctkpC895770m3NSEkvqFPXY1Xn96h
kZubm5OTc+jQIad9Qi7z13/91/Z/uwkhdkKfuhqzT2fNmnX33Xfn5eXl5+d3dXU5rRHyX2zfvt2R
7zghxB7oU1dj8OnVV1+NmBTBaWFhYU9Pj9MCIUYaGxud+qYTQqyGPnU1Bp9mZGQkJyffdtttnA4T
szz++OP4pNQ0VUJI3ECfuhq9T2+99VaPtm7DkSNHnJYG8cfUqVM9nERDSNxBn7oa5dOcnJy7774b
kemuXbuc1gUJwHvvvXf11Vc7+8UnhEQd+tTVKJ9mZ2cj6lm4cKHTriBBsXHjRnxq11xzjaPffkJI
NKFPXY34FDKdPXv2lClT2tvbnRYFCZZx48Y5/e0nhEQT+tTViE+zsrJuueWWFStWOK0IEgINDQ34
7GT1JEJIHECfuhr4NCkp6c4774RSOabXdXzjG99w+gJACIka9KmrgU+nTJnyJ3/yJ9/5zneclgMJ
mWXLluE7eNVVVzl9GSCERAH61NXICr233377nj17nJYDCZmf//zn+C3EUUmExAf0qauBTyHTzMzM
CO8GnpeXl0FCJ/IB1ddff316errTlwFCSBSgT12NjEcqLi6O8Ko+efLkERI6kyZNivCdLygocPoa
QAiJDvSpq4FPp02btmXLFvrUESL3aXV1tdPXAEJIdKBPXQ18mpub+8orr9CnjhC5T3/2s595OGuG
kLiAPnU14tOOjg761BEi92l7e/v1118/ZswYp68EhJBIoU9dDXwa+WAk+jRsIvdpT0/PNzWcvhIQ
QiKFPnU14tMIL+n0adhE7lOAD5ELOxASB1jh06ampiJvFBcXV1RUbNu2bWBgILolJiy4FEflkk6f
hkdU3vyxGk5fCQghkWKFT9evX++/0NTU1K6urugWmpjAp+PHj6dPnSIqPh2jYc/3nRBiHdb5dPny
5Yb08+fPt7S0yM2U8XdoaCi65SYg9KmzRMun1157rdNXAkJIpNjpU6G3tzclJQUZDh8+HN1yExCr
fVpYWJhFsrLKysroU0KIf+z3KZg1axYyNDU1GdIPHjxYV1dXVVVVX19/7Ngx84GDg4PNzc01NTXI
09DQcPr0aXMehL2tra2ow5o1a7yep6OjAyq/cOGCPhGxMxJPnjwpDwcGBuQhSkRBKK69vV1lxrGq
Go2Njf39/eZqoJRNmzYhA/52dnb6eisixGqfZmZmDpGhISiVPiWE+Md+n0JGMjugpaVFJUJn5oXX
KioqhnRtwjBaamqqOY/+5F1dXdKe7Oc8cAcSu7u79QdC7vo6Q6Z4WF5enp+fLydB0aJgyDotLU1/
flwP9+7dq04FvZaUlBjqgAAHag7/PfUBfWoP4fn0V7/61b59++hTQhIEm30KJa1cuRLPQgTKL0ic
Pn06EpcsWYJQDulQp+hV6RLXtIyMjKSkpG3btkG+iB8PHDggXkOoKHl6e3tFuPAgwlI8RJ7s7GxJ
UXUI3qcpKSm41lVWViLMxIsa1nydpIGoE2eAOhG94iFySrCMes6ePRvHQql4Lagn/opeFy9eHN33
eZg+tYuQfPrhhx++/vrr9fX1j2rQp4QkCNb5FCJbfiXQikSmsA+iPJUfSvJoi7rrTwKrigqlwRYi
w35RUZE+D0yKaBRqk4diar06h7XIVyTb0dEhKcH7FOgDT1BaWopEVaIA2yJxzZo12N+9ezf28WNg
SBcRY19+MOgbjaMCfWoPwfgU/1H4t3n++eefeOKJR3XQp4QkCDbPl0FECWcZ+jQlFNUbVqipqUG6
BIYINj2aiCEsQ9enQsJV1QeqEN8hzJSHwfsUFzp9HpSLCiAaNbTcQtmoPGo4PCpcVNJQB0Qr+jpE
C/rUHvz7FD/V/v7v/x4/qB71Bn1KSIJgnU+XLFnSrYHQElGejEHy2o0ok++Q3xDPSsOpijeRInWG
1BDMwlD68UiQmkdrRjbXp6WlxaM1wMrD4H2an5+vz4OfAR4t7vbz2uXkKMvwWhBZe0wxeOTQp/bg
1aeffPLJt771re9///teNUqfEpJo2NZ/Co3K2B5Y0qBU/zVUbby4rDU0NIiX9c+KVeFHPIQXzPUR
OarzBO9TQ/Oy10QDMhUo4GuJFvSpPeh9evHixfb29s2bN/vXaEg+XbBgQZBnI4TELPPnz7dtPBIU
JqGoYVCuOMjrrBOv9Pb2Qn+IW+VsEkXicI+P+BTRMZ4qLS2Vh2H7NPj41NzmbBH0qT3Ap1988cU7
77yzfft2p7+yhJDYJeqNkH7G927btk0itQMHDqhECTn102cEaSgWN8Gh2FdjigQ4UVx8/vz5Yd/9
p2vWrPHo+i5lQo2hD1f6av379MKFCzK41xBfI0DOyMiQdmm8mR5v/acorrm52euk2kigT+0BHyv+
f5z+phJCYh07fQqkJxEXcGWluro6aQce8jYmFgoeHo0fVR+ooKayygL7/sf3qrG1ojz9ahJqLLF/
nwKZ+VJfX29+vSh9ePQHA2quHzQ1NDqJxjAwOHLoU3tAfPrZZ5+1tbVt2LDB6e8rISR2sdmniB8l
qJQJJsM6ncFWiED1czaVmPAXMaCcFlEeDsHfxYsXe7SBTHIeNf9U8sgcVYlGy8rKVAUgNY820hgB
IyLc1tbW/Px8daDk8eVTNf8USkVxkDV28HDMmDHSgKzm0kKgMDjqgENk0C/qH/Ub69Cn9qDvPz13
7txrr71WVVUV5PfrRCDS09MfI4TEBV7H8ERCwPUGxWjQkGq/PX36tFqJSIEUfS8n9CRK1YMfA/qO
V8hL1KynoqJCHy1iX0JUBd4BmDcYnw5r6yMZlmmCmvUTSyFZicH1QOtWdKrSp/ZgHt976dKlM2fO
LFq0yDDb1EzANx8/xiZOnLiKEOJypkyZEvXxSDKx3Y8+cIE6rGFYgFfW74WO8Rf75gOhwr17967X
gJS9Lo8wNLp+L/C1xq+UJXlkQiswr9/r66ZyiI6bmprkcOx4XUgQdUMNJQ/qM2TNzXToU3vwM//0
ww8/bGtrq6+vx7cpbJ9yvgwhcYAV82WIbdCn9hDM+kinTp167bXXfvjDH9KnhCQm9KmroU/tIaT1
e48ePfrTn/60traWPiUkoaBPXQ19ag/h3V+mo6Pjxz/+MX1KSIJAn7oa+tQeeP9TQkhA6FNXQ5/a
A31KCAkIfepq6FN7oE8JIQGhT10NfWoP9CkhJCD0qauhT+2BPiWEBIQ+dTX0qT3Qp4SQgNCnroY+
tQf6lBASkBjx6fnz56uqqmbNmiVL5aelpS1ZssR8BzdigD61B/qUEBKQWPBpe3u73Bnco5kU13ax
qkdb7t7r6rhEoE/tgT4lhATEcZ9Cl3If8IqKit7eXknEFQzBqaSr27oRM/SpPdCnhJCAOO7TvXv3
erS7hZqfkpumIVZliOoL+tQe6FNCSEAc92ldXR2qUV5e7vXZ/Px8XOoN91zD9e3AgQPqjmz6e6QK
HRrY2b17t9yRDWfwdQu59vZ2PKW/QSrCZJzW163Wzp8/j/z4i3JR+U2bNh07diy81x459Kk90KeE
kIA47lMIC9VITU0N8nbbyDZ9+nT9S0hKSqqpqdHnmawhphbq6+vxNzs723A2eNaQjqNwQv35DbcC
b2pqkhNKc7THR3BtD/SpPdCnhJCAOO5TXKxmzZrl0dp1Fy9eDFuZ401Ff3+/6mxFVDg4OIhAFb5D
CjyossEOuEZBi0uWLEGMib9IlFIMtyCHiJGIGFMeioIzMjL27t2LsmDbqqoqjzZKCg8lj/gUIkM2
PLtq1SrEv9F/X4Ijbny6evVq1OH48eP2FBcq9CkhJCCO+3RYa0EtKSnR1wr+Ki8vb2lpGbqyrXXN
mjUeTaaGw6EV6FgpD1dmZFu+fLk+27Zt25AI/ekTkRPalXFQODxFw9C8LEpVw6LEpzjKkM0R4sOn
AwMDcAr+D2FVG4oLA/qUEBKQWPCp0NnZKVNQ9dVD7KnvnURIiERzfyXki3SYTh6KT1tbW/V5RJep
qalDo46W8U5QuTwUUUowq0fahHFOfbb8/Pwove6IiA+f7ty5c+LEifiLT2dwcNDw7IULF/AReD3Q
V3rUoU8JSRBGdFuoxI5PFYhWEJkiCIUsPFqsigh0WBOi1Hm5CbEwdCxnEJ+a243hSqSrZSJQBB42
NzfLw8rKSjzEqcznl3JlzJL41BD8OkV8+LSwsPB73/ueRKmwqj59w4YNqaPs27dPpW/evHmiBtL1
h1gEfUpIgjDibQuSGPSpore3Nzs7G5WU4Ubwo//Xohzny6cHDhxAellZGfYhR1zHcDVWI3uVN30h
J6RPo8vx48fxfnZ0dGB/2bJld999t3oKtcIH9O6772L/hRdeSEpKkg5WSX/77beHtNgW6bJvHfQp
IQmCV58GKVbHfSru009X0dPY2IhnS0tLh7V+Uo82bCnIc5p9igtjRkaGTGhFWOq5sjt15cqVHt3Y
JF/Qp9Fl9erVubm5st/W1uYZdeuQ5s2NGzeqnDNnzly7dq2kI25V6VCw1R2v9CkhCYJ/n/q3aoz4
VHV9GpBBRGp2qrQAd3V1GbLhCtzS0qIE6sunw6ODi3bv3r148WLsdHZ2GspCuuEQuB7VO3z4sDyk
T6MI3tuJEyfm5OQ8PAre20ceeUSeRa0OHjyoMuPZRYsWSbrMC1bpCxYssLSe9CkhCUIwPvUlVsd9
un79eo/WSWq2ZG9vr5hRdXFKCCkNtoqBgQGZRKMGIPnxqQwuKikpQZQ6ffp0Q3FJGoaaIGL16AYg
0adRZN++fXjDq6ur142ycOFC+KW/v3/I5M0HH3xw2bJlkr5//36VvnTpUvGsddCnhCQIIfnUIFbH
fYoIZfbs2R5tBgpiQwSJENaLL764atUqiUaLi4tVZigvNTXVo0WssN7g4GB7e3tBQQFSioqKVDY/
PgVSHGhoaDA8pWabIoDFJR3F1dfXi2QRKEke+jSKwJ7z58/Xp0gv+fPPPz+keROqlXR81ohkVbo0
/A5pES7+gTdv3mxpPa326ctJSeF9i7lx4xY72ySnfTqsLYlfUVFhWJVIDIuA1LB4LzQqg5T0wLky
Bljw71M1gVTNV1XgyrlmzRpDTXC50zdH06fRAuXirTaPzl2wYIH0qMrs4Oeee66trQ3mxUMVtyId
DpV0/ANLukX8cd06x7+n3Lhxi/3tv48f77hPBQSDstwu3Io4sbGxUd1uxgAuca2trcgJ923atMmw
5NGw1p1qWJJXD9LxrL7n1ABEjNAVdaipqYE9DdqV9XuDXB3RalztU4T8Dz/88MDAgCEdlkS61Arx
6YMPPpiTk/Pd734Xn4tkQPq6deuWLl1qSLcI+pQbN25BbjHiUxIGrvZpQFArr3NLfaVbBH3KjRu3
YLbvjRtHn7oX+tQGftffP2/SpJGPPjJvhenp/9zREeF2+7XXOn4d4MaNW+Rb9o030qfuJb59unr1
6iNHjgSfbh1Wj0fKveYaxy8F3LhxC3uLkfG9JBLi26exA+fLEJIghKFRBX3qauhTe6BPCUkQwjOp
QJ+6GvrUHuhTQhKEMDSqoE9dDX1qD/QpIQlCGBpV0Keuhj61B/qUkAQhDI0q6FNXQ5/aA31KCAkI
fepq6FN7oE8JIQGhT10NfWoP9CkhJCD0qauhT+2BPiWEBIQ+dTX0qT1E6NNzp06dO3GCPiUkvqFP
XQ19ag9efDo8PPLRRwvT0n7zyiuf7Njx6ZYtF6qrf7t69e8eeujzpUt/f889f7jrri8zMr6aMEEG
CiIDfUpIfEOfuhr61B4u+/SNN0bmzRvBTnp6GMt7nj96lD4lJL6hT10NfWoP/xmfQqmj8WZIG2JV
P28+fUpIfECfuhr61B7+q733N7+5HKWG6NMLa9fSp4TEPfSpq6FP7eGK/tOvvhoJ8Q7j/YcO0aeE
xD30qauhT+3By3ikoNt+/yM5efDZZ/+ps5M+JSS+oU9dDX1qD97ny/zmN8eTk4OPUv+Yl3dh7Vpz
rEqfEhIf0Keuhj61B1/zT7MmTfrXRx8NtTv1y8zMiytXfvzqq7/u6RGfTqFPCXE/aWlp9Kl7oU/t
wf96DgN79vz7uHHeG3tTUi6uWvVFbq7XZ3HU7x566M+vuebPkpOdvhIQQiJl4sSJuCCnE3ciHx99
ajUB10f6p87OP9x1l9mY/3fhQsnwzx0d//L007+/557/uOoqQ54fJSX9BX1KiPsZN27chAkTbrjh
hjTiQuhTewhmvcFf9/SY237NyyKdP3r0061bh++//9K110qegmuv/VZKivm7qT8PIYQQq6FPbSD4
9XsNbb9+lkX69ZkzA7t2QcFjxoxJ99Z/6qv7lRBCiBXQpzYQ0nr4qu3X/7JICq/je4MZ10QIISSK
0Kc2EOr9ZaTt1/+ySJH7lGIlhJAo4haf/u9RonVCO7H//qehzsEhhBASIZb6FL7IjBKPjhKtE9pJ
YWEhfUoIIfGNpT6NIsqnVhcE3n33XRtKGbHSpwJ9SgghtkGfGrh48eLq1au//PJLqwsasd6nilB9
SucSQkio0KcG3njjDZRy4sQJqwsasdGneoIRJYNZQggJFfrUwObNm1HKzp07rS5oxCGfKsL2KcVK
CCFm6FM9H3/8sZTy2GOPDQ8PW1rWiNM+9QPHMhFCSKjQp3p+/vOfq4I6OzstLWuEPiWEkDiCPtVT
W1urCvrbv/1bS8saiWGfeuhTQggJEfpUgRfy6JX89re/ta64kdj2qSIMn1K4hJAEhD5VvPzyywaf
/sM//IN1xY24xKeKsH1KtxJCEgH6VPjyyy/Xrl1r8GldXZ1FxQnu8qkiwuk2FCshJC6hT4X333//
UW98/PHHFpU44lqfBoTDmQghCQh9KuzcudOrT/fv329RiSP0KX1KCIkj6FPw+9//vrKy0qtPa2tr
L126ZEWhI/QpfUoIiSPoU/DOO+94lalw9uxZKwodiV+fCmH7lLYlhLgR+hRs3brVj0+bm5utKHQk
3n2qiHC6DcVKCHEF9OnFixf9yBRYd7uZBPGpnoCiZPswIcSl0KdyQxn/WHS7mQT0aUDY8UoIcSn0
qdxQxj8W3W6GPjUT0lgmWpUQEjskuE/VDWX8Y9HtZuhTM/QpIcSlJLhP9TeU8Y8Vt5uhT71CnxJC
3EiC+/Tzzz//7ZWoggzpjE8dIcLpNhQuIcQ2EtynDhY0Qp+GQiRzbShWQogN0KdOFTRCn4ZF2D6l
WwkhlkKfOlXQCH1qAex7JYQ4BX3qVEEj9KkF0KeEEKegT50qaIQ+tQD6lBDiFPSpUwWN0KdWEp5P
KVxCSNjQp04VNEKf2kIkPqVYCSHBEws+/eqrr1paWp588sm1a9ceOnTIax7HfXr27NlmHa2trZGX
RZ/aSYTTbShWQoh/YsGnZWVlMMu6devg07Fjx1ZXV5vzOO5TqVvWKPPmzYu8LPo01mDfKyEkbBz3
6VtvvYVqnDt3Th62tbXh4UcffWTI5rhP58+fv2HDhuiWRZ/GGhzORAgJG8d9+stf/nLr1q3qIcSK
Wv3jP/6jIZvjPr3++uvh+uiWRZ/GGvQpISRsHPepgS1btsBc5sVynfWpWH7JkiVjx45NSUnBzqef
fhp5WfRpDEKfEkLCI6Z82trampSUtHv3bvNTzvpUWqGfeeYZiPWtt96aNm1aXl5e5GXRpzFOhNNt
6FxCEorY8WlzczNk+nd/93den3W8vVcfkP7yl7/0eGuUDhX61C1EON2GYiUkEYgRn65btw4yhVJ9
ZXDcp3r++Mc/4q3bu3dvhGXRp64jkrk2dCsh8U0s+LS6unrs2LG/+MUv/ORx1qfPPPPM/fffrx6e
OHECb90HH3wQYVn0aTwR0lgmWpWQ+MNxnx46dMijdU3+QsfQ0JAhm7M+RZVQSenY/fTTTwsLC0tL
SyMviz6NJ+hTQhIcx31aXl5urpU5VnW8vRcynTBhQkpKCqpXVlbG8b3EDH1KSCLjuE+DxHGfCh99
9JE5dg4b+jReCc+ntC0hroY+daqgEfo0AYhkrg3dSoi7oE+dKmiEPk0kIvEpxUqIK6BPnSpohD4l
Otj3SojboU+dKmiEPiU6ODyYELdDnzpV0Ah9SnTQp4S4HfrUqYJG6FNiImyfUrWEOA596lRBI/Qp
8U0kc20oVkIcgT51qqAR+pQER4TTbShWQuyBPnWqoBH6lEQP9roS4jj0qVMFjdCnJHpwLBMhjkOf
OlXQCH1Kogd9Sojj0KdOFTRCn5KoQp8S4iz0qVMFjdCnxBrC8CmFS0jkxKZPX3vttUeDo729PbpF
06ckbohwug3dSkhIxKZPz507F6RPL168GN2i6VMSf0Qy14ZiJSRIYtOnYMOGDQFlun379qiXS5+S
RCOksUwUKyG+iFmftrW1BfTpO++8E/Vy6VOSaNCnhESFmPXpZ5995l+mlZWVX3zxRdTLpU9JokGf
EhIVYtanoL6+3o9Pm5qarCiUPiUJS9g+pW0J8cS2T9966y0/Pn3//fetKJQ+JSQknzKMJUSIZZ9+
/vnnjz32mFeZVlVVffnll1YUSp8SoieSuTYUK0koYtmnYPv27V59+vLLL1tUIn1KSEiw45UQIcZ9
evToUa8+PXfunEUl0qeEhASHMxEixLhPv/jii8rKSoNMa2trLSpuhD4lJEToU0KEGPcp2LNnj8Gn
bW1t1hVHnxISKvQpIR43+PTMmTMGn37yySfWFUefEhIJkcy1oXCJq4l9n166dKmqqkppbvPmzdaV
NUKfEhIlwvYpxUpcSuz7dOTK281E/YYyBuhTQqJLhNNt6FbiFlzhU/3tZqJ+QxkD9CkhdsK+VxI3
uMKnI6O3m7HihjIG6FNC7IQ+JXGDW3wqt5ux4oYyBuhTQuyEPiVxg1t8+tlnn1l0QxkD9CkhjhCe
TylcEju4xafgjTfesKEU+pQQZ4lwug3FSpzCRT69dOmSDaUcHMWGsuhTQvwQ0JJsIiYxhaU+vffe
ezNJZmZZWRl9SkjUYd8riSks9SlUMkSGhrKysuhTQqJOSD6lUonV0Kc2QJ8SYgX0KYkp6FMboE8J
sQ76lMQI9KkN0KeE2EOE023oXBIJ9KkN0KeE2Ewkc20oVhIe9KkN0KeEOEXYPqVbSajQpzZAnxIS
g1g3nIkuTkzoUxugTwmJQezxKa2aONCnNkCfEhKbWOFTNhonLPSpDdCnhMQ4YcjUVwb2wyYs9KkN
0KeEuIWwfcrRTYQ+tQH6lBDXYZ1PqdR4hT61AfqUkPgjEp9SqXEJfWoD9Ckh8UeEPqVV4w/61Abo
U0Lij6j4lEqNJ+hTG6BPCYlXqFSioE9tgD4lJO6hVQl9agP0KSFxDwNVQp/aAH1KSNzD7lRCn9oA
fUpI3BMVmd4/YUJaWloqcRv41NLT0+lTG6BPCYl7ouJTXDMnEHeCz44+tQH6lJC4J3KZzrrxxptu
ummYuJNvfvOb9KkN0KeEkIDcpOG0FkiY0Kf2QJ8SQgJCn7oa+tQe6FNCSEDoU1dDn9oDfUpIglBY
8+Gcmm5s91X1hnosfepq6FN7oE8JSRDm1p6dXds9//t9c2vOalvPfRt/EeSx9KmroU/tgT4lJEGA
T+et65237uy8mt65T/XNf+YXSJlTe7Zo/Qf3bdzo/1j61NXErE936mhtbe3u7o6u4GyGPiUkQdBk
qt8g076i9RDrMwhX5zzVW1Dd5+tY+tTVxKxP8a+Vmpo6WSM5ORkPV69eHV3H2Ql9SkiCYPLp6Fbb
W1TTW/DUr+fU9iJinVvTfV/tKcOx9KmriWWfIjJVD1944QWkvPnmm1Hym93Qp4QkCD59OrrNXdc7
p6Z3/rpTc2t75tT06Ecu0aeuxi0+lZSf/OQn2Dl48OC+ffv27NnzyCOPdHR0IOXkyZPV1dUPP/zw
888/39/fj5TW1lZ1+MDAwLp169599115iMN37NiBnbfffhsx73e/+111lIBjv6eBUiQFz+IMx48f
R+LmzZsvXLgQ6sux2qe5DzQE/BbH8Tan+kzh//gVtjnVpx2vDDduQW5za3sNI5duyphEn7oXt/gU
8SmsgYKwD7VlZ2dPnDjx7rvvfumll/bv35+UlLRs2TKk33nnnTk5OcgG8+KlifjgR5xt7dq1cqoF
CxZAvm1tbcnJyY8//jiOmjlzZm5urmSGYXEg/iJ/amqqNDKfPn0aZ8BrRIk4PNTXsvPQgOPfXG7c
uMXq9l8jl2699yH61L3Esk8N/acSVIpPkSJuBfj3U12rcCLMiLgVMSkke+TIESRCmjgJVDukxao4
9s0330QeZUacClHq+fPnEcOiIDkKyEOEseLTsDtw6VNu3LgFsZ0t/MFZ+tS9xLJP4Tg1xBf6gx8R
iopPESdKtuPHjyOnassFGzZsQPSKnfnz5yMndhCxPvfcc8jW39+/b98+/LsiEYEtUpDn+eefP3ny
pByLbIiC9UOL8f5s3rxZfIqQlj7lxo1b1Le5NfjbM3/1uZzCcvrUvcSyTw39p4sWLZIYE5acN2+e
JB48eBA54TuVDWEsKoMdiBLa7e7uRkA6ODiIRMgUjoaaJSfs/OCDD+IduDyEYN48xKcS+c67ElRD
fIqywnstA4MXb51x76cXvzRvWbfd9e7Jvgi3cTfdNn/dKW7cuMXIFqxJa3vn/qC74Klfa8N9z857
6mzGzVPoU/fiIp9ChYg0h670KYo2mG716tUzZ87EDkyKkBYhp2R++OGHH3/88YkTJ0qYeVpjSGsi
RgrCUsShL7zwgup1Fd58801EtRH6dMj68Ujj0m+5r/YUN27cHN/m/ed6Dr63msvje+et++Dy+N7L
iyn1qBmpHN/ramLZp9LQKuzZswfWgBCHrvQpkDFCiEDFkqmpqRs2bJCnIFY83LhxI/blDEB0uWzZ
ssLCQtkfGBjA+4B4Fi8E8ankB4hnpTs19n3K+TKExAgBTFrdfXnFpMvTZHrm1n5gOJY+dTWx7FM9
iDSXLl0K8Zl9evz4ccSt+CdEImwIUaoAs7q62jM6a7VPi2TxrDx18uRJ+dfFUQha8VdO/tJLL12e
fpKbC03jbNIDS58SQoLES/cogtCanvnPnLo8KeapnjlPfeBrRV/61NXErE9PX4nITujv7+8bHdwr
QKCIIhGBqpFFAo7CsUqv3d3d+nmmCGmhyJ/85CcyiVV/1P79+yFWtcghzoDzSAgcHvQpIQnC3HVn
DaOMLi8zWNszu/bD+zYaF0QyQJ+6mpj1aZxBnxKSIMCnhlFG963+dZDH0qeuhj61B/qUkARhzrru
2Zej0R4/6977IhZ8ev78+e7u7t7eXmer4UboU3ugTwkhAXHQpy0tLYsXL5b5gwIuLCUlJUh3pD6+
aGhogG7KysqcrogX6FN7oE8JIQFxxKeIRgsKClQdIAVcz1NTU1VKcXHx4OCgzbXyxfr161GloqIi
pyviBfrUHuhTQkhA7Pdpb29vWloaik5JSampqYFb1VOnT5+urKxMSkrCs6WlpXbWyg/0KaFPCSEB
sd+nEJNHWyz92LFjXjM0NzdL3VpbW+2smC/oU0KfEkICYrNP5d5bnkCuXLx4MfLgr/kpXNy6uroO
Hz6Mv9j3c5LBwcGOjg7kRNjrv1YwO7KdPHnS67N+fHrhwoXOzk4c6+u3gdXQp/ZAnxJCAmKzT0WU
+fn5/rO1t7fX1dVBVfpE+LGqqko/fgn7SDH3tPb29paVlaWkpKicGRkZjY2N5oIQC+MplW3q1Kko
WiJoWFLyePXpwMDAypUrDUU0NTWF/I5EBn1qD/QpISQgNvsUlw4UumnTplAPhDRnz57t0VauKy0t
hUbxV3paka5XKsJM6Z+Fa8rLy9esWSMHgsrKSv05YVhJLygoQDZRMM4ph/vx6fnz52FeVURNTU1J
SYlUBucJ970JB/rUHuhTQkhA7PQpTCeFHjx4MNRjKyoqcCBMp29Z7erqEvfhWUnBpU9MB4f29/er
nIhDxXe7d++WlNOnT0t0qZe7crHHr0+XLFni0YJZ/ZxZ5JdfCwcOHAj11YUNfWoP9CkhJCB2+hTG
kULNHZoIMLu9MaT1kMKMYsO9e/caDkSKRwtaxZ4tLS0ebeSweXWIVatWeTQJykNEuB5vvaKwoVTS
l09lcXVg7jNFoOrRJvuE8eaEB31qD+H59Oh7fTte76VPCUkQHPGpeeRPU1OT1+rJbBqRJtwxZBqA
hBTpUUUEioeVlZUeH3NtoD85p6h21qxZ2N+2bZs5p8yE9eXThoYGPMTh5gM7Ozs9mtwvXLgQ0jsT
NvSpPYTk0zPdfbsP9T264z9vTkGfEpIg2OlTZTRzey+MOVmHGiMkPq2rq/NoTbheTyvdo7Ae9ktK
SrCP2NNrTjmniFIae5U09fgfj7Ry5UqPJvciE2qRCv2kWkuhT+0hGJ9+2NO3/82+NT/uLX76ips9
0aeEJAh2+hRRm1isvr7ef074SKonYvI/A1T0Jz7V75uRc4oo9fteT+jLp8uXLw/4rtKncYZ/nx56
u+8HP+0tfcb7PYjpU0ISBJvH90r8GHC+jMGn8K9HG4XrNbNEhTKsqLS01ONjkC1sLudsb28f1kyE
fa9rBaN6Ht8+lZFRMbKcL31qD159+k+DX8xc/MM/3+xdo/QpIYmGzT6V8UIebyOL9Bh8KkfhsmPu
l0SKjKoVM8KkHh8jgjo6OuScMnJJgtCamhpDtsHBQUNTsMGnIvfs7GxzETi2s7NTP67YauhTe9D7
9F9+99Vrb//rI40f+ddoSD7NfaAhyLNx48YtZrcZ3/6BI+sN4hria14JFCnDipRPleNefPFFQ2ak
eLQBvQMDA8OjQ56SkpLMQ56knVaFxjL5NC0tTQ5UIM6VogOO7zX3AkvO1NTUIb8LN0UR+tQe4NM/
/Nulgyd+t3b3x45/Z7lx4xaz2/Q/897baBFqMQSPtqIgrCpGG9IWEoSS1AzQWbNmqYUaZHqLwcLY
l+BU38Arzb8oQj8rR1lSNfCiuOnTp4thZSEmlIVsMjHHj0+HR+efop6IeVVia2urSL+uri7qb5ov
6FN7mPntmm9t6HP8q8qNG7cY32z26bCmVOno9AXEBIvpW3dxTVOHwLMINmXCCygpKRnSxYPK1zBj
cXFxWVkZZCE5DeOUEMPqFxsUcEjA9ZH6+/tV6dCxvjL4hTBkV3A6TJ/aBeLT3/z23/5X+4Xy5//Z
8S8sN27cYnaz36dCe3t7eXm5ikbFgIguESTCieb8uKxt27ZNxbYiVq9L5iLgRcSqzozTwrleh/Ii
J4qDQyEU5GlsbEQpBp96vZ84XA/PKlN7tB5V5ByyUabD9Kld6PtPT3/0h+3/57NFm88F+f1692Sf
/23cTbfNX3eKGzducbBNyp5mpwLMQGqyGlJI+YO54Ti8jJxeV1fwdTgunuLHIG8ZI5UxdMLaBn1q
D+bxvf9+6T/ePfv/8v7ifxpmm5q3gG/+mDFjxqXfcl/tKW7cuLl6u/mW220ejxQjIICFjMzjew8e
PCgdtUP2RprhQZ/ag5/5p2e6+146cnk1pP/2g/B9yvkyhMQB9t9PPEaQNQxxKZPpqEJnZ6c09q5c
udLBugUPfWoPwayPdOL9vhcP9K3YSp8SkqAkrE+HdAOcsrOzi4qK8FceGm4AF8vQp/YQ0vq9b5/o
bWjp+87f9NGnhCQUCevTYU2pjY2NBQUFMs8lKSkpPz/f/jFFkUCf2kN495c59HbfxpcCv/n0KSHx
QSL7NA6gT+2B9z8lhASEPnU19Kk90KeEkIDQp67Gap/CF1kkK6uwsJA+JYT4hz51NVb7lPiHPiWE
KOhTV0OfOgt9SghR0Keuhj51FvqUEKKwzad1dXVTp05VC/MePnx4/fr1DQ0NAQ8cGBhYrxFJ6c3N
zVBGa2ur+an6+nqcfNu2bQFP0t3djVdRWlqar4EdHGi+Mdywdtt0exbGp0+dhT4lhCjs8WlHR0dS
UlJVVZVKkZu24DIe8Fh1b/FIKlBWVoYzmJfZP3bsmHorvJpRUVNTo27lZmDlypUGdR44cADpMHUk
dQ4G+tRZ6FNCiMIGnw5pdxrFlV+/aLzNPkXp6k7ieuTG5XKbmFWrVvk6HGaUOiDwfPHFFw9rYAdB
qKRXVFQYDikqKkpJSQl+kf/woE+dhT4lhChs8Cm8g4I2bdqkT7TTp4iOcbh56fsLFy6kpqbiKakh
3OT1TjRIxFNezzCsu1N5V1eXPh3CReLy5cvDrnYw0KfOQp8SQhRW+xTBaUZGBiK1/v5+fbqdPpWy
zPc/lSXxpQ6yeG9jY6P5cNEx8LWor4S3ZtsiIk5KSjp9+nTYNQ8Ifeos9CkhRGG1T5ubm1HK4sWL
Dem+fHry5EnEdLAbLFxQUNDU1GT2aUtLC/K0t7dDVWVlZZM1kFnuBm6uA57yev+1kpISnHbNmjWq
Pl7bhFGQVKC3t9fra0S5VVVVqJUhvaGhweO3GTly6FNnoU8JIQqrfSrOghYN6V59CiWppenxlOwv
WbJEqmo4Fp7ChcijSXDWrFmSp7i42ODNgYEBOYmhApCjjC+S+4Yra3d2dhpyIiyVgvBazCOa/ADd
46jU1FTrBvpGy6fp6emTSOjk5eXRp4QQwVKfwkTiRHObp9mnUJVoq7y8XEYu4fCVK1eqqhqOBWlp
aarXElGkdIbqRxEPjwbIL774oqECdXV1nisD0qKiIo+PHk81HgkKhrIReEK7wVhS7qZqbmqOFtHy
KXEQ+pSQ+MBSn0pLKa755qfMPl2zZg1SEGkaPKXuUmo41mOKJaU/FAbXd3TCj0g0j7OVTk/9tFME
0XK4fhyyorGxUUYlKXAZlOG+XvPrKw93+8oQIfRpHECfEhIfWOpTOMjjo1PS7NOpU6d6vI0IOnjw
oFTVcCziRPNpJR6EWPUpOLMhmwy+NYySUu26vuaNwpuwJxQp2RSIi/Ul6pH5OGVlZV6fjRz6NA6g
TwmJDyz1qYivqKjI11PKp4hJpT5euy/lKcOxXmevSDyoFlPq6uryjI440lNeXu7RjNx9JTKf1Oxf
A6htR0fHpk2bpIlY8Lr4kp93ICrQp3EAfUpIfGCDT732SBp8qoYDeV0AQZ4yHGvuEh0ebd1VJcrk
0AMHDujzIMyUXl0/ICgO8jXiB4BE1tnZ2eZnJUKnT4kf6FNC4gMbfGqeLDNs8ml/f7/Ux+uif/KU
4Viva//KuoIqIJVFigyrNIjjcBEr8oZ0kurHA6M4CNrPmCLVIm2eUCOjnuhT4gf6lJD4wFKfSngY
THuvqMHjrdVUqdZwbGVlpfm0MnFGRhkNDg4mJSWVlJQY8uTn53u0RXf91BkHqqkx06dP93hrNFb4
Ca6lquY6RAubfXrq1Kldu3Zt2bJl586d2FfpbW1tHR0d2Dly5Aj2o1jimTNnXtFx6NAhfbmhckQj
itWLCvQpIfGBpT6VAbcZGRnmp8w+lb7L8vJyQ05ZDNBj8qm5fVXme3pGp+dAzR5TGKsWwG9vb/da
ZzUvVXXCysBjmMvXeg5SQ69LRkhHrXVLOtjp06effvq6664bN27cXXfddZ0GrCpP3XPPPatXr8bO
0qVLsR/GyeHNioqKV1991ZCuFqdSJCcnr1ixoqenJ4xSlmqEcaCl0KeExAeW+lQFbuYZJWafyphb
uEzfsoogUSa2eLzNl9GvCQyXydoRKhiUuauGBmQZcOu1r1Mhg5rwM0D8qCbGoiaGRZCQobm5WZ71
GsBKvGxeziJa2OZTyPSqq65CZCoPoTNIDSkIGPt0Pg07PhVvIgL1n3706FHUAfZ56KGHwiglZuPT
sWPH2vilJ4RYgtXrI8m6uIYRQcM+1keS0URQKgI6OKiuri4tLU3N+jQcK1HkkiVLEB5u27ZNWmWR
X60dIesQ6s+vFsD3OjZYAWlKicqeauEmKQLCRVXxV6bngNmzZ5tX95UGZ4/vhQojB2/OjTfeaPUF
/9SpU4hGn3jiCX0ilJqbm4vPqE/nUwSYe/bsUXmwj3S4uKurS1La29uReOLEiWeffXbt2rUqIK2t
rcUb9eijjxp07NWzsryGtDADnBxF4Gz4bSMp+/fv11cDVYWFOzs7X9VQibt27UL1UBPUR2VGBpwK
9UFVw37HQgIfIt5em77whBDLsNqnMJfHW1+nV58i3EN+/eBbCEstn2s4try8XPyryM/PV9Eodjym
TlJpf/Z4W6/JUA0Rpb7f89ixYxL/GsDFEHX2emMaKQ6qDe6tCgeUnpWVZfUFH97BC5FQ1Cvm9l7Y
qri4eMKECUgpKipCRCkig9dycnIQ+y9cuFBmG0nMi4ceratdtSELXn0Kv3u0VTKkbjg5DkRBKG7R
okVI3L59e3JysuppRR48hDRVey+euv3221ENPMzLy8OBsC3SKyoqoLYHHnjg/vvvxyE7duyI5vvo
DdRk/PjxhqVCCCFuxGqfdnd3I0Yzd6EODAzgKa+B2/nz5xFoNDQ0wEfiKZkcqjLop+FAc40ahomr
SEc2Q6IUGsw9SVEHrzlxhtbWVkTEODkKPXjwoFeTCjLYGK8lYHFhg+twZmZmeJ2JwQPl4YX4yWD2
KWQHMamwFIEn6qlOBcFJOvLDa31Bt/cq8B+FEs+cOQMVStF9WqAKt0KmSEfpW7dulXRIFors0/Wf
IgJNT08X4UqgjRoipFUt2ABxK04SyfCnYMDPRXyI3/jGN5y8ChBCooEN9z+VgUbmJt+w8TOtNXbo
7+9HoJ2dnW3dYvjDmk8R7qmWT4sIw6cITrGjxuVKCy3cYTgVjoIZ+0L3KWyIY/fv349n4U1VEIJN
6VpdsWLFnDlz+rQAEJGmNAUrn6JuCEXV2USaOASflzqVROX6dmMrQEFXX311wAnRhJDYxwafnjx5
EiFqFOdgusKnUknrRiIJ8OmMGTPMw2Kji9xTwNzeq6bJmH2KvxDlPVeC/FHxqbT3In7csWMHdgyl
iChff/11BJudnZ1QOeQrByqfSnhrKEtajA1ns9qnzz33HF7C17/+daeuAISQaGGDT4dHR9VG6zYr
se/TgYEBmC4/P9/S4HRY8+m0adO2b99u6TVfmk/NAkJofP/99/d58yl+PkkTqzrD0aNH+0yhbng+
VeORJD7Vh+ddXV2q9Ts3N/fpp59WdevzHZ/iBwO8ifj0rrvuUok4j3SqWop8NQghcYA9Ph0cHMzO
zi4oKIjK2WLfp1VVVSkpKepectYBn44ZM+bb3/621Zf96urq5ORk1e8J18BHCABhtD7f/adqcsoT
TzwhfZG+fApzebS+ZkO5Bp/Cy4hJ1XwZ6T/9y7/8S3kWbzhKQVXlIWQqw8uVcPX9pzhQ33+6cuVK
aeBVZaGqeIFWt6XfcsstTn7/CSHRwx6fDmuLLTQ1Nenv5xLH7N6929d6EdEFPr3jjjumTJli9ZAk
nB/awj9MZmYmjAkZQa+IE+VZr+N7Fy1aBLvh75w5cyAmGSvry6d9WpeoOQo2r+eAU0GmapgQ4kro
NS8vD+GwtNZCsvIUImJUUr++hH58r7wKPMzRkPAZVsUhCxcuLC4uRkEwsiXv5igoNDU1FdVw4JtP
CIk2tvmUWAF8ihBsxowZ5pZSK5ABRVDe9u3bRUCCr/UGX331VSgJ2tXPFdVXVdpsZR8hKk7++uuv
60s0rDeIE+rniqpzoj61tbUIbw2/K3A2fYCpX88BOeFiVA+iVwqW14Lg+tlnn/UzPyha/OhHP/Jo
K2s5fRkghEQB+tTViE/xd8WKFVZf/EnUufPOO52+ABBCogZ96mrU0jqZmZlWz5Qk0QXx+Pjx4ydN
muT0NYAQEh3oU1cj6+pMmTIlNzf3ySefdFoRJAT+9E//FJ8dV3IgJG6gT12N+PS2227D36ysLLUe
EYlx2trabrjhhpycHKcvAISQqEGfuhq17quEqMuWLXNaFCQopOd03Lhxjn77CSHRhD51Ncqn06ZN
KywszM7OVsNlScyyY8cOBKdZWVmOfvUJIVGGPnU1+vuS4Po8fvx4BKps9Y1lDh06BJni85JbBxJC
4gb61NXofQqZZmZmwqd5eXkc6xub4KfOzTff7GFLLyHxCH3qagz3zUSIOnPmzFmzZsltQElM0dPT
M2PGjKSkJIlPCSFxBn3qasz3oYZP586dC6WWlpYySo0djh49ig8Fn9fkyZOhVEe+7IQQS6FPXY3Z
px5NqXPmzMHVOy8vj32pscCRI0eysrJSUlLw1+tHRgiJA+hTV+Pr4jxTY8qUKZmZmRzx6yy7du2a
OHEiPpS0tLTk5GR7v9+EEPugT12Nn2AHodDkyZNlxO+yZcsYqNpPe3v7ggUL8P3ycAASIQkAfjnT
p+7Ff+OhjPi99957c3Nzodcnn3ySPar2cPTo0Ycffjg9Pf2aa66ZPn06dmz7RhNCnGLChAm4Jk8g
7iSYOYzTpk2T22rDqohYV6xY8corr1h9v9TE5MyZM3v27HnggQfwGxVfq7y8PHxGKSkp1n+PCSHO
c911140bNw6BTCpxJ0F+0LfddtuUKVOwg+v8jBkzEK4uXrx4+/btr776akdHB/UaHhAo3j38Ptmy
Zct99903adKkzMxMvMl4hydOnMihR4QQEq/g5xNiVVnzwaOFrvDs1KlTYQEY9sYbbxxPgkPUefPN
N+fk5OA9zMjIkPcT72FaWprTnzMhhJCQ+f9pYaO0ZW5kc3RyZWFtCmVuZG9iago5IDAgb2JqCjw8
IC9CaXRzUGVyQ29tcG9uZW50IDggL0NvbG9yU3BhY2UgL0RldmljZUdyYXkgL0ZpbHRlciAvRmxh
dGVEZWNvZGUgL0hlaWdodCAyODcgL1N1YnR5cGUgL0ltYWdlIC9UeXBlIC9YT2JqZWN0IC9XaWR0
aCA2MjQgL0xlbmd0aCA5MDE2ID4+CnN0cmVhbQp4nO2dT4jrWprYv4UWWnjhhRdeeCFIQbwwxBBD
DDETMQ7UogKGmOCBClHAkFp4YUKR8aIWgphgEjPUwosK8UIQJzhggofxgBeVxt2YwSQeKBInuHs8
M2La/drz2vTT9KjfaLo1w8k5R7LLVeX7ruxSlVS+3w9uqSRLR6ek3z1/pOPzAbwg+i/+7X8eL742
3p6v9T/+wX/858mXWUB8QH+HO3go33+eycR/+KNfkHfl13/+1e8WxADux6ljv+999ITxNIv/5M++
DSQbP/nTf58I5qacMKH37e/PfhVYRn46a0aDujEnSsh9i3zPCjQr81kxuHtzioTbt7/zddB5+eW4
jc04Hwm1bxfv3EvYy//4Ptap/hFm3/5NsHXphh/8IQrnGyH27Z+GQzdCvv99rFL9Iry+/d2/DDof
W36/HfBdOh1C61vkZ0FnY4fvYS/VJ0Lr2zToXOzyy/+HTTh/CKtv//ivg87FE/5nM+gbdSKE1bc/
DToTz/jf+GrLF0Lq278MW75+iAWcL4TtvjKob4G/V3jBD/GZiB+E07d/8Oug8/CCh0LQt+okCKdv
/yXoLLzkV92gb9VJEE7f/jzoLOzhT4K+VSdBKH07+6ugs7CHHx07xFwYZY88Mp5yFqO4u0y/TJym
3VUA8sckvkn4HQmlb/8u6Bzs46vScVc40iPykTdnrvDFRgtpT0J3GvetpB+TOPrGMf5b0DnYx6/q
R11gea4/0yTCfkR3V3Zwtwt8u648Ocz17cmhmsZ/V174FhV2EgKIwZNVcSfxzTZ4j3coofRtHHQO
9vK7R13g25sk12Rc5avZcYv04HJJzFsqxI1Jps0uVMf0E7qEiwWx2hGIDWyiF2Bsr/lTv4SegOSE
mE2aUKRnk3mOJnc1J+Y1NE1Tp0kX17Z+rrMKf3zJT1NfEzI5g/jQJosLEO4ssqbnj/dtMqUVsH5l
GQ80cZYw2zbPsvzRBCs+GPXdhNI3Pegc7OXhyEvsFEtN53mKbA/Pc+e2IqQWTShZMpTsEaisdNJG
kLWvhLNZG5qTmKAakcTyOuYkIMG8H0uMaULDiSTWzDPQV/noDTmL9XoS6GrkeikJc1oAZ21+xKWR
heRMg7v7mNgwxPJSgkuShMk4IapGHKjMRZY4TViYjROROktwmY+q5M3fooTStzB2T1/rm4tMaB9g
wJ6tXJowZOOceo++dYZ0WbAjdw9JEJPCpsqjWmSZCRkiJ0mGbpipoFO5RJowq091ldenNfqv1edH
ZM7pj84IetMzltD1ihZgqUiWekv3rgKpAa9PacIyV2zeBP2G1tBHtzQ9E0rffh50Dvby1ZGX+Jlv
wL70q+v6ikhUFAD10bepSbcvSTq5IPptGnZ8U9bsFyIXyZLuYmnOR099S9g5Ye0+lb5oDZdkBJkl
WdymIDYlq845KERnB7eBsIMd35QV210bbhN8Y0Lpmxl0DvayPvIS7/FNkxni4plvky7fHgUhp87s
9I5vtDAEx7c82yO5zzcY3BXWTi+hZjZLSZogCHJ9ZtN2Xbo2JkXFlp2Dd33jg7+6ffQtdPjnW4/1
Dwqa0Lmny8EIrlghcz+CNquy5W6kQRv9gqHs+Mbr0SyRJcJqSq2017fiunPrnGXO+hmjETRLNCFL
qdC6EiZaitBqVehc7PqWYQkLSxV9Cx2v863ruMN9y9iaXFq1IGU25Dqt9rKkKTdXI0iaWq6w6kB9
VZJrtHxb9PNOAhL054XCjPm1KuXaZmqrR0svM98uras4iGvbfSA8nGVSTWsCzVUxp9pnRbucU6wi
DBZFWTMlx7dF/5wlPJgX8oNVHH0LHcf65rwWcH1Lj9jPTE9/qNGqLzPU27S/AMp03rygZVO6p89U
AYSbB31IVSuM7pwE4hBpzqcXNCGh9qD3aZHUZeUcXU8OR1GadKTDXmK0N12aeJemnx+KgkoTkgHK
E31CizqRrvZoZkbsYJo4S1hUZwtNekzwjUHfPHOsb59BG/mW1OTat6TeCvTNM2H3rdI2wv8tC/TN
M2/kW7nmU0KNYc6nlN4Q9M0zb+TblwX65hn0zQfQN8+gbz6AviHvyd8GnYE9oG+nC/qGvCfom2e+
kZBXg+03z2B/wQfQN8+gbz6AvnkGffMB9M0z6JsPoG+eQd98AH3zDPrmA+ibZ9A3H0DfPIO++QD6
5hn0zQfQN8+gbz6AvnkGffMB9M0z6JsPoG+eQd98AH3zDPrmA+ibZ9A3H0DfPIO++QD65hn0zQfQ
N8+gbz6AvnkGffMB9M0z6JsPoG+eQd98AH3zDPp2IFexl9vQN8+gbwdC7H7peRRP9M0z6NuBsItm
anlhdxv65hn07UDc67a83ZmlFX3zDPp2II+Xbn4judvQN8+gbwfy5OqNnd4D+oa8E7z3gL4h74ep
oG/Ie/FQS2D55h2cj+tAnly9ZSON7beDwP7CgTxeOqMtu9vQN8+gbwfiXjerX3h8y4C+ecY/3yKP
YZRFCUB6/tLnkbgbMSa+51UkJXp0POb4p0LRpLPHJvkCftVG5SdnQt88c5RvmnOs/GQjjx7pwOIF
fkdUvpHqLrUXH0XbwAOn3hwsSKrxmPAL3LhyfuD0EJ6CvnnmKN+SLMLtbPTkHeJz3+RPh71KS85y
j2/sSCl7TAxJdfSY8HMEI35ocp+ksSfaIPrmmaPr04pB/5dnJXftvJrjvqUqSnzj2xmLSg9yHISL
6gV1M5nMVvh9Z1pESxWJ+UY/K9KaV0rGlYoE0SqR49Q3mVSlHCtF4m70rHSZJyEWr4sRupq/vmQp
7SSc1R5knvBjguWrTe5y02P/Sm+gb545Ov6pcQU8CDND6K87iwfqW9PqDsyCW59eWLR9lrUTsZmu
zWcx0Gamccl2p9WetJx1l0sNIuOlNlskQJ0s+3Mrm34go3Nan47IgzLo0V3bfX6CW6Pbs4Ygzh60
h2UcukttZMmwm/C9boxYwnG6TZ/HQZ2u+nMz42S23nilUJ8BffPMsb7dLlht6pZvJTMBkZkOsk1v
cNUQHd+EFVWyNYT2NALCuA2alRR4FUy16IwFSFoa3M7pZ/c9UO0UCNM7biprv9H6tGhFQDQK7IAE
ixleILGCJYAwLMZZuPBW7WnCrD6lCXf5tj5NMAnC/M7J7ER+pVCfAX3zzJG+RcyrnbUOK4oqOrTm
tF13QWS3v9Acg7AugdGiW1tr0Cbu7lQLXjoONZh36GdNC1QWxFnTdn0T12Uorp02ogCRdI1ISbtf
os1C0ZiUJbr1ScKub2aZ/l6yBXXqJMiImU9bmr6DvnnmSN/KVmRnjTf8L3TQTJ1RdH1LEqmwFoGs
+NbHGLxUC94foDqQtfMZs+WZb3A7gsGtc8S1ThZ9IkFhbNtDCTJ9kzzknibs+sYTlom0SZBx2T/u
j/QM+uaZI33rDnbXePlW1uFuzNYi2+chk5teC4AXhRF44hsv33oa6CxYeETY61uapG2nM3hBSiJk
qW9RiBQXPboQ5fvl04Rd36xN+bbjm7ZbFr8F6JtnjvRt6QSVTzgPPS6tBG2F6VBgfpTI2ca3q7lF
W1q9Ke0vDqZPfGPtt7ihQZu236A73/FNdHzL0/WH6YNzwA2rVhtEqqzo3p1hliRpM9GE3mQnYXXM
E+7RhIX7e9j1bSUd90d6Bn3zzHG+RcgFX276p721NllQTTSz27VvtuVbxJrRTyV9ro2NzBPfEvqD
tlxotDu50EZmbquHZM8KzLelXqMtQlJ1DkiZQ/V+SLLR+VzrW3mgp+ualacJl8k4zjq+OuvCJnd9
y8yPFskj6JtnjvRNcR6gFjcPPy/U4lmRLnO1Gu1KxhUAvsc5fyAhXqpXdC137u58To+Klm/SuRz9
rKSyh3Jp9hlbzyjpNE1IUvLsWcrmhdfZ9U0eiimWUlViz9hurtPPEy4ocZawqKhKZCdBmmThqL/x
ANA3z4T5fX2rF3QOPIK+eSa8vilLMxV0HjyCvnkmvL4llGTQWfAK+uaZ8Pr2gUDfPIO++QD65pm/
CPpeQUQKOgev5lsrfPxxOH37NpAbJN4+DllUSCBZOHnC6ds3gVwLiUjb39G3tyGcvm3bb7nMK/42
4bx2zZ+tZmt8SKVUvWbPMmLlG/ZeCvI3FYl9eF11ng+LJVKS2OZy3PEtItPVVLVKDxJl4UK9eOMB
HV8CIfftnizv8kfeZnGy0Aa2CqAZnXszCxWr37WvIGuMtVVPgK6uDe08VI1O1+bvXeMTMlHE+1Vn
bOSYb5HxOAJVu9djL6lIb9KzXo40Rw4k3L7FeB/L7FxGvvOP2E9xTY9qLODCpgVUZxS3FDbsUlhQ
a+KrcpyNlmzWYFGhhZkjEqtPa2tauN0uBYVw3VL2OcC5nZBIE6Bsf/rbXYg3wu3b2dByNlj3V8d8
Hy+R7+hwywY+RqBksa8aiClSlmV51BdWs8oZ/WC43H7rivk2arHTkoxChgbV9dpgX8KxFIm96Jd3
2nfIcYTbN+pJqWO4Gw/9Ml5EM63pvQ5al6+639SSyZINh+xCqmOS+TnEWkuydIaiMd+csSVEVsiE
VqOgWnzwZJV3JdC31xN23yhCnipBa9VDK7PGihpadcu3ZJmXb9ErmfA+A61TQcgN1xAVINkirKTj
vo1Z+ZZk5VukYtLqlUsaB/TNJz6Ab4x0/aFz6J82GFBXx7rTfmuP4/Yl+76gyNpvkVUzQ9JseKRo
0bItQ/hLUYkuaivafmuuaPsNhMlYSJMC8yyHvvnEB/GNsi3ehGVf2T/nwlNKpNucDWkbn/VPjQzt
n/Z6tM+QMybachaFLu2YWhWo2L3O2nFZNPSqOFp1RmaePw9JWteg2v2udYvlm198HN+2yHQHe1w9
++zflr6uSKIcYeMt2QBI9iiNHRQrqwX2iCVfY0/W6NZa3j3gTMlunr/FZXAm+EhVr7Ps+RvVPSpj
//S1fEDfGu5Os/prHgYjgfABfYNcY+Hut7x7p8uE+MRH9I2SvBnzHcfvcY0Q//igvlES5aFFam9+
gRBf+bi+AXsYvH3pIN18lK8VfNl8aN92qBKyaOZwAEfYORXfnObcul3ARxah5lR8q4zc4fqWt4fB
SDCcim8Ascu++8e0fL9KiF+cjm8U8aK9pkfnP78nEhAn5Rsj15huew0x7D+EjZPzbZfOkSODkTfj
lH0T2EjNI0cGI2/DKfuW2owMnuDD4LBwyr5tRgYzFjiWJBSctG+MdP2BpWjjQ7lQcPK+Afue88jG
gSTh4EvwjRJ7nLWt42FkMPJWfCG+PXJGcGRwgHxxvtWcMxw/TQTyGr443yR3ZDCfJuLtToPs54vz
DdyRwYzFm54G2cOX6Btspom4fevTIM/5Qn0D/jB4OyNJBEcGvxNfrm+7XOLI4HcCfWN02ElxZPA7
gL4xOu5l8DRNBPIK0DeOOzKYgZ2ItwR92+JOE3HwQ7mMUvrsoM5N6MLjoJ2Z4p5yd1+iwib+oCdY
yMT3BX3bJXkztqMHHnNrdOfLzw3p5POxHkvlDkDfY8aeRNOjbTxfL8jvPus/+vaMxy5D3dPI4IKZ
BOHhc18Je5VvI22/b4L0okvNJo2Nee/1oG8OoYifxWrXz48M7vMJptMgqZKzIV7Xmmcg3FzQO6+m
IFLV7nLUt0Jdq9OiU7zSNJUKoSZutDpdChWtKan0g4s7TXEfAgpKW2vQ1FiKUVUq6A9V0MtsR/rh
+Z1WpZpVU7e39JSSyqGV6K12J0O6b9D9C/TMN1orTYs7JdXSNg2E6LXWytDUy1qbBSEWa1r9gvl2
2W6/34s99O1TJN28fGaaiOWl0m9nWFEh8/Wz1aCsmRmomRIMpoI4m1WaVl4ixl19NQYYT6vXiwcA
ot/V9SlAd3XdWBIJGuZNZeFG8h0sqtXZUuTBz2nB6PhmdtUp3aaazepsEgF9MRonicx8q5tTUMxm
uUdy3DcWAH01vmpbBVCW80bLiS4B0fn06s7OCSP9WjWaIIwWlTuD+tZZ1a7fb14z9O2TuCODWXba
nw56SsZjdWDL2/XuPf1xNwJhfF8xJLhiQSBuWxKbyalAoskpbeKfkxgQWiblSSLLZq+uEEmyaXGY
sHgI8uiE6psiyY1vTn3aoZ+TXMIu0R1WNdAH20r6dhmHO+bUXOX1KfXt7oH+F6mzWYhpN6M94hmr
LWlO7holizYSciRbYMsWgSzhZ0vD+4C+fRdsZDDP0Hf4NqG3dvA4fHjdUxSlbdNjTULd6DhlFlfj
jM3/m8hX+nTpuCTV5vTDKJEuCT1K0RtOGjH5SqM7PPGNtd+IXCSsrO0OQK9ufKvygNNittRYb32b
s1n9kyStrOhSdXwbOJMU3/Gsrq6bbNZ22n6rGezMRtWvS/YZ0LfPwKeJ+I6BJAa7tWV9u07GGoMa
MLOzAMNN6BqZ+yX27YdO69E3lVapIBBJMflRZbavoJFZr77fNyeMnDbi6zzRIi8US8ZyWJ9tfdOv
nHPymBOubyOnT6Ox8hd0VWNbzwioa37mgm8X7LtB3z6PePF4N8rPRwaP2vQHL6YceNFylgNo6m09
Ai12W/PqxreKmWD16dY3xRTYdPxSkbDHMDneHy6wyi3FfLt0lju+5QnrfN53tr7lTKaWaLGzLra+
TZhbMkns+tbp0x/nN40Z298sX7P/Q7S/UDX43Nnv9SYPfTuImP18ZLBCq7O4rkLcffiqrpMQmd7T
xpkc0dsg2zkQx+2NbzUjAuLw0bfouiXGxkSKrO8E6iFvv5VIAoQO3UHXWFknQ6+39U1ctgXI08ae
61ty1WSHREmZDTqgvq1F5lvFoB3j0QR2fStYGYjMbtMsDIVqxs9sBcR7AnHrhkUGw/ZbKLnk2Xsy
TUTDnpjDyLZ/KnSsiTGTossWK2EKoFrT9SS28S2uL0fLOnXQXYfcglhNtlwtp3adpxCZrUZ607wE
xV4ZTbrjNbE2vkF2uZwyQ1zfVOd6yQ17PLvv9yFlkXPqm9C2J8ZUeuIbNKzJehSBsjVbrC5YRTxb
j2j1XDD0mVV5rwuIvh1Efk8AuYTMG+zbh6+SnGHxyNlqIs4a/xn30awgCbRdL0chEQV3PZqEhJgi
cdbglzdvp4SsHIN4jB16xnc8SwsJJjg/iCVAU47wRKMSR4QzOQlRmqNoNsKf9yZkVmJFWB6jm3Tj
fBtE5CzPKk1dlFjOc/Kh71SOB307kMcAcqYPYzRTJE9LxPnndzwV0LfDcaeJODig1z7q1tKcffpp
y8mBvh1Huv6wfQkkvGZkcCQjvT43Hwf07fXIODLYM+jb67klODLYK+jb65m6ufZpmoj8nqFHuVZz
367p852Vne5LuuhHRt4C9M0HdgLI+fAesvvSN8m+3zvMffNoje+z08tV9Zf7hgP0zR82AeR8COhl
vBwlLpP9XZJd33bHTqJvh/HxfAN3mojXN+KyM75IK5fdCzhr9poSpDWiyoXCdTcLmVaPDdOM1vrt
EvPtXOs6dadE90mD1Oy1Uo5vWTUJYrXXvmDDXKTbXi0UM2ejb34Sudj+Wjp2zmDVGZSkrPReOWP2
lLaZ5r5p6/lALli35Xs9BpNRuWZWQDVn1TvCheO+pc1B+c6+YL5lzBoI49nVjXEDsjGvq6b3rzW8
IejbGzE+NoDcROYLPlRyyEbPdfq8rtQMWkAtVdoveGgAoWKXLqlvUYD7Nj+A7dNng41aC+pbckVb
kmUjyt6TRmU2EOB65dvf9grQt7ch5ozTPHyaiKjpHMCHSlp9VVUHhuPbiI1X0+iG6QhGZpc98lPZ
4En3+1hsH+OK/5JQjdWcqt7W6d5Nci6z0U7Ku383Zh/o29sQrR4ZQK40cJZ8aAe5dwZvbnzLkh5b
b0CkMjRt1ekv7PhGWNc2RSSVNMxrWtwt+OE53pVA3z7Nx/cNdgPIHRLQS7tylty3NftaQiq79S3G
R8hl09GCAGLDfuHbgg27LNoR2n6rWElosdHDkYso+vYZTsI32EwTYRzSilu5PVzuW3MpQXTe3foG
w2kUkoaasGlBdrN+5ltcYIM9Yw891l8QJhMhy0YItwz07XOcim+MXKOx/T31WfNSm69KcN8iXXtu
TuKPvsUn5szqCHBlLXSj8MS32IpcCRrd/z7On4ckrWu223J1DujbZzgl33YQjM8GkItvnqJEnOGc
kswGK7FxkTHnMXBSltgimmODJvlQys336SNSlI2pZOUjG3kJ8QSbSJHtxodVRiRf/5YjQd/ekTz7
277sAHLo2zuiYAA59O092QkgN/8yZwxG394bd5qILzSgF/oWAGyaiPeaQCFkoG/BENt+Be/sixoZ
jL4FDQvo9eUEkEPfgsYN5/WFBJBD34ImuRNA7uLzu39w0LcQsA0gd/pz8aNv4cCZJkIOOhtvDvoW
GoR8c9uCy5xqADn0LZR0TjWAHPoWRkR+W05xmgj0LYzENyODT26aCPQtnOwEkHuvqZzfBfQtvDjT
RBwc0CvUoG+hJnkzvg86D76CvoWdx17q7ARGBqNvH4YUuzIffWQw+vZhuHYvznHTRIQE9O3jsBtA
7sW3vK4/RjcWfftQbALIvQzotSC3H6HUQ98+GnyaiMbzrWl61aZSANk5EPTtAyJebCM2xNyRwXV2
2Yzw16no28fm0h0Z7E4gHPo6FX372PT59TJ/f3Plwl6nom8fm8tNALkNIa9T0bePzmMAOZdQ16no
2wkg/KsnVy/MdepJ+XZWeouvcYoew4OmpTc4uTfqTy9fiOvUU/KtaY1X4yOjDKiX+7dfl3iYeC+M
1ONO7QOL5xcwtHXqCfmWIxmILF48CfWGvidolbs9/L6lX17BsNapJ+RblsUS6gwAijxsNsSL6foF
iOXGNZsFMlqtn6fPnUhmuXPa5rls1NhQ7fRN41KE4rqd4wcJxXqjLEJEoeVkXGHbzyVyXmbb0grD
jZB2VmuUaBkSv25Uos5qmvkWrTjr70t9zyUMaZ16Qr4xMusKLZOcgkZe65O76GxW75lZSKxG6nQ+
ciJLaSMQx4t618zDhdGq60NomuMyO0YYzxq3xoCWaRKf8Ztur0lk1b9dD6CgaVrXjepcsLuNZRcy
xlidLiXImIOGvlZBWk7U+9W7f+MgLu3jp2b4+IOT8k1YkrEIkHBKGJmUaJtuQQuq1hRuHwRa2T76
VlvR7Y0FaF2AZDe6qU8zyzh7Zr/1zalPmwAlwhPtzZz24apO9zXPpj2maA9GdClZKvTGtMwb9F4t
kC/YQd/FPRgn5Zt4lp0/Dr/mUVUehrQObJLojAoCzUff7sd0e50kqnbnkn3pbtt+i6SK2nPfZBbZ
RWIJrJwBtinCX2BGWVghuDLBZpXXvQpGh6aqGcfl3m/QN88c//wtR7avsvks8Lo+YsR5Has++jZz
tqehPLLsnrjxTezYq2Fnj298Q8XMbJKW2MLpSRRInC81Fcicp3p07n0FffPMUb6VWRGWIttHcNy3
hxb9ETsTJmwqGFq+1ZhvnREMWdCCaFKQ4iCW7NLGt2szzQRy9Co8861gbdrgZ4R1SW7SNut9VA0w
2dMUVr6xeDAJ6Sg9fAd988xRvl1atGjTlgJkJb7OfbtZ09Z7ZwHVVRziqxGUrARfXrGd71bifY+F
SKO+OWGEbhcCCPdEiBEFhCHz7XrrW9Z8nAN1TnU9t6X+JALReRu0aQRStgrtRQyEUUi+UYW+eeYo
34Su0Zsvc4/9U+abMDCH83WOfThc0v5CdG6MVu0RCB1r8GDkaQ9z3l+NRBhavOOZMqfaok1S0LbH
Oq1XoWMNN77d2zqDp51dzwdUv/hsOVhNYnSpD1ZTFaKT9VDXk5/K4dtxtWfiB/TNM0e23zIKn+PF
Ld+i8mYj71PmFImFBBILpXic1YYppci6nNGCkgX20irL946XSgnIxdnuKZEmIOay/H2WKItpmeOc
KlK4ZI89hLzCn9sJF5fxJDutrJwHMc0Msful5+dF3zzzRu/rtZC05P2HXTRTezojK/rmGfTtQNzr
trxNP25D3zzzRr65Ic9OkMdLN7+R3G3om2dw/NuBPLl6Y6f3gL4h7wTvPaBvyPthKugb8l481BJY
vnnnm70DbJBP8uTqLRtpbL8dBPYXDuTx0hlt2d2GvnkGfTsQ97pZ/Z1J9NE3z6BvB8Kv2qj8ZCg7
+uYZ9O1AnB7CU9A3z6BvB9JIv9yGvnkGffMB9M0z6JsPoG+eQd98AH3zDPrmA+ibZ9A3H0DfPIO+
+QD65hn0zQfQN8+gbz6AvnkGffMB9M0z6JsPoG+eQd98AH3zDPrmA+ibZ9A3H0DfPIO++QD65hn0
zQfQN8+gbz6AviHvyd8GnYE9oG+nC/qGvCfom2fw+84+gO03z2B/wQfQN8+gbz6AvnkGffMB9M0z
x8fPeh7mL/04h72kAqiS97REAMVb0LOdk4QI9M0zx/oWXT6foVfRt7+y+fE9hpZkXPQBRpqnXXdO
EiLQN88c61vP+IxvB6CO0DffOS3fLmcN5ltVdlYTzVG9QlWI1Ib9kuObKuVY3SeqZ5C8G92lAAqF
m4ET+vSyO+rkqTzs6Go6PdLV6Ei7GvTzEFU5zmwwUnOkZWlRqvJEIdYcNdhJRHqST8SIDgj0zTPH
+SYZaVYowdhpTkWX98qdqYMwfriqrupufZohZ1QyM5Ix20rLzIBmPPS4b/VVVenaKSdMs644vpmD
ctdOc99WesQ5SV9p2anofFqumQ2ILkY0GXaSGT3JkcGl3wb0zTPHxTMa13gluOFaFwC6OpRNWjDl
7bjbfnuoA/TbMOzSXTpD6ps7Y5rGYq+tlY1vTn06o78vWRA2qJpOmKK7Kdu3yuOnXpCzyooe3tGh
ZMZYcMLncxQFCfrmmaN8u5kIT3zrs4hYZR3aOi2d6qTg+lZdQMzKgdWnW/vmTgyQ+EVFs575xtpv
fEPRyjt7MV0pgy6/pZcaC65b1KG1ZGUgi/AbGtA3zxzlm32vaQ8rbRstjctyoYOma4yc6xuVrTKn
v4341kff6vZUq6w+4VvOLLu7ucHgnJ6EofTZUqYnWTknOdKNtwB988xRvrEChja6pM16i5l0rUOT
VYqRYnTzPKR3SyteWN3Qran81jeJ0Na+YFLfGs5y17fkY8tseEd/XF232WEJkm9O2KoO6oIuxdKe
MH2Bgb555ujnvbw+LTqT72Vp7ZbQdUjb1yC0jK1vF2ubNrMa6xTEF92tb0lSoIeTCnRnUUElCtzo
McH1LT7vRSVJ4v0FxUhBYlXN0cTF/lJM25c0GR3ObOpw0wxTwCT0zTOv882t8uDKWhp9HeDSWK1X
ue3zXmE5pB8KbaJb97HH+rRlT5ft0R2klqbRGyuQtUjG9U1xcuW8u2jYutUW4MpYGQ9J5yR39CSF
9Xq9uniNH36DvnnGp/enkZzzyExMp4WXn8ZyT3uTCXdvISM5R0t7DqJEc7zWFDNnT04i7D1JgKBv
nsH39T6AvnkGffMB9M0z6JsPoG+eQd98AH3zDPrmA+ibZ9A3H0DfPIO++QD65hn0zQfQN8+gbz6A
vnkGffMB9M0z6JsPoG+eQd98IJS+fRN0Dvby46Dv1SkQSt++DjoHe/nDoO/VKRBK3/Sgc7CXXtD3
6hQIpW+ToHOwl1B9r+6jEkrf/nvQOdjHt5Wg79UpEErffifoHOzjZ8Wg79UpEErf/t5fB52FPfwk
GvS9OgVC6Rv8LOgs7OF/BX2rToJw+vZ7QWfhJda/DvpWnQTh9O03w5etH4dpFo6PS/huLPNNCN8b
hv8T9J06DcLpG/x22Obp/5kc9J06DULqm7AKOhPPGAd9o06EkPoGv/XroHPxhFUq6Bt1IoTVN/ij
oHOxy9/gu1OfCK1vib8IOhs7/CgS9H06FULrG/zGt0HnY8tXUrA36YQIr29Q/VXQGXFZ/6Ng79Ep
EWLf4C4cwn1T/s4riBxCmH2Dahiq1K/zQd6fUyPUvsFv/CLovPzNn50FeHdOj3D7BokfBfsc7hff
w56pr4TcN4Df+mlwr7Z++X//YVD35VT5SzN8/PBJDoXf/nkw/yl++eN/FtBNQQJF+M3f+9p6Z9m+
+cl/ygT9dyPBkfqd3h/oq2/eoXT9+Vd/8oP/eoO9hC+I/w9KeqSBZW5kc3RyZWFtCmVuZG9iagox
MCAwIG9iago8PCAvQml0c1BlckNvbXBvbmVudCA4IC9Db2xvclNwYWNlIC9EZXZpY2VSR0IgL0Zp
bHRlciAvRmxhdGVEZWNvZGUgL0hlaWdodCAyNjAgL1NNYXNrIDExIDAgUiAvU3VidHlwZSAvSW1h
Z2UgL1R5cGUgL1hPYmplY3QgL1dpZHRoIDYyNCAvTGVuZ3RoIDExMzAzID4+CnN0cmVhbQp4nO2d
b2gd193n54UgBsFqQTR6qFp1K6jTun1M7MatZVm1E0eJ2zhYTZNUjbuRUydRijerPNpYdk2wg7um
mKIsLriYrAIuj/rggEBdBC44rIq6OKAUQUUjW9n1C73wC4FYBKt9/+zX86tmJ3Pvle+Rzp2j0f18
GMTVmX9Hd0a/z/zOnDkTRQAAAAAAAAAAAAAAAAAAAAAAAAAAALBZ+N73vnfgwIGDUAWHDh3q7u5+
5plnQh802Ao88sgjjz766OMQjieeeEL/1KFPBNg6dHV1hdZUkZBMf/CDH4Q+aLBFCO2TeufJJ5+U
UkOfBbB1kB2WoWp+EBP6oMEWYQWCYlYNfRbA1gGfOqGv6/vf/37ogwZbhNA+qXfwKfgFnzqBT8Ej
oX1S7+BT8As+dQKfgkdC+6TewafgF3zqBD4Fj4T2Sb2DT8Ev+NQJfAoeCe2Tegefgl/wqRP4FDwS
2if1Dj4Fv+BTJ/ApeCS0T+odfAp+wadOrM+nx1apxRGE4hLaJ/UOPgW/4FMnnHz66quvnjhxwn5K
pj/72c9qeiihcIT2Sb2DT8Ev+NSJanyaaPS1GH3WTyvM55hCUQjtk3oHn4Jf8KkTa/i0rEZfX+XV
mJwPLmxyQvuk3sGn4Bd86kSpT9fWKD6FNQjtk3oHn4Jf8KkTiU+r1GjGpwBGV1dXlItPz1ZgdHR0
aWmp+u3cu3dPa924caPKnV69enW9Vc4PfAp+wadO2PtlzJ7VaBSfQiWef/75S5cu/eUvf6mpMtb4
329vb5+fn69yO3Nzc1pFoqxyp7pg2ECtcwKfgl/wqRPm0xdeeKFKjQKszeTkZE2VEZVTm+R45MgR
zdLPKrfj5FMlp+Pj424VDQE+Bb/gUyfS+Wl/TPX5aa0jMxSLn/70p6dPn75161ZNlRFVSBWXlpaa
mpoaGhqqbPV18mlRwKfgF3zqRHL/1EJi9VmqNfG9BhBz6NChKJf7p1Hlptft27dr7t27d5OSmzdv
Hj58uDlGoknnmGmfXrx4Uducnp5Ob21iYkKF+qnP+nDy5Ekrv3Dhgn5dWFjo6+trbW2VxLXlzH3Y
2dnZnp6elpYW7VcftC+tohX9fAWVwafgF3zqRKZ/b2LV12KxKl1d26cBDzRsQmrti5XKPpXRNKut
rS0puXLlitJVlQwODg4NDe3YsUMLXL582eamfSrP6rMWS2/w+eef37Zt27179zI7tWHB5G5tcGBg
QL82xMzMzNgCkmljjP59bL8SaxSPKlaD7+Nz4FPwCz51otLzp4k333jjjbJWxadQSq19sRKrTS67
mkLZpVJFuU9SGxsbs8WUpapELltcXLQSne1yogotgU37VLNaY5K9SKNaUqllstOMT5X2ai0rGR4e
VonUab92d3erJkqN0/uN8CkUEHzqxNrjIyUmPX78OD6FB1JrX6xU6N8r98liicJWVh03MjKSXnd0
dFSFly5dWim5f6rkVL9a6+5KnNvq18TOUYlPkyWTTZkuJeKopFuUKhbhUygg+NSJasYb1MV/ugXY
+izhUyil1r5YidW2Z8+euZhbt24pOW1sbNy9e3fS3GropNWSkuyxFNYHWLNWSnw6OzubzBIdHR0t
LS3LqxloVOJTrZ7sK+1Ta3bOdHNaWlqK8CkUEHzqhNN4+Jk+S/gUMtTaFyvl7p8qi1Sh9Jd++NSs
J/N2lWD9gkr798qhUrPcZ7MGBgbK7nQdPrUt4FMoHPjUiXW8ry3d6lujgwgFpda+WKnQH6m/vz9T
biVTU1OVtlPqU2vjHR0dPXfunD6ku/tGVftUKbM+J52BSxeoKfgU/IJPneB94uCRWvtipYJPFxcX
29raNGt4eNhKRkZGolQfIePatWs7d+7Uz5VyPtVGtm3b1tvbq2V2795daadr+1S0traqMunHYC9e
vBjhUygg+NQJfAoeqbUvVio/LzMxMaFZTU1N1uornUlqDQ0NSZck5ZstLS0y5uzs7EqF8RykvMbG
xijl5dKdPtCnly9fjuIOwMpVVRltStWI8CkUEHzqBD4Fj9TaFytrjudgpkv61s7MzFjSKo3aB7ly
dHTU5pb1qd39lHMXFhYq7fSBPhXKi82htjXrPIxPoXDgUyfwKXik1r5YWXMoXUnQnkhNnjlVlqr8
dGBgoL+/X3lieugkLaMlM6MjWkfc5LHTsju9efNmehfJptJP6whlpqMxqpVS46ik8bkW4FPwCz51
Ap+CR2rti1pjD6hucOh7Jcjnzp1Ll8i22mwOb3zDp+AXfOoEPgWP1NoXtWNiYuL69evtMRvclIzW
0NAgNS/Hj69qyy0tLU1NTTZ0YU3Rrv9re/u/RlH9TFBT8KkT+BQ8Umtf1A75LorvdVb5hvE1mJmZ
sZH5E1pbWzOtwTXid1/5SnDB4dOtBD51Ap+CR3JQRo0YGxu7dOmSdf3dOPrPkpeHY8bHx6t8hdzG
+e9f+EJwweHTrQQ+dQKfgkfysQZUYvxLXwouOHy6lcCnTuBT8Ehon9Q7jz/++D/XWZMv1BR86gQ+
BY+E9km9Uw/9e/FpnuBTJ/AplGV98Sq0T+odfAp+wadO4FMoy/oa1sLaxF4NkyE98MKWB5+CX/Cp
E/gUyrK+O1ZhbWKjBZbS0tIyNDS0vPoy03Vz5cqV9AhLmxB8Cn7Bp07gUyjL+rqChLWJ+XTnzp1n
U/T19cmnKu/t7d3Ixi9cuBB9ftjeTQg+Bb/gUyfwKZRlfX0sw9rEfFo67LySSlPqzMzMujcuNUf4
dBOAT/MEnzqhr6vv8ceDd3pnKvp0IP7vC2uTSj4VAwMD0edH0JVkR0ZGLIcdHR1N32bVLG1qaWlp
fHz83LlzN2/evHXrlr1W5tq1a5OTkwsLC1qgdPCHyZga/XXVgE/BL/jUCX1dp/buDR6NmbbAFG16
nybvQr148aK9T015q31obm6empqyuTZ8/dDQkIWU1tbWrq6uJMK0tbXJp9u2bevo6EjvYn5+Xpvq
6+ur9Z+5BvgU/IJPndDX9Z937Qoeipm2wHRdPs1rYL2yPLC911prlW/qs7xjLznVf8GlS5ei1Gva
zKcy5oULF8bGxq5fv75S0t6rhfVrOkW1G6z5jNNbCXwKfsGnTujrOvPd7wYPxUxbYIo2R35aqT9S
kjleu3ZNqeX09HR6XS2zfft2+2w+zWSaGZ/Ks/o1/V62HTt2bPzdNBsEn4Jf8KkT+rp+duBA8FDM
VPTp6fi/L6xNKj0v09raKhsul3te5t69e1NTU5cvX25sbGxra7NC8+mVK1fSS2Z8qq1JwYlAb926
FX1er0HAp+AXfOoE/XuhLK4+NcLaxHza09OTHs/BGnUzjI+Pd3d3Nzc3W7Ul023btmV8OjExkV6l
tH/v4OCgSqwD0smTJ/V5fn6+hn9eFeBT8As+dQKfQlmcNJoQ1iZr9EdKMzIyEsVJ68DAgD4rtdQ/
QluMLWA+zbwItdSnMzMzKpFJtbrULJF5/4tcwafgF3zqBD6Fsria1Ahrkyp9umPHjoaGhnQuqX+E
0vz0gT4Ve/bsaWlpUSYbpToPBwSfgl/wqRP4FMrialIjrE2q9Gl7e3tjY2P6Hd/WNbcanyqZTRde
vnxZhbJqZoOhwKfgF3zqBD6FsjhpNCGsTar0qT2LKu+Mjo5eu3att7dXyWlzc3NTU5MtUNanpk7l
tulxC+/du6d1o5LOwKHAp+AXfOoEPoWyrC9khbWJkseuri4lm2svptP+5MmTsmcU90Tq6emZmZkZ
Hh7WuvY86fj4uD5nUtHFxUUtKe0qjU0PpiS9RqEfO03Ap+AXfOoEPgWPhPZJADo6OoI/dpqAT8Ev
+NQJfAoeCe2TvLGhli5evBi6In8Hn4Jf8KkT+BQ8Eton+XHu3Dllptu2bWttbb13717o6vwdfAp+
wadO4FPwSGif5MfVq1fb2tqk1I28A847+BT8gk+dwKfgkdA+qXfwKfgFnzqBT8EjoX1S7+BT8As+
dQKfgkdC+6TewafgF3zqBD4Fj4T2Sb2DT8Ev+NQJfAoeCe2Tegefgl/wqRP4FDwS2if1Dj4Fv+BT
J/ApeCS0T+odfAp+wadO4FPwSGif1Dv4FPyCT53Ap+CR0D6pdyTTzs7O0GdBbcGneYJPncCn4JGO
2nP1S1/6l3/4h+GvftXjNuUgj1sLyLe+9a3vfve7oc+C2oJP8wSfOoFPwRdf+cpXvv71r++tJR+0
tiaB9Epb28Y32NXV9e67777++uv6R5CPNr7BgDz22GO7d+/+5je/GfpEqC34NE/wqRP4FAqE91gq
k/b397/22mvHjx/XTx+bhNqCT/MEnzqBT6FA+I2l58+ffz0FPi0E+DRP8KkT+BQKhN9Y+sYbb1hj
r8lUvPrqqx5qCbUEn+YJPnUCn0KB8BtLrbE3nZ/qp4daQi3Bp3mCT53Ap1AgPMbSTGNvciNVP/3U
FWoDPs0TfOoEPoUC4TGWpht7E1RIirrJwad5gk+dwKdQIDzG0kxjb5q+vj4/1YUagE/zBJ86gU+h
QPiKpaWNvQnHjx+nV9JmBp/mCT51Ap9CgfAVS8s29qY7+nqrMfgGn+YJPnUCn0KB8BVL12jsTcq9
VRq8gk/zBJ86gU+hQHiJpWs09qaV6rPe4A98mif41Al8CgXCSyxdo7E33epLr6TNCT7NE3zqBD6F
AuEllq7R2JvIlOF8Ny34NE/wqRP4FArExmPpAxt701b1XHvwAT7NE3zqBD6FArHxWPrKK688sLH3
9dVevjT5bkLwaZ7gUyfwKRQILz49fvx4WYFmSrQYPt2E4NM8wadO4FMoEBuPpVLkq6+++loKs2em
0N41g083Ifg0T/CpE/gUCoT3WJr2KcMiFQJ8mif41Al8CgUCnwI+zRN86gQ+hQKBTwGf5gk+dQKf
QoHAp4BP8wSfOoFPoUDgU8CneYJPncCnUCDwKeDTPMGnTuBTKBD4FPBpnuBTJ/ApFAh8Cvg0T/Cp
E/gUCgQ+BXyaJ/jUCXwKBQKfAj7NE3zqBD6FAoFPAZ/mCT51Ap9CgcCngE/zBJ86gU+hQOBTwKd5
gk+dwKdQIPAp4NM8wadO4FMoEPgU8Gme4FMn8CkUCHwK+DRP8KkT+BQKBD4FfJon+NQJfAoFAp8C
Ps0TfOoEPoUCgU8Bn+YJPnUCn0KBwKeAT/MEnzqBT6FA4FPAp3mCT53Ap1Ag8Cng0zzBp07gUygQ
+BTwaZ7gUyfwKRQIfAr4NE/wqRP4FAoEPgV8mif41Al8CgUCnwI+zRN86gQ+hQKBTwGf5gk+dQKf
QoHAp4BP8wSfOoFPoUDgU8CneYJPncCnUCDwKeDTPMGnTuBTKBD4FPBpnuBTJ/ApFAh8Cvg0T/Cp
E/gUCgQ+BXyaJ/jUCXwKBQKfAj7NE3zqBD6FAoFPAZ/mycZ9+tvf/jazzYcffvj8+fNe/LXZwKdQ
IPAp4NM88eXTX/3qVxMx77///iuvvKKSX//6114UtqnAp1Ag8Cng0zzx5VOZNF34j//4j3v37s0s
ubCwkP71Xsz6drrGunfv3l1jrfXtLgGfQoHAp4BP86RGPn3ssccOHTpkn5977rl33nlHJVpMqatK
Pvroo127dlkFZN4//OEPKtQW2traPvnkE1tLCa9+/fjjj+1XZbsmaK2rVWzdr33tax9++GGy01/+
8pdf/OIXVf7QQw+99NJLiT1VgTNnznzjG9/QrLfeemsjfyw+hQKBTwGf5on39l7x5ptvNjQ0JIbd
v39/U1OTpPbee++NjY1JkY2Njc8884w+yJ4vvviiFpYlFxcXVZ60Emst22zy68svv7y0tPTwww/L
lTMx+iB1WkIqmWo7Wn52dvaPf/yjVHvw4MFkXS2mHWnjmrWRPxafQoHAp4BP86QW/ZHE008/nbS7
SmeSoFRov8pryiKTX/VBmePRo0f1WZLVistxw6zkqJRWJctxQ7F+VRr72WefaePysq2rXWjvmquN
NDc36589qZW8qSXNnqqA9LrBP9PAp1Ag8Cng0zzx5dMPPvhgNkZpoz5LoLKkUs7lWGciWV5qk1LT
W/j5z3/e1tZmm1KKqrU+/PBDbcF+lSu1QStfXs1bd+3a9fbbbyfJpvJcFUq+Z1bRXJUoabVVMntc
N/gUCgQ+BXyaJzW6f/q73/1Ohb///e+XS3Qmdb700kvphaU/86nyTduUDPvcc89ZNvrRRx+9GGML
y6q/+c1vDh06JMNG8e1XLWbZqApf+jxJBTJ7XDf4FAoEPgV8mic18unY2FgUJ63LJTrbu3evNeom
HD16VMlsMvett95SDitpLsfJ7DvvvNPc3Pz+++8vx43DH3/8sSWq+ilrP/TQQ1rezGurGOkl8SnU
J/gU8Gme1MKnSjMPHjwo00lzyyU6O3/+fENDQ9Jx95NPPtGSb775ZjJXuao2ODs7uxw3BT/88MNa
wDrrTk5OapY0agursKmp6e2339bnXbt2ScpJn9733nsvSt0/xadQh+BTwKd54sunsl7bKlH8xEqS
LWZ0ppxRSag8+FqMPjz22GOJB+1OqDX/ig8//FC/Jj11l+M+S42Nja+88oo0KoFqv3Nzc8uxarWp
9vZ2pavWZzjZKT6F+gSfAj7Nk4379M9//vOZFEowP/jgA8tMDQnX7mMmLC0tvf/++y/HaG7S19fQ
FtIZqLaZfshFC8vUWlGK1JLp0Ru0U5WoXLZN77G0AusGn0KBwKeAT/OE8fCdwKdQIPAp4NM8wadO
4FMoEPgU8Gme4FMn8CkUCHwK+DRP8KkT+BQKBD4FfJon+NQJfAoFAp8CPs0TfOoEPoUCgU8Bn+YJ
PnUCn0KBwKeAT/MEnzqBT6FA4FPAp3mCT53Ap1Ag8Cng0zzBp07gUygQ+BTwaZ7gUyfwKRQIfAr4
NE/wqRP4FAoEPgV8mif41Al8CgUCnwI+zRN86gQ+hQKBTwGf5gk+dQKfQoHAp4BP8wSfOoFPoUDg
U8CneYJPncCnUCDwKeDTPMGnTuBTKBD4FPBpnuBTJ/ApFAh8Cvg0T/CpE/gUCgQ+BXyaJ/jUCXwK
BQKfAj7NE3zqBD6FAoFPAZ/mCT51Ap9CgcCngE/zBJ86gU+hQOBTwKd5gk+dwKdQIPAp4NM8wadO
4FMoEPgU8Gme4FMn8CkUCHwK+DRP8KkT+BQKBD4FfJon+NQJfAoFAp8CPs0TfOoEPoUCgU8Bn+YJ
PnUCn0KBwKeAT/MEnzqBT6FA4FPAp3mCT53Ap1Ag8Cng0zzBp07gUygQ+BTwaZ7gUyfwKRQIfAr4
NE/wqRP4FAoEPgV8mif41Al8CpuZf3WcXMGnhQOf5gk+dQKfwmYGn0IGfJon+NQJfAqbGXwKGfBp
nuBTJ/ApbGbwaZ1T6xMA1gafOoFPYZNT01iKTzc5+DQs+NQJfAqbHHxaz+DTsOBTJ/ApbHJqGkjx
6SYHmYYFnzqBT2Hzg0/rGXwaEHzqBD6FzU/tAik+3fzg04DgUyfwKWx+8Gmdg0xDgU+dwKdQCPBp
PYNPQ4FPncCnUAhqFEjxaSHAp6HAp07gUygE+LTOQaZBwKdO4FMoCrUIpPi0KODTIOBTJ/ApFAV8
Wufg0/zBp07gUygK+LTOQab5g0+dwKdQILwHUnxaLPBpzuBTJ/ApFAh8Wufg05zBp07gUygQ3qOo
HHrixAn9NKV62irUCmSaM/jUCXwKvnjkkUceffTRx2vMkwcP2uRla0899ZT+BZ599ln97O7u9rLN
gDzxxBOHDh0KeA48+eSTT8TU7m8c2LUrkenPv/3t2u2oiDz99NM6k59//nlfBxSfOoFPwSOhw0m9
YzoLeAIcOXJEdcjhL/0fX/hCDnspIs/H+Dqg+NQJfAoeWYGgWEQNeAIcPXpUwTyHv/T/Li7msJci
gk8Dgk/BI6FjSb0T3Kc/+tGP8vEpVELfv46CrwOKT53Ap+CR0LGk3sGngE8Dgk/BI6FjSb2DTwGf
BgSfgkdCx5J6B58CPg0IPgWPhI4l9Q4+BXwaEHwKHgkdS+odfAr4NCD4FDwSOpbUO/gU8GlA8Cl4
JHQsqXfwKeDTgOBT8EiecWNhYeHmzZs3btyYnJxc5On+GHwK+DQg+BQ8kk/EuHr16s6dO9P7bWho
6O7ulljzqUApZ8+eVTVUsVAVMPAp4NOA4FPwSK1jhfJQedP2JXEMDg5KZCdPnty+fXsUW3V0dLTW
dSgLPjU8+vRGOWiLeCD4NCD4FDySQ6zQXmTPqampzKzLly9rVmNj4927d2tdjVLwqeHRp5V2oaum
EydOKHZ52cvWA58GBJ+CR2oaKJSeaBdNTU3z8/NlF+jr69MCQ0NDNa1GWfCp4denO3fuzOSnly5d
amtr0yx94V72svXApwHBp1CWA2/+T5uc1qppoDhy5Ih2ceHChUoLTE9PHzt2bHx8PF04NjbW0dGh
pEbrtrS0nDx5cmFhIbPiyMjI7t27bRmF64GBgXv37qUXWFpaUgC3SK4UWHvRRrq6upLKlPp0cXEx
WUVb3rNnTw5t0VvMp/qGS8vn5ub0fTY3N3vZy9YDnwYEn0JZ9p26c/DN/7Vv6M6+U7c7Ts3t/aeZ
ataqXZTQuSqRaRcKp9WvJTNGcUorAw4ODkqa+rW1tTW9kf7+fltG6a2Wt55O27dvT9qNtWsFdhW2
t7drAW1KNbE7tvpsy2R8KplK4irZsWOHVtEupHL9qjp4+j7KUw8+FXaVki7R9Y9S12Mx+pC5HNLh
uHLlis3VIbh161Zmg7oSU7nm6hzQQVxONSYrKdbBzZx1KkmOtS2gVc6dO6ct6NrMynUNpp1qgyrU
ApnbEKrh8PCwVenixYuZCm8EfBoQfApluW/S03c6h+b3Dc13/NNMZ3Vi9RUTSpmdnY1i61W/irUP
Z+yp/DRKBerr169HsSjT9jxx4oQKe3p6rMTuzMpTipBWMjMzo/woquxT20v6Np/yWTN1TTsh14NP
5+fnM/mpvlK7XNH10p49ezRXv+oY2VypShc/KtRcbdCuynRMk9XlX83dtm2bLoF0JkRxO3NyPtiR
1blUqW62gF2VJeU65WxTuqDSZrVx7Tc59KqbTstMhX2dGPg0IPgUyrJv6LZ8uv/MvE1VitVLQCiL
yVGJSWn52RJsloSoVZJ8wdA5b9mNUpKVWED6nGkiljdNl3aj1rLaJD4byimiCj7V6hY/E/8a5u5k
lVqwxXwq18yl0CHQ0bSWgaSlXV+y3KTjlWSdOrLSk46yff9aUsuPjY3ZXOlVpkuOjg697Si5C6Ck
Moovn+zXKn2qCkxMTKiGdl5prix57dq1pErao/ZrFVbddGWYCNQqrL8ic8KsD3waEHwKZcn4tEqx
bjwaVGJqaiqKk81MuUWzDDbLEoTSljRLJcyzlq2UxjHrSCwDalYU33jNLKAYGFXwqeJkFCcmmb40
iq5R3JLs4/sozxbzaVl0yM6dO5csZvpTjpleV79G8eFbWW0rSF8y6QDdvHlzOW46sJvys7Oz6dXt
6JsZq/Rpukqyqkp6e3vTq+gCTGeLzkadeJqrX9NzrQ0kc+23PvBpQPR1PX30pY7TCp6374fQ4k+P
/uy/feulf9a05+Sfg1emwNPpO2V9Wkms/+bLe6Ja+lSByP7BM48fKiu5msKWsVnpz2ksAFoaG5XL
ecXg4GAU+1FpUdllrLysT0dHR9cIUGV354st5lN9V0mbg93C7u7uzpwA1jg/NDSUPg3s8A0MDGgB
qTOKu4RZ/zGzZIKulCxtTGOO1s+Vqn2a9rUZ01YvxS7nVMN0hVV/FUr96/yyUuDTgOjr6n7hP+z9
xZ3O00xMn5vWkGlZsUY17t9r9x/X7iVrQcA+NzU1la2Sxa7h4WFbvuw9WYvSCnQLCwuRo0/Hxsai
uMGw0ogE7n96tWwxn2bun5qJ9Acup/oL6RBUqkxydKyPd1IugSZ3ukv3srJ6c8GuuKr0aXoBnVrR
anZcSjUV3gj4NCD6up7sPbNv6LMqgycTU6Xp60f/y/9e/j8bDwiVsEa8HTt2LFd+lt+CgH02/2by
EXH48OFo9YaatQmXPtBq2ZC5z/q6ZNqNLQkt61OlzFbPzDaXlpZUmZoO77O1farjvmfP/WYQSzwN
01OmwbYsd+/e1QHq7e3dtm2bVlHeuhJfdJUeKUswrc/SOnxq7SSVHka2Cmdux3sEnwZEX9dTL/zH
/afmrX2PiSmZOs9Ul6IOzXed+ezb/+mzqMb5qXxkfVGOHDlSeldUc63nSVINy0OV1KQXU165Lca8
lrQWppeR9RoaGhRp7b6q3YBLL7O8+gRNpf691nszE4StC5Mqv/GvohJb26cr8a1JHTsdnSTNt4Oe
kZfm6njZMtaamp5rurT00zoOZR5JtrPCDp/d2Uy6M62sdjVfw6d2Az1z4qme1sXXstd0B+OV+Bps
cHDQS9sFPg1IfP/0399/OOL+FPqeHdPmmWKlrm1SCbfj9NzBd+c6h+7826/e98vGo8HaKJxatijZ
SXPXr19XHNNPxSIrj1I3oRQkrVDh1OypeGVGTnqPSK+KcoqoCne2zMTEhNkw6eKSbEcRUnMVWhNn
VfKpRWytpTTW/tGuXbtmO6K9t0qiCs/LmEB37ty5HDdT2AVSW1tb8oSLjqN1ybYM1PLB9P1Nu7Cx
g2W5pJLW5dVGD62lDba3t1uJ9cpOOhep0HorreHTlbjdQ6do+pkd1VDng67QVE9tX+dY0iqiQsu7
rcIbBJ8GhP69UBZTagWT3tn/i9v7T3/Wed+5tztOf3rg/Ke21sajwQOR3RQhbSyjDFJJxlYKaPZ0
TIJWzGQrCmIm0ASFu3R3TduOidjQNi2qV/LpSnwTzdoVE+TTWg+RVA8+VdSylvzkkRnletae0NfX
p6spa8NP2oQl3ObmZi3Q09OjQ3/48GF97ujoSDp123NV2qZWUeV11NIPs9jjLVH8TI0Otz7rTNDC
a/tUq+tw20AiqpJMqp0mSa5OA6uwzc1UeIPg04DgUyhLeZ+evt/16OCpuc7TtzvP3O48PZ9Zy0tA
qAZZVTmgjWmjiKSIWukOmuKhwpeClYKtEpOywytpGW1Ny5w4cUJpaaXxgaemprSYPWphXVYSn1o3
40wdtB1trT9GNcxhoP6t5FN9t5XGltSB0FwdrMSJ8pdSSJlOvpMxM32BdNB1CCRBzZVJk7aIBB07
raW5ZtXMkdKvWn1HjD7o3LsQY3O1L1Wm9H6odqoaahXpUt9J5kpPJ4wqrLlW4eRJ1Y2DTwOCT6Es
JT69ve/MpwfffbdT5afuHHj707Jr+YoJmwolNVJ25o6ttRlmniIMzlbyKawPfBoQfApluf88sny6
2tcoTkg/3XfmrwfOn19jrdCxpCbYYxrpVuLp6WlrQqymW2me4FPApwHBp1CW+z69n5De72u0b2j+
24PZpt2yhI4lNWFubs76I7W3t3d1ddmAqyIzJs9mAJ8CPg0IPoWy7Dv9NyWkmpK+RtUQOpbUioWF
BeWnkqndYuvr6yt9R8lmAJ8CPg0IPgWPhI4l9Q4+BXwaEHwKHgkdS+odfAr4NCD4FDwSOpbUO/gU
8GlA8Cl4JHQsqXfwKeDTgOBT8EjoWFLv4FPApwFZh08PnD/fOTSrad+pO76OGmwNahEfLly40NfX
Z5/v3bt39uzZBz6ocvXqVS2WjMBw/fr1s+VYY1Ql7bTUC3Nzc7bi2iMdjY2NqcJdMd3d3UNDQ6V7
OXbsWC0et6lPn05PT/f09Njr+aJ4NMj+/v4cRqPanODTgDj59MDbn3YOzXcO3Y7HyZnfN4RP4XN4
Dw6Tk5MNDQ3J8HGV3u6dwV7+kgwtuMYbJ4Xct1zyAjjtovRllAMDA7ZKpXHwFhcXy+qsdNDga9eu
qdD7Qzd16NMbN27Y48C6dDkWY6P7trS0lB1bcsuDTwNSpU87T/+tc2hu/+nbB0/N3X9Zavy+aXwK
GfxGhuV45PP0oOgb8eng4GD6vd7KIuU4G7I+M2zgzMz9d6OPjIxkKqMQvWPHjsbGxtbW1uVy72CV
mqN44PSbN2/a0LILCwvKgrVK6Qb1p+3evdvl+3gwdehTHREdxMybWXJ4Nd6mBZ8GZG2fHjj/6f5T
852xPfef+dv+oTv7V9+JGfv0tq+jBlsDv5HB3qWVfvXkRnxa9v3OV65c0Sz5MV1o0TjzTkxVI4pf
Btfb25uplaHkVFmS1Fn6blZlo1olY097I3lm5PYNUm8+1VcdVXgNTXt7uzybKdRFzq1bt6ampiq9
1V0LTE5Olh7BNZidnZXNM2dLmunp6TwzZXwakEo+7fjFX/efua3p4Ltz+099VvpqaXwKpfiNDEo9
MplgJZ8qBp47d06yk7mWV1/2XY1PFT+t5unbbd3d3coxM0sq2dFiEzH6cPjw4cwCa7heVVJ415+T
KWxubvabotabT4Wk2dLSUurHmZmZtMX0bZ89e9YaCqL4lXyDg4PJqWXH7tKlSzpGNtdeKZ5pUrB3
oSY3vsfHx+1Va4ZOm/QedSboPLTBn6McX52ATwOS8emB8+f3nfnrvtOfdp6+ve/sbNeZz/aXmBSf
QiU8hgUpUhtUWEsXljpL57AljAk7Y6LqfKo4bGsl+YUMq3Caud0p2yr3tDRWe7T3pWaSDq1o4br6
d29ZxTzeRa1Dn5qwpFQdshs3biRvcMtgfuzp6ZEEtZj9mtwit/NKlzfbt2/XVZmunXQ+2D3Z9Ea0
us4NO1W0HS0gn+pwa4PWqq8TI8ltdZY2NTWpUDXUikqKa/k1/H/waUASn6b7Gu0782lnxXdJp3wa
K5WJSdOX978ZefWp0gdtMPMC7lKf2mIdHR32AkpFtuTF39X4VGEwige6T0oUJ1VS9n5cIlnbqX5m
tqYc2XYtoSsbWiO8G0p/tLCWfOC3USV16FMFsYGBgeTV7fau8AsXLqQbHKanp6OSJgVTqmku8Wm6
pVcS1NaSCy3N0l5UaL/qNJMu03uxOwLJSWJvIa/1G+RLwacBue/THxzZd/q+H5O+Rmub9O/TLz6z
+6pMTDY9/K0fegwLior6d868pjnjU2WXCnEKa+kwqFUUBqMH9UdSoFPiYEumVav0RBtc/nx3I3N0
8tiLdVhSTlSqy+Hh4eTBjShuOezq6lJh2Rt2FuczSdBGqEOfGrLelStXtGt7E5DQUUjuTdt1TuaW
ty6ZVKhZK6vnVeJKw/yYtO7apZdtxE6A0h7gMrIupeyzzlId/eVy/dZqCj4NiPn04Ltz+05XbNpl
Yqpm+nLnzz2GBQuMmcKMT+1+Vm9vb2ax6p+XKX2SRerMxFVreZbf04V79uyJKjTtSrKqmNKfJFOO
4i5PmZx3ZfXu7QO7V1VP3fo0jWSniyLrG2b5o50AOqPaUlijvTnRzivluentLMc9upM76ToB9Oty
7EdTrZTd9nlsp7a8leT6l8fg04Cs5qd3Dr77p31vy6rz1Vt1nzX5MjHFU+u3X/YYFixeZQozPrVm
2NL2UmvKy/j0yJEjmfEcRkZG5ufnS7evTCddaE/ByFPpdU1bZXuWplE819asl0umOTH5MyN/7eT1
5lNdouhYlO1bq8sk1Wd4eHhl9QSQZEvH9LAc1o576YlkDfuzMVFKuNY3W0e/7Dghtgw+rUPs/umB
83/ad+pvdiOsSrF2WhQNfduOaZNM/+7x05HX+6dRucQt41PFrrJh0MqruX+awdr00pJdXFxMOoWW
ZXp62paUOm/cuFH2UQv9o+3evbtsHWwjD6xYldSbT60hN3P9Y1gKaSNv2EAc4+Pj6QWWlpYSEVfy
qbXrai92RiV3H6ampqKSznIr8TmQfMandUhJ/95qxdp5mv69kMVjWLAeJpnCjE/tAVXlHZnFrMfv
Onza09Ozffv2dInt4vDhw3MlKHBpVn9/f7JuVLlzbyX1R+XS8HVTbz61G9A6HzJ9rRXZ7HuYnJxc
iXupRSXDO5iL7fZoJZ+uxA37O3fu1FmRfoRqOW4KLr1xH6XuC+DTOqTS86cPFCs+hVI8hgVrI800
5WV8aq1wmec6V+Jn+SN3n+rfQalo5iaadYsqO+qCRWkFVeuVpMgcxeF0uVwXFJNv5nlGJcJR3Bl4
7YpVT735dGW1SVYHrq+vT4mqjrJyUntgKn1jvbu7O4rvltroChcvXrQHoEyIa/jURvwQly9fTpfb
hdbu3btv3ryp1e1ZVG1zYmLCFsCndcgDxxusJNbYp4w3CJ/DY1iwHDOJTkbp8zLW9Sj9sLzdVI3c
fWp+TO/RMo7m5uZKj72YuC3SKjJbFxeF7nS35MXFRUtOS4cdsDbJZLT/jVOHPl2JW+ntm0+QXtPD
NazER0FnlHXnNqTC5DCt4VPrQy5KW/K133Rfbh3fdOsEPq1Dqh8PPyNWxsOHUjyGBbv+t8cZEkp9
qhTVegIfPnxY8VA/oziyRe4+VQRW2Eyr03KfNXynVChKDSSoVEXyta/ChsfRLGu4VoQv7d9rnq1+
/IcHUp8+NZR4KkkcGRmZnJysdP1z9+5dXS/pMibzHJYioc6WSsMMaq1Mv7UEG5/w+vXrpTudj1nX
n7Ih8GlA1vW+tj913h9A6VPe1wYZPIYFywsyT6kosklSmYitSGgD10TxYynW4qfFks4h9mumO0op
cl/mUVDtSCuuMbKNAqa9ly1x98LCwtDQkDVWG6pSf39/2dC6c+fOpLnYC/XsUzDwaUB4nzh4xG9k
yDz2UmvWyFDWR6VB1w1rTC7tTLUR8Cng04DgU/CI38gwOzvb0NDg1zibB/1dyqn9vvYanwI+DQg+
BY94Dw6Dg4NNTU1rvAyroEijpaPubxx8Cvg0IPgUPOI9OCwuLra3tyfPeG4ZTpw4sWPHDo93Tg18
Cvg0IPgUPFKL+DA7O5t5bLPo6P9Of1Eyur5H8Cng04DgU/BI6FhS7+BTwKcBwafgkdCxpN7Bp4BP
A4JPwSOhY0m9g08BnwZEX9ezzz7r68uHOid0LKl3JNMnn3wy4Anwwx/+EJ+GRd//j3/8Y18HVKfT
S1A1L7zwwtGjR319+VDnHIOgPPPMM0899VTAE6Cnp+fIkSOhv4a65uWXX/7JT37i64DKDsp2Q2uq
GPT29upKRkr19eVDPfOd73xHV7Ohw0n98uKLLyr0SakBzwHJVHVQTUJ/GXXKT2Ok1IDnAAAAAAAA
AAAAAABsQv4f/3EgeWVuZHN0cmVhbQplbmRvYmoKMTEgMCBvYmoKPDwgL0JpdHNQZXJDb21wb25l
bnQgOCAvQ29sb3JTcGFjZSAvRGV2aWNlR3JheSAvRmlsdGVyIC9GbGF0ZURlY29kZSAvSGVpZ2h0
IDI2MCAvU3VidHlwZSAvSW1hZ2UgL1R5cGUgL1hPYmplY3QgL1dpZHRoIDYyNCAvTGVuZ3RoIDY5
OTAgPj4Kc3RyZWFtCnic7Z0vjPJOn8C/oqKiAlFRgahAIBAIBALRBIFArECsQFSsWIFAIBArKhAr
ECsQKxAjVqxAkDdcssmRXAV5gyA5ciE5BKK5cEnvwiXkwiUIRG+mhV2e/UF3us9sd3mf70ewdDqU
6Xc+O9N/zAAgCIIgCIIgCIIgCIL8Wfx9EQPDKCW6irwP8qlECbKFjz6Y+jDHG504AhXG3/jL+oNx
vRhwIxTowYm6C/W7E4ltAyzy0SfND3O8QeIIVBiLCCH5ufww3/TeKrJvxDqRaKNvP5If5lvdKjHf
nutsITl62hbTw7XbACjMloPHSpKtHOUhP944VZA669WLVt+s2yx3frzb9GRwkvTjlfbWrVv20Jvl
YORQ/O1p/dXqjn1q29NA6W3nXQJKd70iCkfJSByBCgN94yZKf2owpUpZ9lb3HnLqvAnJRVlZX0PF
M3WPJjtGgi5lVtmrmSz17vbtm+RWQXOuwdNp42b67ds6Jz0OIanrN47GstgdKeka7XFC7g6h25eT
DoHOICH3uxzlInEEKgz0jZvIvgXoXgLyG13X2/0rFu3JwbfrOU3stYubZhpe+9MUJApz89i35/3W
jDXLBqpH27FUYm2wt9o6B9AgsKnoennDUS4SR6DCQN+4+bRvANdbm/Jg2nT5+eDb3ZolNqFq7xbl
g2937qLv/OIbCbaWXhdfN0dhGegL+0OP37wx2xRHuUgcgQoDfePmN3zLryWAbKa0BNa+JTyVFtm4
ntGlQiqVA6U13/uW3aYAxoFv02PftOVNsDmVfdgsuiV6ZOipq0LQvtE/aomjXCSOQIWBvnET2TfT
YG+Zb9Kso6SdmjS/k0zPhFVdbeyMhNuU8+ty1UnL9zaQJ9Zd5rdpMHcWLFqauaO+3euBb/L02TAM
v0MddpXsKn8/0dX+ANpjLU2P39rjpNrvcZSLxBGoMNA3bqL4lqVHXfBgsrca6+e0nkNPGUB/ccjE
hPJkcd/JQvrFmdEszbnTT0Fx5p+fWot5u96AwsTp3JXAnNfNJtuaZgd9L0XtOjN6VmvNFx0FpPZi
ctcE6X7udPH8NDa+y7fkJ8pqm7+9u5+HxBGoMNA3bt77lm0teA7R34O+XT7x+0Zlo0mf8S2rCdrp
z0DiCFQY6Bs3b74Fsnmf8+1bIXEEKgz0jZu9b6+yeehbdNA3bphvx7JR/Cu2l0QsgQoDfePGBeU5
ju/5hwZ944a1bzmyPU7aOhfGJo5AhYG+cRMcv6kN5y0Jj9+igr5x83p+Wh4cktC3qKBv3Bxdf9Pb
Kz8JfYsK+sbNL9d7ZXPioW/RQd+4eX8/i547oG9RQd+4+ev9erX8Dfv6W5A4AhUG+sZNlOeRfiok
jkCFgb5xg74JAH3jBn0TAPrGDfomAPSNG/RNAOgbN+ibANA3btA3AaBv3KBvAvgfoY/zPUrfE0b0
jRMSR6DC+F+xm3v8njCib5yQOAIVxlrk03y777qBjb5xQuIIVBhCj98c9O2HQ+IIVBjoGzfomwDQ
N24u0bf3A06QOAIVBvrGzSX65kzvUsfLJI5AhYG+cXORvtFyHytH4ghUGOgbN5fqm3ekHIkjUGGg
b9xcsG/eQTkSR6DCQN+4ccEUejMmDn75dTZVjsQRqDDQN25csOL4mi9l9t0FQN+4caEu8mZMLOyO
d2DdSZM4AhUG+sbNZR+/ebNbBY/fBIG+ncHZl333HEwiSOIIVBjoGzeX69vy7jCGK4kjUGGgb9xE
8k0NGZ1e+3DkejUR5btCcGi5h5W3pxJJHIEKA33jJopv6vLcKOT3SY4Ryk9OTvkZHHqO8MuG4whU
GOgbN1F8623POeXpcfpWedeUkjgCFQb6xk0E3276zKlmMKl45tHuFyHNpo8hatvrpe3mo30nqYQR
zPl3b5MUSPWXfhlAadn3TxZIjWGvKDxQJI5AhYG+cRNhfmdHffNNXdeM2k7zZ9Ty9Lx3nbDdamnR
UEzz+nGp0lRp2s1ZS7k7Ll25JvT6RnNnAbHz10vhwpE4AhUG+sYNt2/SuHzUZ6oVANk19r75/ekd
QItNAl5YZ1iOwooe0NfSOx2gOvPn/3uxVI+eUjYGogNF4ghUGOgbN9y+WWPDmN6/HqdXB/PF9hff
qIts2r/0KphC0p8WFQpsYtO0Z7A5K1uW4TmOsxL+a00SR6DCQN+44fbtmaqyXbX3S1ersgqukVvD
O9805zbIUZnSl5LhyQDFVWZLG7uOlWV/FOE/ryRxBCoM9I2bSNffmFNZnb1rTgDKnqF5KbhmvqX3
vimTg5HqtgDJTWrRBKnXhcUNaK4lLRv+kmBIHIEKA33jJrJvtn9VQ19Mx8/jKnQ388FSh6F3Ffhm
emzMaT9LZTVa1SC9mDlDFfLLifNiQWExW4yET+1G4ghUGOgbN5+9nyXpqv9XDew5NWeqrPvXyXQt
yC/D25JYSByBCgN94+YS75++h8QRqDDQN27QNwGgb9ygbwJA37hB3wSAvnGDvgkAfeMGfRMA+sbN
P4Jvz9OP+E/3P86u+7cPP/0h/yRyb9C3yyekDqX7OAvCAfp2+YTUYXEr6jF3QaBvl09IHXa9Rpwl
+Rj07fI5X4fS6qeNZo++XT7n67BIY1CKtSwfgb5dPufrsEtjIPyB498Cfbt8ztahxB6fYs+8/xzQ
t8vnbB0W/SD8qEsi6Nvlc7YOu34QVnK8xQkFfbt8ztWh351SqjGXJwz07fI5V4fFfRTGMZcnDPTt
8jlXh91DGHIxFygE9O3yOVOHh+7U84T/ZuzzoG+Xz5k6LL6G4QfdREXfLp8zddh9i8PPuYmKvl0+
p+vwrTv9SVOCo2+Xz+k6zAeDnW/9Qc/zsRfqDOjb5RNSh99WvedA3y4f9I0D9E0Y6BsH6Jsw0DcO
0DdhoG8coG/CQN84QN+Egb5xgL4JA33jAH0TBvrGAfomDPSNA/RNGOgbB+ibMNA3DtA3YaBvHKBv
wkDfOEDfhIG+cYC+CQN94wB9Ewb6xgH6Jgz0jQP0TRjoGwfomzDQNw7QN2Ggbxygb8JA3zhA34SB
vnGAvgkDfeMAfRMG+sYB+iYM9I0D9E0Y6BsH6JswPvbtutNUX9PqOlxZlMPEDL+sOY1Z/u1CHheo
YDJS0T8tvQ4sdmVE/Ogf7FuLjSBzepVSB/D0jzbgGL8ufuRbe3JD5q+jRtNPE9uyHt2exBbV9bnt
vmGnPyoSL36BbgghL7tC9E+PjMM7YkX86B/s27hpGMbpVYbzBb6lNrQJ62ePPu3XlrYy2aLu0RdJ
1462mwxKoOh7RxVx43kdyiqNmm+Jmp4I/rB/gISu0FdZV4+TEq9FZ2nw5psalFHSPxpS8Q/2bZP0
/1i6/ydjkYYKxhWt+XqCrC3wCvcPeciyLi8IqtrsmhJIN13WKSYajwUadvm2Wz+E+CPfbvqJisEW
zCBt7xvc+1PPjD0nWXAmixeFrXkYKepwMVmkgfSd2ToYx6v8KGzfD2WtTSVquuHv3mg22tZAGTjj
ZRparr2uQHE5XhJJepmPVgWwlvbKHzGxvXMrmk1Ll2F7UKG5H9yRWwFzNJ/QLYTy5/qW2RJnmKOh
9yszt26YwxFYhDVuyj1tc7xZrbXTmW+zCcuhuh1z/CjZQ7PjatLs2RxtDWk0MB8PXeRHvlmT+dOy
B5DXgrSDb6bfqdP2TXJqIPW7dA3VDbpPAI0xkLEMj8/+Jx6vhO38vqzyukhfDP8/pt4HqC7gbijB
fa+w1qC0UtYlkCe3hSX9Z2nBLg25waHo3WcJ6gu6B0y36iIBuY1qbnS4Xod8K/zJvpWccqq11vZL
xSo1cLf3LehP6YH8mDVF1aWfqflCu8R2aUnt6rfKtGtLbI2yQ/uZ8U2wiQ99ow1qwn2dt+2vvmW3
dGslF5zRjn7jqm2aDS/B8pjBhheKsJ3fl/V2dpQm5yrEgSHdGwnumOFSaU3PJ/r95KZ/Q/uC6bSZ
eS36yqAf8DJkvKsAPL/QfKuKOdofFoTw5/rmMzcP764fX1zvF990eoBOVxvr4JArkKNJWwFovFi0
8YGpYa1t23Y7wRY+8q3JVvfuXtMOvj34jQatKIPFydiC07PpJr0u68mPfEsLvISxL+uo/pZUXI06
bQdmfkQeCHutrlgRTEi1Jt49JOrDrS3vi+4x9bw8mXdpjzy0Wb4sKyb6do4002h8u19qzqvZzCnf
0uv9RYgumwAr2xjS11avwbSbGc2hTtlfyfjIt+KSNl/T69e01/MFf+IZWlGqR1uR2wldo28NmNGG
RruDN99qzTNb/wRBWZXd0QnvmP4nVBz/H6LwVKO7KY9LG9rTlspZ9l/nJWhBEmtjX/QZLXSatb7S
1II2++9rJtG3MOozCdKbNARnVjYNc8OD2ynA3bFvmnM4AK7Sf+TCKrtNgjSt5WhHnNkZedpFSuO9
Qh/5JtnEsBwZnoMudX89pLO/HqJ4DbU7Ll27Vbam4ShV97o4ejry7UXgfCFBWfMb9l6z/Qb8eZAu
zza0Oa+WJk3VtYynFxgOitVNMb25MbpjyWkbtY1/aDHuZmjpSuMuK11+m02vG8ajI6NvYSj29GnF
rrMZbMlck0HPUzV3PBw6oO+mcuBbd0N7TL9CpP70iZ6Etdyn+UCGe/dpRv/Z2Z8h5/kCKK1hh7Zg
7eCKVzvtXwB7vd5rkrRUHzAZ6RrpoQTl50FTght6klDwW7aewJ0PCpRps/cq8Vs57WHY1rsabdwG
tGXVH4YtBZTmy1ORtXfDe5Um2d3gAC5PrljpboPS1eqQ6Qzbml9MlYR/8Z/rGz0nLbMrIvurWykj
BUkZFCMr0dRkQWKXnDRFZR3mPkvWYPmThh/0tJGg2enHXlsdvJ/FwZ/sm2DQNw7QN2Ggbxygb8JA
3zhA34SBvnGAvgnj877drOZ/Scs+v77VjMO70sOZLegRJ/NF3y6fz/u2qCX/kma8PSr19tCPeW4z
txGfC0LfLp9oviWy+RsFirWyBHm3rmdV04DEdY1daynWKzL1Ta9V/Osw+gtJg1yp5QPfcimao1Zi
W9Bur/fX/noRZ4JD3y6faL4Zy8VEIzNraEvtzcuVPRk/6sun++UNWFOrP5eNzaQ1e2E5rxbTG83p
t5wW860+16A3sUY9auTsfuo/ugLSUlxZvxb0TRgRfdupkF8pABP/BpZND9eeOgD5tUwToJkwNgnQ
Pf+JENqfdnoAyV3KtJluZUcGySkZXhISnt8TG8/vN//5sn4t6JswIvpGj88aLiFk0fF9q9PDuBFd
9DK33tjKBMdvwTPG1Df/wahJ1dx4LQDLofkc6yhHy3y/+c+X9WtB34QR3bfm2KCkfd+oMQ57wN1I
QLI22OVP+7YsbbNgDVk+/SjHRHu/+c+X9WtB34QR3bfiKgHQrRx8e6b9aWoos584DJu/+vb4tO9P
oTWVKo4C0nPpLYc2e7/13yjr14K+CSO6b9Cb0VMD9eBbyn1qOfdgLVqd1XHr9bC4TS6fW06bnS/I
c0saTq2XmfKWw7wXWNavBX0TRsTrIf4VjGKzKtOThARkWY+YqDbYs0rFxo0WrDf8yx3KdZGtogla
lj26AlL5riIf5ShF/p0g+nb54P0sDtA3YaBvHKBvwkDfOEDfhIG+cYC+CQN94wB9E8aX+Wa83j04
+3xIVNC3y+fLfON4Hikq6NvlE9G3XOflMQOQ7gzuFEhYgwed+tR7KvhJLRUSrUHH/yWYMbWvIPM4
aMrMN6mRB/V+0FZBN8u9bvYv2/3dsn4t6JswovmW2ZhGxwV93Si+PEtTYrQduTUpXS+L8qpmPA9h
0DWaa/Z8SHbUL+Q3teJgSH2Tej1JnneM+7lsrAelR1cSXdavBX0TRkTfrgA0T7V69E/dYNo09S1t
z2q26l1JShZm9wrkfZtof/p8DyBv8uaI6gY37KG3iWlsZZA+HqUualm/FvRNGBH709v+bOHp+yGS
/NW65ziO60Bzs34uQGm5tYMTBZpnyt6NTNNb99hASzTf5vh5JJFl/VrQN2FE862+KGuap7NRcKRy
lbVYRs4Lng6XJKOzTUiQaWz8sXKob0M2rs6iYs60VQXugpEd0Df0jX8V6dC+09OvFwpUlknakyY3
qUWTpg8yG432tJpbBmnmD4VDWnA3lsHYqrQdvF6phXUaNLeCvqFv/KsK68GIrHLQddlYpTdre1WH
3GIynaeg49rLFlTXo/mL3+A1to9yzxnRlo31u4MeNNe228X2DX2LskrJBePGqTnZX2KDmkoZ/8ki
NZ/wk/R9Vo3m1HLy22cTORV+C/Tt8sH7WRygb8JA3zhA34SBvnGAvgkDfeMAfRMG+sYB+iYM9I0D
9E0Y6BsH6Jsw0DcO0DdhoG8coG/CQN84QN+Egb5xgL4JA33jAH0TBvrGAfomDPSNA/RNGOgbB+ib
MNA3DtA3YaBvHKBvwkDfOEDfRJBjk/JuPTabvW2fmIYZfTuAvolA3hzt7IlfvKNvB9A3ITy97ax1
YjX6dgB9E8LV677uTk2F8IN8K9tHff9fp4n7atA3Ibx1qL1Tq3+Qb+r2rV4W8X89+iaG1w7VOLX2
B/kG5K1eWvF/O/omhkOHenqml5/kW+6tXj45eNzvgL6J4dCh1k6u/Um+weRQLd/QnaJvogg61I1y
cuWP8s08VMs3dKfomyiCDrVzeuWP8k1e7avlG7pT9E0UQYeaOb3yR/kG7aBWvqM7Rd+EwTrUc1b9
LN/0oFa+oztF34TBOtTKmXU/yzcY+LXyHd0p+iYM2qH+17nBwn+Yb2VWKd/SnaJv4ng6eevU54f5
RsvzTd0p+iaOq5O3Tn1+mm8N75u6U/RNHDI5u+qn+aZuv6k7Rd8EcvpaL6NumWfXfQvkm7pT9O3P
JPdN3Sn6xktn8c38LUJh//XDrW2+tKx/P1sy9I0TEkegwohywLX5eHNfyuZsydA3TkgcgQoDfeMG
fRMA+sYN+iYA9I0b9E0A6Bs36JsA0Ddu0DcBoG/c8PtWcpars3e9z5Cvnki8yoB1/v7SHvPDHG+Q
OAIVBvrGDbdvyroISffcU2RnIKcEtQ307fu4FN/SD/TlyQLTYEuJermbkWqkk6Ymtoh5lU0wteo6
KE3STgIYj6QKxtS+YrmVBunSN1aCepS9cohhPdWIpUDdovjbgyrpZNinumza5GtyX6O+lR67ZZ6i
kTgCFQb6xk2k47eEW4YH//a2vhm300+jUm2VhvGTQVam7tFkx5DsfvHOVXNupTyvZUf9Ass9fire
bg1/wmPbLMzvs9auXZl0oWKa9zuD5ehMyvV1quqalbkFt06ltiJQdauVOc/NdBJHoMJA37iJ4psy
eh0RQafupLa0vXp4zK8lkJYH34pLCWDQvF7Q9el9fyo3ZCba3je/Px0AlOd0lba48be8pe3kbY7Z
ldsqDm3V7gk4FXbQyFEuEkegwkDfuIngmzbpvT6Uzey62jmOs7LZxO3QP/jW2NLENVH63vxeOxy/
ZTrD5fYX32hvyeZ4V8b3r5ujeCn2wlxmx2/e0nGWHkfBSByBCgN944bft7TbfvsNABOktNIpWmVK
l1/MpKcw326nLJFN6n5tj/a+JTfNrLxv30bHvkn93mFzdNNpfZuljaGnb+mR3A2BXYltiqNkJI5A
hYG+ccN/fuo0/b9agr0y35RNiYrWVqklSdp67QqQ2RkpKos0u62/0PZvvvfNWEmgrZuwLvkZ7crB
t87o8BykUwVpetOnybcLeKGN3guBIT1DqU85ikbiCFQY6Bs33L7d+NktsH2F/A6wshrOJypU1sO5
Y8LD2p7MDKitX5wXOTGbvqyuoLFlv2qXZ5Pnif0Ad1t7Rpu5zqYR+Jb0VrTzbbPtFdzhvC9ps6m9
LEBqMZqPCKTm0+GqcKIo74dGI3EEKgz0jRtu3xKsc9MT+/ZN0tmrUvAfRU0YCtUIUnlJk9lSmiVm
C6ztSvq/U5FyOUmh7/S8rNJUXU3QDldOSvq+76XI+eBTedZnS/mUQpOlbF4+VRRnepc6XiZxBCoM
9I0bQfez7Dh/BODQch8rR+IIVBjoGzeCfGue6ve+Cico+qtyJI5AhYG+cXOJ9+ud19IHypE4AhUG
+saNC6Z9aWyPd4AqR+IIVBjoGzcuWHF8zZcy++4CoG/cuFB3Lo3d8Q6sO2kSR6DCQN+4uezjN292
q+DxWyTQt8g4+7LvnoOzYhJHoMJA37i5XN+Wd4cxj0gcgQoDfePmUn0bVt4eHiBxBCoM9I2bi/Rt
3UkfL5M4AhUG+sbNJfpWeTe6FokjUGGgb9xcom/vIXEEKgz0jRv0TQDoGzfomwDQN27QNwGgb9yg
bwJA37hB3wSAvnGDvgkAfePmr75JuU9U+bdC4ghUGOgbN+990yz3Z81/wQGJI1BhoG/c/Oqb0dud
n7nxx0LiCFQY6Bs3R74pteBBWfQtKugbN6++ZTqHSKBvUUHfuAl8kyr2WxL6FhX0jRvmGz1HOE5a
f/fvr6Lyz3EEKgz0jRsXFLL7ONuPZvTdBUDfuKHtm3z19EsQtt/9+6uo/EscgQoDfeMmOH77RTk8
fosK+sbN6/npm3LoW1TQN26Or/fulUPfooK+cfPufhZT7oxv0rV1LZ1eBbIM5oezEl8ZH+X4JCSO
QIWBvnHz1/v18pn79WRSG/bPFNXROUaAOzn5hwhIHIEKA33jhvt5pOQmAbL3NpSppCfeVnrMt2DM
yyN0f3TKYEBM0CXfNy0BwiFxBCoM9I2bSM+/ZXaJ/fi9cOc6G+KPaU9lG3nLvN1fuouUTje59Pxh
Fq7c2boG6am76ilQcJzFyIL0bL7qnuuUPw2JI1BhoG/cRPBN6m1uAbI6e5/eaKBts3vf/PZtpECf
zXkEvWf2qm6KNJc+s0AaPMLChNTagkUT5OFdhNrhgsQRqDDQN24i+CYbtfXbsZ2av1kbx75RF/1p
2Nojvxu9mrFMKY8uFFeZLW3UulbGKxpGexyhdrggcQQqDPSNm2jPk5PH/Rtl6A6s1S++mYFvtUUw
jIw/7QwU2Lj5ac9Y0j+WZWwJpR3pK3lKFUegwkDfuOH2LTthNdvZL9VnEkgbI72j6v3i29VqP7SH
wbbcLbIzjOpc9VSAvpX0qIv5UoTa4YLEEagw0DduuH2TnXbqdp2Bpj/D5M0ymyZbQ9k2cr2tDts7
LfAtu2mZpn8pTpp1UnU3QUY5w6nB8yBzs7VgMPSXBEPiCFQY6Bs3/P1p8tHu0cO3wDepZQ/K9SIU
By+Vtgo3wzwbEf/qpsA6TOJn0R7tpxRId/ZLlTaC9/Zj9QoUunQToXL4IHEEKgz0jRv8PaAA0Ddu
0DcB/GP49t9xfP1//n51fzvPcQQqjH+PUNj/++ay/u+XVQOCIAiCIAgSL/8PWxAkuGVuZHN0cmVh
bQplbmRvYmoKMTIgMCBvYmoKPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCA2ODUyID4+
CnN0cmVhbQp4nK1dX6tnu219n09xngt3x5It24JSaP4+p1xo30OTUnpbkn5/6JJ/Z+Zsy2evmUAT
SO7c8fG2JVlay5J85K3gvz8J/me4vv3ply9//XINW//29f8/aR09/kLe4r//8oe31z/87S9ffvWH
8vaX//1S3qr0+Talv0mx/va3f//y5y8xwfo3dej8+q8+HVe1t/UvvZePny3xpdc/4Eu//vnLr35f
3qRdff3H337+8xf5unbvmGTg3/3y5R9LaeOf3n7+z4+/ldIuMZEytlG/yaPG1cpQ20aZpVGil87h
Rbe5Zhql5WrVi5RtVM+jxjX6kGrbF/Pqq1yzuohsc/0+j7KruGnfvmh5j02vprXO7YvyuzyqX82t
9u2LpaZRVi7ro1YuVavX1NrmpiGTNKrL5aOZN/rF3i8I0aB8Jq9RLpFpbdtj+3UeNS/t3q1SPU5I
Qsv4jiQc2nYddd+j5lHz6q3O1tjqteg1xKYWtnqVck0cAhwssnoVv4rMkuwrWbQqNOSzz32Pv8+j
BjRU+n46siS0KjSkvVa6x9qhodbLpHtsDRqyIZ3u0WDRcCpKLUcNepxzFnoese4LbsjV2EnTPq4y
ajFndq+wwqoO4dLVwwobFNTo6VBYYa8QGLV7hRUOTFULlYS3awyDb6I24X7hnJVKZV/hMWcZsluh
tTRK7HIYtG32ZXkuhY8uXofRL8K+4OKa71/seZRfNmdXaoWQFGIJFlKZHqGay6WPNpmGqsH79jHH
7qP/OY2CfalM516uwr6gSzfqJ+qQq3Z1oV6uDkhCWqnUT9Q5IAkT7uUQgq6Bz6rQdbnBJrzMLT5m
X4gVXQj2WvbVpzjURBBrZ90tOq++wcsh1rbdk2cNNfgvcyy3sz02xNre1SrFE/ga/ETtuwc49tjg
MXsbkyKFZuELY2XMohsspzVIjZ7tBssxzOVC5xrtQhASodGqTb0ceKI6/SIsB3YvziUBm4DdV1Wm
IYNN1O5tj9v5ixYorcGkdw0l/wUpQNuIDc5kj91do0GPys6QBf7yNpJnSl7OWkHks7l7phw7DD6n
wuz7/kXPo8ZVRyu7/zokYQJJmO/+K8veDB7AhyR55S/28IUOVdIvwr5Gk6KDSmLAA7gCHlJtzwZ5
YQBfvesljvPWmc8x74gKve7YJOsRYQNIAY6cepMOfG99IvSx+NglrBCbnExeXeUyFRnUCuHErz60
Fno6eh0LRyvlCr2FrVrC9zmm9WbBhyxp6JjLL8AXE8oogBIuWGKv9NQizl4Ix7brsWQNdZxawMeh
zL5AOYBNgGCMymtCEoCru4bePfnvfv4On+z+maP97o+t7fkP0VB/MvkgmLAFXYHdn4xmEUwDHKrb
XJ8RzCltgRd/ElVQR69qtq3+13kuBD2Zc5RtXQf5goMDQHuRCX8yBwkHB9a/f/GkjiVg3CydftFC
F2XsXzwkEQRzTt/nOqQa1LGBELdtVKbaMEB4JNj8NsrzKLgIyGEF0GdJwEwROiRpO69+TtA9cJxC
LccRjMUr1zYw14V9NqN61ILD3xR4aBuVaQLOgcBzDWrRqgDtiBvTmFRVcfhrqbUxeWk4SwRGKXT1
FS5iNE1fPAgmXASwnldmEwo36KNboRatFuFstl0SGdAqrLBirkmtUDtCto5RNsvJjldHv6aBvXB5
zXI55vJd28coB6WdLpvlZMersC8ouzRhpxYDQGm7plNreZQB7PVpVKq1BLSfsynTdpUK2FtmqUzb
VQPai2tne8RfBbTHaaZfhH3NaaXQs10Rst26D2qrCOlXgQJqoauHL5QZmmOWU23CrwJwdLqurheo
hNTBfA6gOOieaFd2tiu83AQuSSct73H2CyfbyqSrd3iTCaqz2YTkL/q81MC9hEkV4PmqOP9GVw8s
e7XhfRg7tQCNcc3xujx6XD2QWVxzeIrImYZW7FFC2kxDsHlIQks6Q5nIAcbB7mWXV7YcoISwe7VG
JQHPNOHKkyfPe4RNOKBekkTy5G3ENYcDzTGbaDN8IcQ6qSSmAWgjemwnLdO95vAAXudQpiG4cNCX
5rsvPAmmrUvAPT6eBDMuMMIqmFQNkU/gcvbYkaWKqIf4WKo2ZjkA9VdDwG2DSdUa4HjkMArdI7xJ
h/lUeoYMMW0IaIDQPcKbzD76jpnKb/KooI5T97lEfgxX267YvweO4z/vP6UZxt3g+MeoAxLe4PjH
qAOESg/GLi73UQeEFoAXQJyAcbe5DtDew5G0vn3xAI5V4FIRv7YvnlmhdumEs9y/mIFjZIWAS+Lu
goy6wfHbF3PuyEbcl3oVuvobHL/NlYLxHY4T2Q/sEaLd93h8MfI9E7C907kmtG3mSao5d+SQRBkL
JBDLiXyPTbHB1rXyPRVOvLK5Vr4H/jlZzpEVwh6L191yDhgH+6odnmP7opUMoecF7KJtl31ePdzN
0FIjzD5b4R1Ckz0CvICwdm3sdIA0gvja2GV/SPUGoYkkAF76iAvmbVS6tQeKAE1A1KC2qghBPuFM
9i9m0L4g9ACv2vaYswkBjrGs3Vbltz/m9Wr5TDTf/bERcu9A2vnH/vjlr18MVMnWFYC9/fIF8f3r
H/7r9YfIf8QfXuP2P30d+B9f/vUf3v4bk4EVvz6q8Jr4UoFvvc3yp1++lhX86t/K22//Bwv443NN
wvvQ7wcChKivgSAf54KYOQNk3EedgQDRsCIK633UWR4AFy99XZGSuW6J/49ROeV6T/zfRh2BALgT
UWzuX8x3KXF7E7eMmySOm6C4lxFQyka/aEBuDgLh21w5jOE4D8D5fa7D4QI9DC8t0t1EXggE8MkW
icbbXIeLB4sFv9v3eN64VEgCeHeTquTVO/YI173v8Uz8x0FF4DS6RweLNbCM7YvHbUSBM4L/GJNJ
AjgEliNz0j1G4h9ebfbNVo90N6wQgdiT5WTnDXTaJNJdzL7uNy5k9bcbl2crvIeLZ6neb1yIJFZQ
AXynpzYS/7CB4lz2QwAYVXVf1xFU/FrXWLvd57nmgE201qmfUNhXx2q9sJMGeHp5rUOoFUayPn52
UD1WAA2FfbXCNAQfAZtQ75sej3Q3gIb1VritVthXX3iErh5AdhRQ8MHOUNylTHOp1JtU+C8oW63S
dUVKf0LZjZ2hdZciULfTdY0olZKWzmO+exrhMWGxRmU/O/gWZpx0FCwHuHlWYZKINLyAHVhjHqCV
KIIKiL15zAQYI1kPSxx9nysz9UjWR35q13a+jYBnWlUehZ2hhsg3INZCvUlrAGZlqO52n28jTK8o
BWnU369kPQ63FKbH1oN0SauVrn4E6XplXZ7tvo0eKTGTzuwLbjBSYn23QvttviUJ0lWTho49OkCZ
xR0Cs/uVrJ/QY2F6BLu+DDIdlcneAjPNXnaUdibrB2LaUB6RI1nvxVfK9dnLGSwHdp99dN5j0GKv
q+yKfDFuXDrGOtPjunGpo+6e/Cg1CMw0p0mlkugd/t6/g3OAXa7IKyWp5nusEbhQE87J8fE9Wb9y
M0Tbr2R9s90zpajQg/COOZK/T7LHqb6Ay9eN3rMkehBebCHhr5ysV3g5uM0df2W0DSFcoNm9KpNq
r1GSpNgqkyoOIs72EZHz6oG2IdlZJ7OcjmjVEbadWiFOP4j4HEatEK7+ihiq1Ap7j7wFMAC1QvwN
NKTrQoWsa0KPIOvJ+2ZtAw3BoxTbo1XWUBQ4QvJCEUx32KogxFAMMGCF0oExaewYsMIqo+tnPvr7
jFo+c7Q/dGvZ/ZEK3W4tP0blmyBwxkhs6DLm57lu95G3uTKl1RZpBp/7uo7ygBtZ9Sfl3KvUb1/M
c92q1MlcDeB4uC2n5E8qXPXntcTFxn2u5JRe95EybFvXp/Xnhhi0SeLT+vO4gd8l8Vn9+cDxcKqh
VX8+EM/oulb9uc9Fq5415FFBNEskeW+rz8n6YiBfLrrLPpOvSPwD7dXKVr8S/2COTdjq132k1Zr2
mOlxON5aX5Tj0SYUNKE5wp4ym1DYVwd/UartdbcJs3ZjtvqioVL3uU6yChqKQVOovHrUsbVWdovO
6xpRx2am1CZeleWjzW2UpCKVV2X57LJL4ri1BIwTV+v0ix41l/AWg2rI5wXS3pKGDkqL4DLMKt3j
IquYyweTfYWtQosvWPJ4HitstQ3EaKqhRVY1ymfoumCF3Wvv26iD7gVZbW3sGsrajsQ/8I3vGjpH
AcZh+ft5lEwKb/XnZPW3+vOPUfWoP4etgoE59XIVwLF6e0XCZ6kCOBr0s2v7sAkHeAGC7jSmtTIv
UPuyx46D5AjonkcVFNNQ07CvGS1rJD5G4l90Tr5HwEH4e/dCLbrVAV8Ir08tujWJ+Dh1X1eKaYvS
lim7Xz0T/4hWAFWN+sJFaatoimkHWVWQQl2J7GcP0IaFz2lzP4+eRzm8L1TidNSsIExYPI2ii/hW
xBilegTxhRJlTDYXyPjlHc53P485WS+gHAIa0JgeTUaUVFaj59FUoqSycvsyBeUQaekMHUUEANod
jlzoumBfvcJ+KJaz1q7I4E6KhqxNyAtRrdO5YKvwTFOo9zXYKv7aE+LLtB3+q/tc/VnPvjDo8RgR
Eanso5a9ATltozSvHrbqAmVzm5jwTGAcO4I5vhgkuo5V+/+M5SxSCmCGjWK5vlIKwe7ZuvpKKYya
cE6mjiul4NWMnaGuUTLivp+Oo4K7IvKN6PZieuwNnslfNfZkXdElOF419jepZuoIK6ytrmLcZ9n3
1UsIrkOxXF+9hKPsHOYk0S28nEyKkDs85ojaP4qsgmoDo+keFU4SHeVzXn2Pj1kSkXhoZkbP46La
RYbS89gDy5mujtZn+xor8YC4/VlM+wES/Rl5+CESHZ2jD5S2RDkFSKHdR51U2y+43RF5gttcuUhl
OXEAadlGHRlfu2rQF6dfBEho08rYV3/Q4xI1qisY30YdlfgtalQl8mO3Lx4kGsQk6Mv+xYNEA+wB
I4Tjvc11kGgQE0DCoNofo04SPaNJbTVmkNXjYBjoi2+yP0j0hJmCvuySOEk0zHT6KgYh64LjjaL+
udtEpnuwHJ1R6MHWpQChoHGLtt9G5Uyh9GhSK2pM9houNVxXpaPCpXrTRiUR+Vdg3pXluI06ynUA
2ousJtuPUTnfE1la2L203SZyZtWi06Ou5t/b6vOlQxT1zLaaf5/PkEbjD8xrX9fZLI3APnvXXRKZ
kE+E7DrGvvrPmqXL4gn3UTn8B6UFzl71rrdRR/51RpPtolXPXwTGjibb1db7fDoqLGcWn0leuVJa
A6oW3+WVC/ZWS/UEb6/Mcip8DixaG/UTFd4k0q+dnrSKMNt7XW29z6ej9vByrRm1+9oDXprtHvOo
Px8j4Hj3bV1HZTksJyorzKlUYTlw5Kut9znCRC27amk6qSSilh1+VZxJYuVfD7+aPROcOAAtNjno
KJAJWES89EK03UAmwKGzFea5atQae2mFjnrlX2U/HQfBjGbp92vHZ7t/ZWllVRQ8aygoLbyq7v7+
qOqPZun3fiMiiSCrMEMbzAqDhk44uVnoHgG9IC1LPjrTY5BVAXIvNCo0EIAqMrl9vWdpgTCZhiBQ
gHZxaUz2FvVvs85B5RUV7+Bn7ru8PsnSlkC0VF4rSwuZzk1e+Qrz1VKNMEr96mqpBr3sjcn+a5ZW
ubyixLlb45486uJL1IRzqfb+7dmLZzxhUeL8/uwFkf0M+iIp8h3ripTCrLZL9Wji9qAvLUW+rMeV
y534LtV25HIdMcF2bWdiAhpaCgIRXX3Q0AKTGDueyDnm6BJ8f9DiWaqrpRrimtQmoqW6DF09tM9+
NQhmC/VSvPq1WXpnJw/N0t0ocu/xWM3wuWv7INFD4AuHN/5FeLmvl5PPttqjsu39cpLsceVydZXj
H7b6A43Xny30x+hefSRM4QaBC1dwqU8mf8+Z3uZKsBc4CQFhlkgc3+Y6iNxHNvRjFCvdJXMBjhcc
6rhLvK3roGhxg1bXKwK3UUezNIgcKHvccd6+eDRe+4Uo1XTQueLNCAEw3CRxvDh2K90lkhhRrlat
NPrFKPCdcOW+rf4ghVFj3y1JNWv7VrpLvngr3X1evcK+ENLWHedtrtxHEDnTuGoXJnuVePsDR7Zs
o45m6XARcxVDsVHRpgqYRmW/XvayvoqhnuW13uwqYxXSki9WuIio5hR2HiOz2kGOdZdXJoUW79To
anAmqzcQAIFJNHaG1ptd0TO6W3Sm7WNlq0pTOtdc2Srp++oz8Y17Nixu9wDHdUK8xhX10J3aRBBM
KckmzpxpXDFN2S36IHISV0xehdpElcgTiO4n7aCh0VIdb1DQ8xgt1SOskEp1NUuD40yj64pmaVhh
OmlHS3W/IuYVal/4WLSzrzeCbuvK9LgLQjZIIbWv1SxdfIzdvjJZjWZpEPJS6B5nZKveLxQfbaJO
i9vesse0swwYka+VlScgX/QR5dxSnNkXzsW1HiWiPjryr4i0ws9jkx6NxDWdx0yYIrMq8e4VW32Q
VYCStvscydnQyKwCZuu2rh9tQF1tlscSfgyW4NS+fqoesMTiKb6+gt63UeezpLdb6G+jTlgCnNfK
a3vPc2mUx/Q+trmOptHoTkLAjue6bqNyAA3wUup6t+C2rnzT3koc/tf9zLdR53swcPXWV7f+ba6j
o0jX+wDrkH2M+gzigFYZX33cVZcxeqFz9RmQcD3seZvr6E6KIpqy0iBEQ3ELHc/GNDqX42CscvVt
rs/ecGkyK139esNF6mrYfZbquoVushp2nzW0AIdU3+c67r11XqtxZ5dEDux1Pakoyb6OW+ioHNWV
vLyNynuMxJ7iYDtdPSynuq3k5bNNgGFDEn112N9GHb1CE+BlrA57ssdI2bXZfT+1B5Ro0LbH08dM
j+t1Fhm73Z931fWK9H+lp2M1oOKIrJuERz1+fZ1Fhdnq690VxNnG1rWgxIRNN2aF665aZlGnX6wV
MM4l+Yl89xpQovnY92jp3qi24LxjvddBvmiAS+olaSh/Md5dKXCs9AxFrxCCe/ZMeV29R4dMF+qj
N8DxaIUb4PgYlfu0ZmSrTHwb9cPtxruJ/z3txhGvjh/7aDeOG1r91m/8/qf3huPe67cG4/s/fxt1
dhsH4xvvncbxI/c+Y/l/6zNe7W6vPZE+49so0md8G0X6jNlcH33Gt1Gkz/g+6vmy4r6u47Fyjx6j
eODyvq4sicg61yawGrb6j8sKtq4oCop2pV2qx/tv4+rTIk7cRx0vu327rLiPOq40QOR9BA5hq4+n
JNocc5P9cW3zUbrNpAqaaAMgl0vi44FxYjnrskJbcyp7FVC7YebbF49e1ygKArcu+x6PMvDI7Ywp
lX4xLhg0Hg7d5jquDuCPEXtbZ/LS6KyB11ZlelQLbIoIJkxD64IBrjtZTr7ciQuGGfSIaejVQRyz
0dXHbSyCq1Z2hnRGbkfbLomzgzg68Go8mc/W9d5nrPsec0YWljNeyJpou0p04I14LpfscT0K/kLW
ZI/rUXAga9vWlfsaQSOv9fJuY3uEECLf5436ifcO4rLL67w6WB3E4rt95T1GUTbiuBjTUJRbVxCz
Ss/2eu57turOLLrCM4EIW6/MomE11wAA3z35eQ2x+ox7G+w8rjfbHNiUWvTKc6/EGpPEynMjNNhu
OUfpdot+Sx/UokGOIpPndRslR+l2j/K7FK3Oouz4ZQvyHW/yetkNTprKa5Vux8Nb/IvrZbehXKrw
4dd6cI76CXjLuLaBC6Cy7/Foc9yj0nW93n9ru1TPB8ajgQDRuzFv8v6yW7LCzJoB46+oc7XJVr/e
bCtqRhGMlWggANAVOpesBgLskp0h02hQQYSkaGi97AYMIBRPwD9Hj/ecVNurdHv06Mq8j/qkKBtU
yzlSWEXZY/36EKKhyHMjIhejEdniJsV6vDnJvhhVf9ELxuU1FHEoKq6YRVtU/dlq32J6BKvxuK2s
dF1R9TdwwndtH4XUEi19bUfbRyF13LeMHs9qk3Wtp8M1Cq7ZuuLpcODCXiku7PFm7pD4tTlEXpjk
Whcpg2l7PR0+arz8wb4IzxStVKXQ1QNZFQSFvltOztJHnjt+B0Rhp2PluW1qiqK5eqBHhVf7HN9/
P+s8PtvOj1zvtnhY/4EAfHTq3kaRTl0210en7n2u507d+1zPnbr3Uc+duvcvPnfqstXHy4Hx8ma9
jzqflQrw0uO5hfsXj+vdb89K3b+YpdoDvHhcKLN1RdZZS9/3eOamvz0rdZ8rXyhH1hn217Y9HmXg
kXX2Fs8esz2u7o4eZTVkj68HowBxNtlncBxZZ2+98D3eflMUsZzVqdvi2mH74nG9G0mGoRGCbnMd
FC16cOM1EqahRdEcAmt09ZEpHgAJziz69r7gffWZ7kUP7ut5CvbF+O1O8QTkZKfj9r4g0fYqWMZc
++k4s86AXmAcssnr6A2OTHFUNTpbfTwYFcUwtyFy8LN4k7ZHVfB9onwLGa21bZZJD/Z6LUqxpX2D
+Q41XosaUaXLDtB6B0pVvTCRwiHBbJoaNfrF9aJQvLCD/eJ6o9bP9vg1RMjj7eh6RcrVdwPe0476
9/30wTOjrbeVJoOZ/7pX9m5zd4n59nm9VDWj1piOevHMQt3rV565W9pxdx6/fOqV52Fzxa+VQqDp
9PCuXyuFQDPHJ9bBdBV3xj+9Nw+/MkDP2npOEn/+05+0Hks8sDbZflfrMQJYFbpfXScrihPIaWg1
3jHSyDwS+1ivaUFyg4bf9auvEHl2B5NZSFRzg8jPTt02mFjUyM9kHzlxHy+TY+ffWX2PX8C2Clbu
o/JLZmAhVWAglY4aAk9U+66hY/VRGd7MOtdjNCg7LGXXY+boUfO9Os3pXB78wjzJPr/VtGBnt0lD
ebzMFY8nJt+X2aSsko+5g62DAapC9tN34HbwseDCiAKuTKoWD1a7xu85IFYYb6HXqPjY9Zh5YrzM
BQReqVRt/f4YOCkaMtfLXHBoWqhU44GYHq3TDCCtam5YIQdIUc1de7xmSFcfT1GLD6EnLaq5bf0W
Q6rteCCmjZns62C5YIA+4xkG8sWo+QY8clVmOcGFa6SGP/PXOxeGpXKPuWq+VSV5zOP9rnGNUdWo
vBYXjv73bZQc73cBkgVF31afG817PBADLO/Um/QAp62obaPyoxvBciHT6cbsflVztxYP/RBtA5he
Fpuqn2jo+4x555j39O3/AYsfKiJlbmRzdHJlYW0KZW5kb2JqCjEzIDAgb2JqCjw8IC9Bbm5vdHMg
WyA8PCAvQSA8PCAvUyAvVVJJIC9UeXBlIC9BY3Rpb24gL1VSSSAoaHR0cHM6Ly90b29scy5pZXRm
Lm9yZy9odG1sL2RyYWZ0LWpvbmVzLW9hdXRoLXRva2VuLWJpbmRpbmctMDApID4+IC9Cb3JkZXIg
WyAwIDAgMCBdIC9GIDQgL1JlY3QgWyAyNzAgMTU5IDM4NSAxNzIgXSAvU3VidHlwZSAvTGluayAv
VHlwZSAvQW5ub3QgPj4gXSAvQ29udGVudHMgMTQgMCBSIC9NZWRpYUJveCBbIDAgMCA2MTIgNzky
IF0gL1BhcmVudCA2MSAwIFIgL1Jlc291cmNlcyA8PCAvRXh0R1N0YXRlIDw8IC9HMCA2MiAwIFIg
L0cxIDc1IDAgUiA+PiAvRm9udCA8PCAvRjAgNjMgMCBSIC9GMSA2OSAwIFIgL0YyIDY2IDAgUiAv
RjMgNzYgMCBSID4+IC9Qcm9jU2V0cyBbIC9QREYgL1RleHQgL0ltYWdlQiAvSW1hZ2VDIC9JbWFn
ZUkgXSA+PiAvVHlwZSAvUGFnZSA+PgplbmRvYmoKMTQgMCBvYmoKPDwgL0ZpbHRlciAvRmxhdGVE
ZWNvZGUgL0xlbmd0aCAyMDAzMyA+PgpzdHJlYW0KeJylvVvOpLtuJfh+RrEnUGHdL0CjAbvs8nMX
PINGlYEG6qFd8wd6LX6RGaIUWvkf997AORuZCkkfRfEikovxr4B//0vE//SZ/vq//9ff/t+/vXq1
P33+/7/k2Ab/Iv7Ff//7v/71/Md//Pvf/uFfw1///r//Fv4qKZW/Rmx/xVDbX//xP/72P//GCexP
ck/j1x99HVdyeobOFj6/DVzp+Q+s9E//9rd/+G/hr1hezf6Zf/3b//xb/LX32TBJrn/92//62/8R
Qg3/51//9v98/jaG8Uph9B7WUWVso2J75TpHH25U2Ual8qoxzOFXjNuonLDPFGZxo9o+ar7mDCnO
dVTI26hSXqFhkJ+r76PGK+YSt2/8p21Uba80avrDN7byKrnl7Rv3Fdt41TByi3L3Pb3qCDl3OVdv
r1ZTjlnufpQXpiopynOc6TVrqWnIfc3+CqnVUBQlUqiv2HuLye1+WzHF/Mpp9BTUN6bYXyWENqv6
xpTqq9aIz3Rz/fM2Cvw1+pz6G1NuoESc2zduXJjAX2mEkBwX1rSNqgk8EaM/x7J/Yws4bdzxok4o
gXN6zhtPHLsH5wzsY3rO+cdt1ADtx6zD7+u/7qPAX6X26jnnv+2jcB9DnLHJUTO/Ilh6SL7Htl8p
49dRnXYGf+UBySO5ENfiVXNK/hvr3Eal8BoNCyZF+5zmK8RYc1W7x9m8cLXLlBIABwhK4Ko1xTm5
4BtDq11KOaz1yn3U4uVX3UbV/gJHtJblN7b6aiN0L7+OFduEfku9NHU7coecwGF3fY6j4rTjnPoc
J3kVl8if46Y7Sog47ZI8Jc5RE99Ys6YE9MELEroMydEQqK8wIQzdN8awj6qv2fN2H/cTKrm8oCNx
JRVPlJJeqUPOSblaaniVhMOukhIVeqj3XoeSTKW1F+yQoW9t6bhDIYySFN+XDj2EyUKS3wjJFFKe
Sd60MsBfEF9a15YZX7H14Xl1l4UVnAOOjlnexxoo5XKq8j5WyJzJyaaiak0Jp92yp9cufWuilEs1
eM6Z+6j5KrWUpkdBMtXUitd8O9/XEl+tk8EcJeo+qkHXQl11OVctrx5mrvI+1pZM+vaszrGCC2fG
9SiS9h33MZS8SZN/2UeNV8Yxbie07x6ar1AEeF7dTwiSCWqoN6mRK3TaGGbOr3Nto1poLxhpY9O1
myxssOTjwIxFcU6jzQTxlIc6xwYuhHrs1dO+7aMgMWGwets3bLKwgb86VG2Wt6NB8/VZYIGpmwaL
4zVLnSkpzmngrzA7JOmXc/yXf/uD5wMv48tG//gzU+z1pvRiMIM2muiqt8+LMb5AAtiibtTuCkWQ
PYMhghu1OwAJZIe0jG5f+0HHNGhezpbkvmD2dqzXpvvG/7aPWpyv+6iSX6m03IYbtbscNb4yWLl7
qu7fWOer4l6MvI46HJOWX/Aca/X72ikBEdF7bHZh6+1axw5jb0769WpFKCrM1/03HicERQXB1Yvb
/eGiTYj6+b78V3ol8BfMxum/8TChQ39BAMxcFSVSrK/e4OMkxTkJxnGDOTuG4hzce6r/7m/H4XKA
c2Dwhe45+nCrwIURNmGVlMDlH63kkOXuwTm9lGlqo95EF/QwhHgbs0iqNgrxAUvb7Wt3fDuFOFhn
qLud4JDDXYohKr5PcMhhIfDlR+1rQlHFAh9fnVAO5VVbzaGrfeWYQHuSVdH+cZhgJMj7CG0NlQ03
2tNrdxPgkIOyLU+5+wKDFhepSYkJ3YlvnDgidR8zHPJGclXFOY/DlGA/yn3RYep5k0y7LIQQfE2Y
/2XIUXDbqdhjlrQfAcZLD1lKzDwGjJcRtZyAiQ16wamVErOEAJ6Aa+Jp/1/3UYN8n71cPYx28Be0
X05SYpbYQAkM8vTaJCYcPVCilCglZgF/QarWLO9QyTRoe5mSJ7DWCw5aLPJ2QNxA10K7S54o4EKw
YJ5SD5UWoGHAsY72u7EHNQt3DzJa3u0CzWevL373/7iPgsSE8M3ybtNFGyFvEnM3aOl8zQrnyu1r
l5gV/BVD26h6uByQXxNCR99tumjwhru3Jw6jnQ/WA6rPcU7cHRNIuUL/UtoAlc/aOQx/QnnfF4xj
0KxstsnG0eZ8YdBIir8q+Atk6KHKfVWcUO2wXyVVKx8URxryDtH5GjjrUBRHY0evWGrdrKGd9h2O
Sc9tZsXR4FM4E3NUqUVxONhXmNvud+eeD9Y5xSAlAMQguBC2r+ToBv5KfGWWHG3OV2jZS6ZvzlcC
F263tu+jGFwB8aWcoPOF6x+65FVzvuoMWdIeuvEVYJhvkml3CqFrM/ynpFfk43esyevHw93j43dr
IJk67cbH79hrmopXYUrANhlYWO4L/AV+fsIT93Mc9AIof+W++GBd0sarb438R3/y+zX+mRvary4H
RGroOMG6jjpcDkb3EmRXdqO+Rfd6iWYI9RtBI4VlabH5fe3ucQIDdqgqN9cRRcvw/hNU43Rz7bHJ
NW533/0at7vvHgwIgy+ZaX+fa43b9Rs7PBG5WdqUJ0QBl2Mp/oR2NxRqFvKhzqLngukFn9BT4nBp
6WDCgp5VUmLyLXG2HtWK5oZm+AlN8VeKUGcj9Y2qu8MU52vk/KjZ+4oJlIBmz/IcE/hr9j6i4+jD
KWQMsI5HGV9PO1EMhlnNoP3Mte8eyhjc0/xNO+KccCbyr1fC+4pwJkpLYwZ1hxjd6xOeY5X0MjEI
n0PeR+eG3qkK/oKLHDzfh/20Gd3D34euOJrOKi72KPIOmbMKW64VtS9IrheU6ExFfWOOlbHcUOR9
pEsbIAujlCZwSWCOl5g9fx0xQHxjqqk2uXu4tLD+U3Sj4r4iXVpYjtntPmxUzZUOwJjD3+3dwaRL
C5buel8NbgJsr9zVrbUYYIIGDfIcYexBfMVNwxzOamNGQQ56XxMnNEfyGuY4oQleLfOJon32tbuO
oTLy9TxNXOfCOTPy1TwlDqcwggvDTNs3blxoMUCo0TDU7YBmxH3MtSTF0easpvcT5n33BZZDT11L
E7qhoPWMUisUaFHYlsNLuV0C0FmdFc5qlN/YyivhateqOKdAyuUWutbbBVIODn73t+P4RmjR3sJo
Uosynsg3h6R5Alp0jvyY41cJQGcVVkzwGvlw0Sy7qofs6BV398Wyq0b0WnSXACD6K5l6VxLA4okR
JznlvhKfaVPbOOebS1tLq15ifnNp8dsubUxzaeE4TikBzKWFMqpSMlXIr9mhYoK6jxXyK/MtpMpR
tOVyS1lqBZgScMjhJWTFhXXy6asWz9HnKNhfuOAhK0o02l8RrnZWJ4Tr86q4s5t+3J0vhgEggj1H
7zFT0OAVIHF6UpSAy/tKsY8p73ZjGICvL44S7+eXP8ftyjfS/MhhKmH+ep/ZLlkMZoQmitTPqMNh
gl8P04WLr6N2NwEeOy5/4SvOZ9SZ6MjkMTgKQc5VmDyGWz3cXHMfhevT6khZzgX1P2ObFDfLXHt8
rNG87LU7ep0OE83LWav7xsOR6xWKHWwT5FwWa4P+dysekVWG4yEtm9v9EXWEx95AruiperhCCco4
BzoAd3qlAAcAhqrniSOSwxch6DzPE2cKY4a4gYMpKcFEx9xnSk2dUOK7EdNtk9x9ZsQkmBhc5trd
l8yISQrD89fhCn0icmLFJSK3zLW7HOAv0L+ULOkF/kqt2IujmKtDDM5kL0KCqjBCG+YaU/FqGvUF
JWsvQmIu8NeASO1693CFJhzy7EcdETkqhNCq5/t/2UdNxhz6iIr2OVLUz7nRazfHof7hvYTU1Tcy
0XHENDee2HefIU1aiVFKk1wY5Si96hXBX5BMFh+7SwCIVJj2MNM0VcFfGcT38v5wOXqAW9Ut8iWo
2mHaw+UokidgKr16h5zz93FPMoX8GgVWu979LK85YYVKCQAHGm5V3iT5pgnjTRMWGA+/kmuWX3v1
m/7w67HJ4SMa2GHa4t+m7gm450Xjffva3Xw3ByttnHa4ApCK4KDgpeKRWgipOJj55aX1HgNjnC/M
MuRtsjhfgwcsebvAaG24eE1K2AKjtQ8YRVFSAkYryMCCj5Nr1blDXzzuEk6lQTpNcfJXC+r9a0sD
W369xzVHZFTWHuoEVSBtS2iWBibOgc4WdLmXRIf5TWcLx6/5w5ytWOLGH/tcdLYaFEpV51BhDMOO
KknabhXGMGRf9Zrup7e08hE8wrvK/5lb+v3XR5QNhjgI0jbe3B7aK3O0RrQH7WXU4ZxNptrX6aXg
7oDSujQFKvcF7Q8FPZOXMYdzBpuq51CanIsuXJobdxzOLJ/j4YJ0zUN09HqO2X/jHlOldQmdUavc
12SOQyheAx2uUmCOQ6xeA+3aDEbLq/BlTFLi7eiNHOSK4O0BS6J6ztluJiQaTigG7SXApIe8gkHo
Leg9DloCdV6r0p5tfGiHJbHZ2XvEDj4OLu+YUto2PrQXqGxpUzWzLsH40ga1SCLE4nY79hMa1Osj
eUv1PdcPJHdjJhhcpFqENLi7zM+vN+7+scM9vx3yzxzu9NvhPiKUIEgF3eI66nS48yvit0a2dDuo
yLcvPpL3ddQR/1pSYD+jDmeU9Ye1TD/X4dgWVjs0yzxeVtxd6cJqmvYo9fvu+aqV+6MK7/ui8x5m
Z9b3Mtf+jY3VDtUiIsu+9sipCU7Icz/qSG6Nr5qq1WosKx4ON9++YE9FuS9GKKFDgh+1u/iMULb2
uL/3uaZFfZ5HmHS7cDA9oaJL9vs6E2Xh2DYIM7/ikSgLXo3dag/u55jshWw8ovr6jXTL82z2dn/n
L3PLS+/bN35xy5ntyMjDMmpfkVnyqQdGHsTu6ZbjIEOQ9KJbXoNFAgXt4VzllIK+2wnOVbEQuNwX
6w+hTD29zhTYAEqAK4bcF5yr3kYcftQXt3zGack7y752tzwGOKPgiaZ2n+G6wL2xlPRlxcMtbzjt
2YaUTBmcA3Fpz5/LXJtiznBdUqgzJ3WHcimMNIfZ1d3Opb96hF0R5agKBdgxoMnd1wqD4amMvt+0
3CDvZ69ByvvcYZCW0bKmV698MKwzyxUHlHyHZmySJ2b8Xdtyv4+/3HKvYc76Q8hCXKLh7vZRdccU
2M6XOfWN+D5wIVPXFd9bomwK0WvR0zWGEdljqpKqFnvE0JiU/LLY47TqGjVXGZS+yVsK+02z2OMs
JUktalHFUquXJkc6LVNge25N6toCzmlYdqPXUcs4LR1tOol5JCkzqthGj1nSC85AgGLz0uRMbg2W
jjblTTN3uOXHxRJzDT5b99jV7t+JsqMERfsnBRbbynJfyeLku22yO0+MKk6YVnpFRhXpy3tZuEcC
GRaZyWo/77e20rIquLVS5phLOiGY/N3+4pKWhNuhac8UWFhM3WvkbymwNeYipQlTYGeAJeClybcU
2JrrkNLEUmDhthZPid3hAeeUmttmie7VgDGy9vN5Brp+I2sZYQyFkBXt6ZLSNfca5owqQvNBhxZ5
a+FCQXeEFKQEYISywK3oQVKCYRHMNb2VtsdXGRaZrM+Ru4fmCwW2mrSsYDaCEqV6O/pwqCHl4MDH
jQv3fQ2ma7e03e39HKEf8YlPIObK920ymzHUpKk6iUKCA/Irbre20/4Cf3mJudOrR0vX7pv99dOk
2/htoz9zacvVYaLgBdXtPbjcDoeR5pCjldwuo44KURz0SM8r+2fUHvddIHU+ow4Hc4HUWeYSkDqf
UQpSR1CipleKMFiT/EYm3bZSLFZ73xdYvjEbuMpRa6T5TomlXlPMBWYuc46Z9ajOZBRLYlhW3NMd
1xjylRIuhlxuLG/RYVi9I6sTSimyaiXXIVdkSTc4onnO2fgrWVUBzjzJFa2qgJnYckWWdMP8Tv4b
v8SQA/NaPO13R64OKCpYx5KjLZ3WirrkCVlVQZzRzXVUYlo67fsl88pfjCEHSHrPhd9iyAE3OwX5
jQtYzrLiAYMDVwhGSShqXxZDbiGnrva1guXcqbqC5SwrHqNwQmPULHnCEmX5GhKUNDFndYbu+f74
xqeqc4Ymv7FaJsPQ9xFSiZkMcwZ1O6yqM7dZ5WlnmIQhwACI6rRXsBxx2gtYjqDEApYj9gX5hdsR
upMTeXcKYeyNWp+o9e9RaXdfGKHNoW9U3V201PhUOJrke4vQ1jz87TjcKmgrnkiRsrAU0N5K3BV/
lQrDkZg0Um/TDY24tl3qbXNDYW23Kr+xEYCEkTc5F5NboWI2+fUluXXABuhFzsVKzF8PPp+59tjt
BH/9evC5U3VCW8FSSF4r7K4jraEetpt2ODkBXMjHSX879gikIWFAkid1jpXFRVb6pb6RUdkAJktS
K1Rm58252TlHBJJuaGK1rJwL8msMhsQVT9QyWCtbSpG7N8sKCsZr931Fi8XO7rXokTJMsMIUNvvr
p1Gh6o2ov8uEBiXe4kalYf4eJdMwP6NUGubvUTIN8z7Xmob5mUulYd7nWtMwP3OpNMzfo2Qa5mdF
lYZ5n2tNw/zMpdIwP6NUGuZnlErDvNLLmdDXc3Qm9GeUSsO8UsKlYV5PyKVh3ne/pmF+5lJpmJ9R
Kg3zvuKahvmZS6Vh3um1pmHe51rTMO9UXdMwr7zq0jDvc61pmPfdr2mYn1EqDfOzL5WGeaW9S8O8
8qpLw7x+o0vDvO9+TcO88qpLw7yvuKZhXiWAS8O872tNw/zMpdIw71Rd0zDvu1/TMD9zqTTM++7X
NMw7Vdc0zH1ff18a5ufX/5k0zOvNdAmW16+F1wSZzockN2pHscwEp8hjSE1Jw7zDZNXcAVak6xQ8
d5z4lA2SvyfNHWZyw9/R3GEmdww5SGltJneDtvcSdjeT18jPnfbEpyy1RymtaXLH2Z538t+j/mmf
a9qbe/C7P6IPodLBilquECJlELFE6poKlw67TVHyl9WT5ZQ3m+HHCakrLMr1DtxN0OfXhoa8/Pow
+CGT64OGLKjymPKpeqrscZTH/K6lqzOt9rAJI1ZaGWZ+Q+RuduA+l6GAV6uhF+cAjpwR6kneFMaK
oOc2LvpxQirr13J7ott/t7z6/usj0hMCrPHxxMY/X/tP+yjC27XkrcsDqsXg7YiWre5yg+wLKRdv
2R9xKtp6/UFPvmtGw8lkyaqei+gDDbrR3+UjTkW80wcM7M5DBtUS+qaL9xwHS52kWdLkvh6olrhp
lCNOZVAtaTh+PBJSH6iWErpckXGqziC0XJFxqvTOVvvM9Y8/47vmD2Nj9uvPSComT1+cM7ApuLQx
/e8z6nD0lkjPMtfunC2RnmXU4cxS0D5BarGiCcRqWbnLXLsLx+TFyIQQN+poi8BXixp7/zLXD0T7
GgP6/P6nov37r3eErhXcZVlDgLt8RuUjggQ2yw+Kz0LhAxfUQPND8FTZ98XUyUKweDfX4UoPpoZY
AFacKUP3ceYiv9GcZAiLlNWZWlMGyJ/pueiAbcE34vj9N57pjhGmUq3+G89oVGVqiIV87/fpcZKH
wW+LFc1JntYi4X6fzElOIdek7pM5yT2a4SFWZFAenzCyuk+W7sha/yFp3/na9tRa3PnLnGQokJwV
f5mTjFOsnl472ird3xFDn/KEJsGDcshT8erabmEZtacCEpAlE+lefWOGUzLA0DMr2hsgiyFKKUpY
nGnW7nd/tlswjNEegqLEGo1a9rXPtUSjlhV3B3KJRolvhGTq83mLvvMX40zRrE5JCbgusF+Tl9e7
I5FhKFYo75IkvUaGIRPKJrsPh5u8mqyRguAcODiBnz4UvejOmu0R1TfSnQW1ei5q9zBifqe332WO
pU4SFjTIfYG/iAno7+PhENI1boz7KHqVzPqbUquUE3SgYVrU6OXEHv+iA117K1Hx1ztm1f2tPV3j
wEqknry22tMwG8GDYBFIbWWpk3Wa+798456GORIkE4Eb5b7oQDfKbjfXEY1izIpFkW5fB8ZofhmO
R1GSqYYGx2IUb2UdKYpEb58zRklVKEYmFhvAyP20LbJVcmhNcaFFtiY0pJTkVm/YWix+97sLy1BG
ZY8ExV+1BkgA2FdJ0uvBGO2pKwlAQJYIu8pr5GNFArLAQezSnrAEyzAM2VxQlQmW8CJnlStCizaa
wdIGYIMHCPtYpCy0Bg8whrzEPFMnq+Eae3qdgCyZFbS5Sj3UaH+NWrrUouaSZtxIx19xX5GtG+B0
166oauihA0JZ7555PoQGDEqaNHDOrzi52D04p7D810uAwyWdFjzxuuNwlTvrsAm4pnStVfO94+R3
ziEuKEGsk9QdhguKy128LNy+sYMnoLGKlwC7hum0rDps92888YN0x2+K6Uex2ppurwpruuMy6kAP
TVTZydyEdDucFWNUrMh0R4aZ5jrqbGJBIIAHTHYZdUR0CQTwIMAto3ZHjkH5Phrf6Jd9He0p4MIn
6LzgvnGPiTZW5kTDexWUaJUv9m14Shx1foPdvIZf8ewNmCjEh6fEGfdthLDvw3/j4awWmHEwaP1p
748ZfOWDM+FP+4zVwmFiBplbcTdVDWO0wdpL6hut1QVuYunqG5Nlo8P9ym6uYxRfxmvOjvZn3LfA
jIPs6ooLDWN04Np6/toTLMGFuBqWjX6/Q4lQy63lqL/R+gzCLdTfaH0GYUs0uXu+3xX82N+0w/Ft
rHhsrchR7DM44dTqb5x8MukzJjkXnFWYs5aGeR8Fc+rFvJaW1B1akyLvlGBEt1nKveJoi+jCAehZ
nZBFdOEA5CxXZER3VItHL7vf45gw43AZmuYJRnQhmarn1bMa0NqyWHrV/aYZxmhlhHUdtT/JrX0G
xb4aUQFxQG5U2ve1NNcQtO9EBSw9aJ4YMEKJQ66/kQmWqVjbnzuvWoJlr9NLuaOmi90IUw+M7N11
h3Uj7MNe3e+6w5BIa9gk5tlcgynpKQzJ99azsI9NYh6uNng1EQQ2yBUz82n4TispQTidmkqV50g4
HVxHy3gSKxJOh51npNVBOB3Dw/C39sArZVykWEuJu8Qk7A1zlII/xwP2JpgR2jXtLVlzpG33R7Q3
sjIna/lVZmFlTk1NcbRFjjvTNRRVa0iQvq14njiATSKrrHv1PHE4hex/iPPJ0gaw/oehPM/t19sB
U4KPNFNbQ9bZMKZY9IqM8LLU3+uhwz1m1g28Y3nTzPEd7XlkvloK1lwDRnWTvGqdDWGkTc+r+wMG
c/jaTNHfoSPCC7cKhlNuckXwV/71+H2VmJU4C3PWzYI5MEaZdYNbJK1adjYc9GirnAv8NX+5Qp/d
784XI7atVW1PtNSJRNqjPEerGRw4oKQkgFUDltBnVbRvBZpvwoUZ6g61ytyvbN2N79IEX/eacyZv
uR/x05bsCbNHJU3MPX53JBaUoHv87ki8zLW77XSPWVsUJe3pHmdoZM85++7ZtqylkabaV4evUDHX
lDIHWvaFIbN+s0R/4B7HL1v4mXtcfi+2g6wYuPPoJizLjVTm+DKJdLi5djd0qfNbRh2dID8AN8uK
u+vIV8I8LWFwmetwoj/VgGJfbMEB2yQ1+Y2M0s6ndesyat8902HKA33+GXW6x8OAj+OQK9KlbXyR
d7vf08jZXGOWXt0JHbWMdGlLfRRVuV1YQtewqjgMSXuKVEJ5dzfqcHwJMc6boeayhOcCqkbFEy6W
e919Aheyn1T1/LWvSGQwbGy4FY9eitaCg13L1Tkmww9LVue37OuI5QbC4ffiT+joF0mXI1rdh1ix
whyf2RpP3E977Rcp9sVOkJOw5m6u/aGAjTp6exym+wmxsrAM64cldm8oY6BqUbfWKgs7tJ4/7f3R
4d2oI+sT4utlrFbycN896w/TYNGDW/GoUvwkT99v7Zo8fd9XTjTj9tPe69ZyJhhTnP5u73VrlhYN
T26j6lFZSKX3AKQLShDg5o0GKijRMqNVz1Ph/RvBX+mNBnrnL+sXydBkl1Rlv0gCCHpJvlOC/SJh
VNUkKTEZH+vW7Oa+YgkGs9Q3zjlSkyEBJizarKhqMDhtjOFO6Kc1SgbQeZD5Z4odd+jNWrvSgy0L
ozix4O4z6izgt1fCbEL8M2pXepFtc5kCt476VslEO9xY/veoE7kOfj0MSxNw9xVzhd+Vnve/z4q7
amTzZnbycN94vPZWwuQWw2ESK+JiFLhBphrvu19aPC9zHWAAje9/3c910N7qnfrw33gYaGzLnCG5
NO2XrlniG5euWctch8pmc91qpa33fRnaXMJsUe3L0Ob6Wzxf6WWJVSFbRdqd9inD9IJbb3GV62nD
2HgR5jJ0OdeCSXenV4JI7Yw4ynNkmT883tk8r24+yS9Muj/Qi+lXEBzD39ojsSq9IAPzH75xwaRb
5jrSrwiB/Q6qXnkiw78pUC3J7/5IrGInojBG06Mau5+FGtTumX4Fm+AJl37m2pULvGyYszEXRdUM
Yy/XmKqkV4Zk+oWKtNBrnwsuRyXIYlAcbTVKb7wjsS8q4zfe0TJqV9lUxqF0T4mvyhjyqydJL0Ob
632TE7tZYmhz43kjuN4OS6yq4XEKrzKaiVWDLofe/YJJd9/9ikm37Gt/cWRiVc2Wd39f8Vc1UQ/q
G8EPrzJZzai+0RKrynhSd6+nbTVHE36C5EKCARCHLfv7ePTDii8CLGz0Opo3F4IntCTvNv6K0CJd
SyawsnXqi572Rz+sQmiRJ5pwp2rHOY46p9S1TL+CDzqrngtSLlkNvDyhWZgYGoqn15F+lQgtEpvU
opZ+xbiwtHPsFdraebm5jrfqCkne+naOB3IdE1/62Ph+3z2fTOoMm9VxYNIFnFDYOfoYNWDQxo2j
j7dX2kwDHD0lvWgztfgHifmrebO2Htm8eb4r3+4cDfnMV1WrfBP7AhfCFa2bHtrrsgY7vDGDRO6L
9eY5l82y2k8IXGgNPSVViW83Y+qeo8+3aj6/lDb8N+4A6HwyYcOyqU67MVcAInpKadLsyaRtWvQY
xbfqnEqS9DJ8u1A2v+NobFwYy63Pe/ydXrTS4IZmKe8N3w5zeZ443r2ZSh+a4WDeNUxjKv27eYRY
0Wy5ttmrJ74dbblu9bV3Xm1my8Fg9fTaYw7TUK5DkFaHIdcRGnV8kUw/aAT97aN/5qzOmzqLzHtN
4xGp88ZazqWdt8tv4Bzw98yZmDciGDgHlJmJwd+jzhftxp4dzRJM5u1wIsN/kQW5btSBXNfhOj5N
ID+jTuQ6mBKxWDnuMupwfBuhOa3Fs1jRGhESglhSwhoRvoXSfRTrjnD1Q5S772zUC8+3S3pR8LbZ
qj+h4937A+Eh9kWR2jF2yH3xRRvSpvgT2l0hvlWDC+NQK66wG8uoI/2KFUUh56L29eDbpWym6meu
b/h2na3b1e1IVooJmepGfcO3C+Pp1CEoAcXO2GXscvd8hWZLADfX11doaPao6cUkrRLCdtOOl+On
EXTzuz9ejuOrxmkIceIcJ1NaHlyh+zeaSwtZ0t2oGPZRBPvPwX/j6dIS7L8+VXlX2mcYewk0nfLW
mrOan74sYkWoWRi1eQR1QrkwqJqtC8+dvx6XdlpLgGX3u4MJx6TPkKOUvhmcM0t8kl/v+2qDUD8G
2LKMOsA54ACUpy/Lsq/9AeMNoN4lR5tL+yvm8JlrP206q5V+qPpGc1ZDbkFqGHs5rqUnL5kONxQa
hkV5UvOZs/pGYrvfoTdAxpNhft+XAWTUMKv8xgcgI20Sc9/9A5CRi9QdVt9TIcGipITBaEAve5mz
u3tsywzVt0nMPeGLyVC4Iv4cTwezsDVw0RqmDGa+95KkpVBmgjR52n7fd08A9ckjSYr2BMgIhDys
al9Mc4op1ylvmrVl7qV7aXK4jsmeTMamO741XJ7dGrKIbzRo9DGT1FaW5mRleUrmVJj28IOeBN/r
7TAAdYiU5Of6590NrayGmJttcqQ54RtjeyrY75Sw+p4RvDT5CqBeStr4fqcEq7Cxq01O7MljrML+
lSB35QkDUI+jbPLrG4A63PGc1b7MwWSBTFMSwBzMMnqfiqMNcmIyn0PunnYOLT5pwViaU4XfnhTt
6TrC68ibbXKkORFNepQR9SjYhak8aAv33cPatuLdpm6HJUOV3jfNt7vHrMKGT1ilNdSI9gtzu0tr
qDHa/m6sI3bPYMG7sc6d7zvRft+NdQ7O+YGD+c2k+ZGDyTTz7+blWgW0jBJVQJ9RqgpIrLhUAX1G
qSqgZZSoAlpGiSqgZV+iCkh841IFtKx4JEN9qoDEN1q3iWKVFWJF6zbRrNROrEjIijYs1WYZteNz
LvU9932t9T33fSW2NuzNioDvVE3gnJp68ud4RFaJ9TNgcbh9He7eUt8jRsHYmyC+5mhLYOqjbJxz
AFswcs92JnIuuI64QdbF586FiSWTjbDn6hwThWXOqUZJexZW4tyi5+gjsjpexE/KmhJMYBpQaJ5z
9hMafDmGjSMlQBp8OS6WTbzMdaQm8U24Nk+vw8kJfBNufZMmR/y1Ew/QoDTu50gHk0gHwdHrGzQ6
y2OTo1f8531UoeHY41CUeANbtD7Uab+BLewZbfnGPVJYDF7FYiGCXsXgVcaQcuINbDGKPMdfMOub
9L3ArKep7uMbZn1oKfeGWTd4ArH7N8x6DJJeb5h1Gmh3vn/DrAfPOTeY9ejv0BF/rXCFWtyk7z4q
4hzB0UNK3weMvY+Nc/bWylbfkwxV987R1u2rhjSTogS7fXXreyB3z3bZI5mJs9DriKzyyYSySVHV
IqsJ5nZWHG2R1d4NVuguVy2ymkaqngsPZ5X9EafFVcS+GDN992y6c2GZ7I+YDaH3zoW/KndSU99o
MdN3z6b7ir8qd4K8Q5U5a22WHhR/sXJnvvvq3W9tZc7aZHWCXJE5azDsNy16OL6V2IGlF0Wvypy1
0Q2E5c6rbGbNVNQkrTTGX0Gz3f7a3WMCi81o2XtiRaasw0wbXubs0dDO573RNs13xF8ndEfr/oRO
x9ceaSyJ+c73MEtYWRG23R+dwyBNRo1D0suqgPAJxdPrQGTk88tIrSiOtvoeZmp3RXv2BJsFDlNW
nNOgRUOEw5QVVd89wWLxGnkfxVptFle6E9rrX1th44DUtZ3TrKIbDO3u9l7/aoiMufUg5ZchMkLa
J3m3G3Rtw92YUj8abiMhC6V+bGbxJUOdvHOh4TbmaRkrh4b5c9Npf/x/l7Oaby8vazR0GXUgMkJE
9JmY1voZdcQAl9TdZS6RuvsZdUBDLKm7y6gjwfeTuit2v6TuirkK31Sg2oOkF9//am4bvfbdL62p
l1GiNbWgF1GA4B1nR4nDIadLC+FsZm++MfOKwigoQRQgiIgZJSXYqqCEpGm/ojDed79W7tz3tVbu
LHMdranNTQg1K6omcGEmlJ477bMJAZHtYFYNN+pwVukAjNybXJGpI3OWUdQdWvt43c/xaVXwFKIK
ejEN+F2IuuzriIZ+UBiXFY9oaGKb2O554tgXU0dgiVbPOTuaJlNHJsSZ5EIDtoCPk6VkorMajBSK
v3Ks7HJnncPuK1qC77sQ9X6OluBLtBC3r72SLmemOaU0PX8dYBTpZcGqrKTJCllxlyYrZMX91q7d
vsRcjJn2sMucI1kYbkIB8dMXqv4RPNswHOMD+rz8+ofg2e9fj01G7dzBeG2Dq1kkd4zCCEvMnib9
j9/xxvXNkIS10fkSX3LVz+9fxzklb7LOCJa1X+ME2ODNgusmpS3rjH5FxO8rEjqDOBatKU6xaHGb
deOUo1ECG2kPwy6+3wZIdiae5VnUbbCkZcuuk/uCNo/vdsj322BJy22OMuRcq2t9vQ0E2OiwJnuW
VLXU5vk4IleZ/DjgMVR5SwnDkTqkjLQMymAa/silfOHuxbVmzsIsWi6wKTcEctvswN2NAhfCb+vV
S+7djWK0+NejzO9RP+61FbsQOgG67/2zcBrDs75/lfc4CtQE1HSyd7Xfo05I8cA6o2Qm4O9RB4g5
vJ6J77G3nc+ooxB8vth7yTz0+4pgBxqm9vr2mevAI+svFpSaKvyMOuqyKt+TLfFsWfFLk9YU2iNI
PnMd7Vcb4dytJH6Za0/wsvaFLVZHr7Piiol66TFNf49Kh3nUiWuSTa1+VtwNDKZk5CcJZBl19FWC
iGjpecm7fiPLednRqkhKZFBixKcJ8P0cs6XDdENlWUbt6t66c0yDEPiMOtLAmJaZW2ieXvsrPVNY
QPnu5jpendnnjA+MXfEqX3dHIziQogRTkdheMnme+FLrUmO1ZLE7T7DxJfFdkuSJAsM6voEg79/I
ZJ452YpO7guUGCCYv2lnhxoIJUw4irqPbOQ4e2lhqm9kVQbIYAXXd1411J/wZKffaV+ZcAn7tTb1
jayRgP583Kj7vljjBZuoOnrlfS6muhVmniva88Usgyk2mbMjqcTIF9lYJO0bJDtkb/A37XgBKvFl
cCv1ywn9UUu0r6LqRy8t/XcH9Z1UTAuAsdtSXEedjRyhFfFbXp9l1PGGAvFc6XKuow4/nh0y4Lsy
pNmvbeOtQwYTa4MbtQfWrRkQTUs3ai8gZhY4s3T17pkFPoYhwYt9MQu8BLPdl7mOHhWfd49l1NF8
Eb433PThdn+8EzHvqdfsz/FUoLSe4Qp7qn5r0UjD0lN1971ZWEOEx6roxfJnGB2JQul+2nz3SCEZ
cOYy1xHKZ9ueEkdVp21F0kwoSXL3VljDd2m5rwy/FCzhz/F4OWD5TZljBnU7iFjSQpizS3rRqKrJ
cMbFvpqBJIYpuTBZQ55qJo5Y0RryNAtyLXMd5c/gwhjMehb7ssIafIMbdaB5hMYeORYM/4w60Dyg
XCZU3pC8auH3MK157P2Env7lkBZVndDTMSKVKnnCwu983PXS5Bg12Kaslqhurb1oBAjjqniV8Jp1
dKt+EHM1VhmMEtxNO3KyR6QEiL0onoCNSgmQmpQmbKsISWf45/e5SoBBC0OoSmkCjc5Eqjk9JQ6U
kcJqkejl/en9D1aLGCbWXZqUxJSyEjZZeGSBM6WsRr+vs2NEYbVIrlKSl8xknm5v+WLFwmLRB5/m
fh8tV7wT0VPSqxFfH9dW3lr2goBSCCmp0wbT0Fya/j6eGeUThlDb5NfBE3T38PfeUjj2xS7nROBz
o/IBdknTC+s6vk+bgWZdHnrIXvru5jiD4ZbC7kftIWDDXINYk1RlmJtt1T29jr7qhUWZaXqZc3wj
3IRaR/XfeOZ3g3MyjKGh+Ks2tvfFEpLvLYCN61arukOEsQTblyi1FcPcY9RNRh8nxCbTYJxNyh1g
l92cVW9PHCFgdmYgmqqU5I2Rm5h2/bjnBcdsjw59KnpZ/4Zc7ZXwfkJ0AKDXZpS2L7xBgtSMTT/u
eefgnNmflB+xLzYLTDlNLwv3QHHla1wp8ZtW+HNwt307/p+5HOV2ySK7n/baCB/2GXWA/q0ux+9R
h6GdoLIz7EY31+G+LICLy6jd0IaR0GEDNLfimWP8abe3zLXn38LlCLlZweIy6ovLEa0x8Tpqz2cg
llJow+Lzy6gje3hxTO70Wh2TcmOtJ9Q6DXlaUIINVyB4q/vGoxRxdTmulHhCrdNwYO4rsvCUqSTT
r7gb7bywPRnG07LiAZLIUNgwjKc7Jaw7ABzHpPfF7p5sWuz4/gBcZPZwoI2jzjHxWuOvh6f98eLY
XhVL+rmObzSXY6Yuz5HlqTOy9FRxTurMtWTRnzzHYW0XW5G8yjdOi3IPeY4sYoVh7+/jGbaFcmEn
qKT2ZdnDhMOtal9EXJqh914VJSwgmwkz4kbt76UwOIohQaoTejrMj7RJueOFloCeM9eszvHpNAAN
0BRVn7Aty0UlJfh6OUv2kvxwhep4sU/adocOJ4dY1y16SpyvvcS6fvo636UJO8x37GNkSS/2jq+t
hqbukDk54+nrLCgxxwu3zVDePqP2d29riwdllbua63GFZtqkye4ARDYRywade+f7As6ZpVhjuTsl
zH2x/nOKcwo4J0EtDL37QhNnDK8VzlZ2Fryc3fPEgehvWZRhSmlC3P+JS+QpcTiYvbDJ5mhS8/3C
UhpT3UcLS8YSU1ac8xSx4hINOdfECUHzRXlrGZaMhmSh7IlqdVkQJm73e3uwanVZuGpSmlSry8qW
knE/oQdLKVpKxp2qNVNbzblJ38MVonsco5e+RzTBsJRSylLX0slpEIgtSnrRyRnFYiH3EzKsfnaN
lBYfownwVXtPckVi9Zc0ptQwdRp/jSotmEqUSuI3N0VV666eISnkaVt3db5qS6uDubwDLlpK6rSJ
fwSfPW524dGkzrJ0k5cAh2PCp9UZLa1C7J5PqwZSp/jesPphmG92zuEKsaCf4AZy97SG4NBu/LVH
hWgNtdpGk7sfViQ9guSvRjun4Rz1CU02QYT4cqPeeugHJaXflNzPHLl2U/9rSeky6gDY/ZSULqOO
LF32PwwGkSZGLVm6n1FnKgQN7WlNnsRc7K+ZuwGzqlFgGsZn3VxHzizdvRQNUUJQgu5ez2H4b9zd
KmbWwqMYbl+nu2fNumLLckXLrO3JXKHP7uc+anH37ivyFWfGtFHiaCxnZXrWaOg+VzKAN7ZTdXMd
+Pqf/Nv7aRsaEW3j6ShxoBEtEaZ2ExFr/u39G9f82ztPJHbhrLnErk6bTuEM5XGr7vQqzHxkyqBb
cS8DZUkpqJiapFerLHTrxdPr6G+eWKg7LJrwe9ReRGElpZVNS+TuDRP/gVz9jNqLKFh4CkPC8rME
vVil/4ZcFSuySh9m9sYTB7IR+08/kKv3084xv+obcvXOXzCMWajbPa+e0SpmHDI5TnGOOYU5G4jw
/XY8yPlPN9Vlxd0VKvGVYo7+hM5cXjParVRfUIIlpYndGSUlmAzFyIQ/oX1FRr4647TqHK2xXKnW
+XdZcceL6gaAmsNUfM982jxCyUmuSHx9WMfTn9DuhjI7NpXHIb9TgiWl+K3XMGd2rAGgWl3DMtfu
YNIpbGVsvLo7THQKY7X2OvdvZEnpHH1GKQvNdWTHG69rj/7mkKtQtts3Hk5hYFfvmKLcF11HWAAj
qVsL+fZij+og76NFvqC3q9e1e0SOXdChcEuWK8KM6wavI+daY1pXewLcAJ0GMVEUTzBJC7beY6pe
b60Vi9Zixe53qlqxKG1VydHw9OiQ1yQtGCsWLdOKH++0d1G0+77WKNpVylmxKJSatzHPLuiR4MY1
S71tMLw5te3WHg4m3CqmCzU5ivGxXMaUMoeu4xwtbPL+ANjttHPicN+4PzFVQnqAXP60D/jWEAhI
Mr09cZT8sWVvDtbK7v6NlvpmITk319EMjs1Sk7WyEyuyDQKr/vWKBp07rc5omWtHNmLuzgxd26vm
YMJj3ThnL2KlgxnzyNLvsDZvJc4qrTSDzo3ZcB7FN3arrwtZcg78wVeGw+Bv7Vvz/TluN7+Z3z9z
98btKq5FmcuoI273KcpcRh2lm4u7N24XA+zO7o3FRKoY9YGoXUYdTiHrfbNV8n5GndE9GGilPPHE
cWPAyKD9rI/heF+RXSXZ7tZ944kzhG+McAH8vvYUxqVTilhxGISVlW4ucx3llgZh9cQv7ue4NEpb
5joQhCBIIO+j54kDG+jT1XuZa3f3WE+eidbr6HW0LWNcuGT/jSesbAclwGFBcaGlCqb+KJcrT1gS
YB/1D99YLRW1+W88AWMrETjqnOqELG7XsxUT3U/I4nZ8tpdcaLCyvY5Q5b6YKgjPpHku/Ib6w54x
fvcHrGyDCR2eOOdnX7txHAgqGWOu6m5b3K725Ol1OEyRcH5w3IuSX+ailVj97k88H5iX2FXxK/7L
PooQ27H1omhvHcLh+U7PX0eJJLkwGP75/XY8eD6QE13unmmHsMe3W3uUSLLoF+ck77bh+ZTyOCb3
FYnnE5vhwCxz7S4aJBNME6t9uXM0VOeLGG/bOe70gmQKobc01WlbciJ80U2S7+7Lg9QzuqSqJSfW
8SS2X6n64PkEa6d2pyoUFRHqZ4qKv+h8xRg2rXDi+RBVKsY2lfyi80WMtyn5y8oJ4a1GTQn26yYo
lht14vnAwWy5eun7NW7HzCT9jSPhDtEjl/uCTgvvctW7zGFEDmZ23m7a7uTQzoFPWJxkOqBgI7vG
g4xD0b7Szumx+Tt01L4k6wc/otRp5lbN8mQnXGlv3U0KhNxQp20RORy31laGwVPqHG7UkcJIpEQr
51pHHUmA7FsycUKO9keaJh+sQYfh6HWkaTLWZn1Q5e5pwaQZorRqV0Scu5xYEXHutF8Rce46rUHD
ZJCrRj2qGly3tvhaZr+x90PnlQtZd/Srt9TdqiUU7K/eUmJFQkFA+AbJX60Rdr3k7DjnwOAhyCsF
ueRC63j97i1155xG3MKcasmSqsMAibvf/eGsTgMkNtwcQYlpgMRzSo+iEwqCrcukxdfNgoFPO79Q
9Qd9sccXAv7I3WNs8vsRru7eZ5TC4FnmOtpn8o0zGtMsc+1RtAWpR+yL7h7ss+FWPGJaVprYreJj
mevosd1fNVdrZvkZ9bUjCWxomuPiG2HGwWuvfGlf9rW7VVaLFlrxu/9ai/bAO4l9MTG0MuHDzXWk
fDIlLw6KG7EvCt78ZKuL0x6WbGcvocuoo8f2B4NHjcI5wkpoVVHCwGdhKXR3QmdiKJPtRh2OXkfJ
dwo0odsYcsVELsRNlLeDgLExDTPj7ifEvth0oafj6APrhiBjsCVCVbxqHUlGiFnyxFpltsx1VJkR
CSrH6W/Ht77YI4/iaX9g8EA15jKzp9eeBkzXEdZxi0oC/Opb4jn6jAFa35Jcpjptcx0TnNqk6EXX
cWD7m/w6nEIaVWzEpSixQsHeOcc6krAhSZajiMFjLVwUr7LXCD4p+Lt9uo7D0q+65GiLtb27T9xP
yJzCWIuXAGcyJ83xZq72/RwNvjX2HvUJQebgojV/jseKjLWVYDHmu1YogfyVem1qRYvIjdK9/Drc
vQAurM06Pd3lKuN20GkjBHWOFrcDtZLUQ6xYw2EPr61O15GtXp8miGLFYsCZ1gTxLnNKZd91mF6a
XrUxgdzaxt7vEDFmwrsJ4l3DQNCzcqe0rLiw9MYyBmvreZdf8CKgOwgRLndvSDTRTHtx2uBCyLiU
pAQok91zij1h3ldkXZshQ3g58T3ls3oZfUS+WABDKGt5a9f2mXdLwUBe2a4nyBWZ8mn9WeU3Grrh
NECEO1XfiaGhSpvpnRgat5t2wLc+iaFB6kdG9+A4Jq+Hzr4lOKE3htH9tFn9Nt8YRvf7aNG92kqb
cvf23N6tvvouMS1uhwljVd/4JIaGtsn7ozHmYM++2aR9b3Vt7AkvdRrd0DaLRQrFvpgR1ZpVKN+t
ocaMKDC0t5mONM13R5LkTnt/pGmN2QmzFmk9WjNLK9Z2+9rjnH1Ab8fuddrxjUQkfIrWl0H7awK9
0F5203cnPTM+iafxjfQ/yPj8dhY/8wnveBtLxucy6mgP8sn4FKNMcmXD4BQrJlZ8F8sBXEYdnSUr
G3rW6nZ/eFWFtdzgZrfi2R4EPAOXo7sVD98LOo9XrHhKHO1ByFmj/+EbCTydpsWgxYqwxiGbDapf
UMJk0pyeXmegkO2no8Wgl7mOAr/GJ5Xov/EIfNFDGyS+G3VAd1EmwSssakVrDzKfvl/LXIcfR0jp
aGUOd3olg5SGJeT3dYQA4ce18tyW+1z048A43a145Kuy41LDpXPfeKKFMFm9zhjlvogDAsG0zbUH
Qxtb2WRrSCJGmXyb9hh354lE+faGaRInRCzVwUIaeUKzMCekh6RWzGzDa+alor1hqdbah9/XnpEX
jQt3qh6YImxvXkP2XLiHJhPEc6z7ae+eUGZ7c2KPuFH7voi4CpO8Fz0XA4XTMGvE7lm6Vx/MB7H7
asWo3cvovag4V2rZZBmMn1E/xTnM7Zuo+plygfR9fpX3rAq2LYY+YMXRZ9TXtsXMjKvrqBNkirWQ
zaBJlrn25z9CUT0PnL/HfAWiavhgt6uzAfLykPgZtSM5MrvEwP3cqF0dMLukdevms+z9UFMDYmQU
Mz4/cx0PiY3AnpXR2WWuQ2l8mhYLyrNbQRmGmC8ovzQtFvSa4WWemeOIsx0xWLl3S3G+02ttWnzf
l8F0449nUadtteN8qE6KEmvTYrF7KA1Qw+Cwj339EYg4sT9BHbW5NTb43vz3/fpQWCxbqezkJunL
mC/8X82PVDJwfWMoknIwTwhk0v2+jifFQROseO44ds9Wj2m27az2nIJQCajVm+OOM8m/sATGAHCX
UUdNN+u5qrUIFKOypUQbxNKdEkzMB62fh8crP+an/efzCPCZa3/qhCyo7ypfsWJjUnGYWdKeyfTg
2uBl9Qk2RTDdpwmtWNEQIlpJQ8kCZmpUWkRFnWOJkY5o9xx9ZlfgzrGWqX3hVdyaf/jX+Ne//++/
pb/+7T/+cP+w6RdIGmb6fv/+4V8DZwq/Z7pqvfdM2fPDtw5OadQy3V3ce5IRjDrX/gS//m6Zwv5P
BbZZyf8ZmfL918dpsvtdevBFxTnBMQ9QOV6LH0+Znc1Jy/Ty6YSlhjQmupCXT0dltxXoPI+B1/vG
B7yEH+epZF0lQOKEcK3qJlniPeEkotoXn+YM/6mr+1YzOwXB8fa7Px7dosXm21TyqVoxWSy5yn3R
viAGqd/9/mTY6PJgTUl7SKYXcTzyN875u24lKAUTGBp//v+9le+Z8nYXdooy+GDdF5T2IHQVDNKS
uuItQlfV1Opmk3pA/3tKd1RmxPXSmhgfVzPMkPlrHNGNOip4H1wxE/bjdllpcmci+GY3ajeBMyGP
Qjeje9wYJmayaDUs1mVfX9q9dvbP6G6uL+1ea2tWrbmMOt5g+M4Zix3OZ9QBeU6maQYZsuzriKXn
lxHV0et4/zIQiTZN7Y3bZaUJDMaKXdIL5oZBi1dHr8NgivNF2Orc5VypW7Wmva7snPN3XVa+rRAJ
MDia/mcu6/eZjmpUIu5NeCiOCudbDptZticf4veo3Rllx5uOJXJR/MBeNpgo1S5XZOobH9I83fcX
H8Kd9/LEx+78QCcMNm1w/HBkJzBPow4DH7/faxrQI+CeZbV7Qs2PEXvMimtoZv/qm3C/sdkQ99iA
QEmlzIpuWqB+1PFKQ9Ca+Djm12/kK435G0HJiJzZ+i9blf8y15f3lzZhjshblhmZSDn0qDgns1cS
W2gXSXv2Siot1qI4Bw4cvrEbzJeYqw+r8c36hPi+l0JuevdEA4YJMdy+DiAj1lfX2rvkL8bRoTm7
v2lH9Bg8URnAlHeIcXQWC4ygOIdx9MZntCbnyjSAouXWLXPtdbmVWI3BSpTu9CqVWI3RYP7vfE9M
1zjBP0nORaCsUgyaUXyj1USzMkfSfoSXdUL3K+5ZE6ycBud4/X/GvlkTHfLQ+7Ka6Biy3Bcj5L9w
a+9zsaVqrrltmv1I1C4vQ0XzPLGbcMQMthx/JQHY8ADGS/B2ybFipsMH9e816JGCTYevJX+3j0g0
K6freGJpV+lb2YwXFn2f6m4zUbvT/vSnvecdMHkf5pC30E7kV1a2jjqkfYkb+wqNuLuKcyqb8cbY
mr9DexydvYAg5qbUyM0wg8P0uvY0xVm+k6yn2v2EcPmJgh2btCeID5ssgcSN2kO+qf2u3r3LnMYi
xXf1rtiX5aOm4G3Vs/61Ggp2lLZ9Yz6qdUJW0rcxHxWOpZe+xyhCkGL7Q1odjKOz7WrI8huHNdpu
Sd7txgcmKBhvy+3avRNtJgzDMrnTq9OpH2FkeR/hbrz4ijDrl2/8WaL2sYUfxU3gf12YZg3Kf0Yd
kYAlKL+MOhK1iSAHsyS6FQ88XSLIVavKW+ba3qqiIcjlwkrNz6hvzVLB79nPdUQolmapy4pH5CQS
cMNaGSxzHQ7hJIB/p6G9jDoiJ0wUataEbVnxiJywt02x9mrLN+7uLIPy8Bujm2t/2zO3kX2xv9Hr
j297FtLnI7D7qp++7X3/9Rm1obtT7LrdT4HtQ1qZczuFHawIOykFbFvUKTDUD7cuTc+1u+OXE06h
GvLpMte+L7iHTL2vXXEaoZYg6Kyi5n4D6B4WPvIHdTMZnk8Rx+73dYTn28sKYZMcBSNsYPOehw56
TdZZxjaKohcD73k2A0dZ5tqjCqxJmcnqp+4rEg0XXBtHUrRnanQfT233sq89qsAoKqW55Am6YSx6
GJJXGeDGHR6lqXMkNu1sDybznaMzE+Fh0PXxRa78XU8ibNIBY81SBr/d0p8/ibxnqtXt6YBZGpZD
ZtXMdxmcDdqt1zAVN2eDdhubdD07rdXfMF53GcyK2l8wXvd9saL2F4zXfV+sqP0F4yXmYvMg+GHJ
7/4YxUja06Hrzg9Ewu1lWNrNXTcQzii8q9vEqBZ/N51ZvnGPXrArPAzp4eY6IyHEkojWh/4uSega
BtyMHtUto9OX4phftdEyiogAwQCnlm/cHchpAINW3XY/R9bd9h4s9n7fPaGRQmq5SWunWmvlXqbU
8Yy9QDK1mNU3sjq3UMBkxROEM6o1ts1W22GWMrVL3nTQT3U8k6rbZLzlP6Pj378uU1qAtbKUCpa3
1PFW8wvvL3ld+qXmN4wwp+RaOomjt1inugFMo2796bp4lz6V2BOtlc1+3VN5A9Fb424J7I5KJABa
s0fB+75YzctCneFt4U2zEdiolR69VDwcKDagKnwpVjeAjT8I3zy63BcslPAGu7pbO40P2MSVkbQn
2i2zlsY3zvm79F+zptYjegvyP6P/3jNlz81nOvYgN1tg5H4rmzW7Zh6l4vke2CgtF6+N3o9SP8jH
buLKa9cvXQ3ywKa/cTI69Bl1uGuBajQHUx6fUUcl7+L63Vdk1jYRUt2+zvQ7OIg4Zr5kLnMdrl/C
N8P5C3JfNNsTjnC4uY7UOgPWsXxZMRdfO+rTP2yZawdbsoYrYQy3+2/tjzHTnEHSi68d4FJPrzO1
jm1zodqy/EbCHsRqkbnPqJ/mbFqjs+PIfvCzKX+WsCf75wvf9l+/OloAxcDXaWva8Rl1xFHBa2O8
TcmuuIgug5m4/SY0maBZxrT33WXU7qgTUAXHZQq234QmKwRYq9ennKtaFY7lBy+7PyoEWNHTSnUr
npXe0yqgQnRU3fljWJWXvZCKfVEklmZNKJZ97S41JAuxbJI7oRPYK71o8sSmVmRD7gk7wO75fUW6
iPBCit/9l6RKKNNHCF/plWCgV1gf/rT3xupMbJzEcfMrHimLfCGN1n592f3RtpvV2Wn6FU9orM5O
e5Zoe18xMyIWmvVyXeba44ysSYankoviL2IJz9nCzF/m+uMtthzkg8w/UVoVi/xi0+O98nf/r2XU
kdwR4ZmziVNaRx0Xg9ngkwBO66izMTERAicfbdcVd3HzaTm8jvoGBvG0HF5X3MXNp0vYOuoQNwP7
iuypvo46xE1l4LbUKOdiwgJEanCjTnEDYQmJ2puk6idrfF1xFzeGSRjYplrty577rQeCOm3LGu8M
26xzHe+PMCs6aF/litN6PbHMUKxoTY5HI/zsOtcubqzJcc8zKHo9TY4n6/nWFQ8I+vwi6mKMilcT
IVBLJF7MOtdRtkQI1MQGreuofS4WJBGEp8gVCSwxCxwPN9f+Lkpw08SHUcVffPEMYNWSJb0MApUY
qHL3BoHKdEa5LyYsQH1WTVUmLMxGMGsxF99Fo2euMxvGUEumZ/ozgwX2TRubKDkeHwlIaNmmauuZ
reU7w6Nf9vXHJwOrUio5ekb56ZPB91+fSPRM6h986Fppsj+iFib151KnuuJEjw8WFpc0aUzqhwHm
D/14tmVS/5hV796atFjLJ3VWcBGJ0Tj87g8sdyb1EyhEKQdmvHQo5RTlqMinyNK1aoPQZMO9WbMS
dkwuJwKQFyq7sGOC9xyBTSvVipXPdHVXR18SvGGANS/Qj+wZ5rK02oe8AcxSiTBhylR3jk+RfBuL
VZ0j808gK9KIileZWVJLK0WqIz4yZtahut2nPXWbfcwzTD65eyZ4zwwFV+W+YHywm8umQvZnNxaQ
UTf43R89hU28lk367M9uDSYK7Cetvpng/W6cqOg16KMnpvMLzgHPE8uJ4WzBE0RCgMBhOr8w6Rr8
E/jx9BaESdfMz8xM5xf3sbHoC7exSzOs5cHMJabzC5nToJhTY9NNORc7gbfCYqmTc37Uu/euMLTt
nq7W7yfXYBl1PiX9zjVY59rtR6bXDD6/y7lYowkN06aba3+yYeSwMHXGzXUAANDSyaO43Z9Abr9b
Pqm5KrumNhbaq29c7e3fo/bEZWdvp+3EFks6sOy9mufxe9RRRTuYmlkeX+ez+wPdOzHrYgb5jUv9
5fqNhyX9u/5S7H6pvxT8tdRfCqpamyZYT8WtePbuLXw0mdVz4Q5MRmxMMPQIjhL7E0YheFFP2Y86
cLuz4cvmIefCtS4GLympyogfhka/4u6fMDLdWSwsac82TQUclhXfP22aQqtFcQ5Ty0OHY9vlN4K/
IJwfUf9Z8ajgNAit0JrafWZckJlzXXGOAbmxp01Q0sQeTSCaelb8laGyIZxnnHKuTwMmIZmI7s0m
FCOpm5bBOdYBpKoTonFcIL9ylXNZ0yQ205bf2GkkvF9hPrTf8wdgQldW4lR5QvDxG+WX3v1gwQu0
R1P8BVebj6tNS/IMzgns3iclpnXlhaBOnvZ7BJ4Y4GXXCqc5zsdVQ7UXfF/41GkFcWr3TFOHCmX+
nJAAcNxZw1387s82TYTQCnlICVAKswys2m3VHUcyO9OII3Oy1lFHV16iBdTs71DeqcoE4R6mlxP5
MNqph3L9w+7h48PFqaWo+8gsg1hg0OhznKwDTSMnJZlY4dlzeFzHq4ap4Al2kPe642zABEuhllDc
qKN2k2+U4IEmJRMT0Ilz6m/HmYvAQq82/e3YNR8T0EtjEo7iaFaL9gQrzPP9kTXQX4Q56lIyVQbW
wIRTWgqWNQCCefl1ZIvwXZEdvr5JgD9nUrCMCh5x8b/+aSbF8+syopIrRCmPOIaieQiSjMnJMSv6
tsByNGa/K/oyYb3MGYs/hT2vAZwGJyxHuXt28Q0GN6+kNZsswb9qXq6cTZYSoZGfN+DrzWSSOXvU
bjy0j+pscBWityy+tU+CJZODtLGIwzagAb0kO3DRZ2NpyHeN9IO4/zfV+TM3rPzIDSs3sjs3rNxE
inPD7nOtbthnLuWGldvhODfsM5dyw+5zrW7Y/RtXN+z3qN3YcW5YuYkn54Z9VjzcMLaHqCO4uc5Y
bLFmIDVKSozBRPqZ/GkfLl0noEjIVe3euXTXFRkciQyXN7Wic+muJ+Rcuvu+kqEiM8V23dfurGVL
tsohK15NBq2C/w1u1J5Q/YHIWVc8giMJ5sJ8jIr7NzZCNoXnPfr+jXTp4BVtp727rZ/Ou+uKOyU+
nXfVip/Ou+q0P5131Wl/Ou8K2rNaOLNtmOSvpfOu2L3FwZ+UXSELWS38TtlV+2Jl6JOyK+SExTvS
GLHIuVgZ2uf00vdw/FgZOkbrknMyK0Oh13uQ9Gp8WGDvcDmXvaYTREZ+IytDC4ywKWkPzsmxlulX
3OdiLgl0V5QyOlOBxk6wLyEL6dKxScnGOUd6+bAmJcmf0B7JgBsGHyx6DXP2wYUpUcamRQ8HKxW2
5wqec464QmZn5xi9BDhRt8lfKUd5axmHIZruJgH2FZmFVFgRqXi1NLbdgQHm+etIQh/sOd+KlACG
uk0lKjmH0ZoKszF5S2GPD4FzGgtIvX48Esf5vBVGlHKisCzJSsjVOdYQ2HP+eSq7fmMNZjhCLahz
pEuXYHV0SYnKytABG9rfod1NIMItc/Y97fe092wtfJKn6uGswWiPENRaIxs298DV6uqmWfOnHFuR
konY3NVAw9dR/7R/I5NTKjvYKy409xD6xcucb+5hrHNsWvQYBY6OYfo7dJQJMO2kpbDdod3pnowj
g/bSniAI0DCzVp0Q65PjU5AjeILuHq5261JOMLrFJzxvA+zRQOvPW+GZS5u8ES0Xfzq8rj2iW+YF
hCDlKvvzsu+5l5hHRTTtL9yzIu2cZr1R+vNMeZUmjJTRNElSu9PBzMMwiIXeZrspsFcs0gZosO/h
q6YmdQermJk7uO3rGDXZgwRmvjyhOV4GhO01zA+jgUw/P4/sZ25ouzqFqxvabtd6aRG1jDoz+X63
iFIrWiMDy9RXc6XOGFgyZfx71P72GA1UqE0zXtqNtSyTr8OPc3Md4FcEDQ+NvQzXUUdNsaH3JTPQ
Pise0cBBZs4tym+EmwD3MmdH+zMlOBGC5YnDtJtQikxeBek9vU44cNC+WdOgda7DdYxUszk0taI5
mLTZq1rRHMwUa3MndMKBk7+YKqroZQ5mKc9r3IdeB/gVsQRbS45X0/6Nn7ZO64rfYoYjPm+M930V
OADQ21HyfaodblV5cuGuN805mPcVG98SaazKc1wdzCtHM+0ZpvETa/qMOpo/MWY45vaN32KGmZyv
eALKhx1bU5A3LQf2YoW9NNU3QozA1YYRLU+IMUO+Esakds+YYWRJWZe7JzYsXMIQ5IqZ8e35ZNZ+
5tp3z2oxLLlJpj2eBgVaW+pFnqP1DY55tP5lX39OMmQ/4acacP3179d09oLiPx1W4jvPnJEoItvy
H1zc//6vf/150H/8+59hybmP3hxv5C/V3JB4w5/6nqXO+upJQEB/4w7XNjA9qpYhTwoGZASbhalO
6t2xuGk9WUL71ShmGRX3SuCnY3GPVc71dCxu3dPrcIA7NE3Onv8Phy4zYmaYzUJP4u8ZM69et50p
hnCcoJ6H1JME1cpst/CNZxfXNsONab1JPfluO5W71JPvtlM1SK3FymkY3S1JPfl2bTdZfaw4GTGD
jdLUipV2GGyU7PnrH392e63RFGyllr7fXn+rmqGsvLPKcSf/x9/+59+CTYU7/PzHH+/prxWD1FM1
NoMK8/s6nEZahJhreLm7z0X3GQSKQfGd9U5mcZG3N771Tq6zep330zK8+lU542f/19/+Pxq53ztl
bmRzdHJlYW0KZW5kb2JqCjE1IDAgb2JqCjw8IC9Db250ZW50cyAxNiAwIFIgL01lZGlhQm94IFsg
MCAwIDYxMiA3OTIgXSAvUGFyZW50IDYxIDAgUiAvUmVzb3VyY2VzIDw8IC9FeHRHU3RhdGUgPDwg
L0cwIDYyIDAgUiAvRzEgNzUgMCBSID4+IC9Gb250IDw8IC9GMCA2MyAwIFIgL0YxIDcyIDAgUiAv
RjIgNzYgMCBSIC9GMyA2OSAwIFIgL0Y0IDc5IDAgUiA+PiAvUHJvY1NldHMgWyAvUERGIC9UZXh0
IC9JbWFnZUIgL0ltYWdlQyAvSW1hZ2VJIF0gPj4gL1R5cGUgL1BhZ2UgPj4KZW5kb2JqCjE2IDAg
b2JqCjw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMTEyODYgPj4Kc3RyZWFtCnictX1b
i245juX7+RXx3FC7fb/AMDB1fa4hoX/A0F3NUNXQOf8fZi1/X8SW5G2dyGYmCypPxlHY3rKkpYst
x4+A//0u4v/6TB//6x8//vPH1ev66evfv8uzBf5F/OD//udfPl5/+PVvP/75L+Hjb//nR/ioaYSP
EdtHDLV9/PqvP/7tBwdYP8k9jc8fPdLV3Nv6IedZP7tSS73UGNPH8x+xiJ/SYH2//+XHP/85fMRx
tfVP+Pjl337Ezy+e7aOWkD5++ceP/xZCGv/945f/ff9tDOMqJdeeJFX9vaGK/eo9ttklVSmGKo0r
ll5iVWMFQ1Xy1cZIUY1Vs6Gq5Qotz1zUjH+2VONKYfSqZiz2G9u46ihFf2OwM/Z89dZ7V/zKdqzR
r1RCT5pfzVDNdlV8ZOneulJo1yyltvIw1p9++cm+ptgePge/dpWw/sn14/mPFKuf0Qixars4lfLJ
nmrFqV+1lja6pNo2JLar1BxTlVR1E6d65RprS4rKjpXLpcfZZoPAxTJKVmvatqzGJ6puqepVZ+56
wj9Yovk0VNylMpBTeqz/YaWSMkJeSapNdke88gzNMMIydIYrDZK565pYvVmVnS8F6HBOQ68qmflS
LFcOVhjsBqaUocObMHRL1a+28bQYO5Uy9G7jaU2GqlTYPMvTakQ51QCbl+2Mf7BU+EYyQs/4R0PV
0gOV3Z/U45VSswJvOdHr1brdoW1dfT6NZTkxYLHN0o04pNmvkCwbrEDkEK+N78moWI75YSi7ppzi
NdP2fYYLOYdrLLHxVD/neW2s2tZeyhVbMWpRpqWCGQ5W9bfFV9i/0IcvWhniMDLtiLuuBqixMmN1
LPd+zd2U2qFGu8ZuSi3VrFd3ZwOTrrLtjdVoOACQdrs3Vo5LxN5QQOuDRgv00/BT0nzgGcjDogC0
vf4g8Ku84XPuONbjJ45Zsxsmdiin1iWVNTd0iyZtUlVUFn9Su2KuZSRJtZld4thodQZJtRn6PICJ
oza1+s3QF5jBMFsv7oyVnKGwujPCxeoZRqe7MzYI2ICYKU5sTh1MV8hl9uxSDeD1aGH4nKAjVgcd
bDmW9UdmAu9HD8nboRQWMI6oZrT+SFqucphRcWKDM/g2daaQXJlIqVy9wCBqThiDmXK6QoduD0Vl
AQGgBx8n5eKOBS8Ifwur43E1FdivkrMeawMqeEENnmtxJTq1fI1Sa3X3ESp2gaW1RHdGuEGhjdaK
y/sBHYqzj+7yC6CXMGUZnm4nuPD4wNHVuiywZzhCvYeprcmOjh2cSFPLatngsV6xIyDTM27wmGFc
Uwp6hzZ4BB53GLDuSSHhsSW4Qu4OZQZss5Wod+gPlgqOak1V20IrExmSE0Nuc7gz0oHutWlZtfuY
IV+Q1xant4+50zUevbgWIMNdqmUa+7WtC5apAf6S2scNkid2aEK7tTUxYxV4TMCEmpJPhR2CdJXq
zUgoLR3MD552FLrQUEqjtRaWITnYHgi2x9UCyRllluTKfYHkwJUDLLjfWGnlsPjpWYDSYKNh6rK/
+gYLMCtcK58KKNp6rdmTCYjWVQFE3UWYskKvmZNrC8uAfNXwSo3c/DLpjDIpX8n4ExtX4ZHD+uZc
PX2swLRZA/7lcQIEcMkTmOvNiK25Aux90pbJ+EwVUthgezWKbutK6Zpwpo3P9GdLBUybMZTgU0Hu
Sze2cFt9ztjHGX3fBACE1QeAg2d9YSMQdsSf2EIIFiS6/8QW1sZwbxhbuO1QgzMdQvNxu7Z55Z6M
LdzG6vABYO61Z2V1u0Ki66w9uNpRIdEdiuRbACjiNeCqGQtgkK8F5l7a1Fytf7BUg1YO6OGOBRQd
iD1a9DgBRl0QwZhcVGhpQDuAkHofTUIToeMF52sOV2tbYTIEeqvl3liTBlvI/WnDszkNUWaGV2vW
ZWS1QXJgd4YZy2hto2fFnG13uQrkKzAUw+fXhOTUXEJ1V0/PCkR6LMuvDvtVQws+WvVQrtpH0P79
mxMiiHyOAeEOPyzhp7+2nL15WlLEwuG0z6X886RkzLvD0oeRFdVDojRjc2aUVFsolALUusWm1mWd
hJgJoLF3NVa2aVAA+0SApldvgSoWZudnrv66CusBMSfNry3AbIBshCdFUdlADsYy9vwKCudJ5CPN
YCpxGfGbyqRymFOFouWoeW+zuHAJZxhl5UxuKrvbCCbCspbuWFAMuPd9med7XQ+Z19JgUrsayyhs
QjDRsLhcPd6nCDgbc0Z3XczQToB/C55EI6S6QhxBz7gFmIDsTCkM7roghdifmJu3jymPC5CG0ERR
WU4AjGOFEA6Pq4nGEsGWlsI9DMUO9VaHK6sJ8lUTAz5FZcPQ3ukIjazly+aXB4AqzVdQeFP92VKB
96NBxd19nAm8h3nWNsfu0KSDBifU3aEV0hY4oXrGP9lgNcLKhTKrZ79yZBYauqt3yIaOiVl7Rkzu
uiA5CL56UDJhwwTAIgLyZHTIyiqDVdhpxKvujDXA5qQZkztjHbQ5wddHpnzzrFNjx5YCgHx12K8U
Pe1gzhfOi9GOLQUwGp2X3Lq7Q7PgG3uZvkxMoBXCvRq81QP3AcZvt/eIfAAEfOPb7T1yFbEGvnEO
zQmrHSVVplbncHWowI3LiEPN6m24t2pHOfXsWRO4zyv4MvtoLBNDWqa+kj8jQloIRNNyH+2McOOY
+gqudsB7BtZC0BWVrfaXPi4EQrFpfbQ7BMmBcKWZ3R2C5ECis7Y51jmGC3c1xr2uXa3AIYTjEDFv
H2HogUP0KDyurtCxpZpde1/zctrL1NpRLRUkZ9Tm72Nluh16pvdxWz3Qqs80Q/d0uwKtEGmHrBHZ
hto80ZBG1uuKf/ye/1r7kyjh1+IH5p4hTqDEB6Ko9U9/H4Z5/qtf//Yj0g5Vgkpv8E7m63ALfgGx
R4DeDfyxvX4h5fdYj3+lx+o8fLNG4s+W62R+Rjp6J+/jNJ3cMD/764///FFLWIc7Uv34xw/63bBP
7//+++d/5zRf/01i9R9flP/+41/+6eM/zueG/l+d5nmfNvK3MBK5KhyMZz2ntwxD3IiVN9V2qoc2
I+TOktpNtZV2OgstZbBYKcayp3oGfdfcgqayvj5TVxERV1UzWp8HEdTo8HrU6t9a918o9VEmxUDf
DfNePK6HX4v+r/WvZW9Mh+MUYlkf90W1BZEdQWSAWzd9KjiHAWCkx9oqZTCbcFKrHms7stRB1eHJ
SKpoDzLAnIcw+lBjReu+R0BWDIn5VYcqFZrzTudQ8MtWfnIGVY5DjbW5tiVdi6nDpargPTYgqrG2
4AOwHCLcGDXW5uQ3BkVz5ScElQ0+OjNI0Jbu7WMaPGOBHUjeDrEi9Xl8QnDVVlhWRhemWkuhAZAM
4f10Ds+cYK0p4BNycqlYpaSoNnfGAt7n0FtUVEb16XIHlrf0WNZpreB9hrMcXU7wgNU6QObJBJ3p
kFtL0f1GOtN5BDo7gsoYQR6gAKytiudZ7ksA7xGExerNSDcZwlWGP1YC72kA/LEyeF/qCvzOmgav
4+tA2lnu4TKBCrGta5lK5eE2gLyyJlso0MD7GqFK6htthYUZSkTdubicQDgd8IlTr8ukfui0hlqb
tr52xooQGJ8U0/BmxMKvZVazx9WKQCY08tHjKt3R0AAd2eNqzeB9S3MMj6vAalDxgJukSjoneoSv
WpVJ+G2oN82vPaPePOmiQr15shEK9W4qm3KTqDdPlkSh3hfVZsUl6s3T7ijUu2f0UO+4eoV6N5Wd
UaLeF1UyVkmh3hdVtGNJ1JsnzVCodx5Lot5NZb9Rot5NZfFfot6RSqHeTbWdsBCod1PZk34S9W6q
7eyEQL2bajs7IVDvTCVR7/yNEvVuKg/15skqKdS7Jfrh2OAX6p2pJOrdVFtySKDecfUK9e7V2/SK
RL17Rg/1zlQS9c4zStQ7WiaFekebo1DvXtfD6YMv1DtzVaLeeUaJevdYHuodbbRCvSNXFeod7apC
vaNdVah3/EaFeucZK3jf6jrD58zYeNqs55E8Wa19JebWJQ+HX6MwUb4Owzr8mjwxgFBbr8tWmgNP
ygCsNNbO70F0i0rZfxOyt/gdZL+ptvKdQPabakNjgexiLOslCGQXVA+phk9kF1QWjQWyCyqL/wLZ
z+uSyH7+Ronsgmq7onAju5jR4qxAdkFlcVYg+5lfEtmd1Qtkv6k2j0MguxjLiWfPOySRXYxlix0C
2c+rl8guJPqb+pPzkyJ8U39s9ulZf/JR5qX+5BNHlf7kE0eV/ripui/9sUm4Z/3JR3mQ+nNcl9Kf
47qU/pzXJfUnH/Va6s89lqc/+SSBSn/u3fb054tq87Kl/txUlhNSf46cUPpzTN8q/TmmgpX+HPkl
PeN2TPJKz1jw67u6SGdzU6rPX0u+LtqUrtDFcPVZ44iSatMyHgKY8J7VWJuW9VU6qiwKibG24yP9
ioOnXxXVFqXWa3bM2RTVhmWFl3QDT7+fV5/gYcO/SSwBCip7+h0edm5xFXwF1ZabjRcCjZY1v2w6
n0eKyNTkUsF/66XNZbuOnOBhjlpS7Ipf+82DduUM11mvyx4f6Swep5cunmccPMPcW88u72e6egLt
VOuyWsYz39ju4O52juHKsHBdrX47/R5ZvEFE0r19zKlfENUasierCCp55pva4shq5rXJmUdWq7e2
PteyLpkGf/UNlmSU2Lq7rr4OAeSseW+PooxwtY4ITa/e3rlbBarZmua9tV086ADU0BK9HQIIjODm
nN3jF6/BwQDE5koOgt2rYX/S9GSiZJ7creu4jViXzacC9VIJrenVb+ftaXnrOiJz1sdSeQMuzJk9
fvEkPWxJrNOzOaV3XhvMyeX9OnYQGwvTjuQUZhtibFWt3uDGEQBqUOblt+GGTYo+48ax0qBw45ir
V7jRT7KlcONYJ1G40Y+2S+LGuXYmceOYe1a44dT0BG4ca0EKN85UEjeOnFC4ca7WSdw4VrIUbpxn
lLhxZ+HDp8D9818iy/zp45dfX8KXj+VriS23DMZ7pHd7ks+Ryk9GmiF4HP1EqaakZstGvlAqZbU7
2eLPG6Wmkpot//lGqVY8qXmjVM9q9Xm7p/1Cqdncb3yjlNHF7dDeQqmUtMxbzHijlJHAZ5SqTa/e
Zm9fKNWTWr29ifqJUlOtPllLSZR65+DOGvtGqZRc3n+i1FSrT9utsIVStWrJsXb+hVKrhYqgslW/
N0qN4e32C6UiOKT4ZbO3L5RKSa/eUr1RajRP+98oVTUibLfCXij1imXvGc3qmXEdK4Xo2XpmXNsK
GtVYD3XGDMGJavXZ3kzK4YozrczmWR957A2KVota/ZYlLf3q8CKiWr29UABh4KHQMVxEWLecOo9p
exhUOzs1jGQQwWgaPJtrIjbsw+XEjFevo5bi6XbjLZSa1502wYnt/tK8chmjuxazRV6HKK8MwVFy
IKcXbEkKWmvt3Z5cr9WbROFZ3G4mlaumWQ2eGSmEO8QDzF3jWbb3l1q6YqT5ffBevotnPEnHsXq4
ZqQ5+SaiHR2z90hVW4nveoNNC+Vvy+h9q9bdjtUWldE716dlRu9YB1YZvXNFXGb0jutSGb3julRG
71j7UBm9c91cZvTOdXOZ0TtWzVRG7/yNMqN3rsHLjN65ui4zesd6q8ronfklM3rHKpDK6B13SGX0
5slCqIzeuVosM3rnOrDM6J2pRK1brMv2VRC17jO/ZK27HWtrstZ91iFZ6964+vN85KwPJgG/9td1
BPlwZPhbR33J9J7rs43yf4s/exnz7Y5iYbOGxZKbam9vk7/OBwuqrb1N/DoffFPtdxTZE6itYO6m
2u8osj1EKlGv3gbSgDUYqKBX/3T7cJY5NSesa8hebTWX1DUnrOkE+HVagqCo7MEklo1Lq236VHAW
oHNxuqvvmTc/Gw2/WP12ALjz5ifP5Hv7ONi0rneaO2cfJ+99wd/W/NqOQiHYAVOZFjqvHvbwmvhC
wwlrYANvh40Y1bq2siob6tSWSnapYMjgR+emx9qKr4kGo/TmcQLBCRsQ1VHcbyxsPDhWQCfG2lrl
pKuE2Vp3uQpAwkB9uhKNkI9d93qN7owdsjp4O9zlBMLRmctKYZ7li3cUQ2izDk++EiQn1rEa14ix
tlY54ULwlELzvjHzQncd6y6zmHE7yAUpxFiaX/vxZUJNL1FxYjP87Fo6RtX2a2+Vw9TQbHq391Y5
vN0ajV3dkt+QHNjLOlzrmyE5LZd13/G825mpx/FK5jozQnLGisLc1QNOAfKrMdJZa4EH4BfCJ1cf
V0OdWICo7owjX3Rb53D3kaEaYjDD1e0Y2oRMjHUr8syvEugyzGz0cWuow/YjYd2KPOsQkyJweprm
xJ66hwWYqWct0TbdzoCujBn0N26pk9VYJCRXhwoC87g6P6gZtwTLaiwSw/R4X1q+So0rzedwokem
KDL78J6tXIFMdIBtn54+lsFkYGkhud8ImZj91d/yLPeFDvW7ydL5GytsTnw3WTrPWNmxocem7deW
FIm8iZ2rsV/2iDY7NszShutZVVgmLMr4TPtNRth7nhzTiGxnzB0+AGDBteS1UApnjS7CsL3NBCzk
4lmAd3ubXqc742pcM8fwv7EvKRzGB7D7OJYUTsN7m3Qb7J8KjXR16LO9zXDt6ru9zToCeP5GtreB
KzSNl2abp0R4HQnqqPfRJqQYeCN2Da5dZXsbRPpN+1/WYrbUsUOFDdEd3WaqKWMXY/WsSYNlqqkb
e2+tXCuNvkkK2mLab1whorXR1gdYTXDWRrqcgBSuk8J6xj9ZqsHe39X3kNkqZ8bRH230TyOy9uhO
fi+QG1+T2WuX4dUAfYnWOC18tZGB9q/Pu8ey7UcAZxXyN/SMNuRIbKYOJUtqRhswZThowO1lSMZJ
YV/NZpgXcdcl2sg43yjayAgqu3o4Qmx3X9Tq9wwevjHW1VjE+cYeV1P8Jabn1bONTEqdmVpnRlYL
J7tbubxnng/zGU7YcG+yQgE1Kx6/WPWFwzcfOfEpleeapOiFKn47qt8+5l2ff3uvOMM8wb+d05Mh
tp3h6eoRvH1PGQ4w4qcWXZ6U1d9xNWQQVHZGhnQsQxR39YS/mNZZn/NepZUF7ilobdpCunENuFdN
y+PWKoYQTwfLpYJ0ZLijwbUYzDGutm3Nk2029F6tIvXq7c3PBAeljzjHw4y/qRLOrqZwBXIrz1K3
1Q2OVvU9UqmuVmZAHxywUjQXHvqj9vlO+xz3MFc4AQX2X/Fq6wwOKzbSyHm4Y8GKzT5L1tbV5nY7
z4iMFFyZz3CHENimWTzLs+rSMabq2pQ8IYEt5d69bywh0Qaz44Ogitp2HHeuhP5ssP7/P3sB1HvP
6j17cVN5z17cVN6zF4Lq8OyFM5t49kKM4zx7IajOz16ICZ1nL8RQzrMXYizn2Yubynv2QozlPHvh
rOvr2YvzfPLZi5vKe/bivIHy2Ysz4+WzF+ILnWcvxFjOsxeCynn24rzX8tkLMZbz7MV5f+SzFw4n
xLMXzrrEsxcOJz6fvTiLg3z24iwQ4tkLIQ/OsxfnNclnL8T3Oc9enFVfPHvhrF08eyGGcp69cBYv
nr04i5Z89sJZ1/3shTC4D10b5mZKd2y7n71wlsU3AgDgRl/tSaMQHqi2ZB87JfdNLywCwkIUa7a2
DFccD4u3R4jY28zavy21+Ph92z3Y+LTyh8ZmuwXcn6wyj3a0+PCl/8VHO0Ztn0LhPNpxU+0ofD/a
cVPtwfD9aIdDJR7tuKm8RzvEupxHO5yxYJ5ZHmGnNLEu648Ar0tLaVaXEw1whk9gNkZQPVQ1R5vr
wJuYcQuGmUPl+2lqrI2q0wNaTaMdrjJDB0uUFSc2F4H1yvpqEOzwC3YcDnVgKC9mfKxXzpfwH3eI
wB7pt2aP969uqWF0vUMbsPNoaRq1elx9dUsNc7jyxeAWgjrNWFu3VF5X7ikH9xsr3JL4CkDOO7S6
pfIFkOp+IxtQw9YFvds2UGa9stGYu98Ih3BgrBndGVnVhEQbWd3gnxfKS9UWYJuRVc3caq6e5NAD
QODd6vBkIgf2JESkXLx18chOhlhrK7df/GE3S9gm18q9eqq+GikIKgujObPTWgvuPubMnoSpNpdf
+XVAqyZ/9bBy7Ow2tC3cap+wq7m3MN1vpHs5Rs+uBciwX2xxPJXW2vrIeiakxNXgQcxo9xHuZWGS
MXo6lAed9lxrcXk/GcTHpu2EzUwzWE7z1VLiprLHuHjUO4Kmajthq4ds3dBgTpq3Lj4mgnA/pejt
EB8TqUCOUjxOsKrZJpCte9aEVc0B+dIoulExgQLfMWZPJthTNZYysv5G6xKxqgkuBteuslFH6Wm2
6MlEYWCSShjFXdfgQ0E1he5pB2ufo/Ro+GWdsDkuiGDxLQA7r8LpqsYCWCp2XoWCax9ga5uREk/X
GNzeamY8ulzben7p7AOszqsRaOVa8ro8q7J6L5+xYz3aAUjOPifYebWV1Zn8LBPr0Q6EVknvo60e
soHIfHXadjjBbvWtpOL6E6v2GetK6zq8p8/UmkG+7ZIAfabYW3S9R1Y125gG+Z6qmhjJIN9jVRNu
ska+p6pmaHk9MndeV1ueVe3al7OJlQafacbId5RlFGDrgpnvC/cQ9Yy2EglM62BHd7EDQrMuQWqE
2eqV9Kww43R1u61u9TNord1mpP+Vo/FXt9onz4tVGNbsydeqasaQmutts6o5oERjuuta58VyNnGH
3e3Vrf710vJZa9cDIPC155PW/vzRjvCket+qo/KCxiH44hGQGuMyz/3EqsjDHQHIWCXVFnKIRzvE
jNuxWd7NqInVLTGjreWxjsrzqUVRbUddWUUqLxe6nwwcE8IJjtDQVDZEYxi6fFVFtaWNCdnlFXKc
x4KxhCjHoFe/1WTvpz0criKYgD1d7z2KGbdbFXx7ra071866xAMgzm6PwpeE1qtXYiy7+pkAenB7
hzvjqski/BrejK+abOxDc9UGcpDCGhHEZI9f69gsILtp+bLBamICs1Yt0ftrlYCN2BqPUYmxtlu9
fT2griVny3vDWM7It0LdGdfz73MWtdtb6NjW237sQ+7I1wpDO+9auvzi7Ww2UkvuWH2lTNbDEYJq
CzAjn7YN3bUT6wEQel7N022GoXOMdcPe2Ue4hKONYTRt66XUeaNlzO5943raA1tUu7dD62mPkuZw
7cQKQzssQHVn5NMeJa8bx2d+AXwAZ3UdfvTGAujxdQm9ehvu8bXKPGIM7jdWAvt8JXzO62Ldq8Wo
9XGv2XY4e7A5zdOO3Jm4yyVP9xt5uBYxcgjuNzIMHW1113NkYi4pbEbTtpptYEUhae3YOjgEyGov
xeyQqQoVyBdQtNbo8Wu9ableVfA4URKPndV1FNFZV+Kxs9gN1m79IhGQZ3yi1u2HYBUuTiiubq8j
uLUFLfdbqF2ZuCvRWMztCC5z7nXdtTvjECwc5f7lHB8lej0AkrVd2npwIlQNYa43IZ0v5I22EdeV
mJsqWc5PdnqATkaXp5NXYkrV1ms/gMsrMW3dqzxLBKzuhfi/pOrpBgDvqnOuG85nbkF1ECQAtV3k
qIkp5tSy6+9BX6/1rppe/XYAF98I579PTzegOtSN9eqdGMs+vcL0PryJovV/O1oLDxPehLa9W3C8
el3OkF17WSE5KYVYXXtZ+XL3TDFqnbXdSCeTxzllF4UaZKLOkrWsbsdOA+uAUCwXHd9Ha1vR6Gjf
S0x1XVnQ69rCJXpMPKbij8WXIwuLvu43FiZ8c46uPq6XIxuP4HoeU6t8hCav64rOjG09QlPjdKnY
oXbWVpK7LgSOEaRaVrdkwsA3gg9aa7cdYuAIaNda++bqNwLHpy37XuA4j8GLeO3xpvJeexRUzmuP
N5X32qNYlw2ExH1LZ0Y27Oh9LiM+T+oTc2OzgbBCiXvGLXCky54iD5KJsTYqukHjlTe+x7Kh16pf
zlIVJ7YKIA1cwqdPl1+NzyWnVzbrnnG7bwk3CHak6B2yaQJxTNfhPYR59Jp/IjkMHAsQIXlc5Vs4
qdf1TtX5G1fgWHrp2VuXvG95lgkeu4WDuS5oC6qtfgkzmEPO7m5jNjolZfjrYsYOIJumuy7m4uCC
ZsWJ/SEYHkJrq8nWmfeqynlTbeFl4LGqUnze81ZmhEc43BnZgobNv4ZnJ1SV88yJAUd1pleu97wu
WeW8x9oCR4AxPNU5vB3KbDw9GZcoqq1+STiDv6HlfjsOHNiyp2v52u4P8lZmnaO6nFi3MmOYvbir
h+Tw/e/o2gk2jmK/hBi8fcyQr4y4sEeXE7Xzrmub7g5hLt51bbW4M7YK959t0j3JyT2vECe7ug0/
nCHOaC7CrFYI+N2kqGw2noFjH6HofbTZ+PUmJAKhrLi6PXwPy9QS4rPgrYuPA7Q5p5aJrSU+W8+n
EbqWLzsWHDQEhKtx/plfJfOhbbar8GzOehOyDmMntiAUyMdSaNQSvTW0wg5BJHxUYNurzBfT/RkR
OFa+o6b5td3KROAI2B7akm/NsYhp+ZUgP+8QWy8hjmuuLVyhY+whubaQLbQiHBjfAqygEFDaXU1j
UJhnTNoH2O5IxsQbnkOj++PdzQS76XoKvLtZewnTtXIrKAwpaU3bb2Xy+YZsfKbtG8s61JpD9SwT
23EBZYrhva1yAvlyed0WFTPaSi5T8uwmmN11rX4XYIRr5erqd8ELXC4nYL8QxQWjaVsYyneOa+yu
NVlVztJjjp6daKvfxUjGRj9VOctcFx/OWMsGYLwQFFxvuzElX9tqVHvW7ZaYDE3D+ExbLZQPpSBI
cyUHoHdFeF8GYewdycLmfhHDebxvsF8VwX3TnsJ2w5OdBmAAhrsu2C/4OakMlxONr9WO9SrsWb7Y
KIz3TrXW/t7yC1JYe6uPfuE3bng+weq3AswZj4GJqEzeVFuIxqwX28FqKhu+MOtVx7o/JWbcjr5C
McJcRVyHipXJFtbxEjHjdg8URhwRGMXUGWtVJvtqISTG2lr1RD4dv179uan2A7Ls/xlmimrG7ULL
5E2lYXhv76cidOyxhFDcGXkPdNSpObFd2OE90Aw0Hopqe9sE7niricIsOPHQ17dAxVJw1zUnnNCR
zDdu1UQmMCA4eh9tYBJXAmPVL8/r4l3MDJs6mrfbPK5aExTF5WrKg7cZV/1SzLiFewDQVKcea6vH
sZrIFsdaom0nNxqS8eo46lDBEWLrhjq93YaLfa3YK7qcmOVaB/Orp0Os7QXG2i4neGOTBS2t21sV
il2cM9syeNqB6IwHsJfhPa9rBXJ829u1E3xMOcTXYaKzbvOIaWyvw0RnmWAgB+lZgdxZonnTcsBO
BH/1rO11OIbZ5cS609ZDzp52rCsrc6w+dM7qecSU55J83rMCWFLo3Z2RjXMQyYXg6eNqnLOS6O66
WAEE84eSHBvurUCOhXvF1S3cA8J8NmU4z7hqe++mDIJqO2LKO2bwHIfHL16AWe1Sp2cByrohl1P0
11XChTg7dtf6FnYch29i7KpdfWV2vBSNQ1voyIOoCfapebvN9jr13c7jrNurvc67ncdZH9cR03c7
j7M+rsY573YeZ06sxjkdshM9rq7GOTXElLx9XI1zEvYxeZxYwVeHVFR3XetSFLbbtSZsnNMmnQCP
qxUyMUq3Vu7h9bk5h7Fy2zfyiGkP6xUH5xtX4xwwVcv9Hy0V8LHMVd1zvrEndjTo2oPZ+ypPtkoc
ydWhyluTUMeqd2g7PAoU5Tlnd4cAG/BXc5zuDjX2iQCGalTY+hfzPBRUJLqrb5Cchk8seh+37suw
cn0M7Uc/V/fCiK63zSOmI8RZXC9tHTHteTX+ctbFxjm11NhcrsLPmfApjaew9XuGrPbeNHZsM8Iy
rb5y/oyQL4hEnpr3W1jFpGlf9ddN7r8RVj1txvfCqnwMAETdTlDZAEDU7W4qGxm/wqq4WnYLqu3A
J8Oq1wEgMeNTWPU+8HlT2cyLrMjdVO8muj/lTCxRDf7F0PhBMwCRZUNRyO76p0de0Dz91a9/+xGZ
l5qv1m+sv3z8+q8/OBvzJnBaE6JieJPrHzgir7Ee/0qP1UH3Ggk/g/YW+7NFty6sv37WVzikf8bm
u5UKiPD5Hz+4ndxw/MffP/+D94L+vmjuP70I/v3Hv/zTx3+cu/ciUEsdKglkeP4jG078jAbf/K0u
wKvnOMKhT+9su8rJXkS8DSmpttPEbX419L2ptixB718NfcVYtvPUeqkit6CpHq5fNjjQy9u4Z7Q9
aaCMg4lqtfr7QHhYhN+/JpyC+sDvWowXj+fh1469n/lrjQf231uzMf2rHbyg2joy3+3gXaqvdvCS
amuL8dUOXlDZ5+tFO3hJZQ/13u3gJdX5gVRvrLsdvKDaA/+vdvByrC3w/2oHL6nsWHc7eEl1bgfv
retuBy9324CraAcvqPYDwl/t4CWVTSLc7eAllQ2w73bwgurtlv28cXksDx/9TZnPX1zY7owLmc8n
LiiZ/6JyHjWVVNvJDCHz94zbmQsh8/dY25kLIfPH1SuZz6fdUTL/RWXb3SuZz0cJlDJ/r96m6qTM
HzmhZN6hEjJ/U213s4XM31RWY6XMnzkhZT6fbJeS+TPV/QSCIzniCQRHCsUTCB7V/QSCIzniCQRJ
tR0+/3oCwZEv8QSCs4/iCQRnh8QTCJKrdkY+bYT/g4slOWETCAjwQomwtR4nWNEPr1vqHlViFYv5
IndGeM6hVMypqOxJA16VerXskVRbimeybzBvgzucKJWtrNbdbEcmeIsY2wZVcr+RhylrglOvqOw9
b/ZjX7dUPLkvk/Xi2nzry8o5BCWm4Y3FtMwyq9kdi2cuXk+NOZrGm788x5KyJ/c189xSmsO1TEy4
hMZ2Vp4tXLd1W2WjSfmN9qgx321onY9ieZxYR6BXr1+5rq27MEsNq0GTN+NkIohNm70ZG09dEayS
x9XG6zp9Pd/kcJXpD9qlHj2uMrEReofJ9LjaMnjfJ5Rb+QBfT0H5rkPTDPxtHkc9YaPyOOpJF5XH
UU82QnkcN5WNwaXHUU+WRHkcX1T7xT/hcdTT7iiP457x/Iy6s3rlcdxUdkbpcXxRbU8gSY/jiyp6
Hkc9aYbyOM5jSY/jprLfKD2Om8pGJdLjOFIpj+Om2lq9CY/jprI91aTHcVNtZxuFx3FTnR9d8qik
x3H+Rulx3FSex1FPVkl5HLdEP500/PQ4zlTS47iptpOGwuM4rl55HPfqrS8hPY57xq2oJDyOM5X0
OM4zSo/jaJmUx3G0OcrjuNe1XQUTHseZq9LjOM8oPY57LIt60uM42mjlcRy5qjyOo11VHsfRriqP
4/iNyuM4zyg9jvOM0uM4yqryOM78kh7HmV/S47ip7IOR0uO4sVY/p3hG9qiU/bchu83WPSN7P8mW
QnabQnxG9n6SeYXsbmrzC9n7ie8K2ftJahSyH9elkP34jQrZb6rzc4pyxu2ehED2m2p7KFEg+5Ff
CtnPq5fIfqe7rcchkb2fNEMh+3GHFLLfY21HYgSyH1evkL3/Vv3J+UkRvqk/Nm39rD/zKPNSf+aJ
o0p/5omjSn/mt/RnHuVB6s88yoPUn+O6lP4c16X057wuqT/zqNdSf+6xPP2ZJwlU+nPvtqc/X1Sb
ly3156baWk8I/TlyQunPzQnbjF7qzz2Wl4s78kt5xjeVfeJdesbzN+vicjZPtaDjyxZLF+OxhhD5
WtuscURJtWkZW5Hwrpgaa8+ejyuPWktWY21PhqzOgLxYK6keDpTOjjmbotqwrPDBE2ijt/rEI4Zw
/NtQVDZLDQ87t8iOhZJqaynD9gGNV+sllS0f8hkZMjW5VDy2VdhTxuNEYifrkmJX/Nr7n/I1QLjO
el32aC38t5jT0kVnRt4pTZ3PUHu8n+nqCbRTrWt7GjheYAT+wpuR9/QyLFxXq98PgbJYjIike/uY
E19rg7ZkT1Z5T69NXojzZJU38MrMI6vVW1u/eoOOGYK/+rbadLCTorcuNj/gfXjNe3O+AwEqXwwr
U6/e3jJcBfHJexuSytquOa7EC7HRky/28wx18nVOh188bAkDwLsWjuTwGGXD/qTpyUThTXDEslPL
vT2ICNRLJbSmV2+PURL18nqT0tFH3mFjb72ZPX4V3ptNje2PHJtT2CMxUdfcsQabcK1Oio7k8N4Z
vIRW1eq/+6Q8e5jsAPBN3DhW/hRunCulEjecqqvAjXySLYUbxzqJwo18tF0SN46rV7hxrm5K3Djm
xBVuHGtBCjfOVBI3jpxQuHGuBkvcOFayFG6cZ5S4cWfhw6fAff9ZJYUttwyen1UqPxkJxtnj6CdK
NSU1WzbyhVJ8eVRQZYs/b5SaSmq2/OcbpVrxpOaNUmxgJ2fcXsR4odRs7je+Ucro4nYDfKFUSlrm
txd3XyhlJPAZpfgetVy9zd6+UIq37+W6trvdL5SaavXJWkqi1DsHd9bYN0ql5PL+E6WmWr09S/VG
qVq15Gw3rRdKQRAV1fb+7QulxvB2+4VSERxS/LLZ2xdKpaRXv92hfqHUaJ72v1GqakTYGrK9UGrF
smJGW40M+RorhejZemZc2woa1VjbjWY2W+xYmuLXQ3fnONPKbJ71seZxQdHYfkt+41bj7VeHFxHV
6u2VE95oXk9bu4jAu8owvEAdD4MqX7FoIxlEMJpWecu9wY4PlxO8fFNHLcXTbajPVSs0XK1+O0Ad
Ju9js3mRYzF5vziWsjIEZ8lp7NK9bsx4mM1XX9crUArPbN/5VniVb1aDZ9uB83zl9KpQC3493PaN
keb3wXv5Lp7xTbTfvW77zkhz8k1EOzpm75GqthLf9QabFsrflNGL36p1x2O1RWb04rGqITN6gurp
4dF3Rk9QbU1u74zeeV0yo3del8zoxWPtQ2b04rHaIjN6YiwnIx6PVTOZ0XO+UWT0zvySGb2bastt
ioyeGMv6xSKj53BCZPTOVDKjJ6is7yIyeoJq6+NzZ/RuKnvqT2b0BJWN1kVGz6ESte7zDslat/ON
otYdj3U6Wes+y6qsdcdjnU7WuuOxTidr3WdOyFq3WJeNw0Wt+7wuWesWY21V7LvWfZZ7WesWM+oH
QI/GsVSlVL/NpvbTHiqbeqaSNtVS/XwJXf3avfK/rnsqh2sm37oeQsWh97mP/H8BUbZQ8mVuZHN0
cmVhbQplbmRvYmoKMTcgMCBvYmoKPDwgL0NvbnRlbnRzIDE4IDAgUiAvTWVkaWFCb3ggWyAwIDAg
NjEyIDc5MiBdIC9QYXJlbnQgNjEgMCBSIC9SZXNvdXJjZXMgPDwgL0V4dEdTdGF0ZSA8PCAvRzAg
NjIgMCBSIC9HMSA3NSAwIFIgPj4gL0ZvbnQgPDwgL0YwIDYzIDAgUiAvRjEgNjkgMCBSIC9GMiA2
NiAwIFIgL0YzIDc2IDAgUiAvRjQgNzIgMCBSIC9GNSA4MiAwIFIgPj4gL1Byb2NTZXRzIFsgL1BE
RiAvVGV4dCAvSW1hZ2VCIC9JbWFnZUMgL0ltYWdlSSBdID4+IC9UeXBlIC9QYWdlID4+CmVuZG9i
agoxOCAwIG9iago8PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDE2OTA1ID4+CnN0cmVh
bQp4nKV9245tu3Hd+/mK/RzAS7xfgCCAZFl6tiEgH2DEDoIogJX/BzJGzdVrsoqT1S3nHEDap3c1
WbNYV7Iu8VfAv/8Q8T99pl//+tff/uO3V6/y0+v//6H0Kn8Rf/Hff/nzr+sPf/v333735/Dr3//v
b+FXy7n9GrH9iqG2X3/7H7/9229cQH6SexpfP3qEayUn+eFs4f7dwJ2uP2CnP/zlt9/9KfyK5dXk
n/nrL//2W/zCfTYsUvqvv/z1t/8aQo7/7ddf/tf9tzG0Vx0l9bJC1WSgsHbPNY+koLqFGq8RANdX
qDIMVGqviS1bXaFCNlA5vkIOpUR3x1xfMaQS1TeWPxiokl+p5prUN5ZioGp8lVBa9r+x1lfprYXh
Yl/nq5ZRR1Y7/qOBagn0Kj0rqGpPqAfQCwSL7o69vkLqQ1Niw77PV5iTzOzRa3TQK8wQXOxneNXQ
Q5lqx2ah+mvkGjV/WexTiK8ZeqzB45wUwyvUkaqiff2DheqvPFo2tDennVJ91dzLVDvWYKByf/XS
UtNcaLEv9TVmz01RovzJQs1XBBfG4X5jBfaBWyp62bVafOXe6mguVRt4FVxYuscTqYFXEz69ezyR
en+1Hlv2T2iAEin1ml28xgS9So+uPKY5XqFAhDT2ZscM/RVno3Z0vjGDc1IbMwXvGzP0V0n4uZbH
PxoocE4vEDRXA+SEbwRbJ80TRjoy+CsWcLSrfTP4K82Zuz4h+401v0rFObonlME5LUDzuCeUwTkN
itzXX7mN10wTxPA0APgU2qSP/rTjP/3lsl7xZL3yCC/QcmgdGaL67fT3/fZG34FzH2Fqu2X1cJ7t
BeMQRvCkPE+c+xip6BP9x2+/FjTi75cA3Qsx07rEfO/R1n/9tm+dSoyvBByNvqoWar5KnlnbCks7
eA6vOkGs6klpyZQZIDY8ChfYacho19rW8nmpCXoBZ+ZalFKhFyKsZvH0QmnhBWs3QnW/EXyeMzDz
qdrTq8SAw3d3hDRA4Ie2mlYTlYHzzXn25MlymenVBwy160kV8O2oPdTqnTYUxyuEEbu2TkYn15hh
w2YO0dNqsCb4xl60DSv/ZKHgGcCdqmqtaCxwzekF7R5bc3cs8AxSSTN6VIVH9oKfVDSvbt8Izskw
nT6v1lbgB8IRjC4UeKIlMFjxzrFCS/U+p7HAf7JQBR5xg5fknXaFLgMTBu3Fbqc9qZNnNDxh8Gqh
kKNTdzkarjA5Ohl6/d5AQZuE1mpyvZ+WqL/g2EQXCtoEtqebmMXQHpHTq8YJx8yjVyvUX3EY3W/o
Bbxx2ogh3HNEVIDThu10z7E1aLk+R9KcY2wrfK1XCn0WzfcbFE6oQZ+7XNgGuDDWZLD//c9sSptP
DPftr0nY2U4ucwRrIeCKwvLtJIoxJjjDKYnAttPhRDj8ESpVRLGd2DQmEBQaIKsdLdljGgiH02xp
hdqDUxC0lpl97KGURoAQaexteAelBM8jist8r7WFnZ1infQ3bnjBuYsjgAVXqGTxWgPKD1S2gRuV
Uo5FY7/tCKUEZVOSWssq8QiHv40SWnPXmvnVK+iVPHqpUPGGMiZbhYpHnkjg3QgGy9nDKyEsSODC
MNVahl5XQBmyCNkZr5xBCVBVf6MNOyWgDClqnthCRRiEAl4M7jdWGAQADXVCW3jXYBAg5UFhb9XN
V6jYhntC71Bx6h2NQXiHiiMWl/bvULFX9xvBObMxYPG+EQcNSsBhGp7UfoWKw9UmEIxXLmEWV09I
QIkQMCSPqhmaCdoztO7xF07wNWeP098R/BVA+ap3tEFKpotTc+wuXhmnjfMxnGPcuFwa5BHxd/N4
NVe4l/Bd0nTxAq9mBNZTy9AWdiI4RaQbp0sJ8CqZsE/3HDt0zsCGrjbJAzqnhNBcPZFHeyHgDym7
XDihcxr4p3lcWMCrgEld47UFcnC04anO7EMNmH/4VO4JwVt/9dZbnp5sl1xe8Ja6bx8Rnb3oziaX
76EEXwmx1ejujhUh/BywKe6OlY4Q5MOnV6M7HoOhlw18G1zCELumxHZCHVwIdzbrbzRSC8f4Nb+u
Fo5ciGAJ1grRiyuPZYISYYbh7zihfXNPxrOyIQfCPfB9zpqqNuQI0L4tpOnSnkHhzLB/waNXTQjb
sWHXsr2FjhMaM5bpynaFloMnV+r06FWh5XCILRWP9gwdh9wUuDsW+Dkj1+LaRwkwEbX7nkLlE0Lr
I/s78gkBaxldOG0YiuC+9al1ob1+qXwciNN4VluA2eHn9Go4ZwtpoeWgKwznbPwFLVcRoFVX0urE
acPEJFfSYDZeLcxkbJoN0SI4uoWsPYUt+GIYCl1YXOwZhkboQl/fQ4m/0rf8JcHqxl9vC/N98FWe
UPhZ8DVO7iUCCTi0iJ/DCrUHX3AS6hwS/Y8TO8SEg4ZGHWrHLQCAWOcZr7e1cRIfCavg64nDcd4R
AovwGUbb3bHwBnteEfs4HQ4UDUIOBKKaEvY9DMEXfLgWFSW2d02IIixOTz4lGHzlknt0T2jkVyx0
AFx6QRTznNet1w1lv5GiWEOe04OC2/LqIV6vQOMkPvD9Gay22jxKSFgF/mqK9k9hFYLMXlwuTHBL
MvzoMrxzTBmOUMhDXC8Hind2tRtK2B0LnYQ2DSVsuAfOmSSrPiHjHPM1Dy6COcctdGyQ4hhT6y69
Gtw4uBtJ42XUYOowCOCvGtwTQtg++TDo0wvBF35YjAzZQA5KvJXYNe23AABKvE/s63JOhhKfBTp1
ehogQ+fApQozefRiwAQlHqr7jRk6B0o8xOxpAIR6LwHysYf5r4j36nTxqryNwzkG7xxzg5aD9i8a
+w2KoVCZWhdu4QuDHERoRq+ac8zgiTyC1Uw2DJ0RemKU6VOCr2B1tjg97EsoL4h/8vVEgbWCi5Dk
rvootQXWasIr8a1VSfUF77IGV2MWuJcJOi5VF6/coZl6HdXjr1KYVTJrqR5/4QhfFSF0cy1MgTbp
MXat7ze8Gk5o5F6TS3tYqwb+mv6OvfCN5sqSOFqFAscxINbWJ2TD9jIqrVUfeq0NCloOvm8p7jny
TSv0oDWmvWKq4K8J91JjvznaCHJChunTfL8FObxkjlee1JELK/gLGiXP7tG+wlqliC2TxzlwXV58
JzQ6egs5IrVJ0OcYrdNOb2gg6BsuJcQb6kFLrb0YvgITKLnkcU5FEA1r1WN1oRCYwFqN7OPVYWtx
1sZuW6qCc0DEmXy8+PKFINrIow2FGJggug+uXpXABE5t1ie0vXzR2w4tudYKf43gK10ZFzde00LB
GyqlGqtg8aKfMxEaNo8LW57MIcrFx6tk5hDl4NrHVuMLNCva993wquSvUMt06QUPOX/LE/LytfHE
FnxBM0E79fp0jt8HX+PJIftR8EU/+tlxjCG/eBtP47JA2ZAjwmyAl+leLlBbiAbXC0dDF/qG2kM0
mA2+OQwXCnHqhFhXjb0NckrhLY5ExgvUnywUTeMcUUFtoRAcIXhBpSq8rFhHOEJUI03jtaVSZjjt
vcfmfmOHaexDwoRlrYckycl8q7hCPb18BV6qdLWjXYtKqecxsnvaVEqIKGbwaA9SUWBF1Z/xSnyO
L4yrPM5JcJcgsHEo/rL3RsCJApvoXp6/McHRHgmBmsvRKcNB63CYFCVscl0Cf8Ewlm++EY42Firm
G21YVauEtFNjb1/k+Bxfk9xVn3kCf4/Thotc3RMa4UVvqfnYg3NALUkncqgKzknvaw4He3AO3Flx
Jc475hBeNUVJJzrvmMFfdeaZXV7NMcFpr8HXEzmF14D/36eLF/gLxIpZQVmjx1TKUKA+tJazoRCc
9pnA9tWjF6wdXVUxLmc9gegZJwTaRpdeFec4y0yunpA3LTj2WtK2RFAGcghptTbZaI9ADhF0zMGT
bXmtmsxWcb9xBqaeQqH4UOTCWbQMbWFCEC5sRoZsmABHmy776B69SszU0b1oStjwJUXq6NFdjVng
aIcR5szeOfJNC7ZoVqVNrFtSCksgeirZ3RE2DTKbmysdDNFCnsXItg1y2nzBvjRftktnsJqq1qsb
vcAToGzTvskWFI5GjhaX8CxDZcL1og/q0ksSChPYUEPZYIIZPrVLOuSZXkworGFY/WUDAAZfUDrF
1b7ywgSvPQxPhmqma5+69gG2t5DCN4c8NOdY21ErNBNMWvfx4iXzaNNoJvuNLBlpvVaXCyv8nBAB
1zx5rHChEc9KHtCyow0wBxPGoQtd/4vJiaNOo5k2es0MvILRTDZsbyG+IpScxn4LAMBfCUo/a//L
QkGbwGqX5mrMBm1Sc63aS9sCJgRfJTa53jtrk8araGj7FDyqtszkVwRfylrFH6Z5t/KkEu5fw+dk
+echMKlfv5WsC83EqlTlxemG2l4mGHLA5Amb1hPZWb0FHpW8+xtqCxMy1Q1cIYXX5toXqQTrYv5v
KBtWIQJts/SW3bUqjjDnyPuZBXvrtDcqpTGK2nFPthu8nyl82FuoasOXkfg+Fnt38WLFFbQv8zgX
vGz4MmEQED8yW31Za0tqC3C0UzD0sqlcfC6NoegT2lK5mN3fU0zqtLdUrsxKgTzE/B/pxaS2XGfR
p53t+4Xce0dJwFx2tI625FVfmbYL9jbIgVIqgyVXCsquNXmn0uVG6Lxjfr+Zap7YbsdZAdkRBiSP
v+j29klH7mGtb6U45/pA5p/dSsDheLOpvUlgPogkX65QGwMy0yO1Lh7JB2oTjAhLBlMmft4H6qkM
lEaRxQvLjjYyZqZH71K4tUDZHXkJyjS7oXbcbiWYw1EvUbyhNnUzgFfMSdFrVzfM4ZhFWOu8Fnx/
+OEtKKgnddNnr725VJVMj1mrov12WyJloKG14OIlmR5t8HrTOW3J9OiSlbSs9fS83EH76u64lIGe
d5Tn5dHS0N9o1Y1k7fY8g0evK2t35qb5y6qbBI9k0vJ6vJqY6cEse00vq254oQpzlhS9NnXDggNo
y1zcHSvjwSJ5wsta28MxsE/XpfGZvyCw+Mbr0tihV6fXBa8iu9h3fGPsTUvHhhc4p5Xaq0/VSTUI
NVG9tSRrVzPXfr1x14CeybDWgC5IOTWgZ9ShHcD0UaqSNry+r2mEiwg3K2pGMTV++e/77b2ylDZ5
pKmPc7sOGXSiJZHuLOII0MBmoxkR3ypLmdCd5XVygdreopnrMCQh0sF+QO1DC6fsntVMFPHrevKG
2lJp4T/ip1Vj/3Q5MeF2RBcK3AEXpvumjTWRCERnzZ6yK/B+I8yRVipW2fHaYcKfGC7tS+WlSbXm
aKtjhC/aQ9MK3Xr4BYqAntVwJaDwqrNBrUxP5viaOyvc2uqdI1NWoSukROHMq5WdKopUIjm8WuHX
5sLwUbk7tqow0YS03l3sWXs4ESyU6uIF56NDexoTYqsdK69gYRs09ja8r6Jei9E+NthuLOmAp+ya
b/gTLJTpWr1u9Bq8JIcqdjmH6ZxlDinXOuPVQkY8l1PPHn+1yETgUbLGfnsPDUy4bcGVWjh9L14o
dtcNa5mvgFnKtc46h5WAqc2oXeBtLUSQoV2J+RvnQHf/7s+RXV/Sr7/87Rsr0JpcmZSsbUi8V3r3
j/la6XwdcK00k8J8uzBhtT7M2ygeN0Mm+MAX9Em/3aYfvJg+RQbfmjTGJuTmg3/MNKFZ44gKamtR
k1mInhk43lBWDGNCaD+q+EILlI1NstTRdRq8ZcftxXQi0MaeCnsrOownwJ+BJmOB2uIJeIUNbtVQ
UDYaQgyQG/OXFNRW31dffC/Nil5bNAQTK0RNLhRLzFlYUTx6sSavlhS7Sy9eTPD9r2p6bd79hGpO
NXd3R5jYyffe6dGeb449JWlks+D1UG0HQgTNX0/VdplhYfJ4lR45zlocqvM50tcWVq0eR/M1sc0h
DtWy1kOSZplZHKobyho8NlMBpDhUZ+yZpAnkxaE648UkTWAlDtVZ0njJ0dg7R2P/8GoH9upGOmzF
FyuFWhGH6sxfCC9ZYxYNT2zOLFMTqzhUZ85haxPEQuJQOXhBWcKxFIfqzF+sC0sliEO1QNkgZiJy
5/3Y9OSxwMSOHMWhOuMFx5kpzMlwtK0UShGhThSHyllLktWaOFRnzoE1f4Hy4lDdULf+/7lZBDqs
mhana1npP2EWr5W6XF6e6Q42ZpJgMidtg4jGlPaZjYbbkiql7i0kVz+XzqY/OMPscU2BXGf4XMPV
vHSdawizuxa0Uj/3NH2dykTIDkZtwfvGSmqzaZnacUs4ZM1hb01b9v0tjtZlNK278uaGM+U4Sih7
1qk1U66vVnDON8Ia89K5+N8or7glGg23pTjyYaJKewznGxtb1HVpj3GWMrr0ueUSNE/Y11LWHLK4
19+xT75KlqH5fqvj6nyVlCeHs65numTA+eTi7dhC4I1cm9XjezYKSWOMOLxvZB1Xi5B/lxJMl5xM
ORge9qzQCsxCd/WghAepZMM51vHnHfMAE7iyDSNF/Sz36Gd5bHwRBus0V7bhDr4CIl5jGz+hxjeu
eA8PR/YzVzwd3dTVFU8nsitXPBnEn13xdCKCcsVvKLvj6oqfsV9d8XRSJMoVT6eDVq74DWXd59UV
P0OtrviZEqsrnk5irVzxe63NyV5ccbvj32Wulbv+Wek/Y64PK9lr6pRfzBmNimu2jozgmlzr5Xwe
z5AX9lAh0pRgWcs+ETAlcXQpXHbWgsmoeZShznALNRorXq7UrPNJ83VzzCs1a1lrS0lkQmXI+ekM
l/AAHAgnr/rfOAPMIrhCcY016rywZ72e1hHbCU0+oLVQ1TnabANe6ycIduweN/POPsPiFSVl+6tr
h1nskoB6phfbbMBEpeTSi8mGM4VcpnfaOUvFS+muhmNrjJRSnQovW2QvyYaMpqpHVSYb5nY1cXC+
sQ7e+hfNOdu9eWPP3ymJsQ4lulRnSWKsg1eX6qw2sntCg4+9YYTh7jiZUBmn1pZboiezICBCRjpM
0ihTEplOGaK3Y6EuqrEbnfrQCbEintVcuCXiQTPB7pfs2sZCZxZnXbU2sTtmqXhpvXunzX6JCJ2b
1phbuFH5gIYIQVsqG+ZVJs/Vqe3snpKY2TU3lOGddunhNUjW7NIL/IWIJObsfiM7FocZ9Ant/RJZ
sA8F1t3TnlKKn785R/AXM5eCppe9zwd/9RiL8UtsiAD+4ruZoZd1/uEJMdHTp1dNbNGUWi4evVhb
Jg96xePCSpd31B5dWws/4lUhZ314vMqXjR7GMJJmv5EuL7zj5vIX0xsjczP1jvYbO19ye4rRxR78
lfOMWkdv9GKFEGPx5PEXm14At1T90+aDdrxqUB28YB/7qEzrcXQO31LgIoXo7ojoDdq3SzbespYN
SqC/Zruaxy1QW9MLvirNPIq7I3P2+tUt+qwBpPfiHC27tOeLCwu0p8v3rC3rkLPq6okG/TXg5kSX
79l7ESzYfB+TLyVsJDK1NrG1ePDSYmAjPfcc6aXNkLKPF720ErP2md7e4w86ND59zo8ywiCRB4JG
xPRwcaYEEuUkGNJKJOUg5r+cmEZaifRyxeHlRPbItrHlavW64GUznJjlDX9DgqXzjkve2AI1LRRz
cebQlNhr3qSOKEhMf8aLD7wjNnEcHSjmjaU0q7sjq9ni+zbohtrq1OjQguV9qkqJbStDfaO9Y2M1
Wx8zioNWTmzKEHQWmFlNL9v0IkiiTS7R+0apU4tTqhKXHbc3IybaBKlKPH9jSkyJQVSleMKm4kqT
EETZWWNvE2PZoRH6ZlQXrwLFm67Oa+cTkiYhvUm7AWdHmMbEjsPB3ZEt/1nWr+i1Bfbs0Jhh2l2e
SJ2uKmRIQdkQ7erjeD2uL1BPdWoth+bvCM7JiHSSTwk4aHXGqHl1CwphGnFAOUxvR75ljXcHvbOW
yzSg8NCy1hM2YAJ/BV6XuFpOGo6Md/B1xosNRxAniAm65dEGTKxTywBzZYihYxxvF/qGsmvxQivW
pDnHVuNmJr0jJtRazuqJzOQgslfw9ETufJNkOw5PTzAoHGAyw9EPQSGCnDGixxN8F4tw2TX29hvZ
SgQ/NJJm9USJrJduMpThzKt8PQsFemC6eCXWcCF4T56ekFYiMH2tujsWaLnA5Ax3R15y1jgNr9q0
ssrkIMiIy6tsjw8HIBiNaYMv1qlBPdXpnSNfvXDYktu7QNlgFY4QdG8J1aXXzMw5vt5Bjjvy1atD
MWlduL31IJBj86XZPUqA4aX50hieNmG4h+A+aR9gCyb4dhHYo9GjBF+92HxJewp7uMfrvfdb/Bn7
PF8pxBJdj69yTBIrtN3TrhyTlIpUhDq0Z5OQXqUi1MGLfk7pdbj6i+Ee0+O1b/JYzZahDZMnQ5Uv
9oNdjlzswYWN/epcSWM1GxPfNfYbVZn5DjqU7FGCNW8TSt/4mDasCpNXADm5tG/QX4glSk0e9o39
qiVJ25M0qPAXmy/M4eLFEq1ytV9btO+Pq9memBe/xm/t9G/Tr+c//sufD3+x/HGZjzbe24c9DJrl
yxhYV1zaKcCEphVqK1OhyZBuwyvU9mZEB6F0mT+xrLV1LmSL8HHdZd1Q24Sx8oIOmRJX3jval6V6
VS1VteMebrDpfSn6G/dAIrNBcO+KXtmuJZVs71vjG/ttKhjvU+greXglqObJ/JrysNbCVs/nekUp
9nPIViXIP7n+ev4j2eo7mIWt2sZOTI54k8fGf/BK6/tN94Z6ipcLDAAvF28oe60jkTAcOz6zLlBb
JFxeep09vmWzySEe6bLOQ4HlA9TDeLx6pcksG25lUfNpKZteyVuYcpWHLGv93nIleYS0WqH2Zi2R
/fuaIYQl6AxMkguGoE9VmAarvQlL5qyoobHaAiy6o32YY94CLGnyY9faQ+DysNY+fiBJQGq+cAuU
h8yg00y613Oml6aCLSpkYAs32Z7gVsQUfwQ1n6C2l1NgDuJrWj2VJ/0ACoHHDvX02tnfvQIXsd8S
KwebOVvO2hIrYbit7GxplXWHsSFT5s13nb58Zbp72a61hatyRzutwrKvuTU+rLXtyGlb33Jybiwo
3KTCvsD2atTallA5ypOW2dIu84OW2XCCE8dGL5oKFieGl7EVe8rbm2N/WU20vXqxIYGIs6L6H6zl
06anMDLcPgLgQSD+vpGxrKR/M7NVuewKn7O0q72h9g5m7GfxZokb6qkKGOExo8Ibas+0ZyvEVlnx
eUPtU3kGy/alU9iy1tbyOUGAYEyji/1ym+tgz/renHrtLl7LmNdlLWcqz4L95oTB+DA7drhQMsB1
SI8mB6/JAvMgLYwXvLbKXYjjaJLydT4haR/NYcbT25EO3QhTEjVuqM1sRBlJPNr0vlF6k0HJ9e5C
ZWZysmGtixd7kzF7LLh4Fc4TKK2ptbYK2SpV5r0njws5lWcCqGWPC1m5KxMF3XOUyt0RxJk+86pU
7rLzhfrGbXguK3dbkJGCy1qbacyQ7avHyRl7qdxlhOLyvZTlzlCM1G6JQAzDYtX8ZZ1BKcudSfoT
nClB89gRrWb1jVvKytUpbDZX5zDFB/7zNJTY6hemhA6jejwhA1x7kkYUDl6NU8VC7D5eLAnrKebo
0r6zfjzLTeeZo9lPLIJgRtIs9qNymov043F4ApwDY1o0VW0XQNCKfROqptfeGLpI34TSPF5lLQR8
ida1/trGmAZ2RJBEoGWtzSyPT0eEM3+xsJcdEYp7QnKbW6O0aVnWsmlM7Dr27kTnYM989V6MltvS
mNg+mj3ffbwaX7aYXeFxDu98oXplvOpZatkYOsImNNc+ckZOgspJCsoGS9KbrCcZr7pAbTfDMuw0
dnfHCv7i2IQ8PKpKY+gRkqH9Vg/BlIIws79jZEpBkmGUZ6oyxSeOEow2sfehmYMtmdPpQnGuDZbS
euKpHmKCEJrv94k1CJjirHG6UNdtbiuurWVjaFGrxdMm7GAGOavG1toTYqfWkq7g5P5Gm6pFbwgu
gG8V6uTLQ5zZtUNMy6mQoKr9HFuWzMbQ7wllZ0oweedrQtnZdrTI9y8OYvToJXNtSo3BpX1LmRPw
QnM5RzqYYS3tbW+VDpmtEFqO2aUXfabSS3Y9mFY5g2lmHXfsQ1iZhxFCz945ynhVdlXQa1nspZ9r
yoaj7VrSzzVLFxZnxyHXJbW5drtNvilwrsjDOX57R97Dk9L+UYoP6w4PodCS4nNDeSk+C5ST4nND
eSk+Dl4yU2jI1JQFaqv5SBybKGPHFrxswTczaSE/5hu3K9AhdwX6G7cwtLJfHQIF/xuXhtXON3J+
dLkehp1vBJuyZZr+xv1mvsnpJ/2NWyc6znLoVxh6pgRTfHgz73/j7GzJO8QRGidFIg2rOc0xefyV
4KDVxHcQBbXNAQocKhpr905obUXtQC2tqM+UYFk4OFHGXy5QdiISW1GP0LLC3iYeSIoP+4k274Tk
JjQmycA884Sk+LRc9Fp7oyaa2SI5/g4lOIS1VXmtWfDaxqsWDk2T5tfLN27VIYN9PUZoHudIUAj7
qKVjuy+FaYzvBLgz50B7syy8puadY058Dq3XVc4Zrxw5s156qpy5kF2VGouBtNQ+3Jn2MUetLhQL
j0u4zP8ZL2gTqX3V52iTdzpb6cceXRkCn77yuzvhspYNVuEu9S93/IwX5wB9ueNHXmWtxkxF2qst
UA9zgAa0R3U5R+YAgW9K9yghaTmjljg8SjAth+0jDV5b6TtfKRHT+ngxkMNaxtY+peWMq2HFmV6S
lpOhffUJ2SCHhccwy1o69kCughLpumI66glpH53zdcV0Q21jTAPz38057j2hBvPfYy4uXqxjHPW6
Yjp/4xXIher6JtJkmmZoeHgxRIt15uDaNE74gUMoDT7OlGDnqIq1Rvf4i52jIIxVy6PlVQ4VlXIn
l6qsnAg9FJ+qbB8Nhylrqm6hEL0OEDUFd0fprhqlE/BZOq7ga/Y2XLw4JgOaKWk9sdVEJNZ0Sdrq
maosM5fhSooST12o6gjRaMytvmK8CkeiVQ979qrCWXbjPdpKAPi+Xy0RzrLdZJhGHdXHix2tcivd
PW1JywmjZFeG2GS6Q0tMV4ZgQNkXqkZXhhrzTQasrStDjcPmK+ia3G9k28p34wRnR7nWbiW4/pfM
ASqpGo/P8sSgtQpX8HXmnMHmqc3abRvSTmiT3qfB/vc/DeSeCPijQI76/ll8WJaPA5T2bDfUPi0o
IU6Fm1DVWjZMkEFnabSooLYQLb5Y1pbVjpbsTHiqI0kz5xtqf7eDuqllmrXsjtLLqU3eNyxQW7ct
3nsPyTN3duStV5nTUNW+c8qgs5K6WmvvycVBZzXTjVugto67ATtenTsWKJtjw768bbaa3R2lLy9c
aP8bZ+CTtSglBy/mMJbrhcmhPXMYUxj+jmw9MGayPLG1HkiszJF2iWdelXAvjRQVVZ/CPUhiTi7n
yBsgfICgOWcb6BpeLATWJ7QnvTCbKhaz1lb3wTSUbHhiC+TYjL4XDhjzdkQA8NX20sEeXDh6kTTF
hapbUNig4Kr0aXGoysQJmPWoeXULCqFNUpfGkQ72U0YUz5A8enE+Ueng6+TxPZNoWDo1qveNGca4
9yKVTGe8ZD4R7FRTJ7Q1KeB8oghtoqG2EbL1Vd93ic6ObDbR+XrkUoLJnwWuQvA4h+k2MEC5aT1h
U4WYZkclPVx6Nd6Ot6blcXt/7bwd79IHaPlG28rgXfcxi0uJwTv0a1zoWQNIgMl+qcPjewaY8Kun
lsc9dITJhrIw9LLhXuAV5tVF/nxC4CzOOprD5S82FqgpSTe3Za2tUXBirVnQUrsFX/lqzjG7d44l
0/XKOQV3LTh7hbMAq4s9x9HC9AWtJ2wNSbu7PjlUbXzxzeL2OlQFFyJgHRr7rdKk372hHOzBhW0M
wxN7a2KmM8OmFXdHcOGMcQ6X9nxPDA1xXPDw4jjamGvoCspmmch7YgzyinZDbUNY2WwC+lJrk60L
Gyc/gqjZ1UysNBlwDIPGa3sp5BygOrQGsG035D0xs47MpRcbio8qTwpnncPOaSm3FJqLfZvwaoc8
KZy5kCEtR9tk7XVY7HmRjh2na9MQXDL4ko6Bzo5DGh5Izc2ZC2VoLfR497+R4TGoZTwrGzCx7pav
Ba4G4NtkHdfY6vMJsQtbz6MHV/vyPZFDq7Mrj+BS8P3o05VH9mpLiGCqK48ytLbF0V15ZGOBKuWA
Ll4cWstJ5j69mKmFtYZrrRpnLDR45ZpetvU1NFPq1irs74mdFVbGKmzYQzMR96x9pn+yUHwQKfJs
ct6xs9CiIzjRlPjHH4a08cnc/yykTT8KadOJ7CqkTSdRjGBmDvcSVX/vuDUWgGHPM4gS/0BZF+d6
m4T5V9jv75xL4HvGSxTvvEKhdBIMGcwbr651zo5854QW1ztutUXsBQSPVgQ2nRSJvGCWqyf8AmWD
VQa+HZaqudgzkQMejF7rsUlBrNINzDkhaYhcZfjwQtWtAmnQtZey9RtqGz7MwDf1Sz0f+UtC2s62
oh4lEsvygpSweVBMa80IfYuHPdNa26gyLvRMCXiW7FF4XSccaS+tDOB5heLRPvGWEOLWp7sWpxxA
k1QtafYtlw0PEA+ZE9rqQvhSWJpea2+lnaR3YnQlLTX2WBvSDWzZ0bak6Ag5apPLN4f2vCUM/EqF
l63aGfPTqNnBi7eEoU+tTbY3wMBrNHiqLr0y+AthR6zN0yYczAslewUAR85hjUktbTaXquyV9zWl
xdkx8bKtxqR51YaOmUmmCGmru2PmkCL4/9WlRGGS6cya7/ekXDgJHFo3XUpwfG+IUkF55glpi1Bh
YzQl7Ijixiu5MrWOfuqoB0aN0T8hBtHgVX3aG9RgjQ9ix+TuCMcR8X9Nmqo2FAp8wbwGp56pKum2
8RqcekPZl3uO74UmNKe9p9uyb1XNbXhSK80TCk7T1fdsngBbZfTE/v5amdTWsyu1EvjGLtlWN9TW
IKJOzjnJWq/ugW9ic6GSh4tXZzABYxHdE2KXxcoUDHfHwTDhGqbr7Mgqx3oN013WssH9ZHueqxBg
saI2RAvkrxSqK9syuaeWoE9oCzCZQZZmNVK7NU8Af9V++ZxHPSEhbRjXVfTRG+L7K1yO2vUJbS+r
zFgZ1nbY9gNs7MQRntXjVabI1l6vy6MzvehZwR7rc9z67sFn6nOG7moACUOZiVpd7JkiG1qu05Na
psjm2ovxTbbxvcxriV3jFf/4s6igGff7E0zEX3yywYewsTUrIPgPfLx/+fOv01/97d9/kzszZlNg
Rbbl+Nv/+I2bsb1ugHIc+GO74AFwLfX4V2qpAjBZCD/qYUbzI4GilxOuH3WxyPpn//zbf/zGJvRM
yYFy/utvdFC+/ut/X/9V6drwvwio/uMD9z9/++//5df/wVqsxCUFr///h4Jg7te//vWr+7JPcun6
S8Z9lsvIpibv0aA31NYBgT0sYQ3kqvwDtcVrHCbx9Wx4r7V1QIBWabkFDbV1QIDViqVHhf3eASG/
eI3RFPZ3p+tvSCPh1OfXTGhbfIqeHnn9XwMff5lW+8H4NQhS4acsUPYFlHcyIU0exAJlg7fM/Oci
ef8L1FYrydF5V8rCDbUFb5X30z0ntVa0eFU2ckUwpdba3m/b+EwIv6H2Wsku00b4QrWstQWCDVA5
DrXW/rZZX0JUtdYW2ARJgZSZHcs32rAs5o9BOVMiQVSgrAJ1yYKXcSnZwjykq9HmstbDq6U8DSR3
R7g1QeqzPUpIWAbQkLwTkmmiCdKp1toDLr409pHVWk/NyYVVm9rxqe14vt67z1zIrnAQBmnvfUOl
LWWUfdXYUtzje4Y/QVpruFB8l4Hnn6IntXz3C1DYo3onxEGcTNRhEvQCZcMf3ptLJKigtjL7Jp3J
xtNa3yohyZTfyPxD3RXnge5Kd32gNulfdVc8dRtSuiue+i4p3fWBin90dFc8dWdSuuve0eaLrLrr
DLXqrjPUqrviPJy00l0fqK0n5Kq7jrRXuusMtequ846r7rqhttT5RXfdUFsa/qK7bqinK6Uv3XVj
v10WLbrrXmvre7noriMXKt11PCGlu+4dtxnHi+460l7prhsq/FCuU3xg8R/Kdf6aNp+sLK5y/YFy
5fqG2ro8LHJ9Q3ly/YHaOzMscn3ecZXr846rXH+gtgvlVa5vvLZRL4tcn7Ff5fqIvZLre60t32qR
6+M3Krm+17Je0CrXNyX+6Mj1B2rPpFrk+l7LelSrXN9QD9lPH7m2UN+yuFTlbIj+UDJqPci0kowP
lCsZN5QnGTeUJxm1/kQyzjuuknHecZWMD5QrGee1Vsm4obZ8xUUy6ik0VJJxpISSjBt7y82rZNR6
4uZVMuop/FWSccZ+lYwz1CoZ9RT+Ksm4oTyLd+RoZfHO37havONpK4t3xEtZvKMMKW/9yNHKW79P
2661euv3WjaKWL31I98rb/1ey/YsWb31M1SvL1EA/lostii1RB+vpeXVQvttgA5oX4aMqTjTvkR2
/pwjaG1iL8zZP7vG1PRaW+kWc/mS5BiesWeeG7s3Tb2WfRQooH2trfl4cZh3vSaEnmVICqmoVl1t
wnE2oRETjwuZdRZarCl7ksYSqdCSXBOfac/+xswT09p3G5YSmZtWpWfJGfvK/gGt55Ee1vrWFFZN
wJ/OGrwsaD/luHGM4NewwRtq7yCWPsMGF6gtZoyfYYM31GapmAP+Hja44LXZ2fEZNnhDbZa99s+w
wQUvW57OUVzvYYPON0L6v4YNLjtam8287fewQecbWeD9HjZ4Q22zEtg7+z1scMHL2o0YPsMGz3ix
geXXsMFlrc0DHZ/xf86OLN1+z/12duTEjvfc72Ut6xnX8pn7vdDL2n/mr77nft9Qew+u9Jn7feZo
TvT+mvu90N7enY35mfu9QFm8+ED3nvu9YL9Flv0z93uB2sqt22fu9wK1ddcqn7nfZ7zyNT/jsrPH
b8xyxX/N/T7TS9pKvud+L1CbBQ2fud/LjttD/vjM/V7W2p7o+2fu9wJlvQRW4Lznfi87Wu9l1s/c
7/M38ln9K51kWcsWLMMT+pr7faY9n9W/5n47a7G/y3vutwc1P3O/F+y3B/Pxmft9PiHa2a+Z3meq
0s5yhluMD+f4rTGRislNQH9og+Z/5rqTRfLfB38LlBP8rWtt+X+f4G+F2jqYfIK/BSpt+X+f4G+B
supgCf4WqPDQNfwd/K1r2Zy9O/hb8bKDmO7gb11r6xr+Cf5Wqj50HXkHfyuUVdh38LdAWfZegr+V
9lYV38Hfir190LmDP+ccl+DPOaEl+POwv4O/FcridQd/K142kLyDv5Wq5+tO54SW4G/liS1T7RP8
rXhtOWif4G9dy+54B3/OOS7B30r7c/C3Qm2jeT7Bn3OOS/C3npDF/g7+nNNegr/1G7fpqZ/gzzmh
JfhbqWoDozv4W/HawrpP8LdCbeN0PsHfitc2F/UT/Dl6dQn+HJ5Ygr8Vasvi+gR/K1W3wqRP8Ofo
wiX4c057Cf7WHbf5o5/gb13rHPyt9LI5VXfwt65l843goIdrZsO6lpGhyjzOLl3TV+y3MqHGzmO9
q7W2FoYVtKex0mvZMLjJVOquta+9GqlsdQq91JUGCPOHAa4mzd/nJaTTFbjyEs5Qq5fwgdoD3MVL
SMfnh9VLuKG2+QyLl5DOTyyLl5COTyyrl5COTyyrl3DvaP2l1Us4Y796CTeUtaCrl/CBsv6S8hI+
UJs1Xr2EG+p8RbxC2aB09RLOO65ewnnH1Uu4oR6aTH+8hDNeq5dwQ9nL39VLOO+4egnHtZSXcEOd
r4hXKGv1Vi/hlrQfSj+8hwcB/aH0l9OTgZL+M9Qq/R+obQrKKv3ldN2ppL+cLvCV9JfTRaaS/hvq
/EC07rh1OVyk/7zWKv03lCf9N9T5gWjF6/xAtEBtOmKV/iNVlfSX07W1kv4jJZT03ztaKVulv5wu
kZX0HzlHSf+941YZs0j/vdZ2cbVI/5FeSvqPlFDSf8RLSf+REipGOPK9ihGOHK1ihBvqYTDnJ0Y4
47XGCMVczT/HCEeOVjHCrXN+qgdnflBVP9SD5zEUqx48dbiNx8VX/Xj/th49d779efztvQKT7TZG
FKodm1Hz8QBhAhZbobYLf9Ym0YnOCuphsAgUXauKJrtv1WQ0am5qrU27VjZECRIDHJs+8/GgMj9o
KCibxsf2/a2wsc0KtVVNsnJvVpHwG8reKEQOPEHklHyo+eplzuTSi48H9Wp/7dAryZjVkIam1+aB
XSNpWnd3rOU1c7jszJH2fDzoUMRZc461IF064M7Z3B05www2qyWPV9MMrxg5Zck7Rz4eTCA/i8fR
fDzoMJNNYb9pHg6rm20khb21kpxblcBe08WeozngVMQ6XLwKh7qky0M5ShofDxoYf2rsrWfY2Hoo
tappby1IY6fZPlLy+Cv3cUfuZ3px7HEdUcv2ZkHYLvxq5+LgxceDwr7VzeMv1uSlAm2isbdX+fRj
oJri8OSRjwe8FxrFxYt9cnHcNXg6h48HMGxgIHctWElogTJczim0kl9+320HtGVzHg+eTNSPHg84
WOBo2T4P2DsUFv/dnyOrc9Kvv/ztWyv3eeReV4r3SlLnEz4rnY3x40pbYjEsXp1xpO5CrRbPQn0R
rx4xEeZ4IMs/S3XU/09FExUpO0c8nqb/W+WTx28/NshUqtTLCrU5AVGmUslV2gJlHYo4XgMhVu0r
1NNstFlZJ79C7Y0f6NzCBkd3R86JRjQQ1Tdu5p0jAWtmu4MVagsQ4wuKp2X/G1kQ2RvLhT3s2WOx
DE6AXne0Qd09Qc3bESpg9Na/2VE6MQ6W0no7cpq03ICrHTenKbI97Kz+jpwmHQoLzdcdt8xg8ERj
lx8XL3YCij1pvDYnc06+T2eN1z5et3OCBydvOXjRTRuV490VJbZMkCGZMyV4lGConGrqmgv3XGQW
AhcJ6s68ivgX/FU7nwLOvMohpY1DN7q7I1y+BrOtab9hXwObyA5N1b2KqryYSmFOe7t0S695ZW94
J8QWuKWG4VOVozDB1loDbJQYdN050lBhb3ec4Ggw2fDpNTnlN6bSvW9kCA/vPneF/V7VwK6hUuS/
Qm2PgVdXxzw96WBXx8BeDXot+8yXOudE5jk8el1dHWdNrl6Vro4jckiEhxcd1twhai4lwF9gwt7U
N25OJrs6AveZPJ7ICDwSzEzVemJ7WAwcS8tWxh5ecGsbOxDpb3xya+FDGtuxNaQo5PusOWcfLsAH
qZq11O7OLzuQRo4td+gl/RoRg03Xikq/RqjMWr3TLhw1Hlv1rWiB/uoc1uPyqnR1TJl9sxwLw+YW
WQTSxb5whDJ89+mdtowgQJwZXesuIwjg/eTu4tXKV7N857RB9xdcoTx82ndOOy+5aNrbHKLRGZ60
XF2qsrnFLNYq2CBmsh1QmM21yDKCIFwPxGfs2ftx9BkM7e3jKWfJQTNFl15Vem/HnF16Vem9TbfD
O+0qLchiScHj1cqu2hwAmT2eYKMMXjNpT2Hr18hBBZDsGVyoxrbulX28PUo0yRkN2fVNpKsjApCg
drQZr7V3aIAMxeqeEL20pFlw638Bg9YbkykdE9pCZIpqKi6xGl/mO2iq2WYb68bZW7MYZW974Cd2
wYOj4JqERreq5xJdJ/o9/C1rE7q3YZThb0WHTBslruFvLU5PlchkAThypbjY80a0wP3SJ/Q0WQCe
jmH6p8kCfRbN9PuIOLJgqM3/RjZrhFc1XGUPB5TjkUctLva886HNDv5anINT2GTZ4a8e+K5TOaFr
XeunUwrikwb6WQTdjvHZPW5ugXLGza1Q53FzC5Qzbm5dy0Zx7JILR1WvtcVna5zdToezTCr3sJcZ
5HD0hqLX9sTKGeQyUMujauVZcFa8S4l7Urm31hpn31Dbg8JnUrm3Ix+kEtDS2G8RNNur1WmoutXD
ghKcgTNdekEwGi9W1TfuiR+fGeQO9hL1jpiKPsdtUjmtOiLR4a7FqZuhyHX1gv1DekhigUpSUPYh
NvNxAsfdvROSKQWjx6G+ceswwgvyWHMMHkdLPCuT5FyqiuJN1ZdaiWehBzVHb2tR8aYy0nSpynh2
NklAuKFsApxMKSicEevRi/MHKi2A/kb7oBA4BWO0XrxvzLG+Zue/Hq+yliLmMFPwvjHDh0uwZ0NB
bYmyiBEQwhV92nsMCv7K5TLGZ7zkebLKo9z5hPhwzeZ9zd+xwejNHJK/Y+MsFo5GUWtt9Y9sD1lT
d6VWJpW3nnJz8RqF0VIJwcULnAM6SLKmsyNihMZXBy3bDw0WIY2laM6xcSMH3LG/bff4q0Qadhll
5OAlY/Co5JRe3VJN+ZjTRqrV3ZEpD+yTqbTcHl3CIpcuD9s31Fa9yYqeNGIcntTKZIGrDs+R2gLO
yRlkHZ7UysyAyhGw7jdCm/CB33gwW+tEuPbwtrUMbd845SZktOJJLZsiwtkrbXq8yriRzp6xyDam
4nTxVNky1JFamS7e4bD6O6YJ34SOjrtjZhf5Eg2v2qRb1uFlrOjyKtTuSw47eNLBmQET9sXXvmyT
h1MsWvtu8Sxv91toWvtu9IJvUmLsxeWcOmU04tA+5jYlntPFSy7aS9vaaU62H63F96yuAXfS+tXh
rxZ535tDdrVJS7zvxTkGT7Ybx+oWtln2qNpYmwk1EbRXuwWF9cX5I1l94x4Ups+zvIN945So3Lvr
KbRW2Da8Z22HbOALbdKbtH51uLD1xolAIz3xxPfNLceT+fpZWDVOhxPBDnAUoijLG8qGL+vz5TgJ
f6S6KaHI540T2Tkibs54HeE4qQg+XyLQua5Bx4ns0hEywi1ReP04+2sNtx7exeW309/329tz5xqs
nekLtm4zS3XE8rX2rHhF9s7vXKDSt1/Ldp8SoIkDfT0Inb7X6Wb5+Ns2cOPYlVJDVVy35RIjCATL
9RBdTuFAO5icoHnAUlgG2nWpUlmgtiCQ3bNnMHy+PWommJwQc/bOgeEdNkh1eLwJvqSTnr5ZCyq0
wDDptfYgsMJlDjkXj9ekYz/HMyV3LXbsr3Dou6cXWATP+aZ6rT1LmPN/U6uuDHAyeYbtNfSy+XVN
BiaO6uoFTiaHIpxGEz20hsSGYXZP6qQX/wT6asdt+vrMnPd+PQLfa9kwilmLmrn2t8pAdo5aPVpG
hUtKdr4ugI9kANJg5/cF8I3UQ0Jc/7oAPjJEzswneV8Af6C2enS+Qn5dAN9QW2yXwc6wg/6OjADT
5CgOj16s6IZrN1xVIq+QMADanGw7wmeDG1xS8hg1Dw6XLrVUTzSyJEmm1oMP1eGzhT5dhVOCvIXP
ODwlwfp9BPuhuKqEpZJJbpM9SpRUYPA5FN5TXghAXohhr3ep4wnJiPOSr3ep+xttDFXYRDnm3F1K
wGcLKZUWPL6X2K7n66bo/sat506hEarlyS3QEWDsHHDiODWlw8ftuTWfXowTCzz56e7YJyL5/o3L
wLdKxNVdS9r+vghzjOPurssgjfhhOcKTy6CjyVCM/tpHnMNflqF3Hr1kAl1OqbrnWJkuypFkxZMh
iSZjLHN6lOC49AbEmqtXawmI0YfRJlvUxu48bU7tcjxNoIvwAnLyaC/j0nFMtT9Q9VvntII7K9tZ
aGn+oXN6/TaMm7ZI2xAAaGupZHK/lnlq7+LqBcoW5coL6Pth6byWPIK+H5bOeMld/JVgfoaSSDb3
6J8VPo7zHJM+K9ObynGaW5wcs5Vrdc7BGUggv52mq4k4CW9GTltdoey9VuMk4pbHjJ4sN5bpcRiW
Pgc72Y0zhmEzs087zhjm9XfyZFkiZCiZ4WoPiZChurVfs907dPYlYqq/p2NkIHuZYRQXL7h3k7UE
3ZN4PojiV6VK87wjIpVXDtizejt2jlqqo2mZ/fmz6ZPh/lF8n8IJ8TnBx3CP6AKmY5P0GOCs8BKt
r1B7RjpilT5FlNK5Jb7My4scZrjitU18gCLg2GONvY3aOImFU9SLixdn3CWmoq1QW0M4XifCuw/F
3ZETH0TvKqhteh3TUII8FdxQW7M0VhXAXg5Fr60hHJ86OdlV4bU9m478iq00g9eWuvsZ2+59I9Vr
yaMUjyf41MkpMjV535ioXnutU5321hBOolzwRPJ4ldPrOhPbo4uXDGSXZmnrWg8T5zh/qHV3Rz51
tto1F2478joRbrXmwq3yi6PWG+fJe7yaqCzfCZhn6WBNF6e/MZHifI7SEK6kmLWkbam7d5Tr0Avh
CqiRhysdGeGKFKYqqu7ptlegy/TRhXN+aDJzfBL2H/za+M/8mmjPXE+yGcoLAiBVvTfUpsti/ppe
s0JtBRnxa3rNArUnnYDCqbHB4gL1NMSg1TL1WnuiSGDjNNbcrmttdf0Ms5skzC9QtscW7x6Zqdzc
HakXW50iKecdpSYZzsV0KcE7wjiqxn4vtchM5RG3c9lxa24JFzbVEZK742Aw3jk0fl1r6yQwwUmT
o4Y9nph87kesFD3s2SgzdFil6J02loF1ho/SPOwRhcM696jX2u716JDCuui1Np2R+FzWcikuXrC7
CVakuXyfEP4XuM/d5fvEocsBhiSrHbemm3DW3pVlDlV53whHxdB+a25dPkGvB8VgPMgjpIN9j5+g
18ELlj6OUWJ1qTrSq0KISvCh+NZSWtNrbQUZfGupfQzvhHLgWwuT9L1vFK0O9HvyOIfXlxkB9Kye
PMr15Tu4dXbMUiEYtDxuF5OZmr2GrLhwu5i8Z396O96zP71vrEwJhoeR3G/k9SX+Omv+2jovMCCG
MvTx6p1TiZum1359CT94stDF0wDs4ZYhSK15UDLVky519DhHkk7w5dHVE/CdXgiwkj6h/foSeqJF
ztl2KFESk4ewmOYvex2HuKEFade6Qm3Xl/PVa5Mn5+Ubt+vLzva2NWeXEhX8las8OZ95orAd8Gjy
5Ox8I3ROkTd6taPtB8crR44Sz+43Im7oAubpCUlN4Y3W9LBnsUJo+Yr/jhxdmYIbi1yYnL8RwQBf
T3N0z1GmetbBGRvON1ZOVYeLO12qvksacp3ujuJZXZXzZ+sul4mQv+LyhFwm1lqba7el8AGmITWP
CyunqmOp6sqjXPsF9i1Q32ivaDkvPZfxDb06r0/gGbp2SGZ/Qm0aSbNrcfan1Kd62L8v9FJ29Rdr
HwaOSEvadkXE19cUqznHaaHGS3LTXC+NaS6lzGY80S0ZZnLkZzfe0HaJx9fXeMV/R9rzEk8qn5KL
l7zRBunNcpbaJm+0UNGuB4Mg+JUDbHzwpKPRs+rgMDceanzJTUxPe6DX91em/ckU/iyQO85qYPUA
c+HlCM/TbaTOKnZxQo+zLVS4d15rDffOeKWrXYxcEZ2hWD2A2Eqcl/OOMGdf+avpONEhwpyxDZq4
9seJNKzSzyzkU9+4hcdUSiVJ/n06TppgG7cyi+TfL3jZqysqpZRiL+43DnmMT0PvuOXy8zG+5DHd
b5yg/Wy5KZ7YZxkwIxtwGvstkJufzNQzXvg6iM+UtmTnE1qTPZwdYc76aGVkd0dm1UFip6LX3rSI
imS0qb5xm0ZXyF+wLtWj6poSslB1qwuguinNUMLWGIi6gW/c3B0bsyNHLVrSthoDKqWrhd6y43bx
1l+tx5aDx4WSXoIYWeuJvcYAIdosPepztIEcL95wmFnzlwlDWWPA2siQPZ6QmvlcJQPgjL3UzI+W
pitDVzU8YoniUVUqEQI5zKMEKxG+KlOdHcGrcLxK9bEv5VWYLxVdqAo3LpceiidpUmMw6nWdcONl
AyboL+j86yL8/I2c4fGuTHXo1TmIu4+ePS6UGoMwprZpezV8etVrcoWHF2sMcJjDlUepMQjQ0Rpq
q2CHTRsja+nYq+E5b+Z9ZXKkRInMFH9fmZwnRDHce+cJnG1HyYXvp2W6Fpl5KIEDLpLHhVJjELGh
y9ES7o0qBaXLjjaTo/Hqq43kWgXJMBls9eTxquSOMAvNtdtflQjZx+uqRIhG0rbcEdi0yYJYD+qr
EiG4UlvZ2ahNSfo9S5pkhcx+BdEOFDiHQhQ9SiCGg9fxvgw5cqFUIrQp+WpnLpRKBIhQqh4XSiCH
qKq6toMV7CmwRa7HE1LBXiHaruWT/A349oZe9htZwQ7uit39RuZvwCAXV7brYAbTkJr55Ru3/A1e
ms6cskcJuBKsRSrF/UYpdZ+chOPtKKXuJdfsahMpYp+labu91RhkdvMA1Zp3Qo29gWYbRufYgKki
7igjJNd2sIid3Q1NFLCtNZg4P0t++Mbvw6rWH1D4WVjVj8FE4NCwGOVwbqitLmDJLrihtrBqyS5w
oJbsgn5iLZVd8IHagy/eCKXZkruWNLkoQQKAfmKHKE0uauzqG/chq7wR6tfLaD+xw5XnPyVFc8Fr
G/7GG6EuSUMO9nIjNLJE7Dde2ysab4SadIJcoLZy6yUH4cZ+a0XGGyEwa3e/cTKhZtSWXc5h1n6D
gUwuVZnPkFsbw9tRcvvDaHrHrZtqpCj2khVVt3cVdv5tQ7Ljz/RKObDI+JK8I/bSiqwhknN5IrFn
BpgwDo+j5a0txdRcnmDpNhgnd439FshB1bM6Pbhr8X0MzpJea3tPlA7gMGrVpcQIt/k/U4KDCqF5
jWxva9EgxKrlce9kS4OQpGzrzIUJjhBkY2iq7nOJ2E+5zTE97LNMvXk7Cee1+IrWe+guveA9817y
cvaOJ8RXtMahBsM7bRYBdOjVoWT7xzkbj8wr3Tj/H73kewZlbmRzdHJlYW0KZW5kb2JqCjE5IDAg
b2JqCjw8IC9Db250ZW50cyAyMCAwIFIgL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSAvUGFyZW50
IDYxIDAgUiAvUmVzb3VyY2VzIDw8IC9FeHRHU3RhdGUgPDwgL0cwIDYyIDAgUiAvRzEgNzUgMCBS
ID4+IC9Gb250IDw8IC9GMCA2MyAwIFIgL0YxIDcyIDAgUiAvRjIgNzYgMCBSIC9GMyA2OSAwIFIg
Pj4gL1Byb2NTZXRzIFsgL1BERiAvVGV4dCAvSW1hZ2VCIC9JbWFnZUMgL0ltYWdlSSBdID4+IC9U
eXBlIC9QYWdlID4+CmVuZG9iagoyMCAwIG9iago8PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVu
Z3RoIDEyODkxID4+CnN0cmVhbQp4nJ192a5tu23l+/mK/Rwgy+oboFBAxc19jnGBfEAhcRDEAXLr
/4EaQ6uZpDjFs2+OYfs03JImxZ4UGb8C/vOPEf/TZ/r6v3//8d8/Hr2uv33+/z/WWgr/IX7xP3/9
5ev5m9/+9uMPv4Svv/2/H/jRjJ8dsX3FUNvXb//6499+cIH1N7mn8f6rW7hexlh/OVu4fjZwp+dv
sNM//frjD38JX7E82vo1v379tx/xffbZvnoN+evXv//4XyHk+L+/fv2P619jaI86SupFQtW0QWHt
nmseSUH1HWo8RgBcl1BlbFCpPSa2bFVChbxB5fgIOZQS3R1zfcSQSlTfWP5pgyr5kWquSX1jKRtU
jY8SSsv+N9b6KL21MNzT1/moZdSR3bVafrQUap3u6Xt89B5b87Ha52Om1LuP1ZEfcxZAqHPVHQr3
2GvWlGN2nP0RUqtBY3VqqBRwj3OU4e4IJDxmnzFVb8cEKow5pKyx2jaohHsE5uvwsJrSfLQwS2se
vrDVo41YiksTKXdIg1xi93goFXxjKHX7xj9vUBW0molWFxMtPvLIXX9jjTsUqDCDDKP7jR3fGPCV
0b2hPh5l9OLzdhrt0fKoZbr4muHRIeSipol9rQkqbOCR7J0rh/zoBYQ/PUzkGB9j5tyjd/qcwgNi
oUxN0X2HGo84a9O3vWM15/RIrdeuqXA/fQmPEkcPGvd/3KFAX6WN5NJqhvwaWGs0D/cZ8mvM0Ev3
uCO3AkzwYC6+egIm0pzZPVdvwESZ1eVaUPOjzhw2fO07TshCcGNwaRWCC3K1DP2NdZNMBZQza5o9
eTuWiG8MJbTi7QgF9ICQ65qid0wUSCZ8+H7b/2eDguZrJcypafWPO1TBPXaoIwX1lx0KtFpBi8GF
KtR8EwhzTw/5VSgL9Y6bFi2QX1ChtQ13x9oeY4y+6dodE61D10LgJ3fHXnnbUZ9r56EyEm87aYre
qbBAMqUR8nS1KATEA9ZE3nC/0UQN6YF/LVoy7fQFIfhotbSQvB0r7S8ohZbcHVOC3u5taExseqjS
skpjaAtml77Q/g/YFDNrWt3kaoVkyhmi3JWYlTbTSLG7ErPSZqol5uHJr7psJmju4X7jspk6TAF3
R1DOKDP6Vm1dlhUsYI37TWJW2EwBGzbXgqmQTAlGxXCtxxZAhZCXmxZtO1QHJkBfrlXbYgUmSp1a
FoYNKnXIr5ynK31bbrC/YMG4WIXseiTIy6Hl1593qE7bBIaHuyMoB+Tc0/R4u4EmQqTZ4Z4L0iTA
JI+u/ILKhv3V5kaFO+4hTSpstOZqvrasoQ6D1aOvRmsojKml705fbVlDIYY7++vPv/7EB+zhjvV+
+mPLAUhHhynAHK/xeaR0EiQRCpQifKE9nZAQoUBzL3EpvXRCQkzlAfsZFodaa3dWYXq1DjJUpzdO
Doz2Wjt+Wu24kVYEMQ8sGNS56p92KKhZSK7k4wtKL80Eze1iooUHzK+yTInzuaTreMaEdB0vqD0E
IF3HdCJm5Tpe59oYAxf4yCkNvZY515xU7HO5x9dau5uwBFwNG00Yp5ACrkVNE+EvO9SEqB/R/0aI
ZmAiRP2NxhVKDHOEvnHHfq7MMEecQd122UwcOoUx5BCTRznLKYRqjNM9Vx0Uz71VF6sNVAgxuFTQ
BbXji64j7Oya3W/suCGYCF1z2u6QjwqDA457dKEm5AQsK81D5oagQGFG59E8+sqQTFAaIB11+rlD
DRjapfTg7Zghv8BCJQePazPkVx8j+/IrQ35NGJexeFjNGepsQrd091yQXxHsMRXUrmZzKQ8YtT0l
d8cKiQl3r2iu3d1QGGizzfkTfD1dx6fheJRfGcoYDn6Y1ZNMGcoY7niKw90R8gs2SezTvaGngxnz
dG/o5WA2H1+QXwMG2nClyXIwW4eR43FtARXCc5y+lFsO5pxhFI+il4MJJ7S49FXShBGa4qYV9nPB
wYzwE2L2oQYNx6L1kNkRxh4Nx5E8yVRg7EFWQCW7WAUV5tpbU1jN+1ptPDIFa/LkBGTlozRY9tXj
oQLK6bjuTfPt3wjKmbA5evYousK0h0LbdIdxTGhZgf+ruqG0u3sxU5pkn9Nq7AxXFZ/TYFVB+ram
Oc04cpBMZcKd8HeE5mP0eLO/jOsIWQhHJGnK2fRjheaDqojaSovxe/ZrrXciFD/2KGH9yvXr/rd/
/eXwD+K3IvPSrNncPqS5G56BhicItEsoE10Hwxe46os0P1B1Nyl5bTU+4wIX1L4WWFmvY3YrGQbs
KFmdaVfRzJDcQN1kSCBou95wt1/BxTdL7ZYpuDgQU3qtjUZgfoDziCsJZe1XWKagyQ0RO0JXAIhg
7rkg/+N2KmOphBUIG/pUabfsQLk5GGIwKY30Hagc7qCMXQrpHwxh7WtBYn8DihLbQBlM4K6buetd
YtPihP7asGqSKB1yfW2pvnFPosDxvoEyCQac3my4myAUxfCjNFKNCQIlXnfS2k0eRpLNSmY/qvC4
r2X2A9+XFuaG0j2mvuI1OwkaYwYuiL3pPaReQVuGq/eQeoYHYqHMhrT9at+OZXbs6VFH3T7R2n7d
Hj7txwI5DMsYm8sD4XD3ibtrAda/OfweuY4MG9wyj1BaWmuU5d3tXwrwsCB+Z8J/hoPEiYH+cm3L
L/1AGVEP2wLm0zPwdoZK4VFyfAbeLiiT8AdzDHhuSUFtIUhGWjoso6ygrKKCvVnSKEFC2fQ7A4Jl
RIUJI+sb1FmrMxV3rcaAIOw/jYldqfcA5gYiqnt6SC/Iuba86gtqI0RqKthjI2h87RqUSXpYWamr
tXaoSaETQleYMIliBpwbzq8wYWIVEHIlJjjqHr4SxByEfVoJoGtHE2kJ0I71yWzHG2KkpQ/ojuzh
fiXpW48brd4l6eHehephlfEY2PApu/SVCvQ/UK/XCnuJQYUnHOcz/X7koZXKh//Xokc5Szu+/b8z
JjqsiT67Pv0upaEQHj30UV1ahRUE+hqzdHfHycKgWae6obBjFUKzpZDy9LDKVH6Ds685zXjoTOWX
nFPyKCfHyWhl0fxoks6pM1pZu3vbcLBgOdLAVGvtiiEzYlabloU24c+IWeu9e7TKVH6Husrd/UbG
Y0BfLXgSIDdI8t5Cqp4EyJ1x2w6Z6dEEIy2lj9Q1rZpIC+O28ExduboiLSHmDV/7NzLSUmGNDm+t
FWlJpeTh0eqKtEDvbFLuLtLC6g6tO+4iLQyOuNxREkt+Rh+uTmOkBUw6ukurTNLnMfDxHneUwpKf
GVN28cUkPdTCJldNPAb3OPIzmnSk+wL9OHJ5RpOuc+0xlJ4Zrdx0h8EEfTR4q9Gl1QLJVBq+waeJ
mYGJVjZpst/jxDeCIur0vrHSZqqz6nvcb3ul8kuA0vLOtVL50KJxenS/Uvkt5+Lq2spSSmhRbSns
fmGl+9+wVPdwXwv0dizPKNf5G+kXzhpb8yinQn5lamTX/loJ/zhSmZ78givEBHaJxaMJiHBIgFo1
P9qEf4FW6GUqqN1CrgM3BB2qpdzuXFVovlpGD+ob436uOaj5msaXTfgnar6m8ZX2NHdo0AqlDld3
NLoeGWrIxUSLjL6NGoZHOWBYJsOfJXjHe2yMOwz6FN4NtQwvAAKsuzZAAxU2Cqbp0WqDN8qU3+ZR
7ClzeKNhhqDxZb4R8quACqPmoX0tyK/aZs6uvdpoWSUo/eFigpZVj5s02a1tJvwD65XurLRvJPzv
CO5bCX+g/0BakcHrHicV1QVlkvRQswkGNJWLgLqJb74T/heUcb7oYJa2xI041+58MQoKh4NX6OzI
4HXvk7VwAmruUB1sPcf0d6SwzKGW6O4IMq1wQingxFomqtrBioyqu1htDY5JGCO5+KIbmpnede8R
YhBUOrK6IZOkH+mRIaO3b/zzDgXTHu64vqG7WvEBq1Z/o3VDYS6NlvxvTBBwAcyjv9HUnYta8fM3
MrBKK05/o034M9UKS7u754KbgO1m03S/u7RwEzLkbtdUaMKvEPURTkx1oepKteaNoo3ruKp0YR17
VLgS/riANlyo3lhG0WZ2MTGojMNyhc5UmAaVMdzf4t7QZGYiL1foTIUZkqn0OJorAVbCHzboqB4V
rlQ+JFNwMcFUfgxpoy8bpx1wviDlikerq1YcUq66mGCteJ499e7RKqO5iVLOPxfcBPx3brg34dz2
aJ3lsB5FM+E/0owa9+ZcoK8e5tBYNc5qT4/ZIHOSiwmo2QhR1/Q97rcNyUSlMPx7nO1RwbPRxVcB
fbUGxzd731ggv2ASzjg9KgTDAhMhaG1l3D3hYJ4xwVR+xGW34GEC7PPIOeThnx46LcEpTNOTOW8H
U9Oq+Ua6jhOWdXOx2hjmSCl0FxOgHJhxObu8Dc3+WEXg1f1G6DT6XiF4dL8czArmru6Oy3WEkB7e
jqwCh1s7W/G+sQaYhDjVULg3zgQoBwZAGMHDKhP+s5ZQFNSebluuI7S2liamqjlX6FqIAFfDVL6v
w9l9mbNcR/C/T4W1Jura5bY7O7JIEu5l0jTxlx2KRvvzRYzYcXcwYTPB3JsxepKJrmOEp931WvsN
jZWojdvp96KGCW0FXzW5ds5yMFPfrKE9kL5cxw4DTNOqqQIPlNE1ubS6asUhAPRa1sGEJIe/tEnf
P37Pw2jpzoj6nmOST0IphvxYec6qoHYTOkYYCaDSpKD2rBA+D/+aF/vk00VHmISdj2GGCwX2mTnV
qk9vclow4wbdbAW1Z4XWU4u56rEuqLhn0cA+6eWBirV294XsAw+06XPd1hizftj9xlVjDLGkT29c
DtYYP5+TiLX2exzMDI+g8WWcHNYYw+LT92icnAm/HrQchkcTrNIAJ8ZYvRuCWoTKLkl/o3VMrkpk
cS7jTPDBT1u1ls6Oq8a4z6ppdXdyMh/8wIge7o7MfDUgqLg78nkqvPKRvBt6Pk+FGdddrLZVazNz
cPHFyEtjtY13j/IRq4AydSGMVde5faOpC6nMCwd9Q7YuhLHqmlLy6D4Hxqpb1vdoc1qVUfscFJQx
VSNj1cxre7jn89TReq3Z49rlmODKoyuZlsvRyygKq7uiWs9TU30aL+dvXDXGfeXRnXPxESvMkqG5
Y5NfzxrjtHJaAsrUGMOtinnnjr2ggzmtDiuqu+eCYm+wJIbGhHmeGmlUrTclzlqDFUUg4ehR9HJM
RqpaFtr8GHRaZfWzJ8kLqLCuAknvXDAGGS/tfXo0waeuM6YZ9I57VoiOCdMc/o6gQr6ama4WLaDC
wjhH9qgQWKfbXrKrFQqosM2StaVgnRxIk15DSZ4EoPvSIcSy5tr94SkzX70nrWuN8wX6giOXN/oy
ma9ER241UzhLADomFSZomh59rcwX1to4zbgcAQ4AtLvaMf7pe/ZYDXdiDz8Wvx6zTFx86+GLz2T4
q786o9z/029/+7EurUxYh4Vq4dnoBPBjMvpA3oSrtX5BBT+Xuv0ntVRlHxYuxL9iqGP7K0Kt9zDP
v+orjKb/7p9//PcPyCwYE0Dp198Bw7Yvzz/95+tPTGTzT4STv39D/fuPf/mHr/86d455QPj0UmNM
X/e/ZS3yz2CufjP+vcVFYD297i2ZqHz+FIddUHtiJUIEvIvDLihjSPOZQS1jRTCutUzZF4zyllvQ
ULvJB7aFU9iXmLt23E3kSnMojKZO/92USWQFzvVjP62/iy6OmYB5ed77twDHYLTSNNQefU/pwUpG
4lhA7QYz33KHskotBNRuCkOAUjBVtZYxq4Fj8GNOaq24n4tJNZY0qLVM7oBvbeFJ0lS5oAyF9PYI
qyRWrbXT5DLachxqLWvus9gKSFVr3Zn7ARcd1VpxN5ihCEN89u44YyKtSt25VIk4lzHRgXt41KRv
sZYp3Z58Ird6UTg7FqYE8yqkPmMiVfblKUuNn2+IzwBDAuOptYzB3Pl0r4+s1rKlYlRxINWmdtyz
O5CHgQGU6FFhDsB9hu2t1ko3RWBgrDajR/ern8t6HuFDAffwvlP0uDZn4D6PwNzB+YZo5LJ7BIso
BJQp3GrM24So19pNdJgXIK7VOcms9ZZmRyGUe7lB809/7Cm7IALu8a5k1wfKcL+UXReUJ7suKE92
faCieYAtZNcHypYFC9l17bg/J5Gy6wwlZdcZSsqu6/TmOYmQXR8oW34rZNcR90p2naGk7DrvKGXX
BbU/FZay64Iy4QUhuy4o89BZyK7r9CZwIGTXtdZedCpl15EKlew63pCSXdeOu5MoZdcR90p2XVDh
m3xNK9WQ+Df5unzsvpty/w9ff6Bcvr6gTNBT8PUF5fF1SQeqUXx93lHy9XlHydcfKBNAlXxdjpam
5Ovz6SVfH0+v+Ppaa+dFydfHb1R8fa21W0GSry9M/Mnh67KZxfd8fa3l8fUFtdtKkq8vqPY9Ek8s
SzIH/SZntGNqQXLGB8rljHYKdyjOaCf3XXFGOwUMFGecd5Sccd5RcsYHyuWM81qSMy4o8yxFcMYF
dfOE8sMZR0wozmjhRM2SM9opiKQ449rxpobnwxnn00vOOENJzrh2NO04BGe0U9BNabwjRSuNd/5G
qfGOt6003vFcSuMdeUhZ60eKVtb6ddvmMYaw1q+1di9CWutHulfW+rXWHiqX1voZisFACgB/rQHc
l7paADnnmunzOFrg3nQ5BO5Z6jc93PO9In50aFlouxwC9zWmptfazlUScF9Tz8U7PWtSWD859Vqm
cQRwX2tr/rnqqlKIaXg8VNiYZL0o9aQJHyqExpN4VMhwbWBXguxxGltChJbmGB7uV0uIVoqWvqb1
QgDuW52xe6evcfD52urTbNb6qSqsSS2+adDka1CI30OMig10Jk4WJZTtCh0fdeKHk4IyPiNLzWtl
LeMFZTQVexeO0JmiEOcyerY/Jmukm4Qymr2yGjCuInJxrr0KFtwPKl2PHp1v5PO8FsuSN9eOu84G
9zM1n6P7jWw3QqQqfO0tQviws5c2p7ohozfCava0mmOdz5VAWzn3XBW+THsp1srmtB5iODuyMIKl
BdPdsbDrZZpB4ctYxjXzGUnQ9GX0f0t8WpQ0fdleyIxsP58DnSk6sZiBpKrwlUyyeTzaHH2qc6X9
XLM/CntCKXzt8cEc2LTr+axLQJkmVJCDA/JXnT7u2iVlFg2sSrnzufJqoleeevb4jXlF72fX3GH6
ENTw6QAsoPZzVUq4EDVN7BkKNg+AAEhD87Z5qNge7Exe1en3GDvTtZC7q5Oz2HG3XmCrphL6yN43
8gkirJdZ9On3lCEfr8Icii7uC0tEXilpZ620GmaU0l0oWEIpthb16U3ytC/bvk/vhqhnR2hP6+WI
VerZBvM4xpt7/KkOKj3fMOg3vbj5Pwp3jngK6EjnT0DtwQDh/Amo3eURzp+AMm7d5fxdUEZFCOdP
QJlGPJfzJ3Z0UjVirR0TwvlzTi+cPwerwvkTOxrVdTl/5x2l83fGhHT+Lqi0qVTp/F1QwQmLOFDC
+XOghPPnQAnnz4ESzp8DJZw/B0o4f2co6fw5UML5c6CE8+dBXc6fAyWcPwE1vycSctFo/l2SJJ/C
ZEqSnKGkJMmnUKCSJB8o+0RNSJJ8TNJLSZK/E2AVUE4YSexoetIKSXJeS0qSC8oJIwkoJ4wkzuVJ
kg+UkRFSkhxxryTJeUcpSS6oPSgqJcl5RylJzjtKSXKtZcxbIUnyMYgsJcnxtpUkOd62kiQXlJM4
ETvuJqmUJEdMKElypHslSS6u/V2SZGf2b0qSeqx+lpLkDCUlST0FTpQkqaeggpIk9RRoUpLkvKOU
JOcdpSS51vJskmutPWUtJckFZTpSC0ly7Wg6UgtJUk8BHSVJrh1391BKkiMmlCSpp3CUkiQfKCO7
pCT5QHmpGkFfniS51jL9iIQkuc5l+hEJSXJB7fJGSpIPVN6DolKSHGlCSZIjRStJcuHe1FsLSXKt
tTu3UpJcp98LQ0RAWqy11zWLgLTA1y4HRUDaOZcISIu1bnonvwPSYi3zlPIKSItvvKlYfgekBdQe
thYBaUFf5inlFZAWpzddeK6A9FkyyYD0GasyIO3sKALS4htNj+IrIH2maBmQds4lAtLiG/e1RED6
DCUD0udzyYC0ONf+BE8EpAXlmMeIwH0ba2DTmb7YVzj0Z1dPAbVZ/5Ud3HpcHbbO9FX5dJ7KSq2V
9+ePHCzSS9fSdx+hWDtwz/J6LZn253yDvbl7y1oy7b1nJltszBiie64J3POZlFprD4K1ANwPtkH1
cI9z8/VZme65WmoMLXIIpaScDfeNz0VHW/20xbn2zibrvVtf734E5ZgeL8D9mGvIkjjX/mSxJT4O
HsmVTK1zCGFKWvp+145rWoT+PjuunULNyo47Q0k77gNl0yLCjrugzAtCYcddUGbiibDjLijT2kTY
cR8o279Z2HEXlHkbKOy4a0fTjkTYcefTSzvugvLsuA+UsZekHddOQXdlx11QTmGBgDIFd8KOO+8o
7bjzjtKOu6DMSz1hx53PJe24C2q3HKUdd95R2nHHtZQdd0E5hQUCam89Ie24C8opLBCUs59L2nEX
RZsXccKOO0NJO+6C2q0qacedTy/tuOv0TmGB2NG0OBZ23BFK2XHHHZUdd5RMyo47yhxlx13numl2
8bHjjlhVdtx5R2nHXWvt1p60444yWtlxZ6xKO+4oV5Udd5Sryo47fqOy4447KjvuvKO04460quy4
I76UHXfEl7LjLqjdVpV23KVrv6n/qxbHv0//j+NzG6n/d6j34vm4uLQLrp/WczHOFRu3P22Ha7Mj
94hLWozjUx/2vZ15dfa8oEyBBHRWJmFkBWWsiv6Iq3mh2tFYFRwWPcaypK+1TJyZXRwhpbqCMh0H
Vl+/yMGHAmqPIXE2VYNkUfgyJXOQiLGyd6yC2kv5wG+zll6SCwV+62WulipnfLHYAnyyUZqNDrVH
LjCwNb7uJpHlWlp3d6ycOROe9tUR9yy24LvYrClnt686+5yHOZu742Crl7baS51pld2qY2TrO+8e
WWwxcfhZPIpmsUWHedjU6U2X41gf8IfWUOYLarch+Ro/gbyme/o18Wu1hHTPVSLb/zwt8yOnsdii
gfCnPr2Z58BOzpwoq6BM72j2q+8jJY++1gyGtzY64wv2+5q+WTzKYbFFew0sPp+LxRalsBGdR198
z85X41Wf/m4oM0RTHB4/sthizUct7rkyG8zNNT/wLHNYbAGDLkcX9xyRDFegDJdy+Ab94+9cekBr
tqMeWLNjj8rHL/jjYMOTZrsK/gwUFv/DL5EPldPXr7/9VMtdRYFipXittJ48h89KZ2V8u5J5iAWN
VzkPuPtQl8YzUD83C1ghdIeWf16vzQ+PxL/1uHu9c795k/+Nn2qfoghnXMgFZVLSHEWW2PFZQZkX
4QyU9cEKLwG1u/Ds5so+mgrKvqWACGAfTXX6feynHPIqoMzL50i2DVQeYkdTL1qpFsKGid1UgIIc
9Vn9JKBMgosGWE4aE3b0CA3lurqAXlCmvpZTrIGIOd0d6ZwzTtEV1N341ldrpQvK1p5SNMEdUPgy
A51AObHlpM9lk2UZ6r2U7VwmWcbW6jA+kveNa1zIhKEWPMpZg1khg0v3vjFR2WJDOnWCO0zaPbL7
xJzdo2j2aR1wI/WO5lx0UsJYQzLEWjtW+zIyn4LsvCOM3xLrKuh2dlxTrFurwePtxPnU9MOyR6tr
EMiYPWePOxjWmSWM2rx7XGEdGE19etKEIz6oRUP28LVGfMyyAknOjpmdO58T1wW+TG/VZzukWTxM
vNshDcW15o0HQwswrHr17nEN1MqjbDSxJwQblVvZZbSBKktONFfm0OTjMOg0PTnB+tpUwxr8dOZt
HPwBB2x2lwoZbmILtqC5dr9HyBwOg27Ro4nV6Ki3NcjojFUOAoGIy2V45+IgELiHpUcPX6zVTXyQ
kLzTP9sh9TyTRxMcBPJuwXbGaikMJMEtqu65niNX1zBo51yQX4nzjpq743Pk6tDcYUZ8QFu9W7Cd
OY3tkEbuYbo0wTAY/ImUgvuNo6+K8aHl1x6eW2P+YNpllybmeBQWvLs0Afp7gLrqjJ7MWSM+2lyt
lc47rpAanOTu75hAhb2HoHfcO4rm8mmAKdYyIbXI1oMaaH8owbgbm45GF/W1THZwij147FjZ2r7G
NF3VwQkfAW7tJkzM7I7AVtp5EyZ7+1hmKmpdc8vPBF0HG9Y+Z/wIqD1HDMUHxOYN9fs1zvygPd+a
RxKgUii+uHpynZmDbVrDTLsZbTK2g4pvZFcAcHZHjuwD5hlpjU3r29jFV9qhJsyJWWv1BEBj03pI
nI0dTV63sHfX0OxoZmTQGGL8q7nf2CDkUhxD0cRupDU2rYdYasG7RxybDX437rCzOwYb/HatOswN
cUp9BWu7lNPm5CSgkJu3Yw+dk4BinTcC4OdzQOIdAr/nE46jJyTmgFxQ3hwQAWXa7V5zQJwdxRyQ
C8omywtfgkWGVsVa5nVgY3O/Gf1zwYqDaA7JP9caRzmnxpfxqhjK4cjQ6OIL9llJsL2mgjJvCDkW
NWQmf8W5jE/IF2qjtOTiC2KQqTkO0nK+cay0W9nwZULkjaOA6/aNu4cG+4wxZv2NdnQydHFqLVQP
q6vdbi1r2OH5XKBAjhkf+hvti/7EMeMrfSowYd4jBvY5fyoXB2oNwV3t5BxMgCbqqzRCQO1pAFhe
vbUS1emNr8oXV6UHppLEWqYYM610TtW8vfvjnN1RoIPUDe1J1hVuxxYhuZiYbOcca9L3aIq/V6Pm
FcI800QODFhz5rHacffQOE4bbm+tHu4zVCMsuVWfLaBM+SduqI8chrsjFGiBWt/u0fiX7F9IGva4
NheOcxurkOxM0U/PcaZZXHxxwHqLT6PqyNscDplyTrF6NLEa6XLmpuahPfHQB9VZaT4mOIu5wa9t
HuXkucLaXd/2Ht3LqwxuKS8HE0wWwPBqm5y4eZkJGus+b7NQATQ4evMouqTO8Ypz+ucC5bTB2anu
uTITD3XTotbbo5TroWSPVkvhOF0YaK6GYeIBVNhH9LiDszsgiLrWtWattqhwtOqeaxWvQFIEH4qR
ibzJL9tItzPVv8kvc0P0CcEbwdWPhbO+Z8+aos0kDdo5Lv9U2DglxPV6+8w/FZqqQ/9rOWjKNTKT
gDhE9Oi0stQPwtCXEbVwhlEuWkbs5nOt6734Mzp+nWt3g5i6zzVOVyNUDtNe1qx3O7XnBxy9zS6x
Ezngi8/cgsuxHOY4SnlGOK61zESO9JizPiMcR3lTJ+MNYIzgYZWuXsyzd03NxiFcUYnNejGOF6Pj
LY3q3iNLeEsuI2pZv5fdsnwKdnbQVsI+6DAz3sDBgx7ul0OY8L9aRuxlt3QIWZ/Q3B0rR1HWll1p
yWGOk81JfKw+3cbaXJuQ5cAphDbuNNXPJ5j0u4N+x6Ua4ZP2M+5G4HiZCIGqoMx79M8EExdqzY7I
Va9lGq5wzjFchCqhbJPOQoblJEkPioGlZ3tmAWXTbBUKr7FaU65lXCqYvJVaXUGZtiyfoYnyG2/a
siTYJVDEHiYgbvKYQePetmWJj0op7n/jwDfCW92+0aTZVhokRU0TplnxSoNkqA0HE6wnSqucQEGZ
161Mg+SaNSZ2d2Ol2WYbQ0GZimfSV+iaom0rNTbjTr1rWt2dksIxZ5xr7d1QKhxzVjiA0duRs0lg
cbTs7rhmkww2nvewyqkjZXJwn4fV3jnKLUeXctKqfGGO08UqK9ehfPXpt6qCo3RJc9ygBj8Gw2P9
yvXr/rfsLv8zmHfLc2zfrFArH8tof+wZmH1nJbGEupsEW2DWpCqh9mELqyqANdxJQZkZr+Wh17GP
WTlPcrB4Xq5jIjbxDso02KgsBOl6w72cgY6YXcrUNI53zbVc66bp8Fy4klBWBq3pO21DxI7QGdhS
KGwINa2J2UpLn8qGa/KjreyDhNoLSTiQNYedGAxHJUbmDTHcNJlqBqe2zSkceINTw+llNQHacGrf
1wfOBN93vEn0v9Iwcq27VlQGyoSkaKSwQC+5mOjQN32/IVsOMO/WMqGf8diPfhPReT09cQiCo5EM
3veWw5x5ZJeyTSEjnD7zfaZ+kuPtwnaHd0EYg6q77H1sZWOL22FG+1ImiMHxqXzW5COrrVp+tZJp
oMUZa0SVK9ryCDd8aAJW0EazhbnhfQ9+zXwDZZztAB1vJKAdizp+KkNYq3kjQ/agQ0qPYgSbKdW8
/cA9p53L3dHN6CHoprhTQ9UdiY1WpENtv/U8ScT3GWCo3EtUUZonoIw24GjR0mufEsr0ZWDKOo20
UPuBsj7DmjeXc1ZQph9WW5XkI6kdTT+s/B78ItcyUByEPXtVULYfVnkPfpFr7dqTL0qfr+s8fPHd
3MyzDLWjKc2DZ1E4eUvtaAacwLOYLbbs4r6PR2LaVN+QScNAa5TRR3WxynHsHS5WcL+ROesyWPkr
T78nWMJ6sQwb1PvG5X+AcePwbmj5H/BcU/POxbeUpcJ9Sh7uU5psMJf1N9oePOVROPNU48tof8od
MHj2cL/GsYcW8vS4Q5T5eVjlOPbBwa7ujo0FVj3pc9l2leHBOuTkn76vMiwWRclzmX4+LMNKeeNH
MxsRdlBgUYR7LhYDdjibwaOcVQwIqyTq098VAz7fzTvfyNcYscw6u/eNbH2Z4bmm4NHEM6UDdLlc
m/mqJqcypie/aHNU8Nl2Q3vHMiZ+Yuta5hh8MfHT+ujRxQT9DTi4Obrnog0KdGkNYxM/ARZ0Z0tO
h7eZ+Glz8A2eQxMZ9AVhsvG27SHCCpiRU3fPNVkBM9lIV661B/kDw+5AUPYoGuoddB/bdCVTiXzZ
kZvWQyYpAv3Y5moo6lAO00O1t423rYHCOqyeN/m1v3FhE2OYkL5cLZXl5iNu59rXaoWtQsdwqbB0
voXrcwSPJgps0foMNgso0wQctmiesxeXhwob6dbKweHejrMx6hlC83asgUm3zjdBDg9VWlYce5o9
acJx7PjC3ppHXzWtF71DywlzLkZjYblqfJl3rGxsDf1YqoevWmgl96LtCZNkgUcLpNacfKgBeT+b
pkI7aB1eWqtDy1WDCVbwRc7o9Gh1DVoHtkL2qHANWi/0Kt17HDTf4zNueIbiOPYBi6+7O0LmtFxB
YZ78YlpntswnGxJqr5QD5SRGdjUP7WsxGhtn0bdt6/w495Q+itpxr4FjNBb0lVwLBn7vY878E+5o
fJndcOcaak83QVu1Mucm7/cdWwbXsg7Ghepsdp5icW3MVcEXoDqii68B+uowdFwtyjq/BM03kycB
WOe3VO3d6X9emxfuLvZ7iaR5umiVSPpAGZeDj/5zZLWDhNqTLJHPsdNoUUHtblXiePHOYbkSyiSS
QDS4wxbU6W+is6wgacM9fWGgCo5JkVDWkYOhPcdcgnee2Do2mNA1hKnxdROehepIQX2jHXLPruMp
x+yeC2TaYSwN/Y3G3YMJPWEkqG+8e5gOuZWXM3HE6jORNMoI3rnWe60eSq0e7hNLlElf0d2RJcoh
paBxb9JNq3YqV42JPXjJV11w7YfCqp0owKYlsKmyd4+s4IPz24umQvMUfkC58H2xiy/QV+FjDXVD
dlYd1CzMpZw8KkyNtVMz/AT3PT9gssPG8SiHSSmw4zPNesYq6GvOOaKSJmbu3ZjvJhweJiZzKrln
BbX30V/VgLG26dI9Y8eJBpqLe9YMwtFpcXr4yqDVtEoLPVrNnGsBZVy7x9urGvDZhsehQjYRgmnc
inuPOUOy95mmKwszzLiRQ97o/ma2QoQZF3ysVpj2K/viyej1juzZyMbDfYNixwXU4u7YgAmo9ejK
L7YOgAnaNOXc1QzyRporv5bryAHOWjLtuKfrmPooxbuhVTMYRtG6w05NAq3WWYfibRNDhpQbJQ8t
o01DosQUd5zTxQSbG2UomBTc04NyUsi9VQ9fjG2nXntt3j3Cx4Ys7D12FxNwE8oco7g3VFqC4xuG
L7/WOzL4yNrq2CmHNYOQqmO4vL3ekeETgiu/Vs0gIwBafu2OL4w9MG3V97inavhCrLbBp0XOjjWy
0CLErG253eVgE5gZQWIe5awXYlBqw7WGaqbmi7m4Vlrle3m4HD14uOcTsQbrdbrW46obTLFrDbNz
R+Wrh9UXy9PbbLFZn424vG+k/QWpull8pm5wPsaoqbqWQuWrBwom/x5hf0FOZC2/rIPJl6Qhbby9
OxN8G5FjSa5WgNfFsHYtroxusbHy4hlOOK8F1xHX2JI+vakIZCu+3KtrwdB1hM36TPNda20BDFjH
LENqGqu7zdRoM5XSp2s9Pl3HMH3t/nIdw3AlAJ+IgeFD0Te0O9FP1zF2/4bYLCq1pLnDnH7WBxRH
2WzfjYc69FDPMJBdD6yztCK+AsOXLfenb7qh8Y6p8GPxiy9BQoRcDF9ENX9hj7/+8nX6p9/+9iNS
s7JnGLjxi3GQ3/71B3fjo7+QJ4casWUCf6X8Wuv2n/RaHXDPlfh3MD/M3xFuvUN6/t0K8m9/xwYr
FTqKcbRUv/7+g2/UQLGvP//n+8+86M4/E1j94QP57z/+5R++/uvcsOUBCugFjlL6uv8t665+BgMU
fKvxSyRvRrg+L81luo3ET6L4gtr5PLJWH1YDQ0QXlE1p8k0PnLGu1trf2I35Se4KKJOG7J+yUbGj
aZgWPsldAWV83E/rVAFlPBUWnbySuwJqT4VFTgYsdaodTUN6+KWMSje1lumCsjRqXJakA8U6g1bY
NUZCGY8TFlueG77MNzKiESGkmsK9KYOEtz9T1pRjsMoEdoEvrCnHTJRlyzG6dt5ts7xopNSm2tEk
ZKErZ89Df6NJOTFWkQqMHu9cmboShg8TLedvZHtYsMYq0zljlY3coCVWclesZd6MsW3fiBvdG/8v
w04ZK/p2xgTbvXUWmjeP0zIb8oEIY3NPz3bNLez8uJ+r0VqOqfr4ejbTzvpcptsIZ12WwTc9csfd
Xx6RWG1ZSwADVR4TqA3BpQk2Fh6ZLRPlWrs3xvgCnObi4qswvvBKJp0pukCaQIFHX2LS/2tAmOY0
mxSEBGCwUlP07huxQdkrmXTGKr1E1rNHxbXhj2/FHhbg98uQSsk3yPqpYfHUSvXwY+cGaevH+kns
Upm9+qYKKDPctYd3h1MXar77pksoE7Ad777pAmofOU1l9uqbLqFMtUx7902XUKZapr77pntrpfLu
my6gbB1+fvdNl2vtIrykdx9BCWUUUHz3TZdQRrWEd99071wwN1590+Vt77Nh+nj3TRdQtnK1X8r/
gjK1K+1TcSqgblTLq2+6gPruCOUcy81H/7yj4qL5+cHCXtXVwrujooCySYr57nEooMzroD7eI5Ql
1F7DN/p7hLLccTcsZ32PUJZrmUZw5T1CWUKZlEF+j1AWUOapO7uaPEcoC6j94UHK8T1C2dsxz/cI
ZQl1M3/tNULZW6v29whliS/DGW2NUC7Rhep1jVAOPr7YvCH11rOL+8lOvICdHlYZdOcI5aBOv0tL
htMzJEnXpzdT2uYnJCLOZaa08f0W9HD2vpE1Vm3yyZhH95kV/HP1w/G+kSHwpRUVpxkTiEZEiU2f
fjdIYAK962Cdcy2zuJQ5vRvKy1WarVV3R4atmQNzJUAJ7H0/VxBZrGV68vM9Ul1VqWd8sWVZw/2k
6UmmwireUstUp9/nR62AdAmtqdPvnafYjAwkwe6rAsrWMvFBfJhT494EkVmv1WKdHqeVzk685DVP
ypXBdpetzDtp8vOBxho1v8sKwtHeGN3ls7CCLiiTwBdW0AVlNcJlBQmo3fEXVpDYcbeohBUk1jID
5y8r6Hx6aQUJqN1WElbQBWXGvwsr6IIyNomwgsTpd8dfWEFnTEgryIO6rCABZep8LytIQBk3/LKC
HEwIK0hAmR7olxXkQMXynh7jUA6rbl/TYxwq5MD51/QYD4rvRZ/TYxzKYVL0NT1GQu3ahQPnn9Nj
HPpiQ8zX9BjnHlcP9Of0GOeGViLzOT1GYvWu+clzeozEhHFky3t6jIMJuqiv6TEeFGsUn9NjvB05
Zeo5PUZC7c9v2Hri9fpLQO0ylVOmntNjHEwwrfiaHuPQROGUqef0GO8bGeJ/To+RUDcVqa/pMQ7d
F77VfU6PcXasnDL1Slqd16qcMvVKujtrsUv9c3qMw2lM8r2mxzh0zxj2q1+/Q9GVU6ae02McWci2
H6/pMfIb9xYibGT9nB7jYYK9G5/TY+S59q6MbGT9nB7j7chg0Ktw5bxj45Sp5/QYB6ttvUBY02Mc
rLJa8zUF0MFq45Sp12uGM1Ybp0w9pwBKGyB9z3RoGoG/z+I4hsSUxZFPvKgsjmNwUFkcx7CfsjiO
4UhlcRyDg8riOIbXlMVx7bjbJdLiOJ5eWRwXlAn8C4vjSjXsXq+0OD5QZi6ctDjyiTOUxXFeS1oc
F5QpIhMWxwW1x6mkxXGEUhbHBWVC+sLiuKBMGF5YHBeU8S6FxXFBmQfBwuI4Q0mL4/yN0uK4oDyL
4xhWVhbHMUStLI4zlLQ4jukUZXEcT68sjnMYXlocxxSIsjjOUNLiOO8oLY6jZFIWx1HmKIvjOpdp
dS0sjjNWpcVx3lFaHMckgrI4jjJaWRxHrCqL4yhXlcVxlKvK4jh+o7I4zjtKi+O8o7Q4jrSqLI4z
vqTFccaXtDiO6TplcVy69ruTaKNi9t+n2fdEzL1mryfaUpq9nu5QafZ6onml2etJKinNXk94V5q9
nqhGafbjuZRmP36j0uwX1M3L4o9mryc6VZr9gtr1rNTsR3wpzX4+vdTsHyhjcUjNXk+coTT78YaU
Zr/WMtFlodmPp1eavf5e/sn5jhG+yT/HTJbin36keck//YRRxT/HfJfin/4t/ulHepD804/0IPnn
nIeT/HM8l+Kf87kk/xyzdYp/rrU8/tlzevf8c922xz/nHKjkn3M+VfLPEROKfy5M7PkNyT/XWl4s
7ogvZRlfUHuJh7SM++/mxWVs/s8ypemYHZCZ0gvKcJnIlKZjJktmStMxfyMzpemYyZKZUgFldNmV
KT2fXmZKBZQpT7sypQLKND6/MqUCai/BE5lSB0pkSs+YkJnSdMxkyUxpOmayZKbU2VFkSh3ci0yp
OJeTKT3vKDOl6ZijkpnS8z3KTOmZVmWm9EyrMlN6QZmZpSJT6pxeZEqdc4lMqTjXng0WmVIBZTpX
XZlSAeVkSs/0JTOlZ3zJTOmZcmSm9HwumSk905fMlAookwO9MqVnfpSZUudcIlN6ljkyU+qsJTKl
Z8opq7l7XL00hCT/5szS9abBKIDX/Mz/Dwnc6KZlbmRzdHJlYW0KZW5kb2JqCjIxIDAgb2JqCjw8
IC9Db250ZW50cyAyMiAwIFIgL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSAvUGFyZW50IDg1IDAg
UiAvUmVzb3VyY2VzIDw8IC9FeHRHU3RhdGUgPDwgL0cwIDYyIDAgUiAvRzEgNzUgMCBSID4+IC9G
b250IDw8IC9GMCA3MiAwIFIgL0YxIDYzIDAgUiAvRjIgNjkgMCBSIC9GMyA3NiAwIFIgL0Y0IDY2
IDAgUiA+PiAvUHJvY1NldHMgWyAvUERGIC9UZXh0IC9JbWFnZUIgL0ltYWdlQyAvSW1hZ2VJIF0g
Pj4gL1R5cGUgL1BhZ2UgPj4KZW5kb2JqCjIyIDAgb2JqCjw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl
IC9MZW5ndGggMTE1OTQgPj4Kc3RyZWFtCnicrX3bjm07bt37/op6NuBp3agLEARwpy/PbTTgDwic
NgK3gXT+H8gYmqtqktISqw7ic+D23nVYEifFOykqfgT8+48R/9NG+viff/v1f35dTeZP7///jzXn
yv8QP/jvv/zp4/7D3//665/+FD7++n9/hY9eSv/osX7EIPXj7//263/94gLzJ7ml/vmjt3BdSpk/
HDXcP4sf1ygjxFEbsOhh/tNee7//T8AmchmuJa1+1PG1VB895JE6/lhv+JRfS739T3apxk+dK/Fn
NebtZ4SLH+2Fe0th/dGfQVMpIHAiRUHI0PmH+6//8fnXmPL9d4Kav3wC/vuvf/2Hj/88H9DrOH73
l1//9EcsUa46/xkffyEdXuccJQG/2j7+8rdf/w0fnP/7x1/+t/rPNV4hxFKLhhJZoFoAVBppaKjS
V6gBqJKHWau0Bap3QEkXu9b/WKBGA1TLycUrhQqo3rqLV4pyhRiSZANVF6hUABVb7GbHBfuUM6By
7HattECVdE2i2rVWvAS0xwHE7H5jBe1jk9Y9eqUK2scBTDRUCgtUA+1TkNDMWr9boDpon3ACyaXE
AO1TLrl5UDmA9gkSbNdauDCDeUOqudq1lhPKEJKAT8hmrfj7BSqD9mTVaqCWE8oFtM+h1ehCCWif
U0rVO6EsoD1kckT3GytonyWKxSsuUA20z7Wm6PFq7qB97qGL2XHFfoD2+B8JBmrhiRJA+xJDFI8S
JYL2JZVu1ip/XKASaE8F4OJVMmhfBHuatf55gSqgfam9icf3pYD2pedsNIDcVP3DX75RjkWMUL2U
47e/duvUfjpDo1PPUFqnrlDfo9DMrz2Y/3manx9YjHhamoJTgdVbmvi/VfOn4lnVecDHNqgU0VCy
kgSWMaUcqFwfqJX5I9S5SEyhG6g/rlAd7kLL0syOq8lK9RrSSzV4bSYryxXDkGbxWr8x9ytXaSm5
31jqJbH2HMxaC/NHIZXbyOYbN+Mt8CTyGNHgtargWNPVQQ4aSbXj73Z2HDj2Yej1zsTHCMmVN3h9
8kg6Mm3PV+w1dPPtwbJ8/m2/vXHaiNfoOFf3FBL4sbVaistpKYxLGuhXPE5Lkedee6gep6XULiiG
0ZvHaQmcNrhl904hlQLBhu01JxpXYy/5ktIkRw2VN/ciXbmkFpO7Y4sXPPveLF5jhRrXyDmU4q4F
BxAxQormHDe3Bw4gPjG36kFlOIBwxqS42GdoDHhZbdEYq6sC92KE3lvxqEr3ogUYTYN9XteCe1HG
SAtPvHEv0oAHZbH/wxv3og/JLk/Ad7p6L0DN43uQ84Ja6S2439jlAuPADzGSttJ+lCs1uJMW+9VA
BzgOVbLl6BWvEuMF0ZZcvBMqKVxVpIXg7pjGVSQAwt0R2jqVGrLFfnNCGp0jiK1HryJy9Qz3tXia
Cf7AVcGKVvOn9qn9/ulPkcY5ffzl79/o0dLyVRJ+ar7w0aNfcfrnSkerfa/UgtWWq50pcErBzQyW
HVksHZqkDW7h8ClCgUtejrdaq65Q4GbpvdszXPAShn9wLcLwpEzw7TPKci2CwHXNMSURDy8Bb9VC
19v7RsntaiNCgDyqwgEGz+diuWa1y8IQJBbprl0WeAIRvofVqaUsUJXaEr5H9qRMWrkKlIRUd0ec
NsxZaMPjCaBNzmnyzl94oGCzgTvMnllrkcUa0oXoKVjfY5V+KJGrxBSthlttNrwIyAMI4Vp2MM01
YGzH8LCvsC5j1CKW7xfOqbAuOeEci3dC0A/UvIulWn2JmsGFCei7MlQLfdvyzTlCn8K3rcs5bt8I
GxQbk2eep4n/ciXxuLnCjygIcqwmeeH0bYxRF8fxt4Qm/WuzNbeF+DdKjMyJPFBbBiwwxo+NOSQF
taiaGOHk9dSncusnRo5wBRsokcVArWEOXEHEHKkGg/3qkJdMM3ab1zP2BeoBaj4WDbWHExCw0ccM
FPrpkCGCNPujiksJGLuSUmjZ3bF2qAc4U2bHLbAC08AbuY3ws+MWT8P5DDEHe9orVaGQEn0uc0Jb
8AgjVTqUqqH9FjwOKBF6/gavzaWHkYLj3BYu3HKUBa5zH8GlV4rM8oXeLL0WJWJCjfNaUDXwr0fN
HuekXBnw1dBd7BGQJJof+41reAAupEM/krsW+KvA8ofg4lUjgq5RivhQ4FWBfxDdHWnwoJR6cc8R
Bk8QkQSfqh0OdoJzZqDW8CANgcGrIxRPhjJcZwRKcBENXmt4ACMF5TFzUudvzOAcSGNq4slQBudk
6dlK2vqNmUYKyImB2sIDuDcpyMJfq2znQmcDgXZz8RI6Gzml4J1Qrgjqa8nF37GWrxy4s2ODLgQ/
Z7vjosnhB8Kop8UqbPTq5UKw1Kz2Xa0Cw6nRRrAaYDWgDKeg42JytQnDqdRjcg+7gCUKgl5fRRf4
LRJKzlZNrP56DoiAUhFXTTDmGh18E128EHPF/Ipkj4fNmCshRFiEY4254BfDzx5W5Ww7Qk3UAUES
77AL1EQvoIcrHKXhG6f29YwoY6XRe5ThHvZg1mVA87hUHRBtqJIgHl4IRqAwoc5dhSnMwOIwo6sw
JVYydFzU1xptpALaI66ygrbFShBtKAlx3Rwp4C8cQHO5UOjmINbwaQ8ljm8EmHuOIoyVhkTXGUI4
AkrEYg3yFoFWciE8ueTu2KjkitTk7sgMTq+SXDWBMAPyCGXoqgkZkwtbHS5eLMUiQEgGKq2RC9wc
5kCs+sprTALOQVQ1rAy9Snjf+/8pvkEUv/b/0UDQcChsIEj/BR0E91q2W2C0uP2McHQ7dAvB8rPP
HgKms5NqInj9/auLALjcfyew+csX5HdtBPDc4AEhAkof7/+IL/8W5ukO8Y9wuikNeL24aHWp4da1
BqkqGkrWWkVFNAqnihz5QK1ucGxw9aESWKBWay25u9hhBeHFBwu1BiqQAchmo4VQO66VgAAthdi9
Guyf6DZMQJDz/gNo5hMrBfOBP413bxqXw6/5Vc1Wv45mjVpVVVNBbQWip6r5QK3+r+4UeaC26FB1
ijxQa2Vad4o8UKsK1p0i57V0p4izluoUeaC2KEx1iqi1tsjp6RRRUGu8oDpF1I5r34bqFFHfuMVE
T6eIQwnVKaLwWiM61Sni7Kg6Rc476k6RM1V1p8iZqrpT5ExV3SlypqruFFF8n34mVNOv2Vj8h7LY
j5KhZfELast1aFnsJ6VlZPGBWnMwWhb7otrey+IX1F58VbLYjzyvZfHZ0ZPFI/ZGFh+odUcti19Q
Ww+VlsUvqLiupWWx/0gWz2tpWXyg1m/UsvhArVpJy+IRysjiA7V2IWlZfKCGI4sP1CqxWhYfqDWS
1rJ4hlJdW843qq4tBbXmAVTXluKcdS3VtaU4essDPF1bDpTq2lJQa8CturbO2OuuLYX9Gtiqri21
o9O15UCpri1nR9W1ddZMDN5DgcNdPJ1TKmgvkf67xmuFQtgEZFsuLlU7aD/zBe6OA7RHfGi17x5K
g/bSYrKaaQ1ZI2hPtZo9qkqKDMGCmLW2EmYG7ZkItGutAWQG7WsavXvfyFA61FKs9t12FIaGMmJz
d6ygfW25J49XpYH2lS0MLr0Q2IYWckwuvUZmu1lrFq9Fk7OgOI2VtbXjZya6RiPsv8my9/ATy/5A
ef3YD5TXj63W2ioij2VXUG8CoE/LrqAcL1tBrfZfWfYzXtqyn79RW3YF5fRjqx0dL1tBbZ3Wj2U/
00tbdgd7ZdkfqM3jUJZdrbXSS1n28wlpy67WWj1jZdnP2GvLrjj6h/KT8ztB+KH8rDHxe/lJR57X
8pNOFDXyk04UNfLjJhC+5GdNDbyXn3TkBy0/R7yM/BzxMvJzxkvLTzrKtZafZy1PftKJA438PKft
yc8X1OZla/l5oFZKaPk5UsLIzzGpZOTnmKAy8nOkl/aM+zH1pD1jRa+fyiKdzU2ovu/InbK4JpqU
LIarDYks9zxQm5ThpGXAezZrbVKGk85dhLU9tdZ2t4j9F4EpMw21RalyjYY9q4HabFm5WmOx3cM+
wcOGf5PYf6Gg1swMm8uY2w8GassYRTY41WzptSYZ4b9NoiYXCv5bK3VM3XWkRIL/JiXFZui1yTXb
xjJcZ4vXP6+yKFfM6ZbF8449XyO12rJL+5GulgA7DF6rlIV4gRCzIey8Y47hytBwzWC/5YIiU8qI
SJp3jqyPg1VnY9+ZVxFUXnX02Qh55tVc5Coj92ywX3V9lnKlPqCuXOwrNEkvsTYXrxav3sYs5Sq8
1n6CHq7a7qY3BbVW92fafNRqab/qrtGvBKthOXorvwZGcGNePTjTq8DqQQHE6nIOgt2r4nzS8PAq
sHqIbcoQj79KYaEw1GqxXwu+tHr5LkSf5bHIuHoOY2QXr9rZ2DfLwmedM9txE2XNXavXK8Vahss5
hdmGyNZRo8mt3TgaAAlGvfw2H+6c99c+3JO99WKgepJ+48PVE28ZH66eKGp8uCNexoc74mV8uHo6
aePDnasD2oerJ8kwPty5HqF9uPM3ah/uSC/jw9WThjM+3Lm2oX24MyW0D3fO+2sfrp7k2vhwD5Rz
J/WB8u6k9nMFRPtwZyiV3TyfkM5uOt+osptqR+dO6plXdXZT7ejcSVVQzp3UMyV0dlPh5dxJPeOl
s5tqLedO6pnvdXZT7bhaPZXdPOtCnd1UMrQ2Cqns5gO1Vl11dtOBUtlNBfWmnegzu3k+IZ3dVFBb
o9CT3Txzoc5uKqgfmhyxh/HbLFU/0d1YqmM20liqY+7ZWKpjLtVYqn7SN8ZSHauIxlIdaxvGUh3z
ssZSnaG0pTrSy1iqY0bfWKpzrVFbqnOtUVuq4wkZS3XMYxtLdayAGEt1pISxVGcobamOOxpLday5
GEt1rA4YS3WunWlLdeQJY6nO36gt1ZrR/z6/0dobQfhZfmN8pSjXZjad3xjnLLzKb4xj9lbnNx6o
9aKhzm8ovFYdofIbw8nVP/kNhdcfVul/8hvnb9T5jXHO+6v8xvkbdX7jgVq7y3V+Q+G1eqAqv+Hg
pfIb45gT1/kNZ0eV33B2VPkNtdYqsSq/oei1+pYqvzHWdPrb/Iai6nYF+slvnPle5zfUWmseQeU3
FNSKvcpvKKi1h0DlNxTUmp1R+Q0Fteould9Q3+jkNxTttyvQT37jTAmd3zhjr/MbZ3rp/MYZL53f
cKBUfkNBbY32T35D4eXkNxxKqPyG2nGr1T/5DYcSKr+h1lo9dpXfUGutHii82R5qT9mTDnqzldfQ
XNrTm82jRRGPEvRm40g5xTeS9jNvdhP2n3mz46krbfbs8WbHud6lvNlxrAVpb1ZBOd7sONZctDd7
3lF7s+cdtTf7QG02SHmzD9R2i0t5s2rH1SIob3ac63DKmz1TQnuzCvvfr1CPNzvWos5bb3Yca1Ta
m3WwV97sGUp7s+NcyVLe7DhXxZQ3q6A2S/V4s+dv1N7smXO0N+vgpbzZswxpb/bM0Trvok57XUvl
XdRaq21UeZcz3+u8i1pr1akq7+JAqbyLA6XyLg5eKu+iaD9WqCfvcqa9zrsoqNU2qryLglrxUnkX
B3uVd1FrOV1lZ7x03uUsQzrvctYmOu9y5kKddzlLmu4qO9Ned5WptbYLWk9XmYO96irb1vreglpW
+m0W9Kvg4U1+c6C0BV2hfjb5bbypufzXTH4bb2bKfftbUOnx06k4T35TUM7kNwW1FYbA1mkIfGmz
1upU8HZibQFCqaC2eWe8nYgoE0ZSQ62uB28nVvBJcPFCQNRKpGnw1irlAssxPNHYr3jxdiJicwil
Xmu928R7h43BtFlrTRe0dEkPDPo01HbNJlwNVreYE9quCTCwhQIexf1GBLYxz8tsHr0GXXcIr/uN
TFDkGtliqaHWRAB4AuquD0vVrRkKQV8tDDM11HqdheHvSNE/xzkSgRenDSXC1oAR8I3CK1wOJebg
hA4/UzyOnoMThLeKPY7m4AS5XVsPe06hqpFz1Ty8KicL5oVz1kQAXUgJUEbR3ZEjEWBmFnnc2hfz
541oBbU55gi4e+003hqvrcDXrp5iidHjCU6Fg18rC15rGoNzewLNkfeNcySCgFcN328OHef2QPEH
8b5xjkToWcRgv41XYOIEPCFWOjZ3tIEnJMfh4lWFmr0sunClakOQjOCj+jvSaW2ADe6OcIkQZPWF
V7eRCKA9VI7Pqwi2r1LasLy6D06QS8aAv+OdI11bjpqxdmjVTAWO02vUjEMvzkQA05Xkcs6cQ4dY
QCznbKmaOwE2mkeJOTlBKqJq74QKAhkYq2xp/648KTUXS/utFQWc06GYrF7dSrC8r1taW6zVm7QP
Hcg+XKpyNqEwDHKpCs4BUhyxpHdcnVb4JvDCUnWtuzBsxX7Jcs7qmINz6CQX1w7N5BA04UKJ1QFO
Qr4vyeVoyfmSVMX3TTiLTkaHYfA4WorAgxk1u/6XIMCCXl18gG0qH3QO9GqLzeNo4VRafIJvtxHp
MI0k0dJrrFAcLATLFj2+lx4vjhT0pVb6mDN1fanlTATwfRBXY3ImQrjLDw5Vawxzpq7l1W0yXGSq
GZzRPY6uiVouZ9+PrpxiWGH47Dmu8/bowWw8sc2Pg28CvwpmwdMAVeJVBY60qycqbNqAWu0+vYRT
ZAS6yKVX5RSZGutw6TVnHUJFF3dH+jkZtC1vdvzB1Lp3SvtnYVU5iQ/DKrLydNrL6XDU1DoNtYhP
pOq6xyl4a6X4OU7BwyvBOYZvMh2hM1S+s52puzvCXYq1wd82UGu4B6PHHOxk5nI6wijMyofbEfqC
2iqnDKvIDdFgv822+5pap/FaHEdQHcoSwl/cb2RY1TIHiugd1/CYYVWCqzDcb0RYhf/L1fDEVjkN
dHsBZ7Ffs9bgnJQ4NtzDC1/Hka934Hs8oUSlBKuXi7tjQsjRWUxzd0TwNegTGnpt3RUwZ6H3Osw3
bp0ahfyFMFQ8qnKMdoJxmWb2oeqbSnOGSrKU2PtMwIUNCqy6O8KpKvBzSnPpxRANtI6Wc7YQjdnh
1LO/Y4cJwlqjudj3csUGclm81jAUvJoRGfbg8T1Cqqvc084cvEDRC/7NqJZz1ooBw73QVm2yTY7g
aPWeJHrfmBOz/NDWyYcCJQDUkvuNmeN4chqGv7ZOzUxDlReds1HiNU0v+3iB71NrdzLkqL/g+V9Q
ciG6PDFDxxDu4OtZaw3RWMnocEOrxxMcOw7JXfTXHjoO6NUki7V602fa0yt5dN5xTtOLPfhUHawY
ADuXqnPmXpwPOzg7zpl7tXbfIs+he7GN2j28OHSv9JcTeuRo1k5qeTmhD/ZbgAmHdryc0PM3IsCE
8r2d0PM3CmuZLyf0WWutzMuAFX05oedvrPjGKIvd3u86BAQmCJiGx9Ecusec+LAntIWOHOYuHOLk
ndAQWtGe/RPi0D14dqN70gHVxSAn9O7x/QwdAxjfYr/VdJjWlhKbD8XR0FGs/7UFcuCvOrIUu+Ma
ooG/eim1uvRi5WcMhGAuvaQUVmtacc9xjuaLvVu9ugWY9NJg261e3Yedw2lPcfVgVqj5IEJKi8e3
DTsv0Dk5V9eXm+P0Giy3f0JMfudQFzu0jTFHcC+9We27pgo5xnyWWLN3jhy6JyPIoskX2lfYtFbi
4jPto8cTixjd6sLVS6usqN+1X0ceK/2vIcHqwqUOdg6r5J16eX6NmZb5z5uwany5cdvbQpxPzqhX
Q20BAMSH2YYRDNRafbnbCuqMZsfpcFjvYVWoDQO1VtFgjCv0SMxmx638eBvQ0MxaW8gBykD0Z41m
nA4njsz6RbeU2EMOZvYi5w1qqm41Gs4eRSCXvW/kOzp8J7I27xtTgrqpLc9ayBH7xLcVmGgXd0e+
xVRb6cPdUTrdpTjsCW3XX/mWS7hdryO96I6nWO9s7xfU9ibPiPNthTK8c+R46AK/t1ieeOP2IqQt
2VJ1G+XQ4F6WmJO74yzyw7ZY6VgdNIh1m4lcA7W10wjfcpHY3qz1rRTn+o4tf5RT4dsDL7Kvwo/I
+DV8UkHtM/7Z4Vv5YJKGWoVf5UEeqD3DwfJfFSoStdb2/BjLf30We9Vaq4oo8XNEpYcXfH9YstKr
ixfiVFiymehVa725uY9QqTGn8kCthdDYWMSBA2fW2hQJez7hajRDia3s3ZnebI2+v8Jry5ZkWLL5
eIy3I1O4KfCtBmdHnS1RO76Z3h85Gr555zgVHNsXstlxmxUAP6/AZlueWHv8cmYXc+rifWPiQzRM
SthvXHMEzJZAjVh6bSV05kGSFHuO+9yOJ8Nx5i92KAoC1TBc7ME5MsbCE6uPPbMSPQ8ZnnSwj7GU
EJPFfi3aj8Bh1KkPHwoaQFKx57hhP9hfWUq0O755wIwjq3Pz6MWeyIzg0vLE3uMPPTF6TcGT2pyg
5aC/irg7gr/gffbqSlpmbyuoNaLH9+BmGHa+ZeJiLwGUgOlLnjxCD/IZnZDF4+hZ0Ibzv8jQSvvG
p6jSLAid+T4jtmQ0OLpLVXZhxsRp0B4UC9rgwtJdSrCgHVO00rFnJeCq9hIWzbT1aiZOVctWOrb4
ObFZZSzWas9KwFqNONsEzhqgIEIAyGwTOMtjycI7JLNNQEGtHZ3MXTR8og/F3EVJM6I6czTvMYyR
WyseTxSp4HvgH9y1KjuZ+QipJx18XC22Wi2vbufIsnfpMlxrVei0J/aHenwPo3dV2PZuKbE9K1Cv
NmYHrCNpEgq0XBiped945y7YRu5CzdpRhivgUZWPq5VQkqXEFj/Pljx8evQkbWYlel/s0HaneGYl
4DO7tJ/PCtw3vxTUekdpdq124YB3R9IgFsyE8n0YhwulsSQMl8m1MHyojc+6Bp+qfJavMNQ1O24P
BrAk3KO43tAse0ewhP3GNSsRA61CaHbHrezNxxrusOp82jXxrRnJ1f1GFrSFtSN7juta9Jmkl9I8
qlb6TDkUe9rbM3MlgL/42q/H9zPDwRePXC+t0rPig1ricTR4HtYKJtnVTJU3rDaeWPmr0rMCVnat
ta2i9nB1eNvB9RRqn133PfU3O36fxXkbFvwskCsng6B7jhXUGpjwRZT7lRwFtYd7fJGPN7UM1Pak
G81svlVEOR1hBJvmEatda+8mzp8vEui1tqCwgR1EmGRX37h2E8O1r7ypGQ3UGu4xKARrTVE848W+
njBuA/qsteazZlt+6N3S683wnlGiTKY5056XyAbvArm0p+qCjLHDyaH9vEQmt+N4pATDPXbQlexh
n6jgcp0p7zO9ZlAYeqvFw55XzerIIZu19uJ44zMm0e64j4abRcLZtetBsecl3sryjH1mzwtc9+RR
laEjImi+TupRVXidLt1q8Flru4adLshGj/Ybt2vYvO5cZrnUwR6mES75CNGTIfYvF+ndfuM+eqhe
NcBf8jlnlKvViAN38WL/cs4z5a3W2savVxiXEq3Ubjk7vmoN0xiL943q4TfnG9XDb3qtbYxR+Xx7
yPnGnPkyTS+LZtqyhNAT0EzB1QCzyxmaKUePJzLfMOd8h+Kd0B3ujdHcE8rgnNcLRR5ecKpaxTnZ
E1qvrQ/oiRGjlbQNL14iLymH4emcWYROaYh42POqOeK4UarHX2XmhOsdOq5rfdre8+vTs4TdQ7K/
bcs2xf/tuwB+tuC6AO7QJPULpyrWIu2jnSoLgbOucNY+BaFAhZiM4ElTmWMn+Da6ewqs6cQ6W3PO
EoADuBAtdGvdtmANDh1O/U5vnU+0VfbAh8Xqrt/YC3uBU3D1cOFwijKytc1bWMHe6dma+8bWeDzE
R6le4SXvL8XqcNHR/3v9tvjSMF+zS4jJxDtTXpbMVCrV4yJJgTc8xPeR5pt3CW6Ze1ozhG04WdcP
lHmrrFbfF+Er4jW12djonBZrMq3fqZujZyDwA8NUDGbHtV1hlt/TqpM3KARbjE6rx2vs70aAERbs
1zYKPu2bYiw+vdhKOXIMll7ba3aJUjdbFs8nVAOreZKLq3/41nhsNSSXvypbKRFCWP9hK/izSD8d
CPONWzgcmODhA3YOJWYpP+HH1jqt/d1Z2LLIERSO/gH7ge+llOKdNt8ah7pbrPn2Bjr9wDxadmOW
Sj9whC6uf1r5tG9F+Nbcb4Re7KVFy9Eb9rP9ET7QO12moDJv4ZVFX29QfOGQz9S72LPQ0JtU1z+t
9Cmh+v0TaiFdCH5qcb2fxmeCK9s338jjt/q2Rc9V8MP04wP1JgA/PlBvAvB6UiSRfU+8WRPMWmvQ
zJfXO42uhtoD8MiurTJrRfXENHyfPYYhM6dZT0c4e9h7lKlIzjvyFXdE83bHLRwWNqeUulBiTX4I
r26m2aXrUBXi03vu1dB+D9MjX1SW6cicsWene35l354dt9rtc4F4W+tbp3NOioEoNHO+P3U63//2
lrpQ15LP36GvJSuobS48zDILY3bHbboaJ7X0OylxpG/irBOOyIrujpnX+nrM9hTWYJZhfR2pFPcb
qc55K9GVOYb1vcUiw4Xi7K6U7kTVkR+he2FK4cxb7H/sTs433BFdu/xx1FOfvx1cKb2vO8dm99i7
5BMM+X0B9izLrDS31wVYZ0caAIRK0dUxr0vRd2LuePLskp/Dq1y9MJMKjRUdD6+ZVJgE01DrVK2c
JneLlZR9mhz01QDnGtpvsyQLQipEC74eZVIBkXu0Upe3mfpsWqu9R++EcuV11DYW/b5iz3RBgovX
vROaNWRQS3zsmVT4dIbPeI3wOMPPOW6ph/I4w+cdx2zoCtXlr/vN+XbXto/8db85D+NaPf66H50f
qbn8NR+dj+yocfGCNYdamW2YZzt9P00/slhLt00Y4kyjPkc/ONjDAvMx+Wj9h20WHm9hRA5q8b7x
7pKHg2DwWuv3laFPm5fIHbw4ywsWyerrvYYMx1rCXbU+2pHCyYet19w8Lix8EBniUe0JreEdO+p6
6N2VoVf/ewjdO8dX/3u08rhd351jXWoa7jneNeRWFknb+t85PRRGwbXOdwDOr/J4lResYXbnnZuz
DDEA7xtP7JOP2MlQUnVP+56PVNMitVulucDnabm4vtusIdc+b2GcOWfWkEddPLzV55nPySMejq50
1IBwZeCM3B1n/zsHkbmW7w6t5e5kOH7jHTS3u5PhyNGz/x0hxGIV3vW/33PnnHOc1WHgbimxX4pO
0JisW7v04vAXxMzWr9tryCz0TffHwwu+GDypNlw9gaO54C2MaPXEVh1uV6ktlOhJWuWdwdKqvKPX
98FpeGdMfhac9q/fWiun6oL1A7WHsJze0W+XsJ9U1wxhcdrJQL0NYWMNk037iexsLB6FpVMDtTUW
y8WGu2p23APd54K1gz1cLxjk3C0ltmvY9SpDZl++s6MEdtzfFcpnrbVJudIRqjFYSqwBJWvIqaVo
8Vqxh2nklcLiU6LPS6s5WkqsPDF4abXfiYEzXoNDbkEKQ4ltZGaoNI11qvozFHgXXlwrzTvtGSD2
1EU8/prV4ZzHdPaOlEgzKyh3/eu81swKtjmDQUFtLcMwjYHZD49zEm8CdI7TcfGCu9QE4bm4O9Y5
wDoOi/0656uxCSvmlF2qMt/XESnbb9weF+RcjhxGcrGngssy59s5lBiQoQCqZo8L70vRPdbqYZ8j
ZAhY9eHhBYZnQiy5ROVt5wFiteyxKjuG8X1l+GjxHjPb24fHXrxCAn3TikvUeY9Z2hw290CtN/Pn
PWZQ1rL92xFYHT509Q4o18mErfjf2CYT9jo8xpnRXi8SXaGd0V6WGlwFMOO4XpsVobdxnPS7Geih
6hq9hPZ1P/FMe0Z7OaQarRlaC7SM9uBGZ/uNa/SCOK7im6S72PO2c6t3e8gZr8xBRnRePNpznixU
dLF8vxVVWexF0B6bixeLvQg7WveEtszJoHkOyjqf4xyUJaVZA7Nh31hGgal1RZsxISxorq5rMvuK
a5bkciFjQrlnWDvOEPuKYRyb1RNbHMfmvNGHdQG2OI6OFUCrSy/GhCXE2ItHiVm6nRMuPS0niWa7
3J25R9rPoVuz3dHdkZEjeHVR5Fvpljcx2vAV+YwJG28Welw4h25JnFcGFdRaSOWd6MypW+6OvBPd
6936dYbinejcpLucM+9E996CK7UzJqyIVrvHEyy3JqZVoie1dV42TSO67mqNiEty6c3VAHOcVpcx
XOznOC1pw+qvLV7i5JpeFxdgjwnZ1NWS1fdbfMmO4c5GMvcbOZNmzpt0d4Tlkzl/zOP7yrY7BDAL
F24xYWPdIEUrj1u5le8ogBDW4XtXSP1syDnTnnn0z4acM168i9XSctovDfCD+LK+QeFH8WUKx3hJ
9Sg/UFvEoeYiK6itRFp5xXL2Cz5QW4xDNciLhQavLdpDLMFUb7TYrxEazOyI8/EgDbWVNXm9gheL
zI5rH7Ya4OXgxciRz7ZYSqzR8exRhlvS3bUqHyLqsxbunNC8qnHfr3aoqi7Bqh23QmqjIzRvTjt4
cRJzGHPkjsJrzRN0lnviyhPb/X2We9LCE/uYr8AxJnz6yNkxMc2GUyyWqmsn80yz3VeUzvSak5gL
xyKZHdeoiooXTNi6x/f6EqxaaytmchaAZMs52xVehBwgvITo7ihwqlKryfDq1hXNAV6wyGV4/KUv
wTr0UpdgnbXAX7XFmi3UGh33OZJujgN0doSz10dpsXiyPa+3FpnjAM/nmNmbku6hbme8MntTWhOr
C/dOZpjGmWLyTkjPaz7rCVhOOHu99eLumAvkERqgePSaBcyZOXbXYgHzNUznrO95CfZzmI7zjXcB
c0RX3/PRrM9hOmqt7WmtNudW+PIIj4Rl4WLlce+KhpMA0V14dZv93OmO10UeV3rBcYSDXMWn/WC3
VauWV7eSFgLfUaTl4dF+XpUddd4GUFDb7Ofw1c13/sbZmczuj+5CsTNZaGy902ZncgscJuFZUc5+
BuNIdLXJHOCFwLcNT3/N0iSigFBcelUOiAN7uTwB1wzOMQcQe9oXCuLqMYzmfyMHeEHNZSsdb540
B9/PoQcOJTjAC65CSh4lJJC/YB+bhz1C46tVUDV4kiYRdrvEkn2oxG4+RGiu3RaOF6lj9j+f+Z7B
aoFR68Hjr1nAREQbjDzuV2UZrIZ5m+lM1dlnzKS8gcpbGAq7nWTxc/YwlL3B9IfcHdl8Vu657g4l
Oq9i3+8snGVbBi9ZIy5xpRbWmA2JxUrtFr7MAV4x+z55DSyj59lodZa0GjmYhlGOJ2lY5+L0xGGx
37p+C6SWIblHe3hofCUiRKvJ1wui9Jn6mEMDnbXoM5UwhwaeLUydbWJQJ+UNVb+/Rmpd+d8Uoh1v
0+v+1HS80a37U9PxTjTDKr5bMYXsOA1kdp6CZaZhP0/6UcW9dLx7PHtKeY+0m7W2q5/ztcJ5+SEd
byhHEb6GOS97qB3XkANmA8pkjq1XO25vZjd2QkgWF68p1nlefnDw4sWA+eKBi5fqPFVQ6zXSAcGA
hrD02l/NnS+3Dp9es7g3ypx4cj7tWdzjbYvgnTanBmHX+ZDM+bTn1CDo+2hpv71YSOEvxXL0tiNv
wNf7WpWzY5kpgHmJRa21BoUyUwB8ldGjF1XEbAAwO670ooqIUhbpeNdJWvlGqllrDQpn90Kb85oV
1FYCZPfCTBs5G8LfqJGzTMxSa8TBSKi0mUo8s+qrSXOmEp21OA6o9DsD4I4DgrcarAhtd00To/Z4
Z4XOg34YCcFXGsFjrxnj8B1lHy82ac6qkCccnA/Hwc+Lit6KexyNlmqNLvaVzTH5jvbO2LOVEw5M
aC72rXN8Uq/NPUcW98Y9FOGsCmdxD46ouAzN4h4tsRXH/eYnPZw8X1k6n/Ys26USpXlsP8t2TVIP
3jfOJk3WqqL3jbNsN/ocnarWWkcGc7Ig8wSumphNmgNRtIHaoj2+b5Pqqr7ePAMpDV67qzARr+O0
cY7BOyEW5DpE2zdWLMjhqEcoLlU7/aDcq4/9YLt8Gd3l1RkJ0W53T9L4pGQe952y844CzoFwxOFi
L/BUa4qz4+PMExw/3KBOmou9pMaMScquxuSQYr6MNlxJEz4gWtu863Y+Rw76gbmdd90cvDikGKcY
rFXYxgGxXTVl36SxlTMhIiw+7ZljHiUua213KdmuCqn16dU5JpJXD95847fXcKSzTYJ1IPPbP7yG
8/rt0Kuno2SwCTZ84/CwQXQwUM5v5PcHF0bmqzsFTkx1vuQcb9y/nYd4nFIjm2vLbD0/n8h82afX
HMXjYHgqV8mc0uhx8IzuepeaXLxy5wgtSa57yjudHY5BEe+05ps9cPCWMGNrPE1f03EV1B9+SO0W
HGb1o7vjZVQT3Z0H6Ojo7nhdWN8+TOvlShUDPrcPHSiW1nK6yyjnkT0srbGVNxuod6U16PZooLb3
aHmvMMY76eyM/xE+S3gngL6g0navUPgs4R11Pt+4UnU+TNruYt6ZqvNh0j57ZtRaa2Q9pmOdmzmh
vd0yTtehB49e826flMrbFmfazydHA+94efS6y2GtWdpvMeDsOn85GOcdZ9f5GKm72PNhUs6NMnht
Eax6clRBvYnbPu/2Kc75/c8kL9lf+00C2/b3h+MH3WTERVQEVw/zH7gr//Knj9N/+vtff81+H7bg
z8H38vH3f/vFva4OXycPvrjELgT+A81yL/X2P9mlGuDulfgzpvfWnxFufsv8UZsna37EZ5o5MZ0d
IQgt//aLVX784fX3//j8e2MnHv9OYPOXL8h///Wv//Dxn+dnn3lFvvH+bvp4/0d897cwIMCPno+e
PekcRHFSDfFrvPYDtakGtsC9HiN7oPbe7/b1GJlaa1UNvMr0mqSmoN4Mgv4cnK123FRDuNjGVA32
zxWFMAFBzvsPoNk3IhLMB/5URG4a58Ovue+WDw6BfR3NRvSvd8sV1PY62vNuuQs1+GRjHnatreG+
cxxbF7NWXHOrc2gb3HazVtxuZFdA9ZljUlDbW2VyhdfzyM5aiaPKYmNG8YHam+SZicrzmVi11jYc
ja/l3F2TCmrLfd1v4UW71pb7Au1jk+bjVXnjFrGJPe2t/Z2TqcMcVvhA7c0CvKeFEzBrbRmyURmu
zucFFNSagOETqgl62qy1OOtH5p0TzraP/vy17PN8+6LC1gQE72LwCXgN9e5JDRkhV7PW5kvyAdIu
wgSAgtqeUG+879XocaodtyfUOXEee1az1prJhacC32I2YCmozVPhnE+EDl1DbY9qJ97ug60PGmp7
lCLHObApR3dHzt0lUS29Vg6cY7TqmDrivBY791/Ppyp6bZKBQDu32cLkQDX5muHr7MhKAWKZll3a
j1kD6GwnOFM1w+MEIUIw2G9PlUeOM8yxWey3BhkaxT6vTSm8tqfK572Dmfk+fyM8Aybk5h3AM9/z
JTm45z2L+40cz9c5msJI2prKrffj1dViv73+FunjzoDewQsxQWUb4PBOKE/DP2azjbMjB++xN8nV
ALwPEWSMYbHf5qzLBQXAW4gOvThBnZWJNDzNVFi2L1KGwT5to+gQUpcwU99qx+0tNj5CJD0Z7N/d
Re85jGFpvyVD2SFfowxP0jjPHEKbfS1X+nwIp4x32uRbi7CQ5rEIf8a//w+fNEXKZW5kc3RyZWFt
CmVuZG9iagoyMyAwIG9iago8PCAvQ29udGVudHMgMjQgMCBSIC9NZWRpYUJveCBbIDAgMCA2MTIg
NzkyIF0gL1BhcmVudCA4NSAwIFIgL1Jlc291cmNlcyA8PCAvRXh0R1N0YXRlIDw8IC9HMCA2MiAw
IFIgL0cxIDc1IDAgUiA+PiAvRm9udCA8PCAvRjAgNzIgMCBSIC9GMSA3NiAwIFIgL0YyIDY5IDAg
UiAvRjMgNzkgMCBSIC9GNCA2MyAwIFIgL0Y1IDg2IDAgUiA+PiAvUHJvY1NldHMgWyAvUERGIC9U
ZXh0IC9JbWFnZUIgL0ltYWdlQyAvSW1hZ2VJIF0gPj4gL1R5cGUgL1BhZ2UgPj4KZW5kb2JqCjI0
IDAgb2JqCjw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMTc0MDEgPj4Kc3RyZWFtCnic
lX3brm05bt17fcV5DuDVul+AIIAd2/3soIB8QBA7COIAaf8/kDE4595TIpe49qlCV5+L9pREUeSg
eIu/Av79u4j/9Jl+/Y9//+P//fHqVf70+v+/6zEN/kX8xX//219/Xb/427/98Ze/hl//9h9/hF+z
hvJrxPYrhtp+/e1//vGvf/AD8ie548fvP3o7brZwDcUvrj+Lv16zzBBn61jFCPJPv+d+/1dYTSzl
+lbtmGDM72+NOUKeaeCX7fqBlO9vvf2r/Vude5Uv8c86vqv/jONAkXmvvqdg/uxfQNZaQONEooKW
YfAX12//z9dvU8zX7zl0+83XwP/1x3//T7/+7/mM7hP5hz//+Ms/YwHl1eSf+etPUuI+6lgTFoiN
/vnvf/xn7Pif/8uvP//38tctvkKIpZV1VE1qVA8YlWaa66jS9KiJUSXP7VulqFFjYFQddftW7WrU
7BjVc9q/9V/3USk0jBo8J2f1KdZXiCHVvI2KalQqGBV7HOuo+I9qVM4YlePYvhWyGlXSS4i6fav8
gxpVQXscQMweJVID7WOvffijQHtwYNlOu+p1ddA+hRr6NkqdYxqgfcIJJJcSE7RPueTtW1HRPgfQ
PuESJ3cUmDekllv3OCcn0B5byMnjwpxBe7Jqc0cV0D6H3qLHObmC9jmltH2rDj0KtM+5zejxV26g
fa6xNu8ccwftc2speieUB2ifRxh1o6qecYL2+E8NGyX+fh9VAmhfYojVo0SBgAJzlRHcUQm0pwCo
7owZtC8Vc26jlGQqBbQvbfT9W0OPAu3LyHl6lCgVtC8Q/8XjidJA+xpxldw9dtC+pp53iRnUqAHa
Y4tzenxfJmhfa/Olbw2gfRWp73wLC3+JWM3utxJo38jD3k2rGbRvUB3Z4/uaQfuW5nAlUy2gfStl
l75aFtYK2rc64y5NqhrVQPvW83ClSe2gfRuj7FJuqlEDtO8hx+TOOEH7Hnt3pVwLoD2VVfKoCkmP
UaUr6auo2hJoD7nUo0dVkB2jOkSmR9WWQfs+cbk3DHCt/p/+/AAd2k7AW8l9/LELcZSTbtwQRznd
xQ1xlJOM2BDHM0qhhA1xlJMk2RDH9yiDElbEUU6nsyGOZ0aNS1bEcVz9hjieUXrGFXF8j0pKKm2I
43tU9BBHOd2MDXGcv7UijmeU3uOKOJ5R6v5siOM4akMczyitQVfE8YxSMmJDHM8orf9XxPGMUny/
IY7zqBVxnPe4Io5nlIc4ykkqbYjj4Wi9rhVxnEetiOMZpfXsijiOq98Qx7N6jSVWxPHMqPXsijjO
o1bEcZ5xRRxHybQhjqPM2RDHsy49akUcZ6quiOM844o4nm9prbcijqOM3hDHkaob4jjK1Q1xHOXq
hjiOe9wQx3nGFXGcZ1wRx5FXN8RxpteKOM70WhHHM0pJ8g1xPLp2/lCzx+2y/55mbz/S7O3EW5tm
b6cz3DR7O/H8ptnbSSptmr2d6L5p9nbimk2zH9e1afbjHjfN/ozS61o1ezvx6abZn1Faz66a/Uiv
TbOfV79q9u9RBnGsmr2dbsam2Y8ntGn251vagl41+3H1m2Zvv3t/cn53EX54f8aP7s848vx6f8aJ
otv9GSeKbvdn/Oj+jCM/rPdnHPlhvT/HdW3357iu7f6c17Xen3G81+v9eb7l3Z9x4sDt/jyn7d2f
71EGZa/35xmlKbHenyMltvvzUCI49+f5lvcWd6TXhoyfUQorbch4/PZdFLCpL9XXj0X3LkIZH+9i
ePVZ44jrKHPLcNJ1Aj1v37Kv5+OVR63Qt+u39Is3TjqO0FPdRhkrtb5mx5xtG2V0WXn1HnEbvdXT
6QB8k9rYRulXaiDs3GIhmZdR2jYDwoah0fJOr3/Wo+ZLiJrcUcBvvbRJ2XWmRAJ+qyXFvtHL3Gvg
t5wBnfd1/b2+i/UVc5K76Mw48mumDjTo0n6mV08YO7d16VsW4guEwF94M+YYXhkSrm+rN2/Gcb5w
1jl37xxz6i+wKqC9x6swKl9tDt4Wh1dzqa8y88jb6rWsz7W80pgh+KtvkCSjxNbddfX4Gn3mvNP+
n7SVGl6tw0LbV1/1qPkCe7W2017LrjleCVpj52jNXyXQgptzdo9eBVoPAiA2l3Ng7L4azidNjycK
tB5smzJ3vlenXaD1Ugmt7atXUq5Q6+U6UvfuY6nzNXKYM3v0guH8giyJdXoyp/T+wqXNyaV9Ge2V
YivT5ZzC14YYW91Wr/UsbdkB4yxtqzfvvLBlG5T22Fav9Sxt2Tx7rNVbF23ZOFNO0ePomsdrjl6U
jFYcXUt/9ZFazR5Hw6B/1d5HnB5Va6uv3GE9uxKz9vKKbcQaPY4Gz7xmyzl2j6NhXb86zN7hck4L
4VVrxnF7ErOF+cpljFg9jm5xvCJg73D1EPj0NfOMpbvryvUFzZFj9ji6lfKqaZbu0h4H+AKAbsXl
HCjjVwQT7vpRIaEjpGm7mvg9JHT0ZW9I6Oz7X5GQE0ewIKF04q0NCR09fxsSSicO3JDQcfUbEjr7
61ckdPTybEjo6N3ckNB51IqEjpTYkNA5vmFFQkff7IaEzjOuSOjxK4UvhvvLXyMjU9KvP/92MV86
Md+Glh4ejM+X7qijry/lD18C3PAo+oW72sY15n39wl0pb6eTNaK6cdfcuMa86N+4qxWPa27c1fO2
+qz9ETfums3d44271F3U67pwV0o7z2sUdOMuxYHvcVdt++q1P+LCXT1tq6+aEjfumtvqk9b9xF33
q/L5xt64KyWX9l+4a26rT/pbF+6qdeccjVwu3AVG3EYpff2Fu8bwTvvCXREU2uil/REX7kppX70e
deOu0bzbf+OuumsE/YJ74y55nVlm1P71G3eNnfYaRwju4jPI9i0dj3DhrhS31WeNb27cNZJ3H2/c
Vcu2ehu1ILirx231Wb/o37hruBrhwl0ZWsfTQTfuSkojaDx4464+XEpcuKuW4t3tG3f1uK1evzd+
4a7uSswLdxV58zpzzo27UthvrY6muHHXrs+ixoMX7qpKnykuvHFX3/VZ1qjxxl27PqvfcRI/0mcv
4BVBYeE1I8XJDzWag+fkS3WXEj9GgztT/tYbdf9R9EY/+g/XN+p+9NOtb9TLKIMGnzfqZZSO8Vje
qM/rWt+oz+ta36j70Zu3vlH3o/9wfaNevuX4ePrRD7y+UTt7XN6oz/Ra36ifUea1fnmjXr6lcfHy
Ru1QYnmjPo9a36iXURq7LG/Uyygd47G8UT+jdBzr+ka9jNLvT8sbtTNqid44n9AaveHscYne6EfP
8xq9cebVNXqjHz3Pa/RGP3qe1+iNMyXW6I1lXfplaYneOK9rjd5YvmXiMp7ojTPfr9Eby4zf0tkX
jqVul+r3ZGo7neEmU8+jVpmqR31eQt9+7Fn5v0i6wg8yDMrp07w4I9T3NPF/CqdwK2R1mDEQ+ubE
C/6M0oIH0hdQ7gIKyyitZgA6ImwiwsJnlDaPY6bR1CqNgGeUUX8Aj8DttW2rN+qv5BcMfIFyzroq
QS2spLl9Sz+s1PGCjimEcssoo5bba7QpwH0ZZZ5fKFxh+waXEjDuodY6H0OW1ZsEDawexqOivVHL
AGkd0rx6M6YA0x2WOR/3l2/ppwkY5WNEWFfeCSXw26xZTIVlRhOgCTEAfTpdeiWY7qBDDv6MEE8Q
dGmnhAkJAefU3sr+LaPiS3t1fCnstNffqlcQl6KXVssAtThsMbed1YNzoCPb2EaZRy0YJyXhmk/3
W4ALFdijB+928PEINlqJ7q1N4K+as6aEARXz1UaRx7YzF2bw14RRPqu3Lmj3F8yvUqK3rhz57Ahs
WLwTIvQA27Q6PS7k01DG+ewSIOjnHPAXrn8dLheCVK8K032/HWbGPF+wJ+rOhcZVSOM3z5aKS4la
X2MyoN1dF8AOviQG2PItTXuAHeDakV3OAa1ec5bSm3dr84gwRXE9Ns7RzyaZJjJ9IcO7tRn8BSLO
kT1K8DEqhRmDqxUKwyXH7LuM1vQqEdqqRYIMZ/UFOq2XFnLy+L5kgQxx7rTXIAwmSqojt+iPauCv
Un1pQhBWB+yY5q4L+nFgC3Wb0bhWoR/nBMB1bxofySDtx5zu6iELYRGFtlPVBNoG8kQc3ZM5BVJu
DOjt4PIEjSLYKbuMNvQCF0bYAjN7t6OACyHza3T5Hlbaq4CDsytzaoQ06b35EgCa8dWg3JO7+gop
1yHl1O0wyUTxNeTN3f0W5NdMue+IT+OcWhhCW8Z05QQDgCdfan16VWh3gKGx00s/YzZovlxGLB5H
19ZfbYbZp8c5DBMG38fg4sJK58oEtqrut2big1suw6XqlAfdrLSofryDSQdbuuxa1DwEgnPavB7A
zzM26EccYo3dk198CMyGJzQlGjB5vU2e891uGdoKuH0WdxQNeBhi1aVXK0DIYPtdIxt6VeL7kUty
6dUCnYqlufoRA14tgyv6mxk/WlHigTMf/5nxVY/mSyDQDuKrfkYZ8yXwFQMmRd5GqesDpU4B1+UI
z99KkQJu8G3IWddqyJ1H5euVjH4tZ0YAoQhsnDdKGCMHQIhvd2J81dMRbobc96isvwV2AMdMgZf1
JJQigFABVi07vZQXgIbcSCn24u6RgqRnFjxYZ9TmHgVJKnlMd48QJPhfbhtPJPO+SnCMcfvqTdY+
1BlWFYe3LuwO4HjKW9r5hCAlYSZAgxZ3xgQjmrAkuzNmeicgSjZ6GTNURASMbZdeqZC/YH1t9LJR
+xQkAELB4wkYCDCYsLDhztjqC6i375zzrk5ATbDQ9hPSpmOHOutj5OzxVxrkwjlrc9c1YACEOOM2
Snv4xJDrwMYbJbS/LYNzCvBE2qhq3kQZzZGqvHae1wXR9aqzh13K6VuLw3nVMtsuc4zBBEUFIMRX
MIdeuP0EQjO555hLIxAa+320b8gAVVh7diWAGF9Q2GmTq1pG58bXdLBXd78F4yv2Id5CZ11d4iFz
dTUMTTQIuRCSO+OE+TKjOm0Ti8p4gZJScalaQoIkL+J5PJ92AcRJQIQ7T9haCODC2GfbNYyS0V8m
2nTvEAAcjOjLs32WTDSYvl6tnT1CW8UUrueqo4wutWFG4CVXYmLhL6ClkF0ZzdgDCN/YondCzF8s
taThz9jnC8xVlPzSM8KsGsCYfeccbR7T18S0SlcCVOCcMEqr1VsX4xhyCWOXTBrs1RheNCWKPyPw
WC9h7nLC1FVIkBMzhV1OmBlh3KcESOvyF6Mdco+pu1q0QuZg1uzrtFoBaGfJbaeE/lYVzJmTq9Mg
k14D+KVkd0Y+aw/Coe1behSftQszZD2ZU8FfM8VYkrsueps7QIert2/jS2MTbb6Av9KEiN51rYmv
gK5NuexYzkSGXsZXyS4SvY2vPN3Vt0jnCmT0zve6dgTj1iAluoujgQhBCSCd6K6rgBKA7m2/tTpW
o9AFw3At7xybIKsWla2gY0gqkXtPileVNGnETG1khQv7T42v8GbTPzO++okdIsUNwLEovX46nCiv
OFMCFJdRutQWX3Egn+VNuJ+IAOEAcAx2Hu4ovs/kdFn//cQOke8zIzd5Z3tG6bIdNKsYo72NMg5P
QBwo5D62dVnjC0cIcEzn6TPKGl98xWkS/uZQFRAHKKjM7O5xhFfHl4Tlz+saUOwxsHzcSlVjVjGc
C0bfdtrGKxTiCzCoz/20jfEFs6plCYA90z5F7DEFCbhbRmmDiYKkNykmcOZVaAwY90WCbs6U2Lxo
z7cUXEry1gOZWj3aM1AG+rrufG/SnCEiJriwdnddqxft+ZYOgaF/rJVLBZ3XRf8YWDF17w6lkfgi
1HbaGxNtNL4IteifEMwqaMbed84xyWgsQ1HHdO92DjTue0jR2yODbuQhdKeEMZjSq8x5ee6PtBez
CrAkDW+POWGPCeosuavPUFQdhlV1Z2SIFRisN4/2NL6wqpJdOSEB1h36c7r0AsQpqVymo17Xl5Y4
BsZDhoKOrZWNO8Me7nEM/rt/+jKnj/c3AzglGOajezyUWbZiQERl99whyQZAcnRpUiDJYObHXd6Z
RDiA6dJTrtFbPc2w9PXSfDwrmB0sGXL5KI6akt6tUfso++pNSboK6ZPDzmk2XQ6yAPdkuLeptAyz
NefiSgxQgYFbddeUNmw7MFqm9Xe0/610jDLE73MZwG+4zgSvHlHO9aUpAfrnWwlV++ohBkV3bRrC
nJsw+eImeYxBFAQ+XkbyccYaGMHT067ZjAkWIZ8kO8KdEfqPamY/Q2uCRQacX2jxeH8qIHLMTLVw
V0+IHEOvxZNi9H+lO3j9fK8ZvA4GvB7dzzPSiyEucA/HVCYh1DZ3DWJNsPyqfGB15U0dkBFj9ORq
yTpo6oTm3zIW05kxDqW9jQkWGa91+ZmOM7ZQYVLE62HuSC8Jl4dF4et4mC98rB1KxxsTDJQIbWYX
j7IUYK8j7MjcrCuTV1mgzcOQ9JIBl8fdYrD+L/IqrN/sUhUmGEMUdvx+477PxlV7p85/ZlzNHxlX
80T2zbiaJyJsxtX3KNe4Oo9ajat5OujNuHpGecbV9ygVJ3qkn6T9Pj9myM5EHPnHkn2Wr59Kmuwk
KKO6t1GG7JCmQNoso72O0mQHqXB+gwjiGWUIykf00Ss1ojOqjhdUfqITdZnRpCkEPkzKc+8yypSi
hB1Kz11cR+mklUgLoNKjuNFLuzCh7zqdITu9jBuNqYyVhdSdPTK1NcOUqxu93rnRIAHlqcqZEZJm
YmEjuzNChoxM02T7lnajVdH8UtriGWVtNKKIJkUYnlFZW74S14oL1L1zpF01ZhQrZxmlHqGYRjri
ZaMte9QzTlACnNrcGaEtcPmvpIHlWyZWMDG+b6Ti3Q66mGCn1Tg8emU+tOUUd9obpxbdju1KcFnW
pXF/402Ls+x8r1M/QfvOx5DgUmL0VwNHBPfWMtquhinP0IZeH2VQ2ZfwOxqD5QLuq6jFTeBDCEBQ
WUcZQRKZD906A76fUeZJiOHqc4i59YwyAo5RDmVKsOoyo4lfIDuEyWouyyj97CWv/2mIGHxm1IJX
Xv+hMjZKmMgEvuv3KmE2yygtunBhK73QYZtRh4XL6/8FpZZvqcwcCl4gkRCLS68+aMTGlFxKDObu
50AY66wLoLLFmUp3KUGjpQd5Pz/zBMUz8HBp2eMJiZiA3M37ut7UJ8Ctrvu3bLg6cUuSMhDLt4yo
p0iFSth5wtQmBG7pTPt0V09RX9poyaMqIyaAvMJ+O0yAfIUYhMTM/ozMuA0YltzVM6iqlpT3EzJR
DgS7SfxZyygTv0CwmyV2ZJlRP6tKUPuUDD6HEnzaK3Wo1ZtqiBK3M3dKmG/NDlEfJJjwzPesd5CZ
85G81WeYzrBGUtr5Xj/HQZ2N0XLdvqUhTobp3CFk1U3TEQCpQIGOMIPH0ZnZk7Qqd743cRWRntCc
m3cfgW3oCS11ercjs5ZGYji0x4W5RXpCpY7J+YQYVwE7sIfhrgtGMWtK5+jOyLiKnvuM7mlfoe+9
7hJAQ4kxITGvTLnzHcrgrwIzaD9HG1dBEDpn3UZpLSpxFRKI4t00iasorSm5qkclidvp3Z8xM3os
Sy2AM+fwQa8m7LJ6VGXOYGW53OpRFWR/dXyp+vQC54w4a5zuHhuBdmhlv7V6j9B8AGi9+auH5oPG
kmo63ii6OWrbMcC76tElNkkDOmMACVefvVQXM0m4ehl117U6+YXh6vXOQD5TFWYQTohv7R69JFwd
p6jukKlEHcWxolDHm+c6OlZ8bcXnOqC+Pl1JzloTWfJttnUpuVqJrEbqCgOYhzim7uShzlFTlZUF
JvfurquXF2ia4s73pqo1Tghk9REfa1+PjE25XMjoi4m7vHO0WT2jLyoU0a47TA0MSJMBxLp9y1SR
WELfz9qq0WkaWbjK01bs3AHF13r3ZE5L4zVSGCF4XMi4CkbSpuxxIcPVY7oqi5y5UCImZg3B5cJG
/FVvg/y8rhZYryXtVsDboPZekpLk+oGQzo2Q8giezGnEX/WqW3mWOY3V73OJO6rVyRyAEjhtEsyb
sbMuCgwshYbqz+zJvrP4b5ihkZ6Ww7MEY/ID+AGaahumX6GeB851mLFgnhfObZjOwmZ6PvAeGGcb
pp/3YFHkGZv6monnYAEl8LX6mk2xhn6HbQUEtg4zhrmE5kfmam1rM098jPABv1Z/UgpXnnjcyasn
ZZrPqIBh+6TmxbDSL8QsuG2YtkkZkcYAxJ1uxjxnSFqdkNn+mUqqT2jARdswEyUSGVSb005e+7hI
Zz/wzD5Mm+iJYWkQsXO4dGO69YBhGqpLEMaTDD6QRH9tDChhtohPEFh/MH3qzMPlkFToiumUoR6H
pELDAMpJHdab1OxROytLumtj8bUA23NnJGOrd9YSnFlziIk+wQWM+GOfyb8Sr9VOrfkp7931w11g
aMlosUETeORlVjUs/xH9W0/bEleBXS88urHkHs6VMU7bsDc19/LoQTG5zYaGGGRwTHH5TaL7Y41l
+GtjeH9rWoYYgkgVH4nR9MjL0H3GhUV1s7Tl/gSZ+MMqBBcJvK/NVPsTtmQlH/ewaIzCCFAC32xh
0KkA8O7rLIBVALXBAnaelmF1mgElU3zVVqABAcFoCnhbKIHVdWZJirwmZ5uRUdhBdC8gKwhmlrAu
/qSAfiVmaFT/a0y1boX5PttOTYlnSss0lKK0NZ5ZY6eE0NxTKJXSEowZ3LvAvkYSM1ddGQIE/xoD
kubD12DnxhKahismgSBDtaU6fEaSPAN51vB4HHrj1acZpg0DcORXQpLLINC6I0EOZpcrGZsyYQZm
hQhM2El+xRwYU+yJEJZDhESd+tJrawq4rGQWkHS5sgKXwS4LrbpnVTPf9Wht+GsrfNiDjM7+pEzR
HlJb2RMhkqOdK4uGuV9rIEiATPWBKqNUCC21DtenAD5qkORa0uhoFhq+TULMt2Gmz+Rgvk3WzGsi
VTrLV7HeiTdpE69Cj8mXNE3cCgSXrlXRolgVILt7sZq4H3oK02XyJv4Hlm1yrYrGgmtSsXTfgknr
ZrYv5I2viyS1IPCx3xUhklvQB61Idws0gtPE6vxJxQvBNwhX9IoZXFPXdNNnypzMnPMHo60xKZOF
oIa/08HanyDLcPmtSVpmr1lpNm2ji5ehYsPupF3cDOxa6tKtM4Sqz6pQnhY1HcoZSrK/P9PPFnh8
K3t+aIKno/EHGQ4UGC/79RmmjeaY6HHhq5n7tRSYynrbYelEiiglNma5ENn3MBtAFIE9A2sEbcO0
pc6s9zFuOyydTlPql12xdeswYzRLpFG6eeP5mo55oW1dIp9TXIJICY1Uc/V3KjU0MuOi12E20Ial
XAC4hk9epsiPUPLwJ+WLY4bN2fxJp9g6cUaXvGKCXx1PtrVp92QQWyd1xUimWiltnZaHTxAWr6cF
noZ7WEzDKIybmi7dxD2cJTZkG2a60hIG5qA4xAxjJgbxc9mHaR8rwEBinYXsE4RJXYWw0idIDyxg
BzHrsiVrmgF/xlL8M2VgV6mQER+GAVoAYzdfOKQJixPXT3OvSYeHJp3NEESH6DBrHma/ZnLTEhcA
ryYGGXi3HgYdEG+pSnAZaxi2zqQeau7NYvJGBF/24E9a4ite5fE98rI+Ps61zeDeLMY/lRTHB0YS
L29PM3d/bbStoZWnus4mM17sjpCCe/RXanyPSr7Ziq4QDowQHP7RwzxpV30pbwuwDvmMB6DtTipG
My5qny55xWiGrAz+zRKjGUeYfIFfMv0SAD6+iGblsRZgYkX3TAs7alzFgjxRI0bzVS3IpRtw4F0u
yDv6Ahx41wty19YTY0hK87XzZebGoulmkkJoUNSucYhx6VYWdhlKOBjzRLLgwb/RPQWpLvZtdxzp
Jv7ab7vj+Zq2sAQjxdaCvzaImiaFnt0zveqQ0bW7T2rsXGKkHhTisk5bRm0CvnWfIE/OvAcaK6u8
Fr5p+3R7sua3SU1CfHjhSFn/zLuAzIiPPPvpnwLzv1iLpblseWfO59R88oLfCq+Ijy3FewsAF30Z
cifPfwKNkhffcbF8uIIvwbiu/QPuvTLj8b19mPZQSV2ynrO6gLqmTaNjAdqj7hzy04D9pvDL7xk7
9atsc9LAePM3fg+zbski7bau06z1QLEIxQGDaF4mwPM1k1LR6IyHhtmG2ZyKQm98vMTpeVKIBUj6
eL2gnyfluxb4LO0EMT69wkItiQ0It2HGdALsgXFymfzPpNqnx3ct6Mi4E8RWA6usR1PTfgrv2i3A
GIt9PwVj7ACBFICBC4E8X9Nht5Lfjv1Wn2581xqp1g8EYYY7kHEa/to27+WRIOKWBIAe1eUQSXLH
+c/sckhilh+ARVOH9SbNfcY0Z/HXJu9aJYadLa1NxFoYNWkOMZnu48VUH8UhNh6WUbMjqZ0ae60C
o85S1JUxMbh0S17Rj+6kMNXDFf7oboHpxYUJ7/ukpn0Ea7NKaOM2TE86xaKfcT8FYyQyeHbE0KdP
EHnXwveye/QSGNtqbj733qWj6wfhIAG0TLLJ7hZYYjoye1vdBZMdn1jJtavDMvG49IWCy/UF1OYJ
60eHWVN0mTyXDHUCNld3wRQeY5hj7K279/QuDj1mcK/MVR26hKjYUtONFcpGnb243JuBn6Hkp9Yy
JpaW7wNzTCUGTTAtvZcxaC1jomlZ1CHFEl2CsLkGG5Y0fws0xO6+Zt4WWHGazoLhbwGmMHT9yMHf
Qkks2zhL9nU9y0mzlr++ztomyjjTkULu/qSFXQszpK+LQwpgdgk1KEYyk0IMplFvN9x5UohBQPah
royWllIuusGAyj55OyBBBFJtPt3Y2Yt1pbt/puO74bB3T2nWpRij0vWmnViA7M0zaV1v/JKB5Y21
GLTWH/MpY5k+h7C+2aRrRylKbSkwEaqxOo5LEKmDVuLtUzhPyoSpCEuh+5My+qyxFop79FXQIBvE
+ZMKGsQ4n8nFyykF5F1FKaWoC3tJujoLhjWzR2MLLlte9dDA44p7tZEoZt28X1PPR0/8lsGG6p5q
3x/x24hNH712ThG/QXFp68PYa2DLkccc7ik02AuMy6++DLkCc6WJsnezrsjcMTWUepNJjxmb+tq7
gtMTCl/BFWMkQnB12GNK1OgelY3FimbUMC+/8yTOqDF5Ni7CwTfGoSBo0o5aHH1JQJc7v6WfeuvC
2zv0QwO2n/DM7q3rJ07bvXX9dEximcJKvCTbeVJapoDkl/ekn1gowlJo7AWzb8GanHxp7/VCvP10
9cTk7OP2p/fTZRGTE7D3ekI/71RCKeLtInwmNQXV+NKebxfheac0OVPpY/qTsjvpbL19mFQiLkYv
+xZswCwric77xfh89DABRg+zNndtksdZ0h3s9qxNm0701knY5D6piYRlH9Z0u7qerxlvnRSXmLm6
WxA3HEDUZcWctyCyqISo2NLYkmwXArvZZ0uYh2xwnap7FaTdNDPW9qUZc42xD+1LLT/DtLnW+fD5
pZafYfoQhjyE3Gr5TI/BKjpfavn5mi5JxxZEBXZp8g+Bpavnl1p+yPbGRoRQvNXy9zBbvJrx2Zgz
ulsQG5F9zfdhtnx1YYJIj8O9MeyBmHoZJbo7ZXWBkpgKt+9Um5KFoYStxeB/rUrgtT5T20BIAq9b
yy6HZLapH1UfvXFyXo2GZv0w6W1Kxn1SY7/SRsw9ZHVjTAU1iXCN1ZeCLKFWGzhi+lsAv43BOG6X
IAyEBRIoYf+aqR12p2Zq8aYN0yc30xNvS3Kmd+vZmGjUfGMoZxjT54LR4abNUedT2R14fd4Ckz2/
A6/PBKl84fgKvD4e1pXuKeVxvaOXQNgp9XG9KyOmZE+p+IKrdJgdQHdZTfrOlIRZ2qJ/WGw+xKaz
/nWWYtogrgIOxlAg4ILoVTDEpDESSY02my9UK5HU1bHUQwTi+ovhTt44f+2KXY1tujut0JPA7aNU
9wLeVt3sPpLCnWKj1JnVKegtNIY25FCLv4XGNtwldnUXdLQpAVeU6sjelZEQ1w6Dzb/1krWZctG6
3sSugt/EfenulLGrMdXWfdXG2NXIXqXR3WmTcrcTc7sXsAngCl0BfNuZPC2vVue1sW9Rz1mpDxOD
CflWpFGFq3Ybe0JeieXeYV2mZGohuGwpaZ4j9OSbMtK8iIEj+zCTGEuUl3MOPpM3aTKJz0WfINJl
EgIu+gSRNpPSb8fjtyYeg1maLy0bg61gPaWdLY2fVuzXHpSIzrrs0NF+fWs//NB+nSeLfyk8tA7T
Fr8YpnWOSw09X9N2WJIeWfN6ZniGmapCg0ImXc8Mz6SmxByry37pl2fYG4sz9Hmnu8zTMdHihKUO
8bwNM7Gr7Iz0nUIxT5cl8vUrS3247WsmPjTDqit37Ooz7E19bvxtb/spmLTbWdnO7IaLz9dMUmVi
FlbIwyUIu9Qz8SSqSU1RIJYDpMzah2n3GgM/IYmKops2TCGyMmR93Se1PZKYQpHvnNXzsMIUinLn
rM7TRZZsyVyb4l4b+DmYs3pj+3kSWWx4O3u6c1afr5lqcVRDuDQ+I7Gkdwa/teDvlLIohzsL6/ma
aVTLp8p0Z2Gdj56BnwDGrbt0k4a23+6OZ226sU9kNbh8P26dvxZx6wdLwe5fMyV7pD7jnS15ZHKo
DCg1TD3dnTKpEuZEDMGflA1rwUflwxYKXzS/otieYZogNTKuts8PO60s00R3uT8p6/tQZnRXcIkt
mZgZ6t5T2pKpzz58aclq3NiGJoj1XkJawvBX/GYs08k67LAXlAzRvYyYVBlgJvoEkQ63tYTe3SsD
OCaYQR29zZZkys7Xg8nxnorJ+Z09cyRIyaylC3vBJy+wGNP+jLQ0JidMALBwDO7R03sJaFSVBjTD
AMnqmE2LGuOWjDQ5uxY1Zhg7A7A4pT9p76yaFXL0CTL4PhDnTD5BwJbA/1HrU3300KewnFL3hUOR
AqjS6t3bqWRVppSbUrummS00IMYOJRxMC6fJHsFNKXHjNyOUShaHmK63TH34SuU8EkQa2uavVM7n
ayY+lO9RX6mcZ4KwxyTMteQDDHEkhhY1QUzrWyKuEct0ZYjYkglnqiDBu3TJMMfo/tpGxV2I9+P9
mbyswZjTHe59JC9NzjHKHe59nFTSJUG8D/KtAXFFmJJavr0p2w05chvXR2zJut3sla0El21vm9g0
uE5fDNItGVjy2AeNjdUuElWg/zXBbzkoDWjMuhroWQ3Bh8eN+T3x6/nliBwa+1zmmdRhGcuUtmT8
en45wrwm+C2GmV3uFVsy0SPjyt5G/Nal5qzLbyyKwQob6jr/ni9U8+nPbMkYT5dl84U+w4y/cfWF
LsO0Wbf6QpdJTTnvxRe6fE1Hm0pUPmRW2YbZqkBsD16z+pop8M7MRYhe9TVby5YFyctVsWj5mjFg
v4vZbsM03VhzLdwZKs+wH5dc7+nd1pd6x+3+ufDm0GHs3Lb8m87Lvc8qEOUZZvNQmTxRrqIwyzBt
4bI9U2qXkb4M09Y3PURl9K6+Zggr3uMu72PO2jobgLJv7zbM1lHqbB3VwvDXNkT0dTEPl6+ZXM8B
Fopdf03XLwd5Q29XIOQzzDa/AkFGup5xnmG6Qn6CmcNOzXMfZmz5yjqt/ap8dKYbnapZIgfcnYob
NNwOOGfYZKPv1OpON2tFZlY+0ju1wa2TbHmZOc8wG7UqDUXui/zQzbga2cOkXb7XZQumlDn7upKV
9mGmxS3TueqV8HcmCPvSzgiTf7hMXviCl+sQlXHmkMKaHyX24XMI0+CgG8OY7k7ZAzaBeUv019aS
+CZmcs+UqWYwXGdRV0avDQRhgcE2/J1OGOk46Zhd7iVc//Yyn0+BOByofsbq7pR5WqEDZzV3bbWw
WmQcSr5pfzo4kiGfNTX3FCpseck02xnJRF9Kd5regn8KEGwvKaboCy5mL1VWaC/vDuujOmmK638L
e0CMfFFMl0MIbDaak7xoPcNsz5Uu9WAk4m8ZplUtY0IzDM20DbPlENgKql2Y+RlmQQV7Qd15csuk
ptQgq33Mq7qT8zWm+o3YxFxavqYhSsVOA9PH9mFa4fJVvLGo7T7MVNKnx4S1b3y6dcmxiBIu4tBt
rZqwDDNxWIWpzFeUukMQZggBX5f9FMzD/mSNLdgv/tFvFQnPW2DqT5njqoSxfM2UGgx84mt6pyb1
h70F+5Upft6ppP6UeYW5nRlJUn+kvpr/NalVk0ZPLiMBpECchjn9m8UWKr2m6+nAWVsjW/Ilwicv
VWSFMvIZ6YIW9XpBdc6U9VhZXKa7dyFNtmUAYNwnNZghAGvNnLv6msYMrC6DlXXFlqbUYAOT1zoV
v2nMwEL2pfXYXIJIJXswSJ4uW0op+zKu6Igzh0iEVQoz+RwCO4hMHkr3d9oC37Fj968MQ6dgTqTp
ixoWB8TfF0UQ+44N+daLPiwbOgUom/jEsA/TZzrJby2WD5MS2/M2d1e+lUC2xNXy18Y2lTXEq3Dh
QhD9eB6ZHDavwoVnukHBSyma5l9AiYnKsc7o7pQP1IktSpK/08LAv1pj8nfK9BpYf7n6k7LzJTti
+/qU4BNs2eP0v9ZwAVNsfR9m37ELZe8IvqhhTBRk75WCfGYkSa8Z0NHq1ut8IxbCByRQ0tI+UEtE
X1eHZZ5GpRR+LFlx77ta+Fddao9uUlxh1KxUmwkBupJ1PnHInaxTP2hAJutMFvPfh2Ud/cXiCrMk
9TUdh0A03r+qtS3D9Iu9vM/c/qZlmAHtA/e09U9bEIw0NMwzxRUEI7GYo3+m0kooGLiiLQW+Y7eo
r4wpXC4lo2ZXatdaChPqI4ziAzOp5xfTUJDAPlBHFuyeabhb4Ds2dhBqdO+p5M2UHHvzhwn4iTl8
2KkU6ktFwWPzNQE/ACK+DGlMaLZHb17Fu7hXLi+zQxCWjJLcH1eSS3hS7letFOewmPccoMSrP6mU
Yw5RqY/bp/ODl+e3l+OH1l86WgprGYlnmLH+WB8iAZjlfZh5oF5enp9htvADHyFbbPvatF6WmCjY
1eprZtL15XnZqXn5XF6enbWxZt43nkmnqydl63u7njSXtZmaefnVxEe+DzNGYmMZttH2U7BlJKI8
bsQP5F2r2ztHv1a3d45+rW7v7HStD3GeFBqenY+vt8rzFsSWrFja/PC1IbAn+NwrZSSYcelzb2Ia
YmKPdH9tTEMMjJvz10a3YGdM5T5MF6WAQcEWGyO4d0GqTTAio/pbeLqvbZNq6+9pv+buFHq5pxb1
TvUW+AjZWW3Q5d4kdU9Btg+TQi8DjV9ZX8tO3/Rgi1D1I7pru9qrzRT2W29MJ1bgayFfyO1IXihH
aNJYqs8hmW2hxx18cr71Yplm3Cx167WRmKUwZA8fJs1MxL9jVJZJzYM8TYA7RsWhm1imd4zKMsxE
WEH3zRz0PdXGNS1TAOia/FNg2fp5F9R0dkrLlMHx/gW8qtvPT9ybwUhZHlb2SbVbhN3WGu6+fwrS
bo3O0uDSDaaJ9Clp2T16WqYBBsUYLiNJvFabWqjasK4hkfZd3SydX8Pq9j0OpU/NTlnPD1Zs9UV0
KdKbQQtV25wtPY6M8wVkhFWIIyjkYC3TCkaij8ZV4lK2vsQrfuYsuL7auM3qMpJ0aKP+UBrQWKb5
cbI4Z8q69fUOZTlfGUBnNoTISjjY+hCUlrDrsv81du6N4SqjeyZvTZXuy6vt0DPMmHWs6ADDtBSX
blKob7TbAXHUgDQ5B0uZJX+nfL1vtcbq3oUKxAW02vLwd8rCXWNc7XOeYdrLKaUaGqjrn2kdWfpg
zu6vbUYGxlR9ZTR52Yw5pabIa2yikGiqD4VUbQW+ABQ9r2Sos3AAGODzyxWIdaYbXV2xQvnup6CL
2LFQH1CXtj50ngIL9Q0o8Q/IQdJwRkyp+gRhTza28ws+QZiGg6OPPlJtlbmNX88IRzHI0KkChZ/V
YZn6EAw5y7W+xSGfaw32t+z8QyOxnJ5xtlSXZ5i1/r6bbG/DTDeyCEOsjOuN93uYqdW9eRLLScjQ
+gs4dbU2E1BE6w+yQ69Nm5x0ETKMrPs7ZTXQOG7vSTmxkJh1bd4veOed0qyr4fbslJOQkeIKCZBX
bcFE0bBCVbwqPjprY0pgZvut/WteKfTzpJfvDyCquZNevr94PwqVk5C5fH/pSnl+hllDjNCiXB05
lq9p64+GWKvtkkXHMxVDTGDlPsy4CNn2qY8cfbpRLABD5elPylLo/Y7xXuhmMmIC/R2tqyvzwwC2
1Ms7Qv5QLDwtfL0SpM8wtwRpOrak3EqQpmMHUsZAptHndQuOzX7liQki/jLBjp0ktxKkztpYD6al
K0rZWRuzmHENJIw2HduQSqVSKJa+79TKIuw05qx3aoIbwRsAAWqnVhZhp7HWTzvlG/voVwXEdOxF
ujV5SMcGoozog3Tr7cOkAzCg5K6/ZiqVEp3W2y117DS6hyscmw3v4QpHuu3hCsedbg0Ul2FGZK3h
Cue1sbVOGjNFd6cislgfp7sccoksSI/q71RE1l0S8nwKiUHgUN5pP1NbNwYyJc8xd+41GZfQfbON
ELvLIRLVkOfsalLzxARRM1mRwr2AEtVQ0lWdcRlmkviucIXSXbrt4QrnxvVbuMK5jzy7N7Bjpxqm
k9FggvUCNT/do2dUAwz5+wn9abL8psnDBG6rStQovcxgTsDrrBjJfK0y2rBcLeiWLegXlVpYOzkp
LWPLy4wX28RXXxlJn0UMUIykTQnm+s0JzPBhUr5EtVY+3AV5icqjaJ31JkYCt7lWxSHvekHw/lX3
TKUE6VeO5JktpbYoA0ijK7jk7aiMq0DHQhDzxFQlR1JdZ32mUoI0hDZ8JmcJ0tS/TNdzz3vWjWGP
wn2YeTuCQVdm7ckXg1I3prRRfUUpSXzSCtDfAuvGtHkVqXW2AINuljjmhy10JlBnLQZtjETDYbF1
jr+2CUgQmxGDJiq4U3BdhdXPk/KJCYIrF1/tSglSljBQBNE5a5EtSkrUd8GUl2GLkpq0dtaTZmhA
FhPwAQZz/WLoQ23BJBjyJSrf9YnP2llaRrAwna8XpGVEvtumOmuTlhF81HQPS16iMls1ucCM5WXy
NMrIFPlh8APdHYpDTJOHDMsUOFoRRMe9SFstHI7iEPMSxffA0UZxCcJoakhyIxxMa0RG74/efA3I
l6gxLA4x5WVwWEBvobvkldaIUFpdKUq9tivX70pfcghy5fr16oMfNqAABO0KuttcP3ZD+vLAHkWN
RFwksFt0mZwRF6OnqTGSnpT4rZSrmoezBeK32K7CTc7XRuBjzlDa2WyBdU8zYc27o//8SvYecfzM
HM5PU0Rtr7EDD74qz4/52NcxsgNPn0l44xlmwhUY/RV6Ft7Ix4aNgGM4pnl1vcjHho3bY9oyqReW
70y6huXnY8/JKOI0VEl1WdZmWm0sYfkO3UScpv6JIBSnfI7dCWLiN9iBBxJarc1GXCyhFPnY+fPq
UgjlV/Zh+iVkNWCdw5pFHHBiNS/DzNNcwkVOszeXbgl6mRVZR/G/xof9VONMLnnZagOK73oPfIbp
V9kt3v5Mty3e/nyzUpEKkyElf6dVeqhfdfDOTM4eGiPHqzGUs9M13v4Zpl9lE0s1072S3DNl4VNp
LNH8tQ26V9r1Kusc1tUcIw5/0s2APU+6GbDL17T1txqwZ7ptBqyztrXw6bI2E/wQ2WFslA+TsjlG
yiNkVyJJsZqvalFnicRiNWxQP7rLb7mydOS43hidtUkPjTsd3tlpY/PMEaZSH7r9YGfzTFh1im46
1WKALStsRF+o5lnpWQvDv/VXRdMYSnLXJu0Hc4qtujsF+KfLLH3QMlLRNKdUg3umhVl1WFn0tYyU
l6msjOUSBFgXBGnlg5YpQG4D9kTsrnyTLoWsyhPdCwgL9yVBDR/W1vgSEvv4sLae2EWqq1tvAgzA
SND0V/FkZ21QbSPGK4HXmRT8NiRsyz8saECQ4wruOh9WheCCBXD1CDoTpNJlALs/+NzLfNWcZmzJ
XRsLn5YQY8rumUrhU3Z28dGgNDNks5DobwEaEEqmaORgqtBIM5am+O2nDqDLA2ko9EPEm7/rB3oO
oGeY6wB6hrkOoGeY6wBaJvUcQMswzwHkrG11ADlrWx1AyzDPAbSszXMAOVtYHUDLpJ4DyNnp6gBa
JvUcQMukngPImXR1ADl0YxXHWYZiJONkgSFWC/T8fgq20j80wqTBvH/NDINGKCMqJjdF96XnJPu1
uIclnp0aruCTZZj2nkANgY1qVoykUWURfrsVx5G87Bsg6kVNqqFsZf5g780/BQJjKa7QfIKwuVzD
YqbLlolFP2ATZ0U3g3jZWQJgYD8F/f4siai5XMWCHIIAz+Dgr1SX83XOgRVa7mzEs6hhR4CZZmq+
qCEwDtAII7trE2AMLPvhZgkw/spGdCbN7FNxZyMuX3sTFVzFtbMPe1OecQBbNJ/JBfHOWNRhmUlZ
nrGnq8KkQ5AreDjoLRjEyyq1aei1mfbd84VznXpt2jy52sGF4a+Nfbl7KKH4svduBxc/3CwJ9w0t
6ZtlEK+0g7tq0Ttro8umSsqQd+u/2sFln3uhX2CIpVJ97pUa/uKicNWHdPke2Nnw6VYbmy/14CMH
iQpm/2P/6OmLibVclW2crzEqGEKuKA55U3cxQzqoC2ijghmlOabmXuOLucJ9leAyz/sExpGvjC6H
SKn/gXOIH752pbWG5m5B8lVnulqHnQ8LMgtWc75ah53Jy7IwLEMZk78Fwc/9yvN11ib4ebTpC3xW
cYQRc1WTPsu3yrJjMJ0VeW2MMaM05wzFlW9SxbFDMX44BVYns/xmGwfQLzm6PizjAAKTp3bFpzkE
ITDD1zRbmp7hAGY9dIW4jL3GnuEJKK66dGsEZh3K10eD0jO8wEhUqk3nhMJoYbcspU+Ns4ChyKkk
RTfj7wC/AbLkD0zeCMxSK4rJzTC+WPZePxGEXePoVVc7NeUZB2vvDKU+bN3FzEDHooSqrbuY6Itp
wWfLRvzWU2/N36kUbctjKLCtPTvEbwxyTf6kk/XGowFmatLO8tojXaULl6/9/c/M2h7fXo4fmsPn
ZuBrFcd8bGO45dLmY+NBsXNnvZ+Cz+2715bs+dhMcmvJno99HS87d95vbue1rS3ZnbWxPx4+eXHa
mW5rS/ZlbcYcZu/EO4Te2YI04cxV7dSYw7RzZ2lqpzqWKfarGNfl1DsTRFqyj6Z2ah5M2K6FLei6
vzbGZrd4dQBxJqXbPecr42/5mjGHgQNHuW3wYx9R1kvElRhdnak2EiNfaaDkk3v00tRgjDLVXdAG
LDAqdHMrapipvrjk0i6Tvgvh/sqlXb6mjURWMBjhSlp0CCKd2+Nt/Z0JsoZNLodl4iGXsMnzmUpA
eK1X2SuHvMwTgWwuw731t3Oq9+ifwuacOjefp9u95dCivwVGV2YYHh8mnUSVMQ5/UumkwB5N/qRY
FU3OpHb6rsF7gF2Xk0s31sBMseRaXVEjndu/Fe55bTTV+bg1XCbPGTYREEHLLlsyCHNCfY/u043R
lTCzoi/wGTYJY/jqY+lsobVXASfNfVjVLkKGTdYUleCynRQqax9d/cydtTEzF9IhqzM1xjXrltda
i7sFVvskJIvFJS+rfRKSqVtvnVNdWkvM4QqHkthQBso3uzuVdnvgSnUB37XbC2NctSmWSY1xHdli
TOssa4MXthjrM/jkZWYu86jVFnTWcIMMAcBTW3ibmVvaVHrhXWYuzJOrO7pzWLTBy9TktTWjgBzS
HB+EqoRNhniVXnfIy7DJjK35/Aas++ohXuUOzmurEFyVnp3ocgjY9tWlk6UrQ1gMin0Dkn+zpCV7
TLdHxum1DmwP5B6ViNaWaWERgH6/NpwnJcwrjKZxBVclzKNmmz556fUooxRfiUuLhMngYJfJpUUC
jmL6YvAqLZXuZwS3JfvoEIaKkUxXPjacLbcn68iWUlpqtvth8yhUr9JSfSrZq8u5N6mFAnbzEb50
bi8jaOSgbXDJZ7krhJwRfpN8lrtCyPI1vVMpLTXKByPlKi01a/MPq0ktlFg1dDcptwRmKelT0InP
kqjSyoz+KbDBMcCg1jLazoXVnC2HGPJKaak4w1vj7geBjm/v0A/t3HP77s3OPfYb3boV5GNXxBil
k3a+ntDPHcj5ughwH9XadMDe2q0gHxsU0jLlD1/QwhnGTtpAZHPfgrbXKltptzviwuncDpEFNH4F
GBx7ZG/dCpxToAe29tuRcT4FmJwhzNCyvwWAdjbB7dEdxvJNrC7Up0s3qcvUYIkpDtE2EdB4jyyD
sg0zbeMosua8o93ODc2ZDgyzY6jD0u7LzNZs8SrCsAx7Z0tCdoTqE6Qw4SVfPYmWtb1LB2bxxeZy
CI1E1rPSF9C0bmcjJCZ572szuXWNTehmKf6ktP4gifRO9RZGlTKerbpsybpMLOM5hsshUpcJlkKM
7tpy4MNyCX0/et0hVJqtz9n6Tjddx0AKLvV61fBZJjWhiZPeupn8w2JuHRtlRcXk2meaJTBgdMVv
xgObGC9UlXCwdZmY8BKbEoPGGdpY2YaOEX8LjW8XKeu1maS5+PQfPB997mBLVm3zhaqEJoKNhs+W
sDhwnUdV3GvqWU1WsYNm9skrSXMM5/XJK0lz3x6xZ5g2dhhzmOoNF4+q7e6iftU+OhOEMYfkm5L9
LTDmEHyp5Jt+sWSDCdYU00xuSgGvoYnPzdLGDlRbBIgKvl4orUjP4uSfqUQwpqKP3hhinY8SrRZf
1BQ2cWARRsWWpvMd6Mawi+wfFputA6HW4W9hytvFjGpSbcWwsHBOQZ2pbaXBrqP5qoR5XpskzUHt
Tv9mSdIcziCqU9DpWrT+8t3K4bxTKd8E3JB9vVCZDNJHmv5hVfZoSEyF9LdQC2P4NVuatTEZhNo5
uVemsvymhMz6k9K1CvmmmNykuXVqQBy1OixT5Qnc20bVh2WG1RfOqlcfYEgKHm6z3oI2TwJjkO4e
2We6SR+9eZevXyY19YeJ8EMYPra8e7KnMNxToJEYRxwfbr14YMFN6tabpDk2OAb06b58a9CnjJ/L
+zCTRQj8NiGgNYo2Jqc0W9eMZHYKfgO07DO7Ry8N8mCcKVFjsghZ9YXFdH351jqU0Ry3P9Hpyc7m
pDNp1aZNTmag9J7zB0Zi+c0ytUQyZ8pElXQXFjgLhw62zD1pifTThL6uBd5v2bnn3uKbnXvsm8kG
OgAW/YqMOvYxZAMdPsxd6OjYEvpy1N6dsPKx/6PURmbF9LoPe1Mdi4ZT2ddm7VwYiTjSGv2vMSAZ
Ou3i23O/+M1R+/Sy119r0KQFBlbz6SYZze2OnTt2QN464zg7lac5NvDeJzXmMJ/m2tWq6bxTqY7F
yIywDTM5YlsK3rmhOaVuDlcVwfPaLtdqzMU/LPaLZ8W564H0PCmsmPZV4dCZlLX18ryjj45tcGkO
zxlG/EA39huFWhgf1rYW0XLWthbRWr429TB2Kr9bqp35TXym9DdW99ZLW/mer+7zyzD9dsF+8SNV
vTZtwAapxtbqTjcbkMwA0buU2Zlu0la+xft18dxbPDLRPt3vz0fyZqDK2kpI1T1TtpVvuRrBZcxh
ECT0WZpLXsnUI1v6hyWZerjMo7qnIAHJZdwByectwIoJkG96bW/67ITJV4l9p8YcZrEOthl2JZL0
i2cgSvbXxn7x0GBRiUFjDksNmfuh6Uhe+kzLHHn45JUyxTBMuyKvMYdpUOQ7rfLc0JyN4NnUeroE
YYd36S+R/C0UWH8TV0YpI+0zpZez1abEoI1bZnY5bvN07ynN4TFGz/6VES9nnqP62vnycobZP6yN
jeBb0mJQ3yxxhuZy1W12znSwkWK7k6nP5IXgyoRMwz166fBe7649Z7pJ/WFcrRrcSas0GUytNZdu
YueC3xQjGatZ3JfAz74yqhlsmfPovuyF6njBfBoK1Vg7lw1N2qw+DpEyxeEuX++srUX2nApa15sQ
YpY6byn4qEaKw5B5fUaq4LcCyavJa3poXg10PtzTOpmEzoQhV0SzTDFMoqHXpk1OQqnKIvHuYUls
cEpTrc2YTtCAsc+rP9F5py2xtD7YN7jkbVBthfGOviQXA7bmNNQw7UlkcZic7yw2vxH8hLAs/tqA
uAaOqnR/bYw0ZsTmcDmkNcbf1qiFg+mzwye1dhuJRw65i8PM1n0OYfgZIGHwrY82GTfbjeBSa+vh
aoQ9fdDYA9tqfwXAHyfFopgi0TW/lZ8asG+P5WcGbDl3eF8N2HLuPr86ap9hrqPWmZSWKQwAcV8W
p1/84qgt50bwq6N2mVRbzTRge6tqp7a5D+47cKBcvWVSz851dir+3HiVwSlO9/khddp78de2BiQ/
w4zVzCrQpV+Bjg7doOUbAJ5Ai2Vt2mpe7dzzFiSEuPcrZ2eZ1NRKlQpIPQV3pwlavoQ72OYZZqxm
Phv2drU2WNZmDNjFznXWJs+Gd2X15Wvaal4zap1JVzvXmZTPhl9dVJavaauZ74FfXVQcunVJ9J5z
J4h22aRe2HJ9KkbSlTDFn5tiKh8Oi++BM6dPpyAlVedVdPdMEFakqeQvXzhkSt2etAwxVnNkBaRc
1V0wX7sL12Sfe+9Gsa1W9y7cjWJ739dmQmEL31XSlV1u1vYl2dNJsothW2F0K0LtBR/qb/64sWTZ
5QfcrkSTsWSBQiuu9VA8UL8W85e/xl//9h9/pF9//u3TvsDDbNUW22Fff/lr4KfC96eOyu/0KVPK
tbBn0+V/X0hh7GvwkoR1+iwHNAuD4ioSsnzNmOGsmVmu4oTnr5WQwXL1ehNevqaQT4ksGlCaYmDb
oJYOO9yb6h462wBlCPPh87m0AUp335DzTiXYOGATSruZYGOKuBCDL23Yx1bsmOBvgX1sAUSUojGm
bmMti7sBjTNpY/Bnj0oJWq+09BUNWjW8KeUKqsXRffKyj22OV16DszZ6pb8KdS7CXNvXgS/M40rA
XMCD8SMH9n0rChXYPrZshNfKB9VAr3Sfo3y4MtJ5tsyqrozxrtIrHe7Ml/OZirsZoxTdbMEcBn/2
qzzvWfOKuxkWavVx41XKlUVaXZkPs5/1/bLG2yZFl0/HsfTk8pvEJIPL9a3XDw7s94H7p9SWDV1m
+9FWlbQ0k0pbEGaLuZPe7W7rnC6T3+1ue0ru2u52t03Bcutulna3Q6EpHbl3tbstU6Ep626mgm7X
a6SzU3F8jKChrzZ1xY88L3/cWVqKGd6YJ+FyiLibU53aItOx3JIsdlefcOjW2XHsrj7hEESSxXpM
PvRtkiyW04d7Kn7kAe3w9p7+IHTZxU0fLOJjznhca7Q+w6yvdqnRWo5JzbtF7NSYWi3iJ337H3+2
pahW8ZDiX/74/wxiTlNlbmRzdHJlYW0KZW5kb2JqCjI1IDAgb2JqCjw8IC9GaWx0ZXIgL0ZsYXRl
RGVjb2RlIC9MZW5ndGgxIDMxNjk2IC9MZW5ndGggMTM0NjUgPj4Kc3RyZWFtCnic7X15XJXV9vfa
z7PPOYAIiEzicB7AgwMgiANqpAcFy0xFRQPL4gBHOckU5yDpvanZpJilTbfBiiYzrTyAFU5F82ja
LbuWZjTdsvLmbU6Q8373fp6DoFb3vr/f+8/7EVrPWnvvNe211h6eAxIxIupBK0iltOJyR9XCbdNu
Joo8QNT7puLFHu1fB257i2hCPyLLmAVVC8sfVP8VQTSklMh03sKyJQvKyx/5lmjer0TqqlKno+SN
m3uMhsZdgNGl6Ah/sddroH8EDCwt91xZvuKit4nYGKKI+rLKYgf1yvYQTc5D++Fyx5VVwT16gZfF
gF+rcJQ733R1HCK6dAVR/xlV1c6qh6JWRhIN8xKFlZHwXXnn27U92NrLQjN/CugTQOLrwc8y+wv8
1LmNe48fbz8RlhNQBN5AAJMMeFrGd0ynSWF0/HjHzLAco7/zyzRY9OD5PWVSMZlIoTBKpSwi8zTY
VUkxGyLKWAM2U7P6JlVxN4UDJlv6U4HpVZrHvqRLMLYIMEntT/344zQH/DVou4FvVcb6ToB/LuBB
wAjANEAi4GLARQbMBmRB5nXAZui4TOiR+DO63LKHzoUtAtwBcABuM82l2zH2N/NYKhL9sHUjdCSA
vgv995o303rQd2K8QPBKLOTn0gUYTwZ9q2muz2dZSxb0EegT6I+C/VuEz8CJsO/mbt9R0EOhewrG
bwCeA5xn+Bsj6c+EjJyrmONqQSM+y9C/HjALsAZwMeIj5NMgZ0V7Lege8CsQOBgQwoniwZOpnEte
4BTYn2TMm+S8MY/OOcF/6dOZQcQ0qyvAJzGvI4A9gH1dfDsV1nYDN2WrI2T+xJx7As5R9tBExKVD
zMv0he8XAajMA5jXToCJl9DwAPJthp8TTNvoTrTTAZkS3MT4BqpUf0QOttFS8x30APpJGQ74mWzK
txRrtlEG4pcP/RcBnND5oqyHEuGD71tgK/+CYqGrEHA5bL/uj5OIDdrnI6/54G0XKwZxvRbgQgzu
BFQL/2A/VcQcef+Fze14DLytsDNVAGxaJWDuel6pBvJXQBeTdvQ86BiA8csR0ycBzwGeFz74QdaZ
AVLXZlKVzb4fgHsDYgF7AOtFvQEKAfWCB/aDwB8k6xU1I2pT1IeoDdOrslZnC9/1Oci1sMZYM+WQ
vxjQBzDY/DhdYsBg8Ir4FImaFevFr1vUlqhrP5Y1vUjUPftazFPUVBd8m6mFZgofpF3Ulh+LdQe9
SwRWI6VPd6v7aZ2oWVFvfiziImpNrEexJgyc22WuycYaSYb8AFnrqEU/9seiE++lu6Fzrnk96vQb
ms4/pOnqWzTdtAT4FsxvO/owH74fe1gSzQhooSHI5QzI3nUKvlOAZT+7HLZu5lsQi/10r4zrfiWe
72cm0xbfEROx101blGWSPg2fCqxFHxNYQNex/7b//waU901baAHor037fT7M5xaxJizfsDSA5sfo
bwSsAAwNSGJ3BixizZY5FGbG2Qao5HYaZ7JTBm+hCTyS7IiTDf1zzOfJfXcd9L/KvqG1yNf1lkhK
UI9gb4Qt5X2cDwChH3halzrqVnOn1pIf++v1VCxqRuy7wCbgPlh3OwA7AR8a8AngU9RjhVy/OBvE
/izPB+zRgLV6vfqOdtbn67QB+CZ/fZ5Sp0NPqU/LqXV5KhZni9jf5dmCdQo/1vrnL/ZHsceJPVLs
c+Ls8/OfirvI34694x9yH95D84x1PQSQBkiFjl3GPrJTbfb9iDX6lfld307LBN9O9Q3fTvNdvo2W
Rb7XzNt8GzDvIZ1naou+l4n15D9LRZzEueg/R02JtMDYz+6WvLAvz9G5ch8g8xKsv8upCHrfEueq
WIfqBqw7xBP6VvJNVMY/pXXwPVTdqvfz2TRd7Il8MWj0Y08X4z3UdXJ8Fv+BFvMhoDcB30O9zBZa
bH5ByPj2yL7P9DHRZ5pHf0PdpfLV9LCpgfJFrsQ8lFG+N0TuseZjA1bQvRZCDX9Kd/PjmHML5viq
xPfIehKyTb7jYn6WcyjapGJ+ggcgZEz3kmbE4w4ZixYZo9tlDSMWQqf5PXnfINMB8N9PVwUE0d0B
g7A//USxFuwl0lYDXRRgl3Hn8rz+N9bHN6ixObTKFOH7Tdb/4z6fehxr6BusLwEMY5HUx/QN3YO1
tErGR8drxPpRv6FIUSOYX568T3yDGn+Eqs1b6EZzC+puP86C/cjbN5jLIhoDej3f4msDbw50kLCN
/pnyfiLOKbtvn1gvlhaKsdhhHzzCB3n/g131C/h7K63CXpIV8A09ZNbEvYYx1N4AwHAdZHs5YBng
Rh1kX5iOWRx0XCX7nfSasllVUN9i/HX+GNbePZSlPkpBfAHuD1/TSiWVblCno+6O4sxQIYc2T6bB
6lGaqv4qz58bTEGUIfmicI5/Rbm8APItVMIbqUT1gY4B3I56hJypmeaZinHPuhR6DFBGQyaQcs1r
QKf6Hhd80savvigBfAmlS7kuIH31g/D5wS4+347YXo16EP6C7uqv8LXTT8PHM/kn5yn0Qk7yHBQ3
dR/eG3w2HXfMVNbSFkC98iHu4S20jN2By8oGmsy+AGww4Ak6X+IGwEyazJexVYBcAOfL6D7gFOCv
AfsBGwC7AP/io+g66H4euEm8FwhQnsXeBYzxRwC7AYf9Y11B2DpTf1fg/6RubVM6LRegJONOmEyn
899HI/mV2IfTEE+AuphyBZhDqNISQJXKp+gXe9Ipbbzv/I1X0oA/8+fPgO2lNBlDHexd5+jPB3DU
fwCHumBNYKyvFHE+/099/G8B+V0OWCjjX0/DZA19hfhbKJDtoktZK+pvA10owGgXynjeh3Vv5An9
q2T/KflDrYxWZ5H91H7QKwX426fm9c/a0Lu1K/jrwA+WdNxFAPww+AGntnEeXC/ALGosWbavEuBv
d9r9PcijkYjTZGCSNXZK2xxGNQKUKrTvJFHn5QI623m4V+Xp9SkAsXUJQAxJAPoWCkDsSAB4rxXQ
Ja75Iq6wKWTJnx9/nZ+aH+EXfwl8n+POnEexp+LO+jb2i241P1Ov98622Eu+OIXn5Jo4uTawVn5P
5/9PgLXzBuBVwCv/r22JXUbsEWFin3gX9w0v7qoP4R3zTVpLdGIVUdvzRO2XYR/CW3X7E+ibAzoR
+N+AGPS5gHEataHK2lGNHe8B9gDqeV+60rhX9kE7R5c9sdHQZ9Plhdxx3HbaRuvybTcA7gH9NgBV
1vYi8G3AP4HfC7kC4GXoWwk8Eu1cwGS030F7PEABPQ5wBAA/23GNaU+F/H2AxeI+cob30P9d/Dvv
H/8p1j8DoPnyzgl/T32H+I+xP59/gk991/Dn/8+w/13iNGzEAXe+NwR0eff5w3ccP0Y+fzPgR8B3
fLXvBO6UFnmPxl1W3rnF/dHA8r69X94nmfGZosTi7izur+LuLO6vwBuArzPthT9uulC85wu/UPqq
Af3kgqDAWWiBCsonHjhafAYrPgalMTjHlrOb2S3sAeZlh5hPKVBeVV5XPlKZqqqBaoK6TK1Tb1Qf
UN/mwXwGv4Rfxm/lf+P38od4E9/JP+BHTNtNL5q+Nv1oDjb3NVvN48yzzIvM5eYrzMvM15vvND9s
fsy81fyWeb/5twHXDfhNC9UitQFavJaoDdPStBHaOC1TG69la5Xacu1h7VHt8ThTXO+4qLj4uMS4
YXF5cZfG3R63KV6JN8eHxofHR8bHxlvjh8QnxZ8f74h3JigJYQlxNrIptmBbmC3CFmPrZxtoS7aN
tGXaymwrbNfaVtlutN1qe8D2uK3RtsO2y/aS7U3bXtsHtn8mZibaEycmFiYWJy5IXPSV6auYr8Yd
U44Nb1PatLbRbZlt49uy2rLbZrQVtF3Vtqbt9jZfe9GJCSe+72j3tft84hNqqpeRq2db2R52HJF7
BZE7oFJn5K5F5G5SH+KMh/CZ/FK+jt/B7+YP8id5Mz/AvzJ5TTtN+0zHjMjFme3mwjNG7tiAFQPq
tWCttxataYjcUEQuXRtrRO5yRO4hRG5zt8jNjrs4bl1n5Hohcn3iBxiRK4wvkZHTfidyuZ2RW2er
t23ujNwbiNwBRG5cZ+SciZd/xWTk2DHexhC5oW1jEDl726S2yW1z25a21bXd1NbefumJ8YjcChE5
n3ifut0Xobyh7FZTfYeUt7AiQlGRt7BatohVt9ej7RI125HUMbRjSMdgkH+lpbSYyqiULqTx7R+1
H2rf1/5me2v739v3Cs72u9rvbH+8/QF839q+vP3a9pXtrvYRRJ/NJ/r0kP6pfut1gNs/ubj12tbf
PtnUWovWM4B1gLrWqz6p+fjyj5e07vgsufWmjzd9fMfhOw4/eHgN0eGNQvbj6MNXHMYOfzjtsP3w
iMMDD00+lHMo89DYQ6MPjTiUdmjIofhDfQ9FHGIH/3Xwm4NfHfzi4KdC6uArB587+OxBWDn48sFH
Dm49mHNw4sGsgwMPxh+MOzggtiX2eOwnYc/ipvesZaPlXssGyz2Wuy13We60vG55wvKA5X6cX0fM
401rTaQWi7XLRnf/OYXyTx26tY/hncn4UkvoD77U6eqK3xm5CYCzhU/ns3ghcFHXUbwHEt7fJPze
F88VwGcZrel/5Mcpkol8cCc98A85g3535MJuTZUeomvpOvVSuoP+SdfTTbSG7qXH6GFcEeoQ1mvo
VjpG/8Yu/TdaRS/QIfqO7qPN9AN9Tz/Sg/Q4vUav0BNURMW0jkroDXLSq/Q6vU1v0lu0h76kBfQO
7aV99CQtpH/RenqP/k7volaP0De0mi4nFy2iclRvBdVTJV1BVVRNbqohD2q6lr6iK1HdS+gvdBXq
/Bl6gJbTMlpBV9PX9C1tZ3ewvzGFqYwzE7VRO7uT3cXuZvfQCepgZmZhAeRjG9i97D52P/aiB1gg
C2I9WDB7kD1EP9Mv7GH2CNvIHmWb2GNsM9vCHmdPsCexZ3lZA2tkTfQr7Wd1bA3bxp5iT7NnWDPr
yULYdraDhbIw1ouFUyt9wnqzCLaT7WKRLIrdyHazZ9lzrIU9z15g0SyGtpKX9WGx7EX2EuvL+rH+
bAB7mb1Cv9Fx+pQ+Y1amsTgWz15lr7HX2RvsTfYW9sy3WQIbyGwske1l+9g77O/sXfYe7WCD2GA2
hA2lz+kLtp/ep4/pA/qQDtJh+gd9xL5jx9i/cVZ9z35gP7Kf2S/sV/YbO86SWBtrZydYB0vGOUYK
UxRFVbhiUsyKRQlQApUglqL0UIKVnkqIEqqEKb2UcKW3EsGGKZFKFEtlaUq0EqP0UWKVvko/pb8y
QLEqmnKjEqfEs+EsXUlgI5SBik1JVAYpg5UhylAlSVmlrDaFmXop36lXq9eo16k3qKvVterN6q3q
7epd6r04OR9RH1O3qE+oW9UG9Sl1u7pbfV59WX1d3YO1+o66X/1A/Uj9RP1CPaIeVb9T/638W/le
+UH5UflJ+Vn5RflV+U05rrQp7WqQ2kMNxunCMKmH+SN8I3+Ub+KP8c18C3+cP4FTZSv38gbeiJN5
G3+KP82fwTmzne/AOb2L7+bP8ud4C3+ev8Bf5C/xl/kr/FX+Gn+dv8Hf5G/xPfxtvpfv4+/wv/N3
+Xt8P3+f/wOn1Af8Q36QH+If8cP8Y97KP+Gf8s/45/wL/k/+Jf+KH+Ff82/4t/wo/xf/jh/j/+bf
8x/4j/wn9hn7nP/Mf+G/8t/4cd5GDdSo1LGR9BQ9TS/i7aiJttFLtJKeF59bqTPUWWquOlOdo85V
L1Lz1dlqHv3EvlRaxOcsdBcdxcp8hG5hE+hmlsUWs/U4L25ltdTM/sqOsn/xK3g1v5q71QJ1nnqx
eok6n1/La3gtv44v5tfzJfwGvoqv5nV8Db+RX8lv42v5TfxmnMjr5Zl8D9+AO819uNncye/iV/H7
eT1/ACf1Q+oodbT6gyp+Km0m8v+gmOFGTsop2w4GVW4yWwICg3oE9wwJDesV3jsiMio6pk9s3379
B1i1uPiEgbbEQYOHDE1KThmWmjY8fcTIUaMzxowdd07mueMn2LMmTsrOmXze+VMumHrhtOkzcmfO
mp03Z+5F+QXzLr5k/qWXFTqoqLjEuWBhqevyRWXlFZVVV1S7PTWLa69csvQvf71q2fIVV6+85trr
rr9h1eq6NTeuvenmdetvufW22+/425133X3Phnvvu7/+gQcfeviRjY9uemzzFvXxJ57c6m1obNr2
1NPPNG/fsXPX7mefa3n+hRdfevmVV197/Y0339rz9t599M7f331v//v/OPDBhwcPfXT447N3x7N3
x7N3x7N3x7N3x7N3x7N3x7N3x7N3x//s7mi32yeMPzfznHFjx2SMGjkifXha6rCU5KShQwYPSrQN
TIiP06wD+vfrG9snJjoqMqJ3eK+w0JCewT2CAgMsZhNXFUbJOQmTCzVvYqGXJyacf36KaCc40OHo
0lHo1dA1uTuPVyuUbFp3Tjs4F5zCadc57Z2cLEzLpMyUZC0nQfPuyU7Qmtm8mfmg12YnFGjeo5Ke
Jul1ku4JOi4OAlpOTGm25mWFWo538uLSupzCbKhr6BE0KWGSMyglmRqCeoDsAcobnVDVwKLHM0ko
0TnjGhQK6AmnvLEJ2TnePgnZwgOvastxlHhzZ+bnZPeNiytISfayScUJRV5KmOgNTZIsNEma8Zon
eS3SjOYSs6E1WkNyS92NzWFUVJgUXJJQ4rgk36s6CoSNXkmwm+2NXvp5zMkmlIdPyr+h62hftS4n
xqWJZl3dDZq3ZWZ+19E48SwogA7IKrbJhXWTYfpGBHHqbA3WlOsK8r3sOpjUxEzErPT5ORNyRE/h
5Zo3MGFiQmnd5YVITWydl2YtiWuMjbVv97VSbI5Wl5efEOed0DehwJHdryGC6mYtaepj1/p0H0lJ
bgjrpQe2ISTUIIJ7diWcnWOSkuyCmjqrM7JMeJQwBQXh1Yo1eJKfgDmNEQ/nGKorHgM2fBUwSHlL
kBGXN3BSYV3YONEv5L0mG66IdT9hay9MOPpt9x6H0WO2hf1EghR10llqGPfT3qQk79ChokQsk5BT
+DhetkelJC9uVkYnVIVpQAgf5SK2joJxqQh/XJxI8JpmOxWh4V0xM19va1TUt5HsqUkFXqVQjLT4
RyLniJEV/pFO8cIEVPI2+dIX6Q1I7PwvNCyqd07pOC+L+oNhpz4+dXbC1Jnz8rWcukIjtlPzurX0
8TGdYwbl7T0pX+2rGJTSV5WjKMpLOplFIz/Yy234zyyLusSroihlB9Mme8MKz9efBUFxcb8r02wJ
6CLU7DsmpCQ6KWZ46R2X1L19Trd2N++C61T4yxOVqXnz6uqCuo1NxgZUVzc5QZtcV1jnaPatKErQ
whLqtiuPKo/WVeUU+hPa7Nuxpq938o0FmEQpG5dCu9W7KZQxsvpa1DubwiLS7c3qXU2hvdPtWWHq
7ZQLUMirTqMWgEKV6npaDlDAPrUxZXj6dkE0BYWkh4F/DWmAFQCV6vFksm0HCP41Tb2jhPprGkN7
Sbm/NKaN1ImmsJj03KwI9UpiqlOtoASy4oWtggYAFwP3By7CBbqn9NPeFBqWvgL2JoB9ghpJQzCc
hZt2OnC2Gkt9JVtNY4hup6Zx8ND0rCB1khojWULVnjQSOEC1NKZbtZ2qHZ7a1VVNgT2Ef6sawyLT
d+PyYKEIcK0AV7Q1dLcaRKkAMZO8psCe6euygnEo1gMUcFVAxf3yaVcrGqEI9nLUfhSFsUVqf4oE
nqwOaIy0tuxUb5VstwgtsDe+MWCEQE09Q9JbsgLV8Rj14tbfAhDW1jUljkmnrER1MKUBFAR1Oajl
4pfo1TpQdUhTHVJTh9TUwYs6MuOevRojq8GTqi6lKrWW1gHuB82hMrIREdwuiYGD07erfdQYRCJs
J2LH0BvbFBgiPItpDO8t2WKagkPSJ+xW3TQDoMB5T1N0THrlTnWonEpyU0xfIVDVGBiM0EXruYBg
lMjBbrWfOkBGor+MgDfLijajUNVKDC+e+0R0lHeV/SK/yl60BX7TwHsM/LaOfS3KviZYsTcrfxe4
Nauf8gWUXaZ8RPeDUpSdyouUBoEPlWbhhfKBsp0mAB9AuwR4O/AI4B2Nca9Zm5XmJiD4fk9jzygx
WeXFxqRUg7DaDCK6r0GER6Vn2ZQXlOepH1T8A3gg8PNKC8UDPwccA9yiePCaYlWeUkbROcDbDPyS
skvUtPKM8jSNAW5qDBEueBstAm1tNAv0ZCPprdxU6y7lSWULxYL1icbEWPRuakocaA3dCX1MeUTx
NPa3hmcFKQ+wfPYjmOrpgMAUrjzYmCGUrGvcpVm3K+uUdfaYDLvNnmLfqKbZ0lLSNqqaTUvRMrSN
WlaYchOZEDwsWGUNnhmkKagegB2wTlndyDO8WScwJzEvhVbgWS+pQjyrJEV4hnWOHpPUBOU6mgFQ
oGMZYDlgBeBq4nguBfwF8FfAVbLHA6gB1GL7qIJEFSSqIFElJaogUQWJKkhUSYkqab0GICQKIVEI
iUJIFEqJQkgUQqIQEoVSQvhbCIlCKZELiVxI5EIiV0rkQiIXErmQyJUSuZDIhUSulLBDwg4JOyTs
UsIOCTsk7JCwSwk7JOyQsEuJNEikQSINEmlSIg0SaZBIg0SalEiDRBok0qSEBgkNEhokNCmhQUKD
hAYJTUpokNAgoUmJMEiEQSIMEmFSIgwSYZAIg0SYlAiT+akBCIlWSLRCohUSrVKiFRKtkGiFRKuU
aIVEKyRaldoGdV/WyxDZB5F9ENknRfZBZB9E9kFknxTZB5F9ENlnTN0jg6GgbJYBlgNWAIRsC2Rb
INsC2RYp2yLLqwYgZL2Q8ELCCwmvlPBCwgsJLyS8UsILCS8kvFKiHhL1kKiHRL2UqIdEPSTqIVEv
Jepl4dYAhMR/X5T/dWqUq1l+AA5XZQUbIvFy+lbiZXRA4quoQeK/0kaJ/0IrJV5KGRLXUqLE0Cex
h6wBrNGaEZoVhS1gBuAyQCXgfsBWwHMAi6T2Aj4G+JRR9ngeaplhud+y1fKcxbTV0mpRQs0zzPeb
t5qfM5u2mlvNipbVV+kp91FsLXSzfC7H8zsADhE8J0hqgjISdkdinx2F75HKSHuvo9p3Q9neoey5
oWzrUHbzUJYVqJzHuNzpNMrAu5aV5duDE8dbDwAyEgeNx85009PfRlsbE0dbm9kuHQ2xJwF/C2gA
bASsBGQA0gEpABvAKvuGgj/fHm+o3AUYBIgDaMIERYmP3cJ7Bdi3Kz3ZxqaXe1KgsDNoMOR2Ng5K
A2puHDQD6JnGQUXWrED2NA0S1yD2FDK3BXhro/VzDD+ho8cbrTuBNjVaRwLNbxw0DOjixkF7rFk9
2RyyciGaZ+DZmLfAsxqtc8E2s9E6BCipcVCi4B4KQzaMDmH59DmwzZAaqFtKaLSeAxTfaB0ruANo
kEg8M1OKdM8EEFhtgkPfbWf5nNl7WI9ab7V+C/FvEFiUxwdaMwfaa2tmc+1B1l0p94E5y9qYFST4
cT40GNgr8FPWjbbV1nugi9mett5lHWa9KaU5AN1r4fdqaaLRuhLvBVvsva0rrGlWT8rnVrf1AqvD
Oss634b+Rusl1l3CTSpg+cqWp625UDgFs7A1Ws+zNUsXJ1uXWO3WQdax2i4RXxqj681I2SUiQOm6
9WTEd6itWdT4nIxm1ss+1HLMss5ysWWi5RxLgiXeMsDS3xIREB4QFhASEBwQFBAQYA7gAUoABUQ0
+1rtSeKHRhHmMIHMXDy5pMMU8RQ/X8LLhcICFLqAvL3VqcrU2RPZVG9LMU0t0rw/z05oZkG4dpsS
JjJv+FSamjfROyZparPFN8ubkTTVa8m9OL+BsZsK0OtVVjUzystvZj7RdV1f8X7bwOi6tX23E2N9
rltbUEAxUYsnxEwIH99r7OTsMzwKjWfSya+YrmR/7x1TZ+d7N/cv8KYLwte/YKr3avH2u10JVXrm
ZG9XQgQqyN/Oq5TQnFmin1dlF4Dtc8mGag4BGw0SCGwBE0kTbNhPJgo25EjnS4Q4+OIEAl9QT0qU
fIlBPSUfZ4Kv4YCWk92gaZLHRnRA8hywURceVAxksxsSEyVXgsbyBRfLT9CkY0OkIqsVLClWycJw
r5OKrEwa86aeZLEZLKM6WUZJWyo7yWPVeSIG+3kiBoMn6X/45ZyYxJqG1yx7UXygUJiQ4wQUetcs
Lo3xrijStIZlNcYnDYmFRcWlAjuc3poEZ7Z3WUK21jD8xTMMvyiGhydkN9CLOXn5DS/andmNw+3D
cxIc2QVNEzLzs7rZWt1pKz/zDMoyhbJ8YWtC1hmGs8TwBGErS9jKErYm2CdIWzkuUfe5+Q0BNLEA
L7ASNyk9glDDhX3jCiZGhVWNFwW9/Zy4mGV9d3Bim6gHXueDEyZ6ewLEUEpWSpYYwjoTQyHiUyNj
KGbZOXF9d7BNxlAYunslTCR/aEkwTfWOmjnVGzd7Xr4oFa/dceacucWXHI6hHFc2/kPbIwHfXTnJ
fcYvz5m+ampq3OJRk+QmmuodOnuqdzTevxssFpgqzC5A3zB/n6rKvobAwJxmXwsGk+AE8whzgkpi
SYigPQhvXRal3lxvUcSrgqcptn965W6c4MsBeI9TahtT5fuyUtsUbxPvL56m1FE6xvupwI2xcemw
0JQBUYFtOrb3SgGxzrYuZV1Gva0+pT7DjN6nN6LTulEcpY2pG1XyJLn9gQDpKUCw4Zaw90Bjv/7S
cL0gkpIKktxMxuv0YDN/0DsD6za0uqV6jz8her+bdGZ9MKnGL1RjiMjBGikC0rSD+kl4lPrxRLxA
ke9zP3S4fJ+LMYGVr7FN99fB+Gqkx+kfbDDTqIkdp2j6lfVhw2kKSu8X3Mu20gm6HS/reXQHC8cL
WRTNoSmMgyeJbmT3+Bb7jtC5dAs96HuGrfRtxvjN9Ar9Cg8O4xjMoOngn0NOOqJ+QQW+uymAbqAe
eGGbxaLIQe/j+yf4cCvdRs+yv/p+hdUIWgl9mZRFWb7nfe00lG7k60wHAp+i9bSTmX3FPheuP/FU
pyT53vd9TIlUQA/R4/ApibXw8ymOFtF1dCfro74C6nZ6mDpYsDJfnWR6Dpam0FyqoFqqo830Bgtn
uaYDpmO+v/i+RIn1psHwyUVH2Cg2TXmEB/vG+z6ki2k7vYb5iu8WfjF/1HRxxwTfvb4X8Gr9DAti
u9jzpnTTTSeu9j3ge5KC4c9wRGQ67BTRNfQ8vU7/pu+V5b7ldD7NhuWXWX+msURE/H2lj7JMWaa+
S8Mw2/nwtobuJy8ysoN20m7E5iC10hcsgvVlF7Aitp59rwQrJcpe9R51m/oeZ/wxxDuBbIiRhx6h
p+VP6fYyE/SnsVx2Oatkf2P3slbFq3yr/MID+DW8jZ8wJXa0drT5pvt+wgt1LF1IS2k5YvuQ/DnF
27Sfvqcf6GcWxsawUvnbEq3sWyVQiVdmKFXKHXg1fkKdrq5Xn+ej+ES+iO/hH5quN62xOCwd7Rs7
bu14ouMd3zO+d1A7IdCfSJMR0atRFY/Qc/QutH9AH9Gnon6g/xw2j10KK262it3GnmAvs3fY15gl
ye945RwlG1YrlWrEaaVyq3IbrO8VH2MoHyofKd8oP6kmNV4drV6hPqB61WZ1n/pPHsYT+TA+nM/g
87gPmUk3nWeabdpk2mJ6wXTMnGkuMVeZv7KstFwb8NaJoScOd1BHaYe3owm1G4BKWopI3EcPou63
IQdvIKJvw+NW+hFZiGVxbBD8Hssms6lsGruIXcKcbCW7gd3C7mT3sAfZk5gB5qBY4HuSkqXMVhyK
U7lWuUFZq2zD9w7ldeV95YByFJ5HqwlqkjpcnSJ/jlOBOXjkb1Ksx/dmda/6rvql+pV6FFmL5gN4
DV/K7+KP8m38HdOFpnJ8P2h6ztRiesfUbmo3K+ZYcz9zqvly8ybzpxazZbQl17La8p7lh4Aq1o8N
heda1x8UK32wBgcom5UIvpwdRUd/vFKEYuZJyMNsrIofaILagbyEiHH4Fqn04b2FpNnOveIDCbaT
RrGXablZUXHr463UyA4prfxF5VzazwpZH/6oWmF6Q4mjLdiN1im7lJ1sIm1TMpW5ygaV2Bc48r5A
vV9Jt7FFzE1b2FE2jl3FMthyek+JUmezaynT96DCWSCbwo4RPKCreQld+sc/U2dj6RAd6biP9+R/
xf7UTHcgo4/Tx+wxOs5Mvm+xu6nYjRzYZW5EvV9HYtebj3W2HOuxD3aQMvNe2iZ+d8qSYR7Pl9Ix
+o2OmHagoiZiJ/2yw8Xv45/5MnwpWGFYZbQJ666UzsOK+QJVshtt0boEKz0Ie0k6VnUuzaMSugq7
3nqf17fBd41via+S3oTscZbMjrN6rIhmSGTSa/i+mT5ga7AOz/vjef7eV0cJtdDXLIbZWDrWw1HT
YtM602bTNtOzpj3m4Yj2tXQPKvpTVHMQZlBM79DX9AsLQG76UDKNhL9j4Hs+lSkF6m6axGKpCmt2
MPbxicZM3NCyEtHbgPW8G2vjGPaJS+hZOsAUFo0ZFcN+APRMRZwvA/dGZPAa1oSeEuzaQ+kbzDuE
jcHbdjLZoekO7Fot8OkQ/RPR9km/krEvZLO50PULXUQlsDCacsW/QvI9jZ1qOmWrbyHeA1kYTWTx
7GHIFWKFhlB/Gmv6jCmU3DHdN0ZxqbtxxvjQX4/Tqy+dy66AF6GYxwmKZDNoVMcs+KB/lZ2FU4GV
nhmU/xLUVWfhLJyFs3AWzsJZOAtn4SychbNwFs7CWTgLZ+EsnIU/AEX81rYJ36SShSZuU1iH2dKs
TLD3JhPvUCnIwjsY9QkwmzoUdRdLpEDmZTEUkxT2c+aJzOlhP2ZOO5FJE0CHteMxPC2uV1wvGx6M
OLVraku7XfyDK423iH8nfIPvK36baQeFUj+6dzuF+361D+8xNqPveX2V8LnmuUFzo+bGFPT7xWIe
xc/peU7vUX1z+NSeU3vn9L3NcldgUHAIg7ux4ieuJksEkL13jx6hFBQdFxBbNYANCBuiqImh4jeS
glkVrYC9Pv0nZMUkwcsrMqcdPZH5z+lhV/w87SjcnXAU3/CWrpjP5k/Kt/dYYF4QtCBqQYyrn2l+
Ac1PGoFpjB6RHt4rjBLiEwdF9o6IjhqRPnrUyMSEePMNrM/Kxhc6Ok5sv7jBHj5yypL511y70Hm9
aceJY7d1fNnxW8exjg8vLtigDH1kRtX9W55+4F7x+yu3EPECzD2KGu1JoczKxrIRyoiwiWxir8Ps
NxZoMUWZBir5vUp7mRhTekf0Cu+tRigsVMyzv2oJDAqKiAyKIuoRlBgQaNcGjtwayHyBLDA2Rvys
OSp+4Mh1MfUxSlXMsRjluxjkKCIxKlIMhYK3PpIdi2SRfaInZOrxqE4SiZseNh/Uz0ZLxCUzMwzB
GTu2V/RYNSQsMwAxYvNpPhPBGKBEIiojE0UIzIJkW1btdmyY0b/jS23muZMrRnR8iRB8cf/5Vatu
PrFeGf7ovFHZq68/8S0mTeJX1b9S1pvupT60xz5EI40lBA0JHRdyQUhBqKVPJMWoUZEUHd47gkWH
KxEsRg20BFmCY5oZs4dSdH20N1otBGqJVqObGW+MZKIAmihSVKvHHhLcIzA1KJUolV2GIgGHfXCM
mhgdPidyQsT9EVsj1MKIFRHrIvZFHIswUURYhBaRFsEj+sReWS/jgTBM9WbMnuo9Z+a8/O0U4WsZ
U5A5TVT0j/Mzw37s8znFiIJBlYP1817hY3uNCMWXCA6LTOgVEYXiyIg2o1QSByWO6pUwasQoWy9l
aUuPQf0GXRBT9NcLl47tEXj11SyWJ7Z25K1M6tf3w6EjZuYMv53tbX334Y7VWISX8aVE8i8VEXXI
p6AZBbHxBq1QgOmwQauUL/4eq6Q5RZj+btAmijF9ZdBmijHHGLSFXjKnGXQAJVpWGHQg1fXcZNBB
/AVpWdA9qCgk3aCDaUHIbQbd07zN/KNBh9AlIcc7/xTA8tC55P+78qbQnwxaIR7u/7vyKiWHjzZo
TkHhEwzaRMHhFxi0GXSRQVuoKLzCoAOod+8ogw6knKihBh2kOEL3G3QPGh5VadDBNCKq3qB7qvPC
9xl0CA2Lelf8BSiuwreQ6J4GzSk2mkla/JX7oOhBBs0pKrqvpM3oN0efa9CcwqOHS9oi8hI9w6CR
i+hJkg5Af3B0sUFziom+SNKBRn51Ws+vTuv51Wk9vzqt51en9fzqtJ5fndbzq9N6fnVaz69O6/nV
aT2/Oq3nV6f1/Oq0nl9BB8lY/cWgRawqJd0D/eHRtxs0pwHRqyUdLGPSZNAiJo9KOkT844fodwya
U7/olyUdJvU0GbTQo/P3ljE/atAi5p9IOkL64zNo4c8Pko5Ef0RMH4PmpMXo+Y0S/DFjDRr8MSmS
7iP5Zxu04D9P0n1FDcS4DRo1ELNQ0v2lPzMMWvij59oq+VcbtOC/StIDRQ3E3G/QqIGYWyU9VMQn
5hmDRnxitkg6Rep506CFnucEHdAl/gFd4h/QZV4BXeYV3IU/uAt/cJe8BPvzkkdLqIqctIAcVAys
0WOAPCqV9DSqpAqAx+DSaBJa1aDF04F+l+TQ0FMG+WGgsmW/43+oKbXTM41mY6RM/ltvnceNvinA
ur3hNBbfaZRiUOmyNwsSZcCzILMQPnik1CzocwOqaTGeJdKHCow5qbzTk2rY1cDlMCzp/C5ESIOE
kBcaKyhZWhEjDmmp2NAlfs9HlyyXGsUMSuF9udTowohHcpdKWyLqHsOCW86wWMp65HiF1CKw8KlS
+uAy5lIldQuPiqVXbmlNjAj+Eol1/2ukNU1a6OqVS+r3YLxCtmul7lLDutPgrZS6dNv+/jKp22NE
pBgtPTKn8nmg0ymj4gLWdRcbPTUy0iJXJ6ukUualWka0TMoLT0V1lBtSfgvFUn6xYdVlzFSM6dE8
GYUF4BTa9N6TcXUZ0a00ZuKS/DWydTKrblmxZdK7M9eEf+W4O+cixsqlvpM6qmFnkeGtw4h/saxp
zah7f8xKpO2FsleXr8WIy8ih4ClD7vUaqcRzIcYWG9HWNZxcyw6ZK706NBnDYmP+Lpm1MslTJdeZ
Xo0VUlKfSdfqdnVWlobxK43MlEtvRG3qeXMbK7ms049y2TpZvZ5T9hv3KfMrNmwUSQ01MtIl3WrT
SVeg3x9ZUdvFnTNcIGtbkzVwpYytW9adR2ZjYWfWhe/6ehdrKblzNbmNKju5H+mj5TIjDloq5XWv
hd5iOXqy0nTrJTJaVXKVLOmchd+2kK+V4w4ZiWrDhlhDehQ9Ut7vsV97layhcrmH+n0bdtq+Oq5b
1ibKnbMEvXMNS/5dVuySY/DUaDB0iOhXy5Wgr6AhXbSkdGqZhto+2f+krPVqY+2Xy/pZ1Jnn/9t9
X8/NQmM3dBp73Mm9Stc6B2eCRrlSXqNEaW8anjNge4GsXn/URH26ZcRLDW3DaDr48nCCTAZMwowE
PQO9Qn4ynhfK/hz0zMZTrIPzcHLk4Hua7M2jnhQkIU9WrvsMda119use69mrMvJ7cj2cHh/93KtE
DKplhZRKbv98/Lu/v6aK5OgS8Nd02izu3Ef12NVI2ZP7n9NYIWKXOrln63uFy9if3cb+sVBqcXbu
vyK2BYY1sZMsNvbtos6TT7fp+YPI+KustnMndBqr29m5fqrlXuUx9o4FRu2fKV7+FS8i5uyi5eSO
cbq9EqO+RC0XyV1Y97rIyEyFoflMGRokZ9U9Uvruf3pVnG7Zv4+KHdMhbzUOWC0zou029qvfsz1M
1n5Flz19yWm5cBo3mq4rRz8pHNKjKhlZcXa55Hr785xrRi1WdNlH/XbF6i+RkXZ1ObGqu9y6kju5
q7vU7cl7wh9HSnhXLvX766qym75amf9FMptddxP/XnySsxK8+j5TIyMu9Jd2zkf3q2t1lxu7tx5/
fVVVGfVxcpfvXkN/NKOT9TFFzv30zPnveeJ8cxq3QX02+t2yWGa14pQcVJ8S75Oaxfwq5e2nxNhX
F8t7WC11vcn9efb9+vQ16TTuG91PZb++0/OoR+vk7bhY6jx9Hfsz5jgl1gv+K29PRvl0C93vFt09
cho3Zg/OSr8GccpkoTeFxCk5hkZSBk5GDc/haKXgnWMkII3Ee/YcmmpwpmF0OEZGGnQGjRD/OBsw
mkbh/USA0F4q7yVVsJeK71r5PUye791XfLHc+X7vnBBUtlydtZ11oZ+CLmO3FT7Nkju0foZON+5a
lcYtXqxP/SStliMumYHZeJ48N0RVibcrcWP47/xOlfziL3el4umRO4TIVao8ey6TVaLfJ4Z1cv7v
WqiVdwCd1/m/YsU/lnpKPXbqzltS5VzgKHZqj2l5pU5tWmVFpQdd2qTK6qrKaofHVVmhVZUVD9Oy
HR7HnzClCmXa7MqyGtHj1qZUQG742LFpKXikD9Oyysq0Wa6FpR63NsvpdlYvdpZMqqzwOMuFkuol
mtsBIfS7FmglTrdrYUWyllXtcpRpxeByuDBYXlnt1Epryh0VLrdHKy51VDuKPRBwe1zFbs1T6qjQ
MLZEq1yguWClqtpZ4ix2ut2V1W7NUVGiOaC/prhUcxmqXBWap6bCqdW6PKUQd6K3skRIC7rMARuQ
d8AZf5+n1lnhcTnBXQyipnrJME2GpHKxs9qB6XmqnQ5POYaEQHENpugWxtyVC+CmdGFBTVkZSOkr
zJdXwoiroqTG7ZFTdXuWlDm7RkIkxy2sOKvLXRWSo7pyEdQ64H9xDQxVSM9KXI6FlWK8ttSFGZY6
y6oQkUptoWuxUzLILDu0MoRDK3cidhWuYrA7qqqcCGNFsRNG9HC7RLA055WYTLmzbImGubmR5DKh
o9xVJsPrMerGbdgrhkSRU6txO0v0aDqvqBHO1hSL+GsLKjFlaMSkPB5XxUIx9Won8u5xJ4s0uREy
WUdoljsWOpa6KqDa6SlO1oMG8RKXu6rMsUSYENIVzlp3laMKroGlBC56XG6hWLBXVVeWV0ptw/y1
Ok6f2sTKspJxcyEkSjZ92Jh0bfA0V3F1pUjQEMmSIlim5Ul6k5ZXjeyXO6oXiTn/Ue1jNgtRhk5U
nKwqsM6ZreU6PFqiljdNm7FgwTDpmrPM7awtBduw6TPypkyeMikrb8qM6dqMydqFUyblTJ+do2Wd
NysnZ1rO9LyeQT2D8kqRDH+sRWKEYkwP8/bIPHT6g7VXubDaUVW6RNoR5S8iVbREW1JZIySLRY3C
u5qKEll/qAqUlKxsVIUL9Qx2x8Jqp1PU7zCtAGKlDhRPZZFYfJD0dHNGhKxWFKET6XaK/FQ7iz2o
jgWI/km/ROIrFzoliyyMTjkkFDVfVOOBarhZiXXYZUKD3H6nUP6doegUFjWqLXaU1TiKUJcON+qq
q/QwbU6FrPQl/llgTkZysCgcmrvKWexa4Co+feYaolgha1TIOkpKXCLHqJ1quXUli+5qGVu5J5zi
VJmr3CUmBCOSr7ayepFbL21ZxbKzshY1U1NU5nKXCjvQpYe7HOUN/5GqqiWaXvJGhLobkvGYsuDk
5MSed0WN0y3NYLcsdlZXGDOoNvyWzO7SypqyEtTqYpezVt/kTpu+4EMmndg3Sk5ujJ1zhFtyOy72
nMyxmJjD8HrBmdVKlzsFjN3CUAQ7Ds84wTBndpaWog0eMzJjiJYxfExK2si0tMDAOVPRmTZ8+MiR
eGaMyNAyRo8aO2psz6BSj6dqXGpqbW3tsHJ/4osry7uuCaeWXe2oFbHAEoRT0DSrsggrdDp2rUps
8clikVa7il0ObbZDrg03zqwx6b+jO7XUU16WWu4R/6/j1HL3ZQ6xTwwTnf+hQK2zDL3OPxcRrVQj
jpK728cl0+VHD9XyFczRbcRDNawnjvkj3XoXyGtj157JxsdNXfrUVepu9SX1OTwbzmjNdZq1C0Hp
rwWVcrSm2+h58rrnf1UUL0TdPTgCvIh+hvQR9HcdmysluvacL/FiOZPuI7nGRxA18uJYKV9Nfs/7
bh5wKx/Pz+GT+Gg+htv5uXwqH9tNMu+MsZwqMBuO/u69+kd1i7rbYL3oUzUBV63uUas0Pjz9P769
E8BlbmRzdHJlYW0KZW5kb2JqCjI2IDAgb2JqCjw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5n
dGggMjQxID4+CnN0cmVhbQp4nF2QvW7EIBCEe55iy0txAjvnOIVl6XJpXORHcfIAGNYOUgxojQu/
fQCfLlIKkD7NzGp2+aV77qwJwN/JqR4DjMZqwsWtpBAGnIxlRQnaqHCl/KtZesZjuN+WgHNnR8ea
BoB/RHUJtMHhrN2Ad4y/kUYydoLD16WP3K/e/+CMNoBgbQsaxzjpRfpXOSPwHDt2OuombMeY+XN8
bh6hzFzsbZTTuHipkKSdkDVCiKKFRlRl3TK0+p9+v6eGUX1LSu5TldzioWwzPe30mKmqM9WnPOma
STPT7rfCaiWKXfOBcslUz1i83dA7n1Lp/QJKgXR1ZW5kc3RyZWFtCmVuZG9iagoyNyAwIG9iago8
PCAvQ29udGVudHMgMjggMCBSIC9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gL1BhcmVudCA4NSAw
IFIgL1Jlc291cmNlcyA8PCAvRXh0R1N0YXRlIDw8IC9HMCA2MiAwIFIgL0cxIDc1IDAgUiA+PiAv
Rm9udCA8PCAvRjAgNjMgMCBSIC9GMSA3MiAwIFIgL0YyIDc2IDAgUiAvRjMgNjkgMCBSIC9GNCA3
OSAwIFIgL0Y1IDgyIDAgUiAvRjYgNjYgMCBSID4+IC9Qcm9jU2V0cyBbIC9QREYgL1RleHQgL0lt
YWdlQiAvSW1hZ2VDIC9JbWFnZUkgXSA+PiAvVHlwZSAvUGFnZSA+PgplbmRvYmoKMjggMCBvYmoK
PDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAxMjExMiA+PgpzdHJlYW0KeJytXdvqZb1t
v5+nmOtCVnySD1AKOV+nfNAHKG1KaQpN3x/6k9f+b1vylvaeSRNoMzPa9tJZsmUpfg/4768i/k8b
6fu//vXb/3y7Gs2/vf//r/D3gf8hfuf//vOfvt//429/+fbrP4Xvf/nfb+F7DFTD9x7r/F/f//Zv
3/79G68w/ya31L/+6jVgDBV/4L8d+Nf5l/H7NcoIcdSGD+lh/qc9tn/9T/ig0R5r1ZS/pxyfa/XR
Qx6p43/W+wcAuNd6+U9yrfL9sdL8u97b8XcMF7Fjuv+upXD+5Z9BWiqgc2LC/vVbyxc9/vBf9x9S
oSvxnxhM/OEL7D++/cs/fP9vm0cPjvz2l2+//iM+oVx1/md8/4XJ8GA1SM9f1/C3f/32j8C3/9P3
X/5z+3f8rjUwqggw+q0CS+mKAdwdAqwUBZYD8Cg9N7laUGAlXaXmGhRYVmAUrhpLixKF8kcNlq/e
Qq8ShXJj+odf3lGoJvG7kMXv4hvKQiR+5neM1P27rLHG70KIZaKzgSXNkQywNCZHNrCqOZIAVvJQ
qzXNkQgw6iRXCy84Av3LSa4W9bfRAFhvXa5GGqz2K8SQKAuwQ6haA1hsscvVtCT3CrAcu1yNNKaD
rklduVpRAp8CuBBrjHK1SAosgguxUesuQRLUB0YslCS/bSiwDC4kqEuTqymepgIupDha8jct4ELK
JTeXIInABcCG5DIrVXAhQWnlauUPCqyBC6n1LFcrilmpgwssvFVuGhXYABdyaDW6YpkDuJBBZLla
UjzNEVzIuY7o6kJO4EKmSNUHg62DutUUXXXOGVzIPXRymZULuJAHUZBgShcygQslhqhWU3TDZwEs
lf5ytbcmKjd6Re9PTVvOBgOkaXuCHXZBmLYF5pq2BeaatidY/L1n2p5gpwXcTdva9DeeabPBhGmz
wYRpWyhEz7Q9wcpvPNNmckGaNhtMmDZ7U2HaFtgfPdO2wLT5EKZtgRXPtC0Usmfa1mq/80ybKZbS
tJnMkqZtbVo902ZyQZq2BRY+VPgUX0n9pwpP8UvhtYoKhX+C+Qq/wLR8C4VfYK7CP8G0DEmFtzcV
Cm9vKhT+CRZ15CsUfn2bDmmFwtsoCIU3UZAKv1bTKioU3sRUKvxaTQdQQuEXQX7vKfwTTJtdqfBr
NR2OCYVfYFpFhcJrsLdSD0Pw6mM/1ZY6DF2X2vIE87VlgbnassBcbanjI22xNxXaYm8qtOUJ5muL
vZrQlgX2O09bqpV1Sm0xCSK1ZaGg5VtoSx2WfAttqVZ+LbXFRkFoiw0mtKVa+bXUlgXmukdTyKV7
tDEV7tFkvXSP5rdJ92hqloz8TSGXkf9ivV5NRP5rNZ2ViMjf1AUZ+a/VlBGXkb8N1sAFtg1vVuvg
QiFs63/bABdK7U3ZN5XelgAulA66uFwoEVwoowdlapStLwlcoJiqWi1oMHCBUsvFRaFkcAGIDrWa
0vpSwAWiqk20/jYCF6jF1F3NKhVcYNPrm5rSwIXKH+OKJSgLsEgpuwpYBrhQ0+jd5QIFcKGWokx0
UQpIEVyoNGJzUaAILtSWe3q12lvPSYqQyuOmNx63/9wZXQ9k0FB46gXmeuptNe2/dk+9gWkXvHvq
BZa009w99QKLetPdUy+woDfdPfW2mhJ44am3b1MWQHjqbTVN3t1Tb+TVrmT31BuYdnO7p15g+qBG
eOqNC9qh7556Q0Ef5e2e2uap8NQ2s4SndlDYPfUGpr9t99Tbt2m/v3vqjbxeImszS3jqTUKUIAlP
vX2bdui7p95W05vuntrmqfDUGxc8T72BKZ4KT23zVHjqjVkahd1T26wXnnrDVJN399Q2s4Sn3sir
/dfuqbdvO1zw5qk3sN9psM1Tb9+mfevuqW3bKzy1LSHCU29g+tt2T72RV0mI8NS2tRSe2ma98NTb
purIXXjqbTXPU290+60G2zz1tppCAR4ZYL0XtZrSLMrgQgvQaomCskhUwIUGJyJX026XCFxgz6ZW
06FLBRdaacpE6+CWGrgAs9WkcQjjw5hEUegHY4tknjCL2MIGE7FFss4PZWyRrHNXGVsk6whUxhbJ
Op6VscUT7DgsELFFMg/wRWyxNtXBlogtbBREbLHAtMcVscUTTAdbMrZ4gh3+W8QWC8w7BdjA9EGd
iC3sTUVsYW8qYosFps/zRGxhf5uILRaYTu9FbGFvKmILczUZWyww7xRgA9M+UsQWSwE/tAuIOV4p
7qd2oVhHoNIu2GDCLhTrsFfahSeYdrbSLqzV9BW9sAvlo7P0Dcw7Hdw21Qov7IK9mrALC8y1CwvM
Ox3cvs07HVxgh/kQdsEkr7QL69uOZGK3CyZBpF0o5gG+sAtrNa8uwBYkaRfWpvoQUdiFtZpOwoRd
MOkm7YJJEGkXzG+TdsEkiMw5TF2QOYcp5DLnWGA6SxA5h/1tIudYq2mCiJzDFHKZcyyL9KmhHPmV
JfvUUJJ1li4NpQb7Wj6bywsDun4ePzxyev3zwypBpdvo8abdE0znaxEqjaQDy0kwXVgBlc4cjGcB
lp7Xv7/+U+RawfT9l7+9Qx9qD1tZqRjoPwtBv5YqP7jUEXtCKEfrABRg2snDml6tlXDnL0+wrEkB
oSSo8uhyNS0kSIRzhQ2UbDosLxJheC26Dc3aVJ+oILcahOwvuZjCNl+tjJEkmw4fg9yKCvI1RTdt
K5FbZWTqXdLtqMhCbhUzMixFN32MQ+UaOTz83/o2TZCarwbXkKXcJu1jWroohTGqK7epxyvDm9bk
c2GEK8LlJvlturwImfI1gMGQdDvCwNCuBh9eJQpHGBjrVUbtqbqsz4muBHFTGnrcpGQYpd4iKRQ0
WElXR+yYFOs1GMWrQhmGREE73VzDVVqqJFHQp7LwfBfceE+KC4dX6NtxxFpNO13EW516VFqvT3vg
065KOafg6mlBvFVKL0rItTktiLdSgamRKBwnKhxvwVDG7spbgQvnw6+uuKBXgwsHPSIFVwHx+Rd8
bo7VJUiBC4eBKD25Wl/YhT/j1EUQ/W2tXD3AwShd0Jj2fNV5hOcKEp9ElelT5be9uDNCHP047Vmb
Bg02roGgtyku6EOh2K/WqRYlSEpCKLWLEEcpT/oIfT71fVx+P8+r6oXoZzSJqOP9zEDgXqpm5RNU
dGT/vLyMcj688upNXXlt0REM+ABt4yuwHwsVoE00oGRJLmUTy47pXi91VDgiaqIRe2o+mIiaNNgX
CcmOW4JBmz/Phx1/z3uM6RCB6GuuvvlZ/voifTwdQ+Dz0zGP9RfYkX+HfqWUw0yFF9gpIgkujcJM
+rfVdAgLB4m0L8zz+gV2xKYJARnEberBBqZRgBrDo6WZhG2bHueZdEX4nFh9FGCaY4OBVpseV6oI
oRKSqyA31SggNoKvqkmS9zgFqXDeMGtZkvd4/cLZFfAIkm7H6xeY5lhLjZIgr0oFS3qkwg6myJip
AbhLuunVEEIhKu6luOTlsJhjmRRcCUmhwoK3pqT3iAIjh56dtcJDIXFmNViN/W+DICGkHL1JlTnO
VJB1sKmXq+mIgaPnBrMzyN+UAvuq+y5hI4g+Ha2Id+sohVxdSBXylpB0BJf1fPSCWAZa44M1eGUk
Onn4KEAsEbH3obRepzodljr3kIrPLITstY9YJBeOYyFEgcjW2sg+QSCWPdFIcjUdMWSIZedUUgq5
PurLyNZSqiH6ZjBDLBM+rWVXyDPCFPB0vDGDOVVkRPDOzbUhnCfUlmL3NStnxEalwNH5KHA6AWUI
0V8NQg6iBW1DNAp8/Zbhfn3WZ6SIcfDxnP9tkN5UwYfuEwRiieg+a79wnEVlCBKS5uJj2ttVkfdr
ldGYQixhuGgo6dV3zCGz4WraDOroGW63x5FrdYW88DFkO53R7zXYQCz+1hkVDov5SKK7BEFaAlMD
L979b4NYIi/tWheOS3c+cM1DGfyjUg3pa4S1jL5FKsSvYvFpygzqVAdulzqlQP63NZhoyGZSmGqC
IMvtveETXSEvECRkktR8R1kGMIXSa+OgyQvvnDnoU7ZX338jv6qcIapN/6jBIL0VCb3/bZyG9cyo
ut9GfJXBj7CHy1PYNmTgNeTkb5royrENbfB17pf4QHMMyq6Qc3kBnz+36koIFUhvRZjum0FCoj5K
vE+jHPJSnhdK6Q2mfCTfSQfb+oSXKoQc2hyqK71crABe5aS4oOsse2TvXCj5zOqDvTOpfOEo7hwI
MEqoo7uYwpNeI6ZKvqmpEMvREdAOF9MKt4vouBWfvBVuF2FvC8nfFIllQgBaFReUwa85XAUeq1dX
6yvcLkisdeH4Nrhd5Au9SjB9MFTLAEHiGL4/rXyMnnOMyhn97rPUsdaXoeuHKSeZiRh8H2xpvN3Q
AjtyyXgVZMi3WSALR7gC+GWkkkGC6U0RRA2CDMlNj1yS2xBESFqRYLoaFU4t9UojvFmNjUxqd/xs
o1AIxjnfFVEb2FF3m6FTZZBE4Xxn2qBTWC/634aEIrb8cJFk6TsWArNKvANje1M2MqPGW1nI0im+
eC+1R02Q4yYGBIkjaYIcmWlG4h/ya4K8v66bNirdVRfbzz+9rnv981eZbEUoGpUYH+0AEKwi0h/5
FWV+6HAtJQhnQhBaDLyOwzVTk62lXlw7pTE6BVejOXEuiB1IytL5VAkfE0A3ZUY0xWADEdC0GP3V
iOP23KMUOX20AsozNw+N1skpBBgRSIu+nHOqy41dWvZXG2xtatMG80WqGwaSNilC57vgcUFdS84u
s7i0AQp91+8sMH0wyHddGc6DfEsI54LognL0JSSzeFNLzTe/nBGDtkXZhyMXg2tunUoI/qaJ75MQ
uftWmssuIuIG7Y+OinDYrhIrvdm0II6K+XECY9rVDOmt9evEb4HpsgtIb4/IUapPEBhzpB49SoOp
48+MiHEgNGvNR6FxHQpMevc3bYU7+zxiPNOYZ+gCd/ZJ0dWFDF0ogUYpPt0G4ihkdtVHgcvQK9Qr
+SgUPmYMYXQfhQLziDQxalOjM7tZwJFT9nWB82t+AzykvOljxpJZekMbUheOi8lSOQ0vwdf6wh2R
Rs9VkVcdMyLyQWCDgDy7KlNq4WThvg3dwI5Xau1qSAB78sFa5Cr/WN7wtNEVU45Bgh1nJp0rCuFx
fdtbOmJjiGXxg1WEW+xlRpOs166NYFQrYlBlVI9cDNaysSQ1V8i5kn7kesS0OsniSnr45uqznvKs
RCkpu6xHoHq1cri2I6lHsDrg65UNOTJimvdKPfuaRcT3SmnU6KNQ+V6pDG1DdFIPwwV9CG9sCDXY
EHD0jQ0hGC4ERFHZkOOBIgxXTyFRdMWS+GAQpib50ltDuGYJRHIFqQY4Svi3NzFSjRBLrn6R36au
M+0EML6M+j9MAMdXeZ4uGIqwukjF0h1VDqvkcDaYy3S/J9nAjsvEfvUAwCbAjmRBJIAjGkzne+KQ
IUHR31RcJg6rEjYWxFqE0EJiehZBI9VFyprfYEqwRa3W+8TVRoEGss5O9/HRsIpS5Z3jsKpNY+MC
NeqKIGcCSLNKVxHkTAAHQtnRRvLp1hvoxld2Pk/ZOCNTeEcQBMbAc2iC6GgcEW/lXRXrX905wqZq
1uu8A8FADCUr1h95R+ZTzRyGFMuzL0NG4lxSUHQ7miAhnknIiJOPKSGeabHc1/Qm3biOG+lEScHH
lOu4R6GiyHvUcRPyDnqYLFPrU58nCXel/wamLxNhdRtSwFh8TPn6r9WQpXE4AmOEi6Mg1PIFiXOi
AGkiCXZU7MXGpVGpdPfbuP6vEeXma1ZOyEwT1DS6XOD0ZLReSMmbzmLgvjNS0zZ8MEocz7SgVjsu
7Obl9V1VYwt5biAvJGS8IUiPF4SyjuATpEOQYqvkm+jcB0LZ8aiCME1NHpzWhfvtqE1epCazfkh5
mTOh4LQuPwJjEwUuOmSP1bq/GgQJru1xfmiiUBKndb1XX+v5Jo7/vfsekF/Jxh7vEn6HIDA1Galz
7a6EQB4RP5eojarGlDit44etPqaV87WvYwTThswSRvg/JW9HpgBnBNo+wkXTUSL8h/RS1MzSt6uw
SJmPA7NPN1ikwmc5vqMkWCRCRNCr+218YdcRe2pdOPKOzD6r6ojruInjXr0gS3MlhBBKQf+ajrj0
3VnOF0EKdfymv63EqxI/fZarHVdsg3XhEY2bQs53Z9CFRL5R5YQCYV6KyScvX7H1mptilsYU9q3C
coWXm749iKaGFL7XovRXHUTXdz8Pb2SgQymQFuuARMvAgLTDlhTFXH2VOSq8eemKgOpqyamXhU++
QLehPfOnqcn98958Y1Y5psNnZqVGR55EXNo6VEB0ZF2I6RAmBC3Rx10fhGv0pCRaUxocAwlH1hKt
7yG5CJw/2ZfoCo9dEBFphujVCLlXQZrvK2XlOrIBnXtD3oo0FFaFfGNWoR+wxu+ypdoDV3eTdncf
tuOu/WU4+1G2Grk28LGdvuvbKmQ3sOO9a+C0IM3HezvYkdTmZzv0HUxnXVwT8WiHvoPpdIprIlKd
WriBnS97B2Lq3viYc8f0qJDl7KEOPgHawY6klrMHeB2J6ZnUZn6QGd9hyveQWCzXN2BAAYkS++p9
U50R8gVjT7OKYQc7Sl+5oqfXIFE4qsHZZHLhXfPJ27nwB05Y0k0f6M4KWT7b8VebFbI5xCxXOxLH
rfTVkbe99NWRXi59HY3zApe8fIMXZ+ztowDLFmHZ+fzSkbdUGhc2drXagQIRFzbOakqPII+aViUh
RybNz4lhc5W8naWvM3sISkLObuQze4ipuHoKNbgoptB96eUbPGQPKXSXvHyDh+wh1u6uxldznBQM
xfqjt/ngkodpnB11zpCQXGkaZ4cL/DiZWskxuFxAasmPAUvw9TRT4DoXqr5YZhpX5Mvz4NOt5itB
CkmJpb4PRJJRauiRXIvE119ILkeWXNAHFZzUDvjv6uspX3+FEWP3xZK7MIF2maK7KfaDylBp1aXb
LC9NlYbiqb4DiZWvSpoS8vNeaxZHVy3kR3lpvzIy39Bc8vL1F0EDs89TKB8PZOnDd0b8kg6hb4hK
T49stV6wqPGN24V0wFpSGEosj2wVYsmFysFlfYHPSkjyi5KQ416Lr3Ha6MOV3tK56hlhoFrtyFb5
tifNMyqHbgRBAg/mGZVDEOLgZ77JdL+N5iuiWFTEdWar/P4tzXI/R0KInwelPMv9HAnhWzJE9k05
yjNbpWuk3FP3v63MDlFDKeCRrSIa54cCzTf4SHtZF+LwQwJuS1XK0JHDwQVE4/OWurtiOfPFBtb7
KjPzxZTnjbG3KQc/fB7uG4eZVmLXTr6EcFqZEOX5FmlmfxSp+ZvO7C9lsFZu+ir7a2VWoTqsn9lf
otaja0Nm9tfgi4orvTP7Swh8mytInP3ldr8U9jDl7I9iVG73wLSytQSBfWc00zpoM1WX9TOtS5Sj
bwZnWteQhb9BgRu4lD6LerxNOxvVkOvLPOt9kvha1T5MErOZiIkkMVuk2J9R7mBHTSsbwPvQdAM7
07p53R2r/LYjgd2eUe4o6ARWJInZko27phVeSBHkeEjL190gS/HpVgZUj99K+Zhupa87psczSsRa
oz5iLfvbGtKT0mKT5D3qbRtXNfbUuv9t8Mu5hUQS06MfCwI8GOf5TtlDgZNERFotSLCjgS2yGI77
FEF0B484S61bCi4KyOj4iKnq1fSmECRY8K5WO+c3wCy0MVJ3MU3cICxzAZnLLC7zBIljKT4YNb6O
SBRdzUKwy9cRWevp8T6SH8mFR7KzNtUE4Vyy9lrlt+nbRVh5yFuY7648LsDhppioS7DjJegAF8bd
iNXhwn6luYMdZZ6Vc6KoxfK4IB3XfKLTXPLOm8/IJ+EuptwPq/ZcYnAt0nz4CD9J1d80F35SHIsy
XDqB5ReNtSal9ceVJkXuv5a1LrxKOeGyYnclZOaSAwKiLNJRSgnjAEEK2WdWgxmEbajd1YWZcjbq
yn0crWC4N05qj5zIZhbkDVZptOKqM1dcIl1/5ETmt4HnF4WY3lgkrriklmOP/qZcCJxKVl7mbLfC
bYRTSeMNGGxIhxgWl/UFrg1BT23NZX1BSNZp9JB8MIRkEeZSadZBEKQACav15gpSgeHKIJvWhSPl
rM+qRsd9cI8XbjQ2fAXkp4oDaW4cLus5l4wxZxWHnI8LCz/xzIpuQWcxYcymxG8wpci9cVoo0TU1
fPMJ0a3K1Ly8+az8zkWA6dp54ldEJZKSEN3qigpXDlKvbzbl8/bRevJZP98gIrzVEqIJAkeJwHEo
23u0hr5TzpB9MzhvPrkDlm+RiM/bKSalzkHTjd/9cMcEP+LiN4htPif3CTKfB1FX8duRnvAbRJjB
4Juayk2w2/1qzdl0vkGEpHff1883iDCCRZFXEaQmfgOH6Ce4NqQmLoGsOb/ZdAZmUHu1qU4SOTBD
lKHJq5PEGZhxP3XXn9YZmMVayZWQOgOzpLOPIx1uXGcN1vuZEWwzJASsjz6z4Chbu1uLephC3hDN
6uzj2JRbi8IBRoWp4ikcLmLyEUpwNatxxNVD1LmMnHti5qvttVf/MM8lSwv4lhOhVrwPb+3RdxHB
QIBHIAl2TDlBAsunhlmCHbecfNBH6T6mNufGcWPi2hAvKhSO15ZsdRvdBFqbHv0zOYHtsQYBdmR/
nMCCTVltqswpP8rk1s73qYX9bVxvArt1B3hkiVDkHom9lSHp9pgg9n5udWuvcMLvfn6eOiQi3PPU
a/t756k/1hKz0xE3HPPUJ9xM1rZ56vovv+apc5uP9Byo/vjTY6I6V/q3ryHq4g9PuP+/keoIp549
4Z2R6huYN1J9A/NGqu+rOSPVd7DjCGaNVN83dUaq72A/MlJ9+90Pdfbl//zc75LVInDvCLyDOeOa
djBnpMIO5gxW3MC8keobmDdSfQPzRqpvYN5I9X01Z6T6DuaMVN83dUaq75g6I9Udguyt0/dvc0aq
76s5I9W9TbfW6Q5B9tbpDrP21uk73ZyR6juYM1J939QZ1+SI5d46fQPzRqo7urC3TvfAttbpjjrv
rdMdZu2t03cwZ6T6DuaMVD9X+2yk+knvT01baQYDpGkr1kszadqK9U5SmrZiPQuUpu0J5o1U38C8
ker7ps5IdQ9MmDYbTJi20gyuS9P2BPNGqjtckKbNBhOmzd5UmLYF5oxU38GcSXQ7mDNSfUfBmUS3
r+bMjHXEUpo2k1nStK1NnUl0DhekaVtgPzJS/ZT6TxW+WgPLpMJXa/yZVPgF5gyJ3sFchX+CeUOi
vU2FwtubCoV/gnlDovdvc0aqeygIhTdRkAq/VnNGqjuYSoWv1nQ5qfCLIM5I9Q3MG6m+r+aMVN/B
nJHqJ9hnI9XPj/2s23Vkphqx+tbtegM7nxWv9tM72OEeZ5uU+UZyAzskkgtne2hJfduhVJ0veMY8
6VhghyYTN0bmftTy2/TZROVrtjrbaXqYNrpyfdztbZu+qJlGtFZz9DHleiCmrqSbHuqZQrxaqeO2
MuvbtDfgW6WSYiP323iKRs7trmvZVjuUitumwXo0f1PuA5y4esvflA+SUppvmffVtMLTrNIISt4O
Fa2Z3wsnJW9nS14+IuiFhivkfDM9Hh1Bdy7oPIKb/o3ehvy2dMxW6lcZeZCkm1Z4fkWLFe8KxQ3s
6I4Ls9tL6hIFPTYOLoOrDQqR+20556tCklJ0Mc3zMORxiWLTjS+JUy2DJAr5GKnOgzNDVBKij30y
3BVsw10bt62mweCuKt0PgXYwHX1wW+9CNUoUjv5Og59jh9aziylP0UD+NYpCQV/ERn7hAwifCyXN
nrFJCfnZ+iZchUs+2hswrlyvNSoUjhLhPt18Gy6zuPa3hzrfvTrk5XmuNdy9gE6evnVXs3/wqbgf
Bnfch9RwMHtwt8Dc4G4D84K7DcwL7rZv84I7Z9M9uHM23YO7BeYGd85qe3C3gTkz/nYwZ8afQxAR
3G0oaHu6B3cL7LD1e3C3bXrUW23BnYPCHtw5YHtwt236otH8M7jbwLxszhZykc05mO7ZnM16kc3Z
3yayOVuzxEGVLeTioGpj/TEKcDuo2lZz5oo7uiAOqrbVDne1HVQ5YNuMPw9sm/Hnfds2V3znwvGi
Zc0Vd7iwzxXfwfRbim2u+A52jB9fc8UdFPa54vtqR93Qmivufds2V9zRrH2uuGNq9rnijljuc8Ud
Bdznijtc2OeK76s5c8UdFPa54udq76dtK0L+WILIRU0/5anNluLSU5vNrKWnNhttS0/tjKvZPfUa
baKdpvDUTzAdmktPvfpDH7fZu6deq+mbduGp17fpMnbhqddqmrzCU5sN8aWnNkfpSE+9Zr0cDXB3
T724oB268NQLBX3zJDy1PShFeGqTWdJT2ygIT73A9LcJT21PjhGe2uwmLz21ySzpqZeEHHMXd09t
jiWQnnqtdvR73T21yVPpqRcXXE+9wI6y4t1TmzyVntocQSQ9tcl66anNeQPSU5vMkp56kVf7L+Gp
17cdLnj31AtMv3oUntqepyI8tTOMZPfUpoRIT73Ajmapu6c2BwlIT21aS+mpTdZLT20OEpCeeq3m
eupFN12TKzz1Wu0otuVxoH32u99XU5rFIzpCC3Mm5I6CHvhRKj+9mk2NHbdLPIKIPZtaTYcudb7v
bMpEH81SW+ZHfvcTos0DfjjAmhSFfjC2IOtkXsYWNpiILZ5g56H1HluQeT8iYosFplNoEVuQfRO0
xxZk3gSJ2ILMmyARW6xNdbAlYgsbBRFbLLCj5f8eWzzBdLAlY4sn2OG/RWyxwNxTgAWmj5lFbGFv
KmILe1MRWywwff0kYgv720RsscB0ei9iC3tTEVuYq8nYYoG5pwBk3XnJ2GIp4KeD7We3g0NxP7UL
zboOkHbBBhN2oVlXFdIuPMHOCtrdLqzVjj5Bu11Yq7mngwvMPR1cm2qFF3bBXk3YhQXm2oUF5p4O
rm9zTwefYIf5EHbBJK+0C+vbjmRitwsmQaRdWJtq3RN2Ya3mlbHZgiTtwtpUHyIKu7BWO26pdrtg
0k3aBZMg0i6Y3ybtgkkQmXOYuiBzDlPIZc6xwI7LrD3nsL9N5BxrteMp455zmEIuc45lkT41lCO/
smSfGkq7VbQwlD/cyVEaUKupoX3k9PrnZ/PxeLXBD/MkmLZx2yzrDey4/i88MA/BeJZgR1zGbWFz
JUmZMy6r3Ib4bq+1rXbY39lyI9wJhdlClIsJCLo1HzEns3EgD4LKFUZJ0u0whWEOQqBb8+0m2pE7
npe7r4wHNq5Wxkg+3biYgAoSKJ9uid+eInXuim5H+FZ5xF2pzd+UuDlceDgkkwtcTNBgq7MSJO1p
+LlJCmNUf9Merwz3VpMrvdy5O8aYk89TLiYYwGAUV8i5mKDBqVaJwmGV4nyH3ZNEQftUbsmNfx3D
R4FfnCMUuV89Ot/GL857ekQ2pgJyMUGFMgyFgg4ta+AGn/cT1Q3s6F42LvjVnpIrb7n17XzAplvn
ITQ8j8IVJC4mmO2fgvttXExQSi9KyI9rl8gTqmBqFApHvzF2vfcQGkdPuZiAT6N68b8NPpV75VFw
LRIXE8AJ5uhzoRA/O+aBq64gcT/rFTguf/GhFyztpTf70AvmYL4s2b3gAfZjXnD7+c94wfVz1wsu
sKPvyu4FN7CjqenmBRdYetbsfj5/T3jKV+gf8/fKDy51nMDsTneB6VRXON0Flo/hG5vT3VY7pmps
Tnf7Ns/pbpvqe4Xd6dqYCqe7ycaLgYRPp7utdlTwbU53A9Plb7vT3VA4WtBsTnf7tmNcxuZ0N0nT
bnJ3urbcCqfrcGF3utumntPdWP9iNuDT6W5gx33M5nRt1gunu9FN1xPsTndDQYPtTncjiAbbne62
qed0t001CrvT3TY9cqPN6W6r6dRzd7ob3V5U8D2drq2nwuna5lQ43W1T7f92p2vLm3C6G9jRcWVz
urYCCqdrE0Q4XVvrhdPdCKK/jYdIBDgYpQsa05552MvoviDxfUyZPlV+24vKiTjovvPYNg0abHCn
9NIUF/TVCI/T7FSLEqSjq0m7iCuPFQrPlnof+b5HX3/K3LuORpOIOt7PDATupWpWPkFFR/bPy8so
58PCD251ZUVH28uAA+zHQoX99cC2lE0sO6Z7vdTxLA1RE8+xmc1kHDARNWmwLxKSHbcEgzZ/ng/y
/55H9LdDJOPk583PunVJKxo4LrDjeGNv4LjAThHheYUU5tH3ttoxug4CXluYt9YL7IhN9waOG5hG
IfFzj3L3+942PW711ug6DwWY5thgoNWmR2ERQqhENF83bJtqFBAbwVfdDw221Y4Gjmsm3b7aUdvL
5+2ZgqTb0bIApjnWMidA7Zu+eN9V0uNA2MF0cEsyAHdJN70aN3AsuZfiknd2+Ucsk4IrIdznsfXW
lPQeUeA+DMBGQQwDcL4NgoSQcsxHEJvKHDcLyDrY1MvVjjcmPJMu5jnu1tuU5iix+0Z9Q+FFNdOA
HDWlWa9uFnq7+8s7BOGZdLmTEsvzFWniF1J343gHhc6j3nuNb3jKo+t4qkT0ecqj6yoP9HZRuGfS
pR6b+208DCAgvW0S7BznTfx6a45+dsibIUjYuGuV0V0jHw0ctdYfYDzhju+y/E3nhDtIkjIORwLA
o8Soal3Q0TMSgB55jJVr8LnP46g8CUKudpROI1GH01Tf9mlHnjmO5+Te+3Yp03yU9DgAgon68HfT
Oj1/d3pDvjn68oYL7BxIitweLmK+SFpg5zP9iric7haH22q6wBOJMZUSZgaywM53iJFHE8XpW7fV
jqpSyF5DWCtROJxmG/xwaZAkyNFDGa4E1vWeRuCs1tlyhtCGj8LgoZ8xdkWQo0aVhzCOOxmwyTt9
BCKOmVXazOITFr5DrQrTw5WwgS13x38bBfYRoVNRmL56m8Jt2kkJ0gE2YE+QqWSXp6lwa8hxz0fZ
wI6BMYmPde500Za3RDxtpRdqLk8TYpKRHi8HN7DjvCbyVPemNOv0OIMHA/Ta/NUgSBlufwSfvCNy
l0atgOfpDzBFEtnktx22jo91KN3TCOxvYx8BXcjJ/zaeKwMDknpweTrfbxKMQ3Xpxu83oVchDldP
86wZ7OONAvIUVETxMST/24hPzUC2/gYM0deIdz2MsynsG/6Z4hvyQpASQpzyhrzzOTbPTRRgR2Oc
XmBqesrNVZk85rvXXJV901dVEKQ2QA9yMS0QpFF61Xp69AKucxh09t0HlwDD6N8lFpvPOt70DG54
fZd/2OpcMg8BgoEL/reVeIGv90wvm1lQvgtpXm1vNoVFQn7Ry5tNea5MBAZqU/1StXKZbQld2bfj
AAvZ5UgpviFvDzxaOrbko9DzHC2dq48CLNLXaGlvU3jAr9HSjs/ilsEhUlY25JhogqycO4yG7Irl
nCuDuECZmrPJb7iQS5Hyzjqv4Sa/sWJN31Hi4/mAPnVlHPRqsEi1IPqRdDsO/oinCFBIxdV62NML
sX5V33a806o8H6U3/W26SLzxaMM6gm9UidPt0ENOroQgX+Qel1GFBAemgy9dRmvB1foaIEiRypsw
rwY+zUAgOtxvq5FPM1IdydX6mogHyt8TwpxNU4fKjKE9oN4UeXTne0xf6ysk5FmQZkvvbMsbio4t
j67HfFYO6xaDy9PZlhe2Jqtv082RuY0mom2qPt243y7M1hvvzP12n53TbbfL/XaR4d+H4JsgfTpB
drw0UZ/mXOUnc67ylGQ35yqWSZQ5V7HEQOZcxTI7MucqlrTInKtYjJvJFCLl+mZTzpK+jhY3MF2Y
xgdu4SteWgQ5siR4HL52TS5BEhuKkOq8uLLJm/hmBfnKKC5BOEuKiVqQXDgC7wQutNrD8DeFK8kF
dph8FHJZB5XeatyGJbXbU9solLoOKm2e8q12G/DXb8hLfFoFlcw+QfhcLvZQ5bcd1cgIbjng62/o
xslUAcTwMeVkCoFQkyi8KgzmCGc0H9MBqz5Spu4KOQ9WgakoXRLk7BVXICGxBsWsow0m4nPGwFdA
rh+mxgeaLgp8lQ53cjdf2lbTR2R84AYD13wFlMmUvSlX2IQUqtr0SKYa9wS/B2E6dJttWErWmnX0
zEHUym23FOtfTUwJlYh8LvCQTmq1dR9TnpjCUbxvajIECcbrnr5pYwr3i0wErPfJy4NVCnS6J3dT
HqzyHEhjqwxf89cZQbryxtf8bfSu9PT4tlxmU2itp8c1f1qTZpxNEQM/J81smL6oBpglGW/oVhGT
UIhKT49EDzkXdCFrPT3aLfQ1aWYD090seJZngvEdrgLyLM/nQBpbesvIayCN/W1cWwDx6CG4mHJt
AZdupOzSjSKfiFLXdNMjPSKfiLIddFEgHmQe833742zKM+o6tvY9ICHHB/uDDjB02ogcv4Z+Tylw
6MYt/mnk7Gs9cefzDL1XmB6zPGFqeipJoaDfyFYkBTWH3FzjQPMmtNxTCjYwXQjCM+qg0yrAOJgF
eUPcXbSevhqsgohA+dMjjOfBKl9T5ezV5mAVvt72yTsHq6R8d/FaYDrz5SGdiJDu222bbjUjCUWU
kX2LBBM+75Kqb5EqX3GGeneNs4W8Eh91tnv0joMpX3FCjJoEOzJfnlEXELwXl6e18XCm+DiLs7+N
Z9Txg5roM6vDZ4Eq9GZTnneewuO01t6Uz6VbjCp015lvC+1iO16lIH2a6LX40gN8mujVn0z06pNx
bqJXLSMmE71qSYtM9J5gfqJXLZMoE71qCbxM9OxNRaJXLS2Tid4iiJvomQSRiZ5JXpnomQSRid4C
cxM9e1OR6NkoiETPWW1P9GwURKJn8lQmeva3iUTPJohI9BYKbqJnYyoSPRtTkeit1dxEz8ZUJHqm
kMtEb23qJnprNTfRM5klEz0TBZnordXcRM9UQJno2ZuKRG9t6iZ6Nt1EomcKkkz0Fpib6NlcEIme
jalI9EzplYmeialM9MxNZaJnbioTPVNlZKJnyptM9OxvE4meafBlomdvKhK9hamb6NnfJhK9tZp+
fAZBGtTv1r7Ot3EGx+OtqytvBYIEVxSrb98KBClnTh5cPS2DC7URGxZXkAgekA/GtT/VORcyuD7v
TlxM52jMkmrNrsrM67CRm1LnI0uChCCQa6W5mHLvH65EiNFHgW/NWr4LaJ1NOYObdRIuF2YGB1Zp
46DTRs7g4OqVcThHY3JEPVJ4Gb+9fUTHl26Mv7Kinz6ie/w8KOYeKEOMR0d+rtRfZ6OI51uPub2M
Hn+o5L0G9lyVlM10St7tG5zHUsM3SvAeMHFcYyJJcSSYCSZuaLt6XHUlfqgWHnVlazWdnSXi04CS
gr9aznwaQMU3SpxggpuPS2RT5DjBRJpfQnOZzgkm3EPW0ftx98fVm3Q/kXIwbVyDhAxTitDH13Dt
pcH4NDvrP5mdff3uTXbWLRrK7Kxbsiezs26Zuzjv6znil5seSRy3KA8Pk2KDse4nLvWTYMeMtoSI
lKsw5LcdxYqIN/Jjzquz6eDiMWQG1SWITOK6JVSyptH8Nq57h/XKQ26qj1tlTaO9aWL7T/f7WGfT
zPa/3pOAbYJwTSM8daIgVzuys8bt+h9Zhk03ihcS5HxfxJtimYg4QnhEywvsVeOHZ4Swvu2YH8fd
ATspZr2saYzjHvG7barfx86axtD6G0xnTWNqRaKgXRLXNNLIvSUX01nT+HT9pi5wTWMfCNS6iwIX
KyLySUoXjvQhz/g21+JimjMfGoT7qarN01zCdnhrY1rm9I0SfPIiw2Crfo+YdTYlfsvQchqu9AJF
BAa9kC8hCByuORiE/G+7u3JR9jVr1jRC56vSLP2Mlmsax2PCxbaaDvg5PIB8kG8G54QLguHy7RvX
NI6U7mmqtmbBSV+wDC37dEM6exWkLKQI8qJ3xSo0sr+twL6xp/TpVmBqkP6Eml0uFPis1KExvrwV
HliDNF+p89kJA2YQRi748lYacciX3tFtFiu2TL68FVgkhHyPQvH1ba+KFYmbWrnug4sVEfKFN3rK
xYoI+e4hzBvY8XaXixVDDgrT435t8NOkuzeBbZH4iW+LPDLKpRs0D/60t5j91Qo3sht3vwmbvMSh
1IhNeeezWJH7j5WiXdtRrEj8NPpRY2ZqFs2+CTBv0ce0B54HdLcftg0+9X4hPNfx24EpTE3nDhxS
F85iRZ5QnkuNLk9nTWMaVcdvR7EiN0QIh6M8bsQQ5uWoHeVZrEhX6f1x4WhvynOU8oja9h7Fityc
JSRlez9OCl5b2fl++P8A/KhW+2VuZHN0cmVhbQplbmRvYmoKMjkgMCBvYmoKPDwgL0NvbnRlbnRz
IDMyIDAgUiAvTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdIC9QYXJlbnQgODUgMCBSIC9SZXNvdXJj
ZXMgPDwgL0V4dEdTdGF0ZSA8PCAvRzAgNjIgMCBSIC9HMSA3NSAwIFIgPj4gL0ZvbnQgPDwgL0Yw
IDYzIDAgUiAvRjEgNjkgMCBSIC9GMiA3NiAwIFIgPj4gL1Byb2NTZXRzIFsgL1BERiAvVGV4dCAv
SW1hZ2VCIC9JbWFnZUMgL0ltYWdlSSBdIC9YT2JqZWN0IDw8IC9YMCAzMCAwIFIgPj4gPj4gL1R5
cGUgL1BhZ2UgPj4KZW5kb2JqCjMwIDAgb2JqCjw8IC9CaXRzUGVyQ29tcG9uZW50IDggL0NvbG9y
U3BhY2UgL0RldmljZVJHQiAvRmlsdGVyIC9GbGF0ZURlY29kZSAvSGVpZ2h0IDI4NyAvU01hc2sg
MzEgMCBSIC9TdWJ0eXBlIC9JbWFnZSAvVHlwZSAvWE9iamVjdCAvV2lkdGggNjI0IC9MZW5ndGgg
MTY0MDkgPj4Kc3RyZWFtCnic7Z0PcFXlnffPYgpptQoGSTRIQiSQgMQYoAULW/LSFPrCSkaBZYUa
/miCRBoGecEqJQrNCihQ2MGNFbahooQdFGZxQcNOOuhGEUSBFQyVbVk3jtnBJd3J7NalQ3m/nh95
enLuuX9y7/l77/czd+6c+5zn/Lnn3vt87u88z/kdTesZg3UKCgownZWVlZ+fX6gzaNCgW2655SYS
GzhWOTk5t99+Ow4mntPT03E88/Ly+vbt+41vfKOHnwkhJBm4VcfrxonESXZ2dowftGh0xIgRmIY9
0fLffffdy5cvf+6551566aWmpqbTp0+fIz0Hh66hoeHJJ58sLS3NzMyET+WAw6p/9md/5tTvlhDi
P27T6STBBEqN+hEj8LzjjjvGjBkDh0KpEyZMWLdu3dGjR70WUXKyf//+hx56qF+/fr169cLBv+GG
G5z/ERNCfAF9Gmii+hQmveuuu6DUIUOGTJ8+/ciRI14LJyU4e/bspk2bEK7Kp5CWlub8T5kQ4jH0
aaCJ4NMbb7xx4MCBmBg6dOj48eMRN3ktmVTkqaee6tOnDz6FjIwM937VhBAvoE8DTTifFhQUIDLF
3Nzc3K1bt3ptlZTmgw8+kG5rQkhyQ58GGkuf3qVTWFiYn5//+uuve+0T8hU/+tGP3P91E0LchD4N
NKE+LSoqGj16dHFxcUlJSUtLi9caIX9i8+bNnvzGCSHuQJ8GGpNPe/fujZgUwenYsWPPnj3rtUCI
mS1btnj1SyeEOA19GmhMPs3Ozu7Tp8+wYcN4OYxveeSRR/BJqctUCSFJA30aaIw+HTJkiKbnbTh0
6JDX0iCRGDp0qMaLaAhJOujTQKN8mp+fP3r0aESmL7zwgte6IFH44IMPevfu7e0PnxBiO/RpoFE+
zcvLQ9QzefJkr11BYqK2thaf2te//nVPf/2EEDuhTwON+BQyHTdu3ODBg5uamrwWBYmVfv36ef3r
J4TYCX0aaMSnubm5d9xxx9y5c71WBOkB69evx2cn2ZMIIUkAfRpo4NO0tLS7774bSuWY3sDxzW9+
0+sGgBBiG/RpoIFPBw8e/LWvfe3+++/3Wg6kx8yaNQu/weuuu87rZoAQYgP0aaCRDL133nnnjh07
vJYD6TGvvfYa/gtxVBIhyQF9GmjgU8g0JycnwbuBFxcXZ5Oek/iA6r59+2ZlZXndDBBCbIA+DTQy
Hqm0tDTBVn3QoEFXSc8ZOHBggkd+zJgxXrcBhBB7oE8DDXxaUFCwbt06+tQTEvfp8uXLvW4DCCH2
QJ8GGvi0sLDwpZdeok89IXGf/uIXv9B41QwhSQF9GmjEp83NzfSpJyTu06ampr59+15//fVetwSE
kEShTwMNfJr4YCT6NG4S9+nZs2dv0vG6JSCEJAp9GmjEpwk26fRp3CTuU4APkYkdCEkCnPBpfX39
BCtKS0srKio2btzY1tZm7xZTFjTFtjTp9Gl82HLwb9DxuiUghCSKEz594oknIm80IyOjpaXF3o2m
JvDpzTffTJ96hS0+vV7Hnd87IcQ5nPPpnDlzTOXnz59vbGyUmynjuaOjw97tpiD0qbfY5dNvfOMb
XrcEhJBEcdOnQmtra3p6OiocPHjQ3u2mIE77dOzYsbkkN3fGjBn0KSEkMu77FBQVFaFCfX29qfzA
gQOrV69etmxZXV3de++9F7pge3t7Q0PDihUrUGf9+vWnTp0KrYOwd+/evdiHmpoay/U0NzdD5Rcv
XjQWInZG4YkTJ+RlW1ubvMQWsSFsrqmpSVXGsmo3tmzZcuHChdDdwFbWrFmDCng+cuRIuEORIE77
NCcnp4N0dECp9CkhJDLu+xQykqsDGhsbVSF0Fpp4raKiosNwThhGy8jICK1jXHlLS4ucT46wHrgD
hWfOnDEuCLkb9xkyxcvZs2eXlJTISrBpUTBknZmZaVw/2sNdu3apVUGvZWVlpn1AgAM1x39Mw0Cf
ugN9SgiJiss+hZIWLlyIuRCB8gsKhw8fjsLy8nKEciiHOkWvSpdo07Kzs9PS0jZu3Aj5In7ct2+f
eA2hotRpbW0V4cKDCEvxEnXy8vKkRO1D7D5NT09HW1ddXY0wE2+qU/d1mg6iTqwB6kT0ipeoKcEy
9nPcuHFYFkrFe8F+4ln0Om3aNHuPcyd96hb0KSEkKs75FCKb0x1oRSJT2AdRnqoPJWl6UnfjSmBV
UaGcsIXIMD1hwgRjHZgU0SjUJi/F1EZ1duqRr0i2ublZSmL3KTAGnmDKlCkoVFsUYFsU1tTUYHr7
9u2Yxp+BDkNEjGn5w2A8aWwL9Kk70KeEkKi4fL0MIko4y9SnKaGo0bDCihUrUC6BIYJNTRcxhGXq
+lRIuKr6QBXiO4SZ8jJ2n6KhM9bBdrEDiEZNZ26hbOw89rCzS7jYSdM+1NXVGffBLuhTd6BPCSFR
cc6n5eXlZ3QQWiLKkzFIlt2IcvEd6pviWTlxquJNlMg+Q2oIZmEo43gkSE3TTyOH7k9jY6Omn4CV
l7H7tKSkxFgHfwM0Pe6O8N5l5diW6b0gstZCYvDEoU/dgT4lhETFtf5TaFTG9sCSJqVG3kN1jhfN
2vr168XLxrliVfgRL+GF0P0ROar1xO5T0+lly0ITcilQ1PdiF/SpO9CnhJCouDkeCQqTUNQ0KFcc
ZHnViSWtra3QH+JWWZtEkVhcCxOfIjrGrClTpsjLuH0ae3waes7ZIehTd6BPCSFRcXl878aNG2W7
+/btU4USchovnxHkRLG4CQ7FtBpTJMCJ4uLz5893hu8/ramp0Qx9l3JBjakPV/pqI/v04sWLMrjX
FF8jQM7Ozpbz0qWlpZpV/yk219DQYHlRbSLQp+5AnxJCouL+9afSk4gGXFlp9erVmn4euMNqTCwU
3NkVP6o+UEFdyioJ9iOP71Vja0V5xmwSaixxZJ8CufKlrq4u9P1i651dfxiw58ZBUx1dF9GYBgYn
Dn3qDvQpISQq7vsU8aMElXKBSadBZ7AVIlDjNZtKTHhGDCirRZSHRfA8bdo0TR/IJOtR159KHblG
VaLRGTNmqB2A1DR9pDECRkS4e/fuLSkpUQtKnXA+VdefQqnYHGSNCbxEkygnkNW1tBAoDI59wCIy
6Bf7b/uNdehTd6BPCSFR8STfoBgNGlLnb0+dOqUyESlQYuzlhJ5EqUYQbBo7XiEvUbORiooKY7SI
aQlRFbAJzKvF4NNOPT+SKU0T1Gy8sBSSlRjcCLTuRKcqfeoO9CkhJCpO+BQSNObCDQUN1EEdUwJe
yd8LHeMZ06ELQoW7du16QgdStkyP0NGVvxeEy/Er25I6ckErCM3fG+6mcoiO6+vrZXFMWCYSxL5h
D6UO9qfDmZvp0KfuQJ8SQqLihE+Ja9Cn7kCfEkKiQp8GGvrUHehTQkhU6NNAQ5+6A31KCIkKfRpo
6FN3oE8JIVGhTwMNfeoO9CkhJCr0aaChT92BPiWERIU+DTT0qTvQp4SQqNCngYY+dQf6lBASFfo0
0NCn7kCfEkKiQp8GGvrUHehTQkhUfOLT8+fPL1u2rKioSFLlZ2ZmlpeXh97BjZigT92BPiWERMUP
Pm1qapI7g2u6SdG2i1U1Pd29ZXZcItCn7kCfEkKi4rlPoUu5D3hFRUVra6sUogVDcCrl6rZuJBT6
1B3oU0JIVDz36a5duzT9bqGhs+SmaYhVGaKGgz51B/qUEBIVz326evVq7Mbs2bMt55aUlKCpN91z
De3bvn371B3ZjPdIFZp1MLF9+3a5IxvWEO4Wck1NTZhlvEEqwmSsNtyt1s6fP4/6eMZ2sfNr1qx5
77334nvviUOfugN9SgiJiuc+hbCwGxkZGTHebhvVhg8fbnwLaWlpK1asMNYZpCOmFurq6vCcl5dn
Whs8ayrHUlihcf2mW4HX19fLCuV0tBYmuHYH+tQd6FNCSFQ89ykaq6KiIk0/rztt2jTYKjTeVFy4
cEF1tiIqbG9vR6AK36EEHlTVYAe0UdBieXk5Ykw8o1C2YroFOUSMQsSY8lIUnJ2dvWvXLmwLtl22
bJmmj5LCS6kjPoXIUA1zq6qqEP/af1xiI2l8umTJEuzDsWPH3NlcT6FPCSFR8dynnfoZ1LKyMuNe
wV+zZ89ubGzs6H6utaamRtNlalocWoGOlfLQMqPanDlzjNU2btyIQujPWIia0K6Mg8Li6Tqm08ui
VDUsSnyKpUzVPCE5fNrW1gan4HsIq7qwuTigTwkhUfGDT4UjR47IJajG3UPsaeydREiIwtD+SsgX
5TCdvBSf7t2711hHdJmRkdHR5WgZ7wSVy0sRpQSzRuScMNZprFZSUmLT+06I5PDp888/P2DAADzj
02lvbzfNvXjxIj4CywXDldsOfUoIiYp/fKpAtILIFEEoZKHpsSoi0E5diLLPc0IQC0PHsgbxaeh5
Y7gS5SpNBDaBlw0NDfKyuroaL7Gq0PXLdmXMkvjUFPx6RXL4dOzYsQ8//LBEqbCqsXzVqlUZXbz8
8suqfO3atQN0UG5cxCHoU0JIVHzoU0Vra2teXh52UoYbwY+R34tyXDif7tu3D+UzZszANOSIdgyt
sRrZq7wZDlkhfWovx44dw/Fsbm7G9KxZs0aPHq1mYa/wAb3zzjuY3rRpU1pamnSwSvlbb73Voce2
KJdp56BPCSFR8dyn4j7j5SpGtmzZgrlTpkzp1PtJNX3YUozrDPUpGsbs7Gy5oBVhqda9O3XhwoWa
YWxSOOhTe1myZElhYaFM79+/X+tya4fuzdraWlVz5MiRS5culXLEraocCna645U+JYRExSc+VV2f
JmQQkbo6Vc4At7S0mKqhBW5sbFQCDefTzq7BRdu3b582bRomjhw5YtoWyk2LwPXYvYMHD8pL+tRG
cGwHDBiQn5//QBc4tvPnz5e52KsDBw6oypg7depUKZfrglX5pEmTHN1P+pQQEhXPffrEE09oeidp
qCVbW1vFjKqLU0JIOWGraGtrk4to1ACkCD6VwUVlZWWIUocPH27aXJqOaU8QsWqGAUj0qY28/PLL
OODLly9/vIvJkyfDLxcuXOgI8eb06dNnzZol5Xv27FHl9913n3jWOehTQkhUPPcpIpRx48Zp+hUo
iA0RJEJY27Ztq6qqkmi0tLRUVYbyMjIyND1ihfXa29ubmprGjBmDkgkTJqhqEXwKZHNg/fr1plnq
alMEsGjSsbm6ujqRLAIlqUOf2gjsOXHiRGOJ9JI/++yzHbo3oVopx2eNSFaVy4nfDj3CxRd47dq1
ju4nfUoIiYrnPu3UU+JXVFSYshJpumERkJqS90KjMkjJCJwrY4CFyD5VF5Cq61UVaDlrampMe4Lm
zng6mj61C2wXhzp0dO6kSZOkR1WuDn7mmWf2798P8+KliltRDodKOb7AUu4c9CkhJCp+8KmAYFDS
7cKtiBO3bNmibjdjAu3b3r17URPuW7NmjSnlUafenWpKyWsE5Zhr7Dk1AREjdMU+rFixAvY0aVfy
98aYHdFpAu1ThPwPPPBAW1ubqRyWRLnsFeLT6dOn5+fnP/jgg/hcpALKH3/88fvuu89U7hz0KSEk
Kv7xKYmDQPs0Ktgry2tLw5U7B31KCIkKfRpo6FN3GDlyJLZ49OjRL7/8kj4lhFhCnwaa5PbpkiVL
Dh06FHu5c5SVlVXqVFdXQ6zHjx+/fPkyfUoIMUKfBprk9ql/qKioqOwOnL5jx45Ro0adOXOGPiWE
aPRpwKFP3aG4uHjPnj0rV66sDAER69atWw8fPtza2kqfEpLK0KeBhj51BzUe6ZNPPtm9e/eyZctC
xVpTU/M3f/M3cYiVPiUkOaBPAw196g6m8b1Xrlz5+OOPf/nLX86bNy9UrI899lh9fX1zczN9SkhK
QZ8GGvrUHcJdL4PjdvDgwc2bN1dXV4cT69tvv02fEpIK0KeBhj51h6jXn545cwZi3bRp0+LFi0PF
unLlyr/7u78LJ1b6lJDkgD4NNPSpO8Sez+Gjjz7av3//hg0bLMX6+OOP79y58+jRo/QpIckHfRpo
6FN3iCM/EsT62muv1dXVVVVVhYp11apVEOvx48fFp9nZ2VFvZ08I8Tn0aaChT90hkXyDJ0+efPXV
V8OJ9emnnx41ahRk+nAXKPS6VSCExAN9GmjoU3ewJX/v+++/v3v3bgg01KpGoNSHdChWQoIFfRpo
6FN3sDcfvoh11apVEXyqJhYuXDhz5kyv2wlr4Pu7NG2Ipg3StCxfPrBvxZo2RdPe9/pYkVSAPg00
9Kk7OHR/maNHj+7cuRO6tLSqPGOuhKsLFiyoqKjwusHoxnRdqSM07VYfPyboMv2J18eKpAL0aaCh
T93B6fu1QZ2IQ8WhlmKFTOfNm6ciVj+I9S807c/15wZNu+rjx1Oa9v807S8ZohLnoU8DDX3qDk77
FOuBKGU8EnQZoXcV1USsmF60aFFtba1XTcc0TbtXP5v6B6+NGfnRoWklDFGJK9CngYY+dQd37icu
saeI1RicWlJVVfXUU0+ply63G3+hn0f1f3DKEJW4CX0aaOhTd3DHpwoxqbp8RoYnRRCr+9fa/CAg
wakpRH3cnaNDUhX6NNDQp+7gsk8VIlOIEqGo5eWrpjDWqGDnGo1xenAKpe71WpSxP57TtBpNu0/T
XnTuuJCUhz4NNPSpO3jlU6G2tnbRokVizHnz5kUIVyFTFa6qs8e2Nxp/rmn3aNoorxXZo8fvNa1I
l+kjth8OQrrIzMykT4MLfeoO3vpUUVFRoTpYRazGzlaTWGXAsBLr3LlzbWkxEJyO1bSJmrbfa0X2
9PEzTVuoD6NiiEocYsCAAWiQs0gwkY+PPnUan/hUIWIVt86cOVNdrBouboVMlVgTTBQcxOCUISpx
h379+vXv3/+WW27JJAGEPnUHv/lUAZmqiFUyP4SzqpRDphLVzp8/Pw6xjtS07wYzODWGqOWa9lh8
h5sQktTQpy7gW58qINMFCxYon0YQa6WeO0Jl4O9RouBReog3yWstxv34g36+GjKdneDhJoQkI/Sp
C/jfpwqRqQBpRs0OUWlIFBw57VKhpn1b00Zr2q+81mIijwZNm6Fp32eISggJgT51gQD5VAGZzp8/
X4k1Qger+NSYz9AyA3+Jpg3X+089d2KCIWoJQ1RCiBVB8elvurBrhW4SRJ8qJEqVM8Bz584NJ1ZT
Bn4ZIawi1uQITq8aQtQpDFEJId1x1KfwRY5NvN+FXSuMyrhx4+xa1dixY4PrUwVkqsQqw4MjiNUU
sZb06pUEwak8EKKO0WU63YWDTggJDo761EaUT53ekHDp0qUlS5ZcvnzZ0a0Ey6eKBQsWKLGqK1Uj
9LFCrNOGDSvRtA+9VqFdj/2a9n/1gVU/dPO4E0L8DX1qyRtvvAEXHD9+3NGtBNSnihgz8KNwxqRJ
U72WoL0PhKgPatpUT447IcSX0KeWrF27FiJ4/vnnHd1K0H2qqOyegT+UsX37Jk1wKo/9ehdqKUNU
QkgX9Gkon376qVhg0aJFnZ2dzm0oaXyqUAJVGfhh2Dn33vsXvXp5bkDbHwxRCSFG6NNQXnvtNeWF
I0eOOLeh5POpoDLw/3D27Hnz5o3u3TvJglN5vKGHqGWa9n+8PuCEED9An4aycuVK5dMNGzY4t6Fk
9amioFevEZo2x2vxOfeYqMv0O14fZ0KIH6BPTeDtmPr+vvjiC4e2ldw+HaKLZqimfeK19Zx7/EpP
7//nDFEJIfRpCL/85S9NPv3Hf/xHh7aV3D7N1x9JHJzKYyJDVEKIDn1q5PLly0uXLjX5dPXq1Q5t
Lol9iuB0fLIHp/L4lR6iljJEJSTloU+NnDx50vJyj08//dSJzSWxT/P04LTCa9m585isy7TE62NO
CPEW+tTI888/b+nTPXv2OLG5ZPXpQL1LEUr93GvTufP4UL8P3QQqlZDUhj5V/Pd//3d1dbWlT1eu
XHnlyhXbt5isPr1dV+qjXmvOzcdUXaZ3eX3kCSEeQp8q/vmf/9lSpsLHH39s+xaT0qcD9cE5g1Im
OJWHhKjfYYhKSApDnyqee+65CD5taGiwfYtJ6dO81AtO5cEQlZAUhz4VLl26FEGmwInbzSSfT2/R
R7rmp1hwKo+P9RB1oj62mRCSgtCngtxQJjK2324m+Xx6m6YN0LRVXqvNq8ecrqtuCSEpCH0qyA1l
ImP77WaSzKe36M+3a1qH117z6vGJfsntdxiiEpKS0KdXDTeUiYztt5tJMp/aE5z+6ld/etTWdps1
ZEi3uRUV18o3b75WkpXVrf7EiX+aLi7utuz993erOX16t7moHO/+S4g6zOvPghDiPvTp1e43lImM
vbebSSaf2hacGvn8826zqqq6zVW2hQGF3NxrJZjYvfurEqNbjWCucc1SWWEUcc9D1EJNm6Rp3/L4
AyGEuA19Cv7rv/7ri+4ogZrKGZ+GI1MPTn+aoExNPgUFBWGtp3yK8t/+9qvHwIHXSj755FqdcD69
eLHbRiFuIwn4FI9HdJkO9foTIYS4DH1qifKpo1tJGp/epD/fqmm/t8unv//9tYmamj/N6ujoNst0
Ntj4gFuFUJ+qxdVJ3TvvNM9KzKefa9pgPQPhcG8/FUKIu9CnltCnPeIWTeunac8lLlPlU4k3wYED
18qhP0Gd3VU+NfafSj+pMiOm5dSu8qlafOXKa4tD2aZZifkUjx9p2ghNu8PbT4UQ4i70qSX0aezY
GZwaffqLX3w10dl5NS3tq3LoT4BG1YQsYuw/NZ3XlVUZfYrViqkPHbq2OJRt3OJVG3wqIepEhqiE
pBL0qSX0aexk2hicGn1aUXFtevz4r8qhP1O5pU8LCr7SourmxvSzz5p9Kt5EDJue/pWspbIqv2qD
T1WIeqeHHwwhxF3oU0vo09gZqGnZdgWnRp9CjgK8CfEp60X2qZRE6D81rgGFY8dem0ahrT79XE+X
NMbDD4YQ4i70qSX0aezk6FeI7Lfdp0qLb7/9JxvCeon7VJn6mWeuPvnkn5a11ac/07RpmjbWww+G
EOIu9Kkl9GnsSC6gYid8KoL7wx++OmcrwHqJ+1RVePfda8saN3fVBp/+Xj8g4AcefjCEEHehTy2h
T3tEoY0hqiCCU+qU8bqmwkR8+uKL3dYshfb5lMEpISmIr3z6b//2b5cuXbKcRZ/62ad2hqiCqFOd
mBXEerb49C//stuaJXWhTT79fddd2x6cNu3hhx/Gt8jLz4YQ4hb+8Wl7e/sbb7zR1tZmOdcnPv3t
b3+7fPnyiRMnlpeXNzY2JriVpPGpZmOI2nWgzWYEc+b02KcDB14rNPk0K6vbJyF1bPIpgtPZxcVi
UoCJhx56aOHChXj2+lMihDiIH3x6+fLl1tbWN99889ChQ3726eeff56VlQWTNjQ0rFu37oYbbvjp
T3+ayFaSyae2haiC8qlyHJB097H49N13ux3oUJ/i8fHHYbeVgE8RnI7q3RvqNKZ9hkwf1hGxMmIl
JCnxg08/+eSTd95553e/+53Pfbpq1aqCgoI//OEP8vJnP/sZlJrIVpLJp5pdIaqgHKfsCf2ZSiL4
dOrUq10fkxxoC5/+7d+aS+zwKYLTWcOGqeDUCApFpkqsc+fO9fpDI4TYhh98+uWXX8qEz3367rvv
/ko13VevNjY2pqWlJbKVJPOpPSEqnIiHymyfnn6tRN2LDf9hpKRv32slmCUlkklJHljD/fd/dSO2
IUO6rad//2sVsLhpPZglJagcb3Aqw3pnzpxpqVQlVjxDpmLV+fPnz5kzx8tPjhBiB37wqcLnPjWC
KHX8+PFTpkxJZCtJ5lPN3oG+AXzIsN5xvXpVVFTAleJNNREuYoVMH9KhWAkJNPSpJZF9Cpmi9cvK
yvpE3RcsLpLPpzZfixqox+/1BIOa4ZpTkWkEn5r6WJVYpfvVm4+QEBIv9KklEXza2dlZXl4OmX6s
BrTES/L5VEvhEBXB6Xe6rpQxIaGoAGlKL2q4iFVkKhNg5syZbn+EhJC4oE8tCefTzz//vLi4uKCg
IMHIVEhKn6ZmiKqC03ERDw5kOn/+fIlYFy1apPpSw/WxSj+sdLNSrIT4HPrUEkufIjKFScePH98h
N7ZOmKT0qZaSIWqE4NSSqqoqFbTOnTs3Qrgqz5CphKsQa0VFhYMfHiEkXuhTSyx9unTpUhyx5cuX
P2Ugka0kq09TLUSNMTi1BDKVVA/iVrlS1VKsEqjOmzdPKsDItbW1dn5shJDE8JVPI+AHn6LpmxhC
IltJVp9qKRai9jQ4tUTlUBJ1RjgVLOC/nEwsWrSIYiXED9CnloTrP7WXJPZp6oSoiQSnliilGjMW
hrMqolSIVVW2aRcIIfFAn1pCnyZOioSotgSnlqjTvDCm9LeGQ8WzFCshHkKfWkKfJk4qhKi2B6eh
1NbWykhgOcdbpRPBqpXMwE+IR9CnltCntpD0IapzwWkoIlaR6bx580wp901iVRn4JZ8hEwUT4gL0
qSX0aeJUVFR8d/hwLXlDVBeC03AHVo1cgljVpTfhxAqZMgM/IS5An1pCnyaIJLCVMCpZQ1Q3g9Nw
B1l5UzI/RD4VzAz8hDgKfWoJfRo3tbW1aNUldJJjOGvWrOQLUb0KTi2BTNUJ3sqIGfgruycKXrBg
AbNDEGIX9Kkl9Gl8SEMdOh71zvT0JAtRPQ9OLansnoE/Qh+riFVOIDADPyG2QJ9aQp/GgTTLUKox
OJIuPC25elF9FZxaoqLUnmbgR81evXp5vfuEBBL61BL6tEfU1tZWdl3/GNpcIwga079/MvWi+jM4
tURl4AeSKDhCBn7ph508ebIsm56e7u3OExIs6FNL6NPYkVEuKv2dEXV7lGS6FtX/waklxkTBEcRq
zMAv9ZmBn5AYoU8toU9jRM4ryhUZxmZZhiQZb9+ZNNeiBig4tST2DPzy4UoGfnnJRMGERIA+tYQ+
jYrcQcyyKVb5fIz1kyNEDWhwaokxA3+Ei1iVXpmBn5DI+NOnn3766fux0d7ebu+mBfo0MhK5QKmh
Da+0umifQ5dKghA16MGpJcqYke9oI0gGfiVfr/edEB/hT592dnbG6NP//d//tXfTAn0aAWlL5Yyu
qaWViXDBS9BD1GQKTi2pjDkDv1IwO1gJUfjTp+Bf/uVfosr017/+te3bFehTS9BsRohiYglYAh2i
JmVwGkpoBv4IPq3sSibMDPyE+Nann332WVSfXrx40fbtCvRpKJVdF79Ytqsxnv2TELXIazMyOI0F
JVb53GPMwC9pl5gomKQgvvXpl19+GVmmH3zwwZUrV2zfrkCfGpHLSysNZ3RVK6rO+sa+tnxNy9W0
17z2I4PT2DFl4FfX1FiKVY33ZgZ+kmr41qfg7NmzEXz6r//6r05sVKBPFeLQcJeXxpGnbqD+PMJr
PzI4jQO5zYHK/BB5PHBlVwZ+wAz8JBXws0//4z/+I4JPOzo6nNioQJ8KchBUb1poJKIuL+0RdwQt
RE3l4NQSle0hagZ+/B8zZuCXzIde7z4hjuBnn16+fPnEiROWMj158qRzJ3uv0qeGy0tDz/FK0JFI
qxisEJXBaQQqu2fgj5AoWM2Vf2LMwE+SDz/7FPz617+29OmFCxcc2qKQ4j6V5jHc5aXSQZbgJgIU
ojI4jQXRpbonAqYj3IzVlIE/vrMchPgNn/v0P//zPy192tnZ6dAWhVT26YIFCyxP39mbdC4oISqD
054Sewb+SsOd0ClWkgT43KdXrlz54IMPTDI9ffq0Q5tTpKZPVRNnyumqRnXae3VhIEJUBqdxY8rA
H66P1ZiBnwkiSKDxuU/Bb37zG5NPP/vsM+c2J6SgT9WVL6bTdJJfDq2c7U2chKhf07TrfPzore8k
g9NEgEzVSY8IGfgFlYG/komCSdDwv09/97vfmXz6P//zP85tTkgpn6LJkrYOzZepoZOWDUp1qFlL
81qXkR9p+uNrTrzzlETlUBJpRj4VrBIFU6wkKPjfp3/84x9PnjypZHr27FnntqVIHZ+qy0tNIzNV
ShyeeSO2Y0wQEc6nJrHGnoOLEK/wv0+vdr/djEM3lDGRIj5VYWloIyY9WZQpcRQVosaegV8p2Ot9
J8RMIHxqvN2MQzeUMZH0PlUBgilGMCZideL7Rkgopgz8UdMuqbvVMwM/8RWB8OnVrtvNOHdDGRPJ
7VMZHBKa4Vyd40UFh75vhERAMkXL37keZeBnomDiB4LiU7ndjHM3lDGRxD5V7Y+pgZJAled4iR8w
drCqRMERLrdhBn7iB4Li0y+//NLRG8qYSEqfGu9eamqaVHpVp79vhPQIY6JgEWvk2+8yAz/xkKD4
FHz++ecubEVIPp+q07mhYan0WLHxIX4m9gz8lXrmQ3yf1dngSg5eIq4QIJ/+8Y9/dGErwoEuHN2K
Oz5VfVKW/+elzeHFfSQoVHZl4JcxAJEz8BsTBVOsxGkc9em3v/3tHJKTM2PGDK98KpnJLe9eqsZ7
uPl9I8QuKioqZGSdysAfzqrGDPwykImJgokTOOpTqKSDdHTk5uZ64lNpQKRv1NS2SMPCoUckCZAM
/HI2OHIGfrnQRvXDcvQdsRf61AXc96lx6JHlf3UOPSLJhykDf7hEwaqnQ93lgRn4iS3Qpy7gsk8r
ww89kruEU6YkuYFMJWJlBn7iJvSpC7jpUzXu0ZT1SHqa8MyeI5I6qBxK6ufADPzEOehTF3DHp+qC
AlNWGbQSaByY9YikMpVdg5EipIYwiZUZ+ElPoU9dwAWfVhruyGxqHCTTOPD6u0aI9yixRs7Ab4xn
1eAlr/ed+B361AWc9mlWVlZlyH3AH9bvWyrTPHNFiBFTBv4IsarxMu2eZuA3RsSOvh3iE+hTF3Da
p6NHj7b8p80fMiGRgVjlt2PMwB9uVHBPM/CbgtyoO3PjjTfa9LaIN9CnLuCoTzMyMkw/f/Wrp0wJ
iRHjHQwjZ+AXJAP/w133jwtdYWXImMCoicjQGt92222dJJjcdNNN9KkLOOfTN99888EHHzT9Zn/4
wx8WFRU51vAQksz0NAP/okWLJGI1ZeBHifGskfTYyjrDbfo2Ha+1QOKEPnUHJ3za2tr64osvGn/d
+PHip4q/2X379nWl4SEkmYk7A79kHgsdaQ/kAvBwuSPo00BDn7qD7T49evToT37yE5NM8SueNm3a
dddd53KzQ0hyU2nIwB85UbBCThpbzpJeWsvbOdGngYY+dQd7fbp///7q6mr187z//vulK6eSvaWE
OIkkCjaKNcKp4AjBrEqpbVo/fRpo6FN3sMunH3300datW40/zBdffPGGG24YNmxY1KGGhBC7iD0D
fwRC/wPTp4GGPnUHW3z69ttvr1y5Uv0Yly5d+uabb57Tr5cBXjUshKQyxgz8lV1D62OXqSlNBH0a
aOhTd0jcp7t37zaOFayrq/vwww9lVtT7iRNCnEZkKqeCH+663WpUlIhlJfRpoKFP3SERn548efKv
//qv1Q8QVt21a5exAn1KiH+IMBIpMhp9GnDoU3eI26eHDx9+7LHH1C9u+fLlb731lqkOfUqIf4ij
I7Wya/wSfRpo6FN3iMOnra2t27dvN57j3bRp00cffRRakz4lxCdUxjUwSSm1oKCAPg0u9Kk79NSn
x48fN+borq6ufu2118IdfPqUEJ9gyonUU5/iV0+fBhf61B165NN/+Id/+NGPfqR+ZatWrXr33Xcj
HHz6lBCfIEOS4vOpcPvtt3utBRIn9Kk7xOjTjz76aNu2bcYfV319/ZkzZyIffPqUEJ+wYMGCOXPm
LEoA+jS40KfuEItP33777R//+MfKpDU1NYcOHYrl4NOnhPgEleehKi4GDx7M873BhT51h6g+3bNn
z+LFi5VM16xZ8/7778d48OlTQpIDju8NNPSpO0Tw6alTpzZs2KBMiv+oO3fubG1tjf3g06eEJAf0
aaChT90hnE9Hjhxpury0ubm5pwefPiXEV6i7tlX28BYV9GmgoU/dIdSnV65cOXDggHEo4LPPPotY
NY6DT58S4ivUJahqItwNT03Qp4GGPnUHk08vXbpkPMe7ePHiv//7v4/74NOnhPgKY0qHqqqqefPm
ycSiRYtqa2sjLEifBhrf+vR5A3v37j1z5oy9gnMZo09Pnjy5dOlS9XP78Y9//M477yRy8OlTQnxF
6FWlMnz3qaeekvPAxnvKGKFPA41vfYqvVkZGxiCdPn364OWSJUvsdZybiE8vX768e/du469s8uTJ
US8vpU8JCRbhcjWoe7SpABaSNS7orU/b2toQvGzcuPGJJ56oq6trbGy8cOGCVzsTDuwk2szz5897
vSMW+NmniEzVy02bNqHk8OHDNvnNbeDTzz77bO3ateqXhRAVgWpP7ydOnxLif8L51MSiRYuMetW8
8+mJEyfKy8vT0tJMbwQlKIe/3N+lcMD12LEJEyZ4vSMWBMWnUvLzn/8cEwcOHHj55Zd37Ngxf/78
5uZmlODLsHz58gceeODZZ5/FHyqU4F+WWhz/Zx5//PF33nlHXmLxrVu3YuKtt95CzPvggw+qpQQs
K99wbEVKMBdrOHbsGArhxIsXL/b07YwfPx7bUr+jDRs2fPHFF1d7eD/xCD6dNGlSjD9hQogPEaXm
5eW579P6+vr09HQR6JgxYxYuXAhnIXAuKSmRQrQwTU1NLu9VOOjTONBC4lN8ptgQpqE2fOsGDBgw
evTonTt37tmzB3+iZs2ahfK77747Pz8f1WBevDURH/yItSEelFVBPZDv/v37+/Tp88gjj2CpkSNH
FhYWSmVYDwviGfUzMjLkJPOpU6ewBrxHbBGL9/S9fPjhh17/WAkhfkdGLrnsUzSPEpaOGzeupaXF
NPfIkSNDhw7F3Ozs7Pb2djd3LBz0aXw+NfWfSlApPkWJuBXg66e6VuFEmBFxK2JSfEkOHTqEQkgT
K4FqO/RYFcsePnwYdZQZsSpEqefPn0cMiw3JUkBeIowVnybSgTt79myvf6yEkAAwduxY19p/NJiZ
mZkiUzRTlnVaW1uhCdSpq6tzbcciQJ/GAY4YHKeG+EJ/8CNCUfEp4kSpduzYMdRU53LBqlWrEL1i
YuLEiaiJCUSszzzzDKpduHDh5Zdfhn9RiMAWJajz7LPPnjhxQpZFNUTBxqHFOD5r164VnyKkjdun
ZWVlXv9MCSH+5eGHH0Z8OmfOHDfj040bN6JlS09Pj9xDWlNTg2rl5eWm8g797N+yZcuw23jGdDgp
I5Cpr6+vrq5GzTVr1jQ3N4fbFmbBmKiGZ4mX8Xzw4EGsQSqE8yn+GzQ0NGBXZdkIm3AOP/vU1H86
depUiTFhyfHjx0vhgQMHUBO+U9UQxmJnMAFRQrv4niAgbW9vRyFkCkdDzVITdp4+fbr89cIKEZ9K
5Du+O9gN8Sm2Fd97AUOGDPnCCrj+eMJkZWUlcj8LQojtxK7Ryq4hSQ899NDQoUPd9OmYMWPQss2Y
MSNyNbSNocKFsBC5mMYvoSRUZDCpNLNGSktLTWN00UpPmTLFVA2ahjoxAaVKNUuf7tu3TwJtI4hi
XB4GHCCfQoWwT0d3n2LTJtMtWbJk5MiRmMAXACEtQk6p/MADDzzyyCMDBgyQMPOUTod+ihglCEsR
h27atEn1ugqHDx9GVJu4T3t6P/EegZ3H+4rvfhaEENuJUaPQrspMKFekujm+F/4S72zbtq2nyx45
cgTNjoxf2rVrF2SHZxm/hHJjPyxWLluBtRHAouaWLVuys7NRgj8PKuoEIlO0wHV1daiGymJS6d6N
4FPMkjpYA5aC0Ldv3y7dvkVFRWjPEzhIPcPPPpUTrcKOHTvwMUGIHd19CmSMEL4bYsmMjIxVq1bJ
LIgVL2trazEtawCiy1mzZo0dO1am8ZniOCCexRtBfCr1AeJZ6U71v095vQwh/iGyRqHOefPmyXSV
d9efwnqy0TjG7oo6EQB2GE7wYhpRJ8oxV0oQjIh2IUHj4ggbRanV1dVSImca09PTjS7GClXEGs6n
qCNh8sKFC42bgBFEqW52+/rZp0bw9+O+++6D+DpCfHrs2DHErfgSohA2hChVgLl8+XKt66rVc3ok
i7ky68SJE/LVxVII7vAsK9+5cye+AIWFhdA01iY9sPQpISR2Qk36kI5oFKDxt8zo66ZPYSjZaOi5
XEjtCSsknHzvvfdkQbSipgVRIrNQBy8Rimr62OCOkH5VmYV4R2bNnj0bL3FMTNWk7dXC+1SJ2Bjq
CvX19Zp+Cjq+4xMHvvXpqe6I7AT85znXNbhXgEARRSICVSOLBCyFZZVe8bUxXmeKPzD4LH7+85/L
RazGpfbs2QOxqiSHWAPWIyFwfNCnhKQOoaOMxKfhNKrwxKehl8mIiUIR88opXLT5lquVaHHjxo2Y
ljcLV4ZWQ4gq6xTzYm2Y3rVrV7gVhvOpvCwqKjoTgqhW00eixnmMeohvfZpk0KeEpA5KptIxCqDU
WBZ006etra2y0cbGRtMsU3xaXV0tNcWnka9YkU5POcFrnA5F1imiNE5brjCcT2M5sK7ld6JP3YE+
JSR1MMq0Rwu6nG9QxsSqTsxwwEeye771KWLYOeFhfJpk0KeEkKi47NOFCxdio7Bq5EGwJp/KVavD
hw+3rIxyret874wZM7SQkUJCW1ubrFPONsv53u3bt4fWjHy+V2LnKVOm9OBtOwZ96g70KSEkKi77
9NSpU3KlSehAIFM12T3xaXNzs7wMvbpT9YqK/tasWaOFGRHU0NCg6eOIROUyHim0pzXqeCTp6pUL
N0zLnjhxoqamBmZ37ZIZ+tQd6FNCSFTcv7/MihUrZNNwWegQWdDY2CgXnmiGjkiJGefMmWOqLGdf
EfB26KN2JQkASmA9Y7X29vaioiLNkHNJBkehsvHinY4YrpfBPsslOXgjpp2ZNm2apg9Viu/IxAF9
6g70KSEkKp7cr00N6UFLAqtu2bKlXgfBncqABNOtXr26o+uyF0hWyrGsXDWDQFKtxzjAadmyZbI4
YlWJZxHeSl4mbM44UkgGAyNixSJYA3ZDnBs1n0NdXZ1st6qqSlaInZGAV9Ovc3T8CHZBn7oDfUoI
iYpX9z/dvn27JFiwBIGeXNViZNu2beoubwq0RaZsS2j9TDkrBCjDlJkQNU0XE2H9sKp0rUbON4jg
NPTmrbK4A0crLPSpO9CnhJCoeOXTTl1nCOWqq6vLysom6MyYMWP9+vURLjZBvAm7TZkyBZXxjAA2
XL7clpYWRLulpaWoWV5eDueG69NEaAkJYrWoI2uT3L/Kp5jAXNMJZFkQVpWdxzOmURLPgUgA+tQd
6FNCSFQ89Km3SMLe0AtbVJJhlzPbxwd96g70KSEkKinrU8S2mp4Q2FQuI4TD5WLyG/SpO9CnhJCo
pKxPW1papAO0qqoK02fOnMHzsmXLpNDyulQfQp+6Q9w+ff/993fv3k2fEpIKpKxPO/UM+aEDnFDi
5g1iEoQ+dYee+lQ0+vTTT0siUPqUkFQglX3aqQ9wWr9+vcoTiOlAdJsq6FN3iNGnJo0q6FNCUoEU
92nQoU/dIbJPw2mUPiUkpaBPAw196g6WPr106dL48eMjaJQ+JSSloE8DDX3qDkafQqP/9E//tGHD
hqgajd2nkyZNin1thBB/MnHiRPo0uNCn7gCfxqFRQkiqUVpa6rUWSJzQpy7w7//+7/fee6/XP1NC
SADwv0/b29vPnDnT0ZUb3x1aW1tduy143NCn7oD49JNPPtmzZ8/KlSu9/r0SQvyLz32K1qykpGT4
8OEdXT6tqalB+z9jxoyoyzY3Nw/SiWO7FRUVsFWEZMJ+gD51B2P/aRxiPR6RrKysRYSQpMDnufUk
MeC+fftUidymzXTDF0vkJqcgju2eP38etvL5nw361B0sx/dCrGVlZY899lhUn0Y++Ndff/2AAQOq
CCEBZ/DgwX4ej4TwMD093aROd3za2XWntoaGhvgWdwH61B0iX3/a3NxcX18fQaxRfcrrZQhJAnx+
vYyo03SHbtd82tbWhrYuLy+vw92u29ihT90hxvxI4cRKnxKSCvjZpwhO09LSoDNTeQSfXrx4EW0a
NCr9npF92t7e3tTUhDoRcgzKDcd9mx6fPnWHnubvNYmVPiUkFfCzT5ctW4Y9XLFihanc0qdo9J54
4gk0TeqtlZeX79q1S6ZNy6KtW716tTEZfllZmeXQI4TGmDtmzBgn3mDi0KfuEPf9ZUSs9CkhqYCf
fZqdnY09RItkKrf06ezZs1GIeBYahVinTJmCl9CNvE3TssOHD8dzUVHR+vXrURk2wcvMzMzW1lbT
thDwinb9OdCXPnUH3v+UEBIV3/r0xIkTmu5HGM00K9SnjY2NUvngwYOqcO/evXIzUy3Ep6CioqKj
q1e0vb29pKRE00Pa0D0ZN24cZm3ZssXOt2cT9Kk70KeEkKj41qfbt2/X9EAydFaoT0tLSzX9zuCm
mtXV1fI2TcsiFDVpuqWlRdONHBqiLly4ELPwnOhbcgCnfQpf5JLc3LFjx9KnhJDI+Nancq1KWVlZ
6KxQn8opWdMw4E49n4O8TdOyoeYFctY39OoYuQA2luHE7uO0T0lk6FNCiMK3PhXx4TncLCW4M2fO
yHsJ7eJsa2uTWaZlLU/eYoWYBY+byuvr61EeOszYD9Cn3kKfEkIUye1TILNMy0KRoTUj+9SfWaTo
U2+hTwkhCt/6VHotY/Hp+fPn5b2cOnXKVLO9vV1mmZa1jE9l3FFdXZ2pXHw6dOjQhN6PM9Cn3kKf
EkIUvvVphF7L0P5TuS5m165dppqx9592dHTISoyJggXpyfVnIl/61FvoU0KIwrc+lVQMlmdZQ30q
JaGDl+BNeZummpmZmQhdjTUbGho0/XrVcJfnVFdXJ/qWHIA+9Rb6lBCi8K1P1VnctrY206xQn544
cUKG+MJ6HV1XlW7btk29TdOymn6pqVJqU1OTBKcIikP3pKioSPNrVnz61FvoU0KIwrc+7ewSWWNj
o6ncMj8S4lnJ3pCdnV1aWjp06FBNP0krb9O0LOJTTY9GUUEyOWi6YTtC8t5fuHBB069L9ee9xelT
b6FPCSEKP/u0rq5O0xMZmcrXrFkDmYaegEWYCT+KVdFG1dTUIAKdoKPqqGHD8K84V9OvhdmyZUuo
TDu70kpY5k3yA/Spt9CnhBCFn33a1taWnp5u2acZAVSOkGvXdBkOos7Q88lGysrKUN+YxtBX2OXT
rKysgaTnFBcX06eEEMHPPu3sShi4bds2u1YY4bLWUE6dOoXKJSUldm3dduzyKfEQ+pSQ5MDnPkX8
CGUUFRXZtcIe+VSGB/s2OO2kT5MC+pSQ5MDnPgVbtmzR7Lujd+w+RXCalpY2e/ZsW7brEPRpEkCf
EpIc+N+nnXon5qBBg3rUixoOGcuE56g1p02blp2dHbl31XPo0ySAPiUkOQiET0k46NMkgD4lJDmg
TwMNfZoE0KeEJAf0aaBx2acffvjhCy+8sG7duueffx7Tqnz//v3Nzc2YOHToEKZt3OLp06dfMvD6
668bt9tTDunYuHu2QJ8SkhzQp4HGTZ8++eSTN954Y79+/UaNGnWjDqwqs771rW8tWbIEE/fddx+m
41g5vFlRUfHKK6+YytUdDRR9+vSZO3fu2bNn49jKfTpxLOgo9CkhyQF9Gmhc8ylket111yEylZfQ
GaSGEgSM5ww+jTs+FW8iAo1cfvToUewD7DNz5sw4tuLb+PSGG27wuiUghCQKfRpo4NNbb73V6Qb/
ww8/RDS6ePFiYyGUWlhYuHr16nMGnyLA3LFjh6qDaZTDxS0tLVLS1NSEwuPHjz/99NNLly5VAenK
lSvxbaysrDTp2NKzkohSzjADrBybwNoaGhqkZM+ePcbdwK7CwkeOHHlFRxW+8MIL2D3sCfZHVUYF
rAr7g12N+4j1CHyIOLweNwSEkIShTwMNmuLc3FynG3x4B18VCUUtCT3fC1uVlpb2798fJRMmTEBE
KSKD1/Lz87OzsydPnoxyrFZiXrzU9HscqHPIgqVP4XdNvxmQ7BtWjgWxIWxu6tSpKNy8eXOfPn1U
Tyvq4CWkqc73Ytadd96J3cDL4uJiLAjboryiogJqu/fee7/3ve9hka1bt9p5HK3Antx8881yeyNC
SKChTwMN2uGcnJz4OhNjB8rDVyVChVCfQnYQkwpLEXhiP9WqIDgpR3147VzM53sVUCG2ePr0aahQ
Nn1OD1ThVsgU5dj6c889J+WQLBR5ztB/igg0KytLhCuBNvYQIa06gw0Qt2IliQx/igW5V+A3v/lN
b9sBQkji0KeBBk0xwj115tMh4vApglNMqHG5coYW7jCtCkvBjOd67lPYEMvu2bMHc+FNtSEEm9K1
Onfu3HvuueecHgAi0pRTwcqn2DeEomptIk0skpeXp1YlUbnxvLETYEO9e/eWu/cSQgINfRpo4NMR
I0aEDou1F8hIszrfqy6TCfUpniHKb3UH9W3xqZzvRfy4detWTJi2IqJ89dVXEWweOXIEKod8ZUHl
UwlvTduSM8amtTnt02eeeQZvoVevXt61AYQQe6BPAw18WlBQsHnzZkfbfDl9GioghMbf+973zln5
dMKECXKKVa3h6NGj50JC3fh8qsYjSXxqDM9bWlrU2e/CwsInn3xS7du58PEp/jDAm4hPR40apQqx
HulUdRS5gxIhJAmgTwMNfHr99df/4Ac/cLrZX758eZ8+fVS/J1wDHyEAhNHOhe8/VRenLF68WPoi
w/kU5kK5GqCrMPkUXkZMqq6Xkf7Tv/qrv5K5kCm2gl2Vl5BpXl6eZhCusf8UCxr7TxcuXCgneNW2
sKt4g06fS7/jjjs8bQAIIbZBnwYa+PSuu+4aPHiw00OSsH5oC1+YnJwcGBMygl4RJ8pcy/G9U6dO
hd3wfM8990BMMlY2nE/P6V2ioVFwaD4HrAoyVcOEEFdCr8XFxQiH5WwtJCuzEBFjJ435JYzje+Vd
4GW+joTPsCoWmTx5cmlpKTYEIztyNLvARjMyMrAbHvzyCSF2Q58GGvgUIdiIESNCz5Q6gQwogvI2
b94sAhLC5Rt85ZVXoCRo13itqHFX5ZytTCNExcpfffVV4xZN+QaxQuO1omqd2J+VK1civDX9r8Da
jAGmMZ8DasLF2D2IXilY3guC66effjrC9UF28dOf/hS/weuvv97rZoAQYgP0aaARn+J57ty5Tjf+
xHbuvvturxsAQoht9O/fnz4NLiq1Tk5OjtNXShJ7QTx+8803Dxw40Os2gBBiD3379u3Tp8/XSWDB
hzh48ODCwsJHH33Ua0WQHvD9738fnx0zORCSNPTu3Rs+TSeBBR/isGHD8Jybm6vyERGfs3///ltu
uSU/P9/rBoAQQkg3JESdNWuW16IgMSE9p/369fP6i0MIIaQbBQUFY8eOzcvLU8NliW/ZunUrgtPc
3FyvvzWEEEIsQPt88803I1DlWV8/8/rrr0Om+LwyMjK8/soQQgixADLNycmBT4uLiznW15/gr87t
t9+u8UwvIYT4G4SoI0eOLCoqktuAEl9x9uzZESNGpKWlSXxKCCHEz8Cn3/nOd6DUKVOmMEr1D0eP
HsWHctNNNw0aNAhK9fprQgghJDpQ6j333IPWu7i4mH2pfuDQoUO5ubnp6el4hlK9/oIQQgiJlZE6
gwcPzsnJ4Yhfb3nhhRcGDBiADyUzM7NPnz5efzUIIYT0DIRCgwYNkhG/s2bNYqDqPk1NTZMmTbrt
tts0DkAihJAgIyN+v/3tbxcWFkKvjz76KHtU3eHo0aMPPPBAVlbW17/+9eHDh2PC6+8CIYSQRCko
KJDbasOqiFjnzp370ksvOX2/1NTk9OnTO3bsuPfeexGT3nTTTcXFxf3795eckIQQQpKDYcOGDR48
GBNo50eMGIFwddq0aZs3b37llVeam5up1/iAQHH08P9k3bp13/3udwcOHJiTk4ODjCM8YMAADj0i
hJBk5cYbb0SsKjkfND10hWeHDh0KC8Cwt956680kNkSdt99+e35+Po5hdna2HE8cw8zMTK8/Z0II
IT3m/wPaUDS5ZW5kc3RyZWFtCmVuZG9iagozMSAwIG9iago8PCAvQml0c1BlckNvbXBvbmVudCA4
IC9Db2xvclNwYWNlIC9EZXZpY2VHcmF5IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9IZWlnaHQgMjg3
IC9TdWJ0eXBlIC9JbWFnZSAvVHlwZSAvWE9iamVjdCAvV2lkdGggNjI0IC9MZW5ndGggNjQwNiA+
PgpzdHJlYW0KeJztnV+I+8h9wOdBD37Qgx8M8YMhhprGUENNa+hC3dRkC1vYA0OXsKEudcAPS9gH
E5bGBRMMMWVpl2DKPmypHwxxigumOI0LS3EP32HCkvqouW6Lc+dclJzv4vzOuXNS3UW50wV1RpL/
e3+/sT1aSbPfD/zWXlkrjWc+v680+kozCK3h/ctvfKszeDaxnmfSD1/9h78IrxcBYID0CC24La+s
FjLwd2/+UntUPvnZu99JemxoD95RH7cdqZgsF/Gln3xkSzHe+dHfBuxpFI5xvG+/f/+xbQX56f2V
166G4RSH+ya+rNhalP79iX1twyPO9u23ntldlg87ZTiNY4ijfTt+5F7CRv7jFTimssPJvv2VvcfS
Ka++BsIxw8G+/ZkzdNO0V16BQyornOvb5/7P7nLM+Leyza3ED471TXzP7mIs8DL0UhnhWN+6dpdi
kQ//F07h2OBU3/7k13aXYonvX9ndUJzgVN9+ZHchVngdUltMcKhvX3ZauX4AAY4JTmtXAvbN9rzC
Gj+AayIscKZvf/CJ3WVYo5e0u6m4wJm+fdvuIqzzcc3upuICZ/r2M7uLsIG37G4qLnCkb6Ff2V2E
DbwBt5gzwJG+/Y3dJdjEu6d2txUPONK3f7a7BJv4uGh3W/GAI33r2F2CjXzH7rbiAUf6Jtldgo30
7G4rHnCkb07snoJvTHCkb+/bXYKNvGt3W/GAI32T7S7BRsZ2txUPgG/UgG8MAN+oAd8YAL5RA74x
AHyjBnxjAPhGDfjGAPCNGvCNAeAbNeAbA8A3asA3BoBv1IBvDADfqAHfGAC+UQO+MQB8owZ8YwD4
Rg34xgDwjRrwjQHgGzXgGwPAN2rANwaAb9SAbwwA36gB3xgAvlEDvjEAfKMGfGMA+EYN+MYA8I0a
8I0B4Bs14BsDwDdqwDcGgG/UgG8MAN+oAd8YAL5RA74xAHyjBnxjAPhGDfjGAPCNGvCNAeAbNeAb
A8A3asA3BoBv1IBvDADfqAHfGAC+UQO+MQB8owZ8YwD4Rg34xgDwjRrwjQHgGzXgGwPAN2rANwaA
b9SAbwwA36gB3xgAvlEDvjEAfKMGfGMA+EYN+MYA8I0a8I0B4Bs14BsDwDdqwDcGgG/UgG8MAN+o
Ad8YAL5RA74xAHyjBnxjAPhGDfjGAPCNmg8DdjcWB4BvW9A589ndXm4HfNsKtZUB5fYBfKPGrCql
kRJ3qWnfRNmBMWd6g2/UjMPFgfFOaZx4tq7p29322rCg0W0EfKOG9E+jRcn4Ra4mt1PuM5/sttdP
+Qpw4Bs15vWQeGlo/C6XDwX6it4xvPEW4MA3aubX3+I3Y3NR+ZCynncNb7wFOPCNmsXrvcJh2VRu
WIrT1PO/777ff7Wo6W0BfKNmJb/gSVbNcg6voi+q5s/uHN5wgPuMVY1vA+AbNev5LE+yrhifDYrP
V+6VfXZ8a1Xj28BHu1wUspgfusU3jJhqmMrd50MP1vI+4Y2zAOdEXOQbRsy0zKNEL/9AinWv8MZX
gHMi7vIN48u0zJU62Q3Kfe7X++1Z/ax1dQ240DdMINsx1+uspVi/v++u29bVNeBO3zCBi56xptrK
eBeW/87H++76UwhwVuJS3zChvKncYlZ/7/AGAc5a3OsbJjLP6hsp1v3DG5zBWYurfUMkqz9NsZKs
/ussdv49C6v7yeN239BCVn/SZHJJXf1tqyob4ME3THyaYmXCnSU1DRD48E3P6k9Y7R0CnHXw4hvG
8zar3UOAswyOfPtTBp1TA/X3WFczYMKRb2+x23+PdTUDJvz49hKz8AYBzjr48Y1heIMAZxnc+MYy
vGnaJxDgrIEb337CtgR99lUNIH58+/M973tb5ZM/sqCyAW58G7IuAgQ4S+DEN9bhDQKcRXDim8S+
DBDgrIAP376isC/Dxy9ZUuFPHC58E961ohBvWVPjTxsufLMivK0GuGg+9/BDrwAtPPhmTXjTtB8v
7COp3lbkDNOqf5Lw4NtXfmVNKT794nwfp3mEjhXvw4UAqODAN8/IqmL8dHlHYS3GsuqfJBz49tcW
hTdNU78834sQC9eH2w/tCizjft+sC29LAe5A0ppRhMoJ49dbOJfbCff7Zl14mwc4MpirUGkj5Buk
jCV0Qx8Cq7jftx9bWZA3jX00SvhHRIvMdhrcYjhhYAH3+3ZjZUEujX1ct/CPE20+HtPdJQqAcjvg
ft+8LB89XeEXplMRJRs8HDVn+wxpcdQppU7J9RHx4oVDvAIz3O+blQHucrqPeEdTKvO5bvJDFNCk
Sm8cQyglQ6+VHg58sy7AySuHTKF3arzpXaLsxI9Qp4nK/TqrtngKcOCbhQFuZQR+XzWhv0a1KOqS
LkS9iY61SYlVYzwBePDNyjM4TdowHHpxoJ/BIWGcQZmx6BdzzWs4iaOCB9+sCnBvzEbgDy/vr18k
Z3Akie9DrTIS7wfZywlcAKaBC9+sCXC/EMRUYzYc+uLNSD4vui/i12oLdxsOUUHBp3InEw+6OGDZ
NFzChW/WBDi9c+qbj8C/NBx6ACvmkTMoOxLQUMEH3aAW9shttcvVFFzs4cM3KwLcz6edU9/ZbDj0
5RH4w3ciuq0in3aYKI+Hmj+pFY5KwlEh62fTNjzCh29WBLivL2x+NgL/2iTn18q5qCbJ+HNXqE6G
mr5Sag05uWer8AsnvrEPcD9fufYWzM9G4E8vTnJ+lEA1fBCNlbyikkIogc/n0DkuvycIN2dugBPf
2Ae4r6/vI5TvG58tjsCPEWuKpDaElIIX1kmmNdQPZCaKWhHXt/HU4cU31gFuNbyZRGcj8NcWJzn3
JyIINav43ehcX3CknSF/u4Zd3KVROIYX31gHuA3hzSQ6m+S8erwkZeUY/xin9fedEdYxqnnRIJvW
1/JumuzrCcKNb2wD3APhzWQ2Av+4fLiyYqXlQfFuWKv05GpWC0a1UaXXwUEuO9z+K/EIN76xDXAP
hzeD+STn4+vlFGtn2FZKQS1EzvbGqCj5kXCfRzf96x2+Eofw4xvLAPf88GYgHFamk5wvZfXj6RgS
Jvg0TvAG0JBkuS5b6FxTLnb4TvzBj28sA9yLwpuJJ1k16291kvOMXEw2h964Ri6K1BsoL4lwEZjA
kW/sAhxNeDPxnDZmWf3FFOtB9b4RQyWNlEvOol7RLOPp6dMeFYIf37znzAIcZXgzEVPNjVl9fEQd
yri7ejP2khvmCL6B1FRun3Kk48a3A0n7KqMAt0V4M5ln9buL1z0OtcPRXX8SR0VzMDlPRkS+7i0u
7fZfkA848U3I4faWv81m79uFNxPf+TyrPw1g5Q45gHr1+8919OvCVz00jXcoUXpil4T58C3Qwn+k
ZNmcwW0f3qalWM3q98/MT27Hegb/WBmN5e74ktwgjH/LI9Qp43+FHffnRrjw7Yh41o8y6qLuFN5M
QvOsfkpEwjTl5cnoI9208JHUn8GxbYBVQ81qoKelUEBL7LFDt8GBb0KJ/EmZHJZYBLidw5tJKD+b
5Dy1cqhstPC2awMU13C/wqcm0fVkfJB/UpkH9/sWIhFFNh/UYxDg9glvJvOsfnUxq4/C/fvKnVYk
Z3DkEp0HdUuC0GuVLp/Owzau9y1NvkE3aP62f4DbN7yZxOZZ/aOFLcaSIe0ItStIP3UjD3mFtO55
VT1mslMX4HLfxCpZ/XLeonsHOAbhzSReMkcKW87qB3yoND4QzrVDlMfdhsJIJAdadNY4fQrP6bvb
txg5bo0OF5bsG+AYhTeDhaz+UopVLMny3VjQsw4DknmoN0jnVp4dffm9NdjVvl2Qi6y3yw8U7Bng
2IU3A+GwOsvqL13kPSkgPz606lfiPLJ+11zwTjOS+lcdxqVwDi72zX+L11RXb7vwPttnx0zDm8mD
WX1Pfxy5JF2HU3InOkr0Rrp2QnycZV8Kh+Be3w7J2dFgfQTnv/90jx2zDm8mntQsq19YSLF6jsUu
uRLXaODgVlOvjMNocKCVuU2xutU34ZKsV92QC/LuMZ6vFeHNREzdbsrqk0vConIqFpXb2aAR5bti
AIUP9HO5UI8v9VzqW7CL1zLOetbYI8BZFN5M5ln9u+Vn9Suerno++5U8tu/vqEOZnCrwdjXYnb6d
kmL3HriTbPcAZ2F4M/Fl51n9xX7OSUPp5UwHk4oPNfshFJukEOpdWV2kx8WNvollsk7pQTl2DnDW
hjeTQPbO2Nvys/rkeGsk7qsNFCFPTaOru/mNJLzgQt+i5Knj8dHDK+wa4KwPbybzrP7tYorVFyQ/
PXIKXYzIu8KA3EjiLdxydLec+3zLkp5e67ln0TsGuEcJbyahwkNZ/YCW9xT0C3CtGhpcFyZ3Sfxf
KMHJbehu883XxB+ruedHIq803IHXH3mA+1lWX17O6uek8LGCz+UOtOMDTdXInQhnymjS5qKj6jLf
EiQLLnFzfDmYZ/WXH5yuD7L5SQ2VBtEJ7oTHtQzylO8QB3M+uMo3oUiuJ9S4yi7GS9MU61JW/7TW
PBfQMI8aFYRu5WwA+bUQ6hXP0+7+9m7yLUiuJchnGz9zMfOs/mhlVq64FkDZERLUm4bcymnRkDYw
5nxwLy7yLTnBn/Qimz5yO8LRPKu/oJNwQMbeD/u0BPJmWhNPfuRDwp2r53twjW8e/caPa27vEXsw
q19No/4Vdi/oQX3ymFcDfGPOum+Re7KY73FKxXlWf/nB6bhcxuHNv3jvkltxiW9npCE6/A+hJqZa
m7L6wWKrGjGeIjTuXXItrvDN28DL1ILrLwZQMc/qrwyHbjxFSO5dcjFu8C0u4UXDJzShsn+e1T9f
SLEGfOTepZR95WKA830T8uS/e8Pdl522JpDtGlWxMgJ/pOPuHpPjfQu08e/K+cPfgFvmWf3m6oPT
7sXpvh2TS6H3nN2UQ02oOM/quzuuTXG2bx59qIYbbv5378BDWX2X4mjfwuSAMjmxt4bsJ/5QVt+F
ONm3DCncXdDeCnIG8euNWX334VzfxBp+o166unYZMs/qr0xy7i4c61tMwq/Dwxd/g6eDcDzP6ru1
B+VU33IbhmoASFZ/Nhz6qnJnK0MN3EnOo+5M394n46Oq/I5qsA/zrH5/Oavf1UpLK6q2NuFmJs70
7Tf438CthwzrWczqB6cLY/jX2uLZLvi2DWTy0ODOt948dKUKL09u2Kgwb6egO0ZvXs/q6/cH3i5c
qgTf6NHHR/V22zu2xkF38/LYHUKV9Y16Z+Njkgmad9znoxOYZ/XPfEg0WrIzf4oLfKNGJScmBwN1
V9/S0sPLN/gW1IKz9+7xDRHlZsOhf8usuv7sHibwjRr9eq9yWSVqxCtGLzV3VK6H0GmjlcfHDCF7
W4tWwuiKXIrCr+i43ip6sTlX7foJindk84+Oq+06DpUZMk1fLhnGy8OV9kmzmcJ/paMPSlTX6knk
K7bqx4Zv4UoSCWfNZlZAvkqk1L528I2es6z+lNF0nCXwjRrdN78Rik4ko7Xbw9atrzi5yNx1Pag8
SmUGWgJJ5GQMv17IuXSrLwpSNZ1XT6ONSUG/fymNF19rR9gtsoFCEC8PVuS7s5KWRAVMf6Jvu6SV
Er5RO5OX88Q3//BGQDXp/GxQw6FvcHk2uH90jbYhPE2xGkzMy8HgGzVm/nTp0Ncmz/uqSdw7G2cC
ZDyX5Nw3UcGvgpQNajGETo9mx9MiuaTSLUx9M46nY9xpaN+Qj0+UhL4aOZ5eDnCfIaX6Epq/XyIP
t4fJ8oMgGeL0UHNwgNOJvrZQe7LxmAf4Rs1G366wIFoRRyXp5pScZAlz3+JaiUSrunAv1zOBhfM3
79H5zWTFN7JRfUF8+ugJ8a1NLl6J2lFC68s4NuZkEv8muSCZ/WXx/M6ZiEvtqOrfC3yjZqNvBeyR
pp90ZdL6Sb3pG/YuYSzPITFzK6vnM9/OlPvaRe8B38Ijc1JSwzf9Ooh2ktCu+zWECrK+xaRLfDtb
qUCSagDfqHnIt4R+YEuGDsirz/QtrCWi5DiKjiN+3DfwXE+mvgkKecKkj32rG6+LvvmJVgbEp0YT
kYeLY/j87UA70Wd/wYfmgEt8667WYAl824JF30Jp4xom8U0YNER0rB2j+4ZHuMEqdJuCp0xeO16U
UNMR3A9AlS5Kj/WRXTxKjsTEEiqOAvi1gE7VoMf0Tex0AsFgUO9W+LVT77F6jMRmX++fXo99vsm1
gLJq1B2+xdarsCaAb9Qs+pY2G1s/4IV78pAErXB/Mm5hFY4mk8mllEDBriKpl2RwuOF4cIDCE00f
jzCr9qR6/Rb57tVxp1FAgbF2YvqWMPZkZBPutGt0oQzlblj3TZTqKC5NRpM0codvmyaduAXfqHnO
eIOhAyPcRYK6Cp4D8x6S4IEeqsSYPsCIGDQyVN64+XHEuCrlCW7OdJE4J8aCS8siUdfcv00i9Rrg
GzVU830En9TEodsDvlEDvjEAfKNm6/nrgXXAN2rANwaAb9SAb9tytn7rPfhGDfi2LZq6Nl8v+EYN
+LYtpNbkyiHcT74T4Nu2mBW3+KAg+EYN+LYt87rrTx+hAd+oAd+2Zan6OnrvAXwDHgvSewDfgEdE
3mdedasA3zillwtAfKPmg033OwDPYan6hpdROH/bBugvbMu87iblhLEIfKMGfNsWs+KUxnzQVfCN
GvBtW/Rqa2cWZw0A36gB37ZF7yEsLwLfqAHftuVyffQy8I0a8I0B4Bs14BsDwDdqwDcGgG/UgG8M
AN+oAd8YAL5RA74xAHyjBnxjAPhGDfjGAPCNGvCNAeAbNeAbA8A3asA3BoBv1IBvDADfqAHfGAC+
UQO+MQB8owZ8YwD4Rg34xgDwDXhMfmN3ATYAvvEL+AY8JuAbNfC8MwPg/I0a6C8wAHyjBnxjAPhG
DfjGAPCNGvCNAeAbNeAbA8A3anbz7aA9Gd6Iy8tOOvOPJYSkA+qteZII1a7Wl59u3LgDAd+o2cm3
kHwVivcbywtnM4sjfabJSph6c/k2Qu3K2uK4tnHjDgR8o2Yn3/ID/COpLQwRJAZFXQkhSIZySWjL
63uNyXbxWuYCf8i/8HHB8C3oX/4rYytikIzIPPPN2AHZZsg5c1iCb9Ts5JsvhH+cYN8kYxJddK4M
JzWsRHI0npgz6WqJs7GHTC0YE65VSbkRUKU10jJkbTKVr3brMeb1ldJpXIxguzOY4GXm6JHEKfI2
jQrKUK2Lum+lURgd4x30yA4uVWWSZKTL3oBv1OzcXxB7dYSyCf19XD1CkbGEQuo58lT6pm9eBQuR
76H8KIKCUh5VtExMn3uqUxdQTDuZ+mbEN+UIRdUU+dgvXetbJVs5lxMo0K8T34huIeUCCeW+kNAa
oqfumGMs+EbNrr6Jnf788Hfdwj/yErq8R3pEM3xDVWzkIIuwagjlBqjSM1c/wOHLO0ov+4bXRV2y
QOw2jbmCyFZ6RD0cSdNSScJ/VSAHcr8WT2gRckDfsezMAd+o2dE3f3dBN+Nk/0TCEUwnZfqWULwH
qm86ACnSp7Mn+C5bQ1lZ8Y1sgiwQmj2z40u2Mkkj3eC0NlZwB8TcQTpBprlfPUu0D/CNmt18C49a
i+OJNqr4xyn2ra2nr0XTNyRlrnHYUrP60plvHunuNCoMTd+GK77djKYik60Mz/GbqBZMT/zNnoDK
nekOguDb8+HJN9+ovjg9HroY4p7BjYTOZGxhrBua+lZoj4/x6VoNr1KsznyLajESs7BvN8ZroTP3
LSfPho9MaAJq6EfqsYDP34JyAWVkfAIY7UbAtxfCk283Wq2C8aFOVv/d22+dXMkS8vR7qcyghaa+
BbQR9jKhlk+KuCsw9U2cNA5T/XEO5ZXcWR+fx50pRZ/pW1xrFTC6c2GtHIvKNfy3Gb1/eq5GPfe9
tLGDIPj2fHjyrVipGL5dmZckfKX2TfIKi1ds3eY8KFwxr/cW9OsfkUq7doRQJmf+eazWvomcnSPh
olVP5OJILFXCObJmLhk3thzX17uoJFH4pl07xD1gkn4oZZGYN3eA41x4/RKxTYBv1ED+lAHgGzXg
GwPAN2rANwaAb9SAbwwA36gB3xgAvlEDvjEAfKMGfGMA+EYN+MYA8I0a8I0B4Bs14BsDwDdqwDcG
ONK3D+wuwUbetruteMCRvj2zuwQbec3utuIBR/om2V2CjdTtbisecKRvd3aXYCOXdrcVDzjSt3+x
uwSb+Ojc7rbiAUf69k27S7CJ907sbisecKRvv/tru4uwgXe8L65N4EU40jf0nt1F2MB/2t1UXOBM
375rdxHWUb5qd1NxgTN9+4LzivV2wO6m4gLnNSzxTXBehuG/7W4pPng2ch7/hdDXnDZO/3sJu1sK
sBBhZLdgKzh60Ehgb770id2GLTGK2F0hgLW8abdii3wKuVPeCfzCbskWeEN8cYEBd/P5j+y2bMa7
QbsrA7Ce7Md2e2Yy/mO7qwJ4DG6cIdwHGbsrAngcsk44pD47tLsagMfi87+027ZPfxKyuxKAxyPw
hr3X4X75MvRMnxZf+ql9qa0P/+cP7f76wGMjfO19e24q+PDtL9r93QE7EL7w3WfKI8v2wTv/GLP7
ewP2Eflm/XvS6APZet5/961X/ykPvYQnxP8D9XCOB2VuZHN0cmVhbQplbmRvYmoKMzIgMCBvYmoK
PDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAxMTUzOSA+PgpzdHJlYW0KeJylfV2vLblt
5fv9Ffc5QMqSSOoDCAKM3bGfHTQweQ/GGQTxDOL5/8CsJdU5p4raxX06iWGn+15tqURSJJf4ofwz
4T9/n/E/bZSf//rXH//542g2/3T9/7/vLc+/yD/5n3/+08/1D3/7tx+/+1P6+W//70f6mXPN9WfH
f3Oy+vNv/+vHX35whvkn0kr/+KPXA3PmEvzTUdPXrxMXW/+AxX7/64/f/RFj9ajz/8bPX//yI398
fi5zmtJ+/vrXH/+Q8tB//Pnrv//4p1/f/U71+rtU/jB/d/n7fqSWB0hxHWbNDbNyZJVh+TYsiR9W
j5JtYMB1mPpFbRzaSmr1vmh1w2o9Oj455XhY0yOXLsXN1t2wXo7ShsqdIOqHjXSoJNM3i44G8emg
d0gQfPvRJVUt90XVDxvH6LlZui+a3bDcjyylW48XLdgpNiYSLyrpELPhdqrVD2tH7ZrcTrdhakfK
JY8ckreYHLlKGSMkb6ngwsha9M2wdvQ8TEdMkAYujGyaQiEvzY5RxZIbVtywDnnLWt236T+5YSMf
qqW5b9sIMsZhQ3orIeslQd5Ux7Bwp5Kx01yHWch6yZC32lPr8aIF8paHP4Dq6CaCU9+SOIJkRzdR
yJsWiG9IXoFG0oHB7tvMDYMgSdNkEhPEGrhQ0xs1KDUflqFs7t9W/E4b1GAqZWi8aKsHtFKxWKlK
T0eBHOU3BOn9kNFEeihvUM5HK6ZVQnnTJEdvFaorZL3mcmD7LcUnS3M90hi13Y+MOmbhHB/FUhsS
7lSlHArblmNNrhAkM0ky4i1AkFrCF5ZQehU2q5t5sdx2Co0EuwZ+hTzVqscYODI13mmDGjQcmTfk
be2ANi8jVlza8wGZLM586O/9MJhdNWlvJASmzUbVEZs2g2mrMAzWQrG01EEQyFsJF7Xc4GBA3txZ
cOfUIEgKuysp/jYoLsNsjm6e9QbFVQcsQ0wQU4WEYBFnAYcfhp3CAI7Y+TG6Ug1KOofSa5A3iAeM
TfxtFdqyJ00t3ik0UpVs7+gGjQRFrt6I+y10OQZExOs3v4WBnebUWuyuYKIDzlnzx9ltoSZoS6g3
5zl4Ia+QN1iFXmJ5g5sOHVKHxqe+lnTU0oc/zuaH2WFpWImdnyqCIwNvUENBqvC4GtzZFLO+wuPq
faKP8NsMPMWSbrZ9mB2YEdo3XrTK0UbN3qH1zILHNeDi1zfkhVhixeJcd/GzweMaLXenyb1SrQNK
FcrSaXKvkRoESS1DMsOdNghSha13XvQp5G+BV8vt1da/C9j00wVxfMIZPlqzUzj06Yhm+D1JgCjk
Nswf0VyNZ68vZaRP7MwwVyIy6ogXBTttpJx7vCjY2eBgLK5/zfY/PMQq8NpB//sW8jcZkJce1t/K
gNPbff5dqefv0u1301x22K9Thj1gzOQbAHS6DdvgZ6HUqep9No+2suJ8SbGWb8M2zAvfphlgZbsP
8zIFKahwzf2iG3szdaZmt+gmLLCDFbDRDfOzgb1wbNTRbbtSAD6q8EbsPqx4JAhoPLQ2t4UNuwm5
kOv0Ri7DPNCGKYdZqlOQL8M2+AkuFG0qId0mSoXhKm6Yh5+9HNCbfV7FPEtIgXsGovVSQ55KqsBH
YtXN5pFgyUceXXsNeSqnWEoOdyqihxXQLYdcgINxiEE4Yy4IfGmoFMvyigtvD6S0/kqy8LujVOBy
mIDy8/U//vOfHv7i8o+XK7seKAT7VAjJKwScJqDcVG7DtkOXcTY7SCW3Yduhg6PSa183b8Gi8Hg1
jTZxx9ew7dBBvdgAwrp/m2zXfQojg33b/ds29UKcC1f2PpuXitzoa1m8zQafJ8H9v1Nj06KdLqWm
eWl6GbZd4sFtyyVrvGiBw1AHUMAIOVUSYALWbCncJuD+vCPt/T5sM2uvpWpZzY11+F2aQ75/pbzk
s8vDlUjGrj9vhr+GbcYcbhKcJPDkNmyTqExtb8nGfTbPX7jlUglBbsO8k58BAy335YVehnkxEGhU
6N2Ji4Nvw6H49Ecusw1/KHDEMOX0Dy7D/uiH4VDAFbX7sE3aAQMLRGbe5V6GeSeowgmCqZA35OVV
eQPh3Gx+GI4PBHTGJ67D/IFt4xgJJqvEW+j9AEOtpXjRwaBAqq2Hs/H4SIXz4ORtM/QZ+nCMnELW
A4fjMOaU74tuNre0YwC0O9ZvF8gQJMC2nEoolgUSgqNd0oi/Dd4FtKZMhPDMBV6VwyUbVeLZ4ITI
6Knd5S390Q+zQwF9JMc7rQNWCU5XCc8p0PpRswDxxgTpGdgT7qfFW+iQt1zhh8TfBnwHtZmdDvFa
XRIIgnPTNTynAnmzVlSdhHiXJsF5I0CKuSDQ6qONJu5kbTfqcGmgLN+oQbpbJYF6IySICENa2noK
hZwX71oAzCQ8gLx4t9aSV4N+p8QU+DQd4Tml84Y/xOfFBGmMVTUZ97Pwez8bFJdWMa+Rtvt5SK+Y
lRLTrUN6U9NeQsUlI88YX7LwnAIWAz3BysQKXyFvDTxQRxBnZXjxjr/XGusQhb+Hs2oj3ikv3kWz
WUw3hbxpFsuxhCgMJfBflVhb8n4eY8w5GNuiMJQwWGYt1CEKQ4nzUr2Qe4JADSY4Iyk2lAo1mHpp
Tql65wfkP+DdtqLhyeL9vAB1630L3k/W3rAo3MxY9yrkLRsE5A2z4LWWAugQ615LDJBVK073OgBo
hCGgh1ODflGgNSCCUVOskQxmFxjWvPRu1/iFwZTm3LxtUSC7gUWHxotKpqe6rqODRQFOhc5PrLhg
/Y7KsPibRZXhNhzoN4syKMDouVvUX5VbO3j+3HHervEhvbBFkmN7arDOKk2lx8Ngna13r1S3RWGd
oaCrc8z2a3yBe5yrviHIwFmAL+j8N08QKF24Un288Xshj7xE6sMpLj8sMwoMz72G+m1e4w/JEktI
FUovfEaNh+mEvdJjTV4Z7yYBSjybUd7A+xYPq0Kz2zxP/+CHAWflcl4XPBOkKcyuJnvDLN5cZcvt
DbOAymtvWWIrg+N+dOnFXsKxt/e3K0C0fcXb301rRR/pAZle4fDXsA2ZXuHwZZhHpsS5wJwz0PY1
bIN1sPIKy1bv3+YjGhkopjUtbrYdDsNHBaqYBLrsdEsJA+6AFzVtX/BtCttXbGXLXGbb7oiIO2qd
yPTybc4MZcgtnMWW3U79txHnQjjqnQs7gCXu4D1dvAXeJsFR7Y71/tKMOBduyHRUAvIyjjno+Nxn
83fLxLkKr11CeSuMY+ax4MkzQSYcbjBX92H7pRPgcKkrvB58G+Fwg3KOpbfAD8wAbcXJm98CHLzC
BL4RcmHCYYBm923bTg07hRdlGm/BYK2YgdjiRSFvHRpQWsyFCoIAMzvybjiXcUxT8QTZcC4IgnH6
8mR9aKj8GJmCHGJfK5J7+fn95rD8xp9viXw00K2sW51niYLbe/TaFuB9lgGZHwMTXULKSIHHYj1V
R2e/KAGvYXC8BSAeHFh4XSnkGsMQXQEqa6iaxDrgTG/ituDvEyAqKrD2PR4GUWFCT9WYIJ03dVok
hdIu0+ka4oyXD6UCK8BA6/L0tkUhOb/7U2amc/n569/eCKFC4XxGEF4J4WfS9MdUjxb3nGpoCY8q
4Ouh3KRTmBvUhQURSRZzUwEWWtfcnBH0GWtMDYJlKBbPxtSgbCM7NeIsiDIaX7T2HjKd4BQ2Cfo3
VEoEpwXQU2NtM8Hp6N1J2rbTlRe9AtNfw7LPpoPzxphdik2qMn0a57Peh/mMDh2D4DS90auWGsFp
8XrVY4qcwFOcPWfHPbJj+nTO77wCgtPcYaJzyNMJJwc+LeaCaTlgGcSrLA/DjTEmXeGA5/Nu0EVd
8b853mllAqq0VOOdNiIUqzV2fQ0oQDIgRY2ZBUGCiHsH2W8UAsKb3jfuD/A36JG7O/Q76Oxw9GQl
lm6LvscK6aWX8E2sUB4dRoKA1NsyoeWJFBMEYAczMHKZzUfYZrALR+W+aPaLFhypwdz6+6Leg2ZM
TNupY54XBXhtUB4TvAaLqsH9HLakuzxxMyudsnzqmPIkQUxagqew0i4uw7yjXeltSStvCALpHqIr
DyVgVheWtqxYYkA36r8xToz1NczvFHKLs3xirMdhBQa5pbwScy7DfNAGTtawVq2GBCkQU8hcq3cu
bD4v9V9PTVNIkFkX0sepJh+ltwhzbJNnlkeTrAvp0AozRyb4NkjIUALs+2x+GPRfGswWvQ/zcAcS
UoiHRyiWBRICxveeYvI2QDEg2CThkSm83mClV40XpQLsI7njvMEdBrsIOmMuCAQpAXQ2DQWJ3jow
lsl4M4xpPr35nfqYGINdUnvpIU+lpCNhNqdDfHHArDKxMXIJucAqE8k5icWLssqkl1UoE9CNwS7g
BK9qtioTXllZ0RzTzSi90JnxOQXJwKxiZcRbYJVJBfKPpXciCWHObngWBKAT6MVafABZZaIGTX4f
5pMg4PGAbtDnGi6qTJnp0OTunHrfE2JpsFjVsd7DF+ZOQkebheTVkqFqTFssllooveft+DN5VSi9
Y9PkPjwFNZhrWiHH5+OsgKQKw9UdQaof1lnm1d1Z2LbAmFgG+r4P2yARa1Yqzl98FmawC16Q1+Se
WU1mNMZZmW02uIE0bBb7SJAgOj/mNPnmPkO/wW2oJYXMslQP+J/2RpMbDGUT2fSb+WGDcFmaO6fu
1BsRZ6/i7OmOJ2apqKQ338bb2QQwLKGEGG9npZn2kPVmGae+V+f8bIsaA+ajuePsL1SIJzCXt6cb
DoM9hbeaeiwhALhAnFbeOD8zPCUsr34zDDyFfhMnb1vciXF1bCTHzJrFKMA67mQ5jVQhbw3OiveR
fDEK5A1/m5x7vIWAIEhwy7I55eDDLJIZ+C09lrcKQSqjeZvlc8MrBAmaRtxx3uNOAAIMD494C8bi
p1a9EfeVHJWXiwB/sRFn+Qh0SPWKy0exGJ5KOIIpphs0khnQTGwBZ3gKjoPzVLc6pMEaKahLjVkP
ZNoN7tlL/fa+fMQdjt+GTPVJLeQEpGAsyroN25FpOfDpqzL1MturbM3PKNbzsFsUS59EiKUPBrld
ruzXbD62I5Db1sayCPrEdKYwz3vnfhu2R7GM3EzJLerTMNnYAH5gu8+2AdgKgZR6XkQ97xQOngES
rVuL5522xguVFY4OZuvGG5WiLd5pZyFFLkViZgF3tPoR8XjcKRsbDJjIFO+0ZDhRcMmyht82Aaw0
GY6nHtaxsUHvOlrIegJYlbHytr6G+fuBAj0JiHIiLH1SWYV6smWxmAszPFWKVvdtww+DnmQadLnP
tpWMMC2unlccX8O2AhSab+1+CxuAZQsHnK03XGC2JvSk3Id5TDSzNdNI1kLpLYN2eZy+1iNPCWAJ
/IeFBxB+wAH8mrob5iM/LIMwKTmFBJEy4NvrKi173gL+/pjiNkK6waEET+toKWSWKJN3WCYa6l42
NoAOKbmHQj47FsCQao6/jaVdLOXIIU9x9gAo0uq3EdANEjIqE+PiRWFJk4ilHqoaHPcjJ9PaYy5A
kEav2emQLVEXBrcoTmAPuTAhJ4Sy3VnvUyqYhtkHeN9DghBysoStxDpEIW8lwcWLDyAEEo5xaU5x
bViSaZjQg3WEEsLYFHz24VTNnobZeTc7LD6nbJMwkqyePcEWCDmbrVr5gCCEnKXmN0p19j8Ayu1O
WzoIoD1BDYo6sdzo1oUaaVWnPavomYaZPyLbz982wNPau9vChiXpcSlVfvhtjHRBNKvEPJ1pmB/p
XZfZnLYkMoUH2Z22fIlM4RdrDSWE+ZWd3VEcQXz8R3lhUkaJecqMSLbisRJ/26yPqSm7c+qxJNsk
AIk5ZnmwwzYJODLFM2uLdJWjYg95xDtlmwTLou5k/eKHsbfW8C7BDjl5YZK1xNqSyJTV6L2H57Qy
vah9pD496jccgoOp/m+EvDJvyKR5unmEBdedP+4xT5k4CQXSNTa7+ChGPcxz4UX/g5x69VxwElJZ
RgPfp1ooIbXygi71Hiv8So+rwvt1OsSj5lZhPtImlltjA17QlTRiCalMBhHdPK5tNijVVJP3HMr3
oGN9/RXfhJz1EVDcEifr05m6J07WJ/rfIWd9otgdcn4O22ocr3WEl0X9Fq51hF/DtnJYLVgU3rje
huVfvkfHvMyX39M36T9+a5+DWdtQCOD87/784z9/MAveZimV/fzrD3iHH//yH+tf2K+H/7LG3f/t
Y+D//vE//+7n/8Fk9PDmqoXtopgsZD8vs/zrXz+Shn73L+nnL/8XH/Dn5zaN59D3NCm8mD055Qt/
4QR+NNG4DNtivml8NtG4DNsiyHACCw3am9nYu2jU2u6zbfWj87q4zAY212H+imZeF8tggtj12/wd
AuP4bNJU40VZtKpM+7vPtnUVyYfQ57kv6i/GZ86vptmi4DpsSw0eLL+eFfDXRf3dS4MCAbjyW/AK
hLfK2nN3XHhRGv4Rx78u6q+PLnH8aAsAHUD90ixctMzrYgB1J0j+UmXG8fPMlb7O5lE/5A2IYtYE
BwQpAB3wVLrmUJDK7DaE/faQIGV1G5rpddfZHLPKbAmgucZnoVhj3YZkiRdl0eoZV40WpTI546oB
s+Y1yBlXvS669eGAa3TGVSPywtr2M64asR4SkgCIR3wWeA2SYbw9ebfGjSz7AzhxW9iqUZk8vrJu
g51KgcFi749YkERYz2czAek625ac2xmIyWmEGkmUTbCgfS2UENHK0En3zHI+thg7C8If05hulZ0F
GUyKCVIr28tNfyz6tsqKqDzD1hFBIG9wiaVbKOTX25JIQi63JYFykDHTkG1I+G3zGqTrrLe4zuZx
OiPvYl1GKOQz8k4ZL+EWZuTd+myEE32bsMEqtxYKEiPvY6Q63iwKeUsVSF3i2bQd8H2l9HinxoaX
qsUpVX+HAFgK51N6jhdlNaq2GSSKFmW3yNFnD+jrbP5qi9cgEEq18DgDph0zcT+WNwUsZYjCEWSv
RgXSKawGCXnKa5AZk3Reje8WOQNPTO4LCWJltnBjb5ToZNnsWlSaY/1eP8rGS6uNU8BTm21CanNO
47ZTpoSP1h1Pt3shpkTCM9NYeg3oFe6WptgbBCQ96FZ7/80ThAF6iIjGrGfCL0MZTpN79DTj+KPO
Yt/rsK1+tEM5rJ4H0aKQt2Gr50Egb7N+tKyeBwEXWD8Kx332PAjkrULeJnXjUz/bQBoTWEPy8hqk
p9XzIHCPeQ3SISCiIUHWNUjKw0KCVBa7MFQbn/oKectNZgQz2qmxqg/Oe46/bTYdwRc6sdyqUeES
sMWGO86eIOwWCcI58u7hfmPCW/c2y2+hCxPehrNZG7MG00tgP176SN+4LXnp0H0LrWMTTwb3GqC/
DNta71wC9NfZtpA69SSMmtxn83CYkLNnXWqhPlFsQk6WfN634Ht1ZIGkwTNO92/bc8IFrmyqy0TW
J0mbZaZSqlv0ZZlpl7Zwx9ewF63I4NprTjF5eV2MKbMjiO8IxfpRxXwSc4Htcoc2S/FOeV1cV8w3
2ulspwSbpuEWVjulPpZ9eWT9rB8FuK7tzbBxMFI+SrhT1o/mVmeqWzQb2wTChhWLhykfT2CJ8X3R
Fxnmid7niAnCe+DZKCkU8tVOKZ33Ko/Mmsh0dgaOF519kjRlJyE+K+ASoI8WvQTog5NVOsQSuHM4
5eAB7GyntFpkBTydyFRK1vicst8kZC6n+7CtSz3j+MCdTsj3AD27fImo46kHYozjZ6iImG6M4ycc
GHHy5u7xZoB+lJJipToD9IqlY205A/SfSOGRWTNA/4kUHoWcqeODXV9qKG+EnAmufR3xt3W2kNH2
5jizupSxH29lPARIs4VMkh5yYUJOSKU7p1uUNjFxDs69hFvQjJ3CePcaL8oAPXwtbSEXiEyzpeKU
w57sDYLgMDvlsOE1Jnsb9JK8+ra3dd4KOcSvNTup/mad98PPty0bq/qG9ViDaZVjnrAanmulC5dW
EUdEmdlg3lKLzw5fKjAgCb1vwZeDK1M+hnlrvmUvJ4gK85VqyFzG1nsH9nFb8FCrgOwd8zm16dOS
Z5oiu4zFw5TVt0yaDunGdG74BudF6CPdmM7da7bmtuDTA6BM4FA1ean5f1M5uDFH0VY27EtZ/X45
+JoKhiZWIzMtvDBUG7pJ7FoEwFAkx9wcbO9XxWK/sc56vZbezFYz089Wj4rA0Mx870rnLGT6zPfO
PeVYd818b6jVFtvxle+dvYHedspuHPAv233RDcMaAMiQJi1kFqQMbpJVZys3ulWIBLty51C84Rsf
rbbh1cKrqDpEsr75Nr4qMPJ5+ea/7RsAMNTubwBgf5KNa+3wZVhUO3ydLagdvgyLaoeviwa1w9Gi
l9rhaNFL7fB1tqB2+PptQe3wdVhQOxx926V2OGLWpXY4otst5tif5PYec3wcdq0dvg4LaocDglxr
hy/Dotrh62xbaJIPofTZn+lKtxdt+KtBZcl92NYol6+ZsaljvFMCQOgGSTHdCADZUaDHO72FJh/l
7R6afDyn99Dk1049AKTKKsyUj5kFo5bah3J+3sKYYnkq58eTxU4/JX8o569h20sCq8RYJRTys8RY
nUba4lO50H2qyc3mceJZO1zi43zWDneLT9aqHU4nvn6k20ft8BuNJKpwVPTE148SAmIc9UzHirZQ
mUzYTnz9/G0wkfi003w/k5e1w/D/nH7buxAZG76K10iep41N6IeZxVvojAGtDt+BXZiJ3I0OTUze
ASGH9NYSEoQP2eW51XALOt/B4H1k+G04yfAqge1S+G2aWaOkw1nnDTSVGSpKQ+ItCDvK9+RP/Zbv
rSwPLE6Q9tphtlMq/py+LDGWdMaRH3XvfBZvtjaKv42BTmnNWZmNvEAcBR5Bc6bNF3q3ysShlN6w
noFOpso51m+VyJReSd3i2RjoFDvDzY9Hhm13iW+9H7IVLDPfe71aFOzU5nsIMl/PC8g7873P+oJA
LGfBMlR5j88COxvBs2wau6CsRE6zkD4k71mJXP1Z8N/GC3zajxzTjRf4gMvuLHjHbOZ7KwvPQmZZ
pdltNmI/xNgnUnvzJ2sbBlg9Rncqegted77W2EatMRfYIgtzuS3sr+ex7Rx7doSCNCuR2Ra2hkJ+
IlN54xLMgmUY/NFCgkwAy7TZFBKkshAvDdPYfFR2kqkExCFBqmKnObcRG8pZsNxh4O5n4eV7d1X1
jYPBfrrQguYcjC3JnNdfgHrOwdiSzKG4WFriyLtHMDtLS4Yj75ZkzudrYIocefeC5UEjnpyn+t13
1M58B0/v7+FcXkKun/kOcAx0Dmar5NuwPdAJK48fT//5a9j+vEybnfPmt34N2xBWYclnne01rsO2
RrlfJcbXYT78J43KubudbrNdSoyvO/WoeWZ6lJxzvIWZ6SGzRCUiCHHuLOu6z+avEWamR53vKV2H
+RTcXlhlsy5ag9kGE5D6Cptehm0vv7EOS+u8n3kmyCwxFmvtvoUtSsgW4FVGun/bBnYynzCEiq4h
3Qo7hafWrcSzMQW3jZXkc9npixRcEHeIhRIyU3DhQKvEO2XBC/ODezwbcW7N5d1OmekhMsufA55O
nNtVPBe2RrmDhWkib4YxHlqAY2KxnIHONtQLkifILHiBy+Ckd3uJHV4l27zeZ/NXmpIgvQmwIz5Z
690YpjHed7oVLBsful8e7zOz2PgWQ5fHGyxawKyPBMvLolvBMrzK2lYCebAoH4TJvSWne1/1yKoQ
cqe4Xj4Ik4a28NTPHlmtef22bYE4l4e+xVuAIKV0ViIEdGM8tKeeY+XAuuZsZV26Ph9ngbxBVa57
++DbmIJrtu7tn79thU3raG6nPpX0DJuK05YecjJTF3JU3XH2KOYMmxaLh83nZcpsyBAtenk3JjgL
K1O3dSfke4+s2d15vLELavQqLblv27CkdWqk4r7tu9VYWuUV995XcS2nQfv6XR7fDCfMd3+/fpdk
60DSjs5EqHYbtncgMb43cqrrr2FbBxI23LD5AtJl2P5SLxtuVBu3Pb3IXGIwos9G2tfZtvtt9uWA
msnxFgB8rOc6cz+etzBraqAXrb36tvfN1AmIzof1rj//bjP11z/fLBSAuY0x8p25e2OTfshYrSGu
s3nrCT8BRCytxZRRyoDNXsLXYVtCFBt0pFlyHm2BULpZTxZyrTS6iGk0x9wXlh2+6SrEuAzzV/rs
MYJRSeJhbP/LF6liUeEbbjOjxEJpF8bUtK77ycts3rIzV0Tz8Cdx61cpbDOYvYRsr67x9gmO4n0L
W26SzRwbrfG55mWy0KHP4UmU2fHvxKHPPKX1HLmMKqH08vq3wcaW8Up6f1M6gRDSAt24g/BfSSc4
pzKNdRdvmyHelu7D9mvkwvciqqP/drmamWA/2muF+T7zB39eWHCa/ktK6eHne7ITfCc4HrmGbGWn
/F5KcjZiy/zha2+5zb4r12Fbfc1gSZo6TbjR2Rj+bisr6fmoKvvIpbJuMp8VpjZAb3Ajl/AMAt/M
545bDw+XMh2u9+Ista/iZMtK9o/PbgvbU2nslNJXVtKziuPVbmuyspKe6cZSF5tthUNlbrAg8LBX
VlIwm1aKcdGXgvTbEoSM9zy64qT/vRN9TlX96fAUM+Yqr0fIg4PPK+IEM+kM1lbkUnmzBO6VUNKg
Qpg2M9+gu3pxW1aSHfPxjBSqEdbCKOxztngLBLajeWfPP/oNOAj9jDN6Z4G86PWBD1Pnxfna+cqc
21qTkw1/v8dL3QTH0C263dYqg8upen9ga+LBlwqwgxSKN6tXiFi7xcOIMUdP7oRu17DEmDq8Bd8e
l4NLUyA4Fnu/bOIxn7J4QxBiTMVW7wTZH0kDxhwmKdaTENwD7tFsKhsoGVhvJs9Yd4v+4XvYpb3e
03cxT32SSL4vb11XPdVl2FbUwauWbssC1aeTnOezKWebhq9hWzFM4yOn/YQf9YlPucPsQastIF2f
BJdFHbA/bamP50XZdjZTG4WL8iX6fL6KcZ3Nt94D11Njfvf927bUH2HLlZPr9Um18a4T9qeOO922
MgzmxUrqjqfbt7ErQc6rCD/4NmGtPvv23IdtV6LM4UsrCeCy6NbDccwa4NFj8poAFWv18ra9uM12
5OttykAsC59NSax1CMWSrwtAg+cuoYSwqKPBnqQ3W+Bjnc1K7TFB+G6UgmyOCx4A8Ap+dLESCjm7
ErAlfLNwUb4FBmFaZRjPW2DzAnyfDAvljSUiBhW4TMLzokBrdT7KHi/Km/ohOlMbL4v6tCRh9Wmu
y5v5WtQjSd7Ut9IceTfgBHkT9gdw0usBJ+RtpNWlKJAQYE2WR543RM87pacCp77Ep55vZCucYkvx
FkaG95/ma4bRogBjFZ6zaEg35vRAuZlTg/tdJ+tFtfaY9cpuQ8as+fDbeNeZS68ph4qLJSIpwSeu
oeJiiQjkQ8SdLH+rC0Eqn7D/eTYIEjihXr/5b6N7RGsUK4dZ8iE12YjpZnyRtqcSsx6O4gFfO2vM
em3sHsKHO0Idoo3dQ87CsEBCej2GnIVhwaIQS3pqOcXkHXzmu6q3pz4VIzGFpa3C1+cjw2Qd0K46
s7sBPz4bAOSRSkhedl3kC2newdhetYZYAqA4e7ptQSmWbNQQsp7JOvCR8pvjPF8XyCU7um3fRv+t
9uLM7vZttcCejlUpFywKeYMrJU5F7z0c09GriNOWW7VPY+mgnhdqjxLCnB6iuh6fLByDz1cZop3y
2bvzVYZg0cr7yvNVhmCn7OGI/65OOs/mo/I9uwHApqG8MVmHj94587E3Z2TpYGvOXdlSf/jsHbSD
d1d8GYmy537rbxRXna/jje7dlS2nh6WDaXh7uuX0zMuj9MZdYU4PE97fuCvsSpBhKUeN6Qa88HUr
8agGmfrD/G5vKLecnsK3xTef3Al5SwyVwXVoobwR/uFID2cozy18A/691BbfhX/9aZMACZ+dI6/D
fIqQ1c/OkZdhe0ZMYrHgafz6EwNY+v/ROfK6qI+MESWejxVEixIlnp0jo0XZIqVA0vp90Rel/6Nl
9d+2oURIZCmrM9nztzFxBjw3HSF5mREDf7Yun+yRIKz8gEC2avGihH98Di6FrJ8FInwO7r7TLeik
mSbhzFDoT/K9HpcDpijxt7F3HXBMuu90w8OVz3PVlC1edD4uh7PhePqq9F8B2O7M2tA1C0TSahJ8
HbahRHZRHWYSfxsESXo6L+c+h/k3X5kRMz+thnSbGTFFT6z+OczfCLL0X1srIiFPZ+l/AeasIUGk
KHvz23IavsjrQREzYjJ84zdbEL7voSeueyTv7F2XS5McHmcG61qV2Qg2ODIzIwby1nr8bYR/HeDU
sX5r4c8+Df1MAHlkPUawWnS1yQwW5atx7Llv8U75HBx0TY3FkkG2ruxWGrIeB54p9uZPvY8RZfZb
bSf8e9yp5jHfP04SHsBZq1Ggo3s8myibNiXLoXKY3ebKyG/sArvNZZw3sZCnasbuhsXbha0Ig+/J
JHljAQnYqp0FIpfZtnfe2BiJ/UNigsCBrl3P8ODXbFsRBvNWbDXVuAzbkBhzFqp4Lvidsum+Qp+X
cAuzCKOI172vmu5LG6WV8JzOIgxJ54XU12wvmu7Xns/s10curOfg5LycfSTveg4OGqnEW2CzJeAF
7xJsuI61GnxbIjyA69U46d5deflqnI4WC5LxNSTC6xEThB5Xb6vb3LMmZ4QN1D0940fnx9hsqdbu
3JVtC/M5uDa8DtkCcWN6g056t85ksyQXsCh281YRhmxq0IOiWZILIx4LUp0luZu8bWG9wiey2Qj4
PmzDddCWlpIz4v62enYRYIucN9+mDE9pct+2Py7HosaSnUba43XzScnNyvgWd/S4Ul5Fjc+sr3zO
lw/rOkHyUVO+0wtjb7FvOd95g65p7dVOv1Fd8dIx+SZ2Ys/Y83c+iU5n08U67ffXsL3ooH11OL8M
2/qhAVH00qdvcVl0g1jQzsY2bLdhe6fu+dbJcFvY4F/PX1UY0TD7qsK4DNuwk3xVYXwNy7/4YXwS
pcwnn67Dtu5qGQ4NjJa9GQYlDqpITDciMTgqI9WQC7MGH3A+O7ptETa6IGk1Rw0WLeyKczr3z8zi
K2lFZTVHfeZCofqANOURD9PZm3E+7Bgwi4+pmZyu22WYRzu878HJcN/meUrABu95uNk2ZvFaaD4o
Eg/jtRDOQtGYvLwW4lvE951usUSG9WSshJzLsO0xtcpIkbhvK1sJAyxuO/ttPtNN4EB39soo9y1s
z3zz8WtZ3udlmF+0sIAdAHCEBJmArbBQIBRyAjYgIpESCjkDcd36wk7BosoaojTqfdH9me9Enqbh
Ft1KGBrfiCm5xYvyKZleVgpHsAW448JimLtY7pUObOEiK1vvMptHYp1vlLB7yH3YVpvAkvOa632n
+2NqLDmHx1jjLQy+ZsjHZsPZmDwJ4mav37YafDbnTCsofZltew2czTnzCko/cwFeysGCVyfkG/AQ
SK8Atr35NqE95Y12vFMtzA1ujqcb5mQyJDwH7SHrFfI2XwfKIRcm/Eu55vjU8821Dl6pY9YWiGts
xrv6i16GbW+uzWjz6uYXcKHPaPPwdNtmY/qiZadUd/iXv5qNB8wa46vZ+GU2X689w3pns/FnuvHR
cPYZrLG8wQ+Hg5Hmy9GBBWQNPhwM6+7UeyQmbAgjzR2ZrQZf2BBGe4nN7oz+KV+Cj7fA6F/uzUIm
GOtvmg7vhvg1GfzT6mfbQ4n9AJLpYjGvWNcCCXZOzd7gXJnUmXrsz1qf4ZPiFZJH9INJ3wC6NRSQ
yqwsqtTYy+PLbIUlqPdhWxCLrZ27NueovmpJbpistPBgsVKf77Z7y7YF/zJfP8g5hguVT/zxiXqn
t3zEUfkUj8kbuDB7yDE1LoeCxB5y8N7mI5DRFirlLWmK5Y0tySv7ttmrg/W+61t7afu/i9fKE8Sd
LysVAEm7D9syIgfrjsvyjj6H7W2u9as73GXYVksOJCx53VNfFt2KxCssaVnFp5dhPr+SXTLgp8wI
52XRraaMl7zrjcXLsP1lpcKUvTzib2NGJPMQkiPIhrD6V9/vYBg83s++31/DfFyk8Oyd73cHW5gZ
kTZWddLXMB8XmbGuTP/ovtNXsa7zYe6AC7MZWmYm232nG3QqjPavvK1gC+zfyDcBJRTLwrPX0kqQ
eWY9a8QaaNxG/G0MlQPRpzvrt+5wjHUxI6uFZ4GpjmleHIZbYKoj/d1aw2+TNHuVNMesPYcR3jiL
E3N4AImwoOhbjlk/oRMMpcRnYba5TsDW8amfOYyNIaB4C8qa6PROh8ym2aWsF4KCLTDVEUDX65Ct
fi1/PvMdfVu9dD4JCNKE7X1Ww4RnQWL1d/9ozxjsFK4sXPFiJd7pYOzhfBLuMtv2ABMb/4q647z5
9vBRs+lmPraQWJrI1DPrFz+Mb70xEhfSjamOvbM7S0gQvmo9atZe42/jq9awIf4seILofFuwNQ11
CKGTQQmOFkoIvA9ISF5hgGezO5+rzswsir+tzr6LKwxwmW0rN2MDqHIC2Echn5ioiThB2qETYw92
Athn8o7ZDlRbCxWX8RlW2PAULzojZymbP6dbr2yW6pfa4wM432lKsmIPzzydxWum5zXpI3nnA0yp
Ju+ubA9Mzw4S2RFkm81mB4lVQRMQxGYHiVJj5WB1dpAoJRZyq7ODhLjjvD/ANBvvi5c3T97ZCruu
pJBgtj47SMyXoyMu8IZch3lj5INYrAmAmXHGaPPaefUNnDsslN7K7j2lN3MugbswqXTMrPYes77C
UDZwK8XKYYbE2hjOLmw75QNMbBvqeLrFutguj1GseNh8f0RWB7bg29iWJ1lx+m1HO8w1rqsD2zNP
WcJWPzrkBIsyCakN8x7XVsLG90eyVg2VA0vYPqvJNmZ9o7H2S3H+LsR6rPq7Q6zHWrhb0dll2PYU
bmNKy6qss8cawtmPY2Rbqu250UabXSNXLwZ7rCGcb9yC/vn+bXvW4aVthz3WrK5+HO2k9/MWZj8O
BhPv3+YT2W6xrke6zazDJqun8zOzJhJLeaWNPH/bglhlNWu+EMT3iSjzHbLSe0g3+P9Hg4taHes9
5lQ4DUBO69b7kaez6Ix3vDEXZr9pqF032/7gEKUXgiTxopUXBOdzWfZYPjqzDhm0juWN3TqAJ5oT
y73ozNiXv6X0ZrZ5QXAGJp+/bcwLgpVh/rzobEvNt/ZiZs0Xc7P0mdb+TDcWnUnV4Y7MHsQqODIg
SYoXFV4Q9NQkFHIiMRyZ7A7gDrFY7sRevCHdGMTK8nFP9jVsi3XNC4ITNj/vlFX0I58o8fE482Fd
0Y8L12fyNqia8XHh+rwoY13ws2uNCcK21ArH+L6FvV0XC0a0eGZtITHFcTZpb+SNbamhud4cwAnY
al+NfZ8X1Wxfr+8873TlMObVxOQyzIfEiMSadYlPFoNYGRrCJJSQmcMIp8HbBd/4A/IGENOcBfxu
X1G1l0YMv/vzj/8PuxFcIGVuZHN0cmVhbQplbmRvYmoKMzMgMCBvYmoKPDwgL0NvbnRlbnRzIDM0
IDAgUiAvTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdIC9QYXJlbnQgODUgMCBSIC9SZXNvdXJjZXMg
PDwgL0V4dEdTdGF0ZSA8PCAvRzAgNjIgMCBSIC9HMSA3NSAwIFIgPj4gL0ZvbnQgPDwgL0YwIDYz
IDAgUiAvRjEgNjkgMCBSIC9GMiA3NiAwIFIgL0YzIDY2IDAgUiA+PiAvUHJvY1NldHMgWyAvUERG
IC9UZXh0IC9JbWFnZUIgL0ltYWdlQyAvSW1hZ2VJIF0gPj4gL1R5cGUgL1BhZ2UgPj4KZW5kb2Jq
CjM0IDAgb2JqCjw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggOTIxNiA+PgpzdHJlYW0K
eJyVXVuuJDlu/a9V1AYcI1HUg4BhYN7fHvQODNuAgfnweP+Az1HErQxRGcw73cBMoVoZkkiK5CEp
Kv9M+PdfMv6nm/z8j7//+N8fR6/zb8///xerSfkf8k/++7e//jz/8I///vG7v6af//1/P9LPLK3L
z5Hbz5xq+/mP//zxXz/4hfk3pcv4+qv3A7P0NubfWkuvXydOdv4Bk/3htx+/+wvG6tHmP/bzt//6
kb+Wn2V+ZpSfv/39x7+mbPpvP3/7nx9//u3T71Tvv0ulz9+9/nuVw6o0ycsw/YMb1vKR8WOxddjw
w+yQqqP0ZVgqblgvR5E2sqxfUzds5EM72LZsPVX/tWFHE0vgQjjM+tFHyqWFa5OUj1El55UgJblh
oHdqaYx1C8URRARs0ZrrOmlpbljRQyX1lkNmiYJuvRQ36bYF7YdqLdURxK+t1qNa07aurfq1NUiI
aLUcsl56PlKvDQPCtfV6ZO3NiaVnvYxyiI3e3grSl9TnJ6mX0UGo1MX9PC8/l08/9wT0lLF25Fat
rnupjmsl6WEtuxO8bbnkAoXUZLT4ayJHrVmrvGMHtva7v2YqLfn52z8+UKmUfBSwP48HKv3Sf1+f
elQzX5/qFnK/lHpoHk3jE10g57VZbyWmWM1HF5xBR7Hqh7WjpVxLjr/WFPSHtDtuuoNfeiM3i9Xw
OJQBOc+io8fchO7KQ1VH/DXoLtCu9hzuVJMckqHLY/WrqR0CzZWceP/eDcvtGF3U1q9506BSjySl
efF2W9BSjty168rTmt0whSBJHS3W0lBvB4gy3AHXP/ph42i1mNNd/iArNKEN6PxYE2qD+s1JNId6
VaEJFRLSNF5bh7xlSJzFBBlyjDaaP++eWQb1CxPXa0w3A7MM9reGYqkGsWylWQtZXxPEMuvIsVcA
8weCVNPYbNVsRy0dhjxcW5WC42zDKYcqbhg0Up/j1rX92Q+zIw3z5n7bAkyq4HgVDZlVK8Uylxof
wFoNBIHO7OFxrtBIUIVmGq+tywG+Zv81p9/qSHBFoN5SKL11jKNbL173+mGwfaZDve51R6bB9sH5
bY68nqdwpLDT4fWbp1vLQjeplthvhCo68KlWa8gsmFqYD+nd6V6/tkI1WCx9WJsmEASKy+3U/LAB
gpRNLB15G2wWFGtOFkoICHsUUNN/7Y9+mMKeZgCddZhfW4O2LJBftwX/NbhwBhp/cKQb5C3haxb7
M20okAWcqNjKNINpqz2N2InqKR2aYNrKu0k/oqWe9N2evomyRnraJHQknGOo57oM21AWuC5S0vSh
b8M2lAW90DVPq/YatqEssFNhiKYpva3NydACxoJJ72Ds9rXmh41jABjputMdjEF94IzWdadeieOs
QziGtHWn/iQLXGepVtoI1ybUC6OrxeQV6oUyWorJKwWGGZLb+/q1P/phDUCxdWnxFhSKMkPyVkFS
vwW4vBVYrNo67C9+mIILkpMjiN8poR20aV7X5jUgoV1OWpLFdOsE/1WLxFwYDVygMxuT12CuYE9z
D0+WGLwogV85wpNV4BmPvvF087MzvCixLhqurWSKJc5XzCxCNQWKdXTzQl4KxTKZp5uHMcROLVe3
020Y7FBREbeFbafQSDgIRXu8BTg0cIy1S8iFAodmWPGs/y5ch7MBiwJXbD2Y34XrDz/3glfgJ8Ej
rO7s7JAMRwzSKU5Xe7gI+SyVrmP8NXrSiln7O3b8U3Bd4W2bZhiIByp9H65fn4LvHso5JgOogHzG
yhwuGdCCqoyQYvjvQAs80qEAT6AIhG09/hqBIuTSnD1ycF1rATcbLFJ4HHCwjp52e+RxUasHbGDO
sQVRmFQrBMXxTvugBTljiK9heRX7ZyY6N+G7zsoZk/jnf3cGsIZcv/snQ9C/fgf87L2eAqKCR+sw
751C8x1De50hptewzdUCJw2u7nT+b1/z7kyHd9phmMv6tc05UljIfJk+eTooGaYP7Jah8dpGAfqu
0tK6Nu8GAssL8OHpzjxvAaqlGExfC9cGXxh2A9Akr1/zEVeYPjj1l3aUp7MuAOkd2GoGZoNhAgVD
bFXjtQGkA972mkIuyIRgUPAtJIgoI1GtekHafCiB5gYStvhrDWYZLCzrTjf/DsanQ1ullbwe983w
uEH4P2yBPpTmrI4L73woQKKuMXnpQ0GJlxqK5fShYAyshmI5faimJcdiOX2oXFVzuDb6UAnO+Iz2
3JTDH/0w2E+69m7YFhWHWGo5o2TBpLAtAygrS0iQUqBqIHDdKQfvuClcewAFL5YuxFSg3wqwteSY
blBc8HbNaUsPFEozaFlL7gAmhwAKTBAgYpIeE6Rjpxk+6giFnD5RapbrB7ox6A3pzSWedEDIoVMd
eX2KTRMQpzA6vg7zxpZOSmo5ua/54K3Awg+o/ZUgPsUGlAPwByGPt6CFAKv5A+hPPXyiI88QXsh6
remQUas48np/Ac44NG/2dsEHlitce4YR1q95ewoFCASg4k6Wj/bAdAABSBmxINHlGQayjFBCFPJm
MLpphKpGod8ybG+JbRaWf0gD4WKzq8boIk5SbIwq9BuESXusLWtqh0IoSwu3UOkNAT7VmPXgOcSS
2iFem8ACVmhfx1Mn5BVimUfr3jr7MDXEEjpuWAolBDby0GSjxpq8Qnp15JGdBdyGMbooVjTkaW0N
BNELMD2ehQp72pq2LvHXYE+h8LszbR4lVIMOgfvgeeqjsglAB56q95G2aDbEUukUxF+D4ioGExif
+pb7AbdAndndwq3QbwWeqnOPvYQw6N26eR/Jm7YZ9C5UcPHaAMI61H2KvWjw6ahwyj94Dq0qjXhy
nsOWU4DiAlS74pqP8tbg4Qv+cUK+7RQgDMZSncLfkgX0uN5IiGc9NFJ7IyFuCz3RZuEExv4b8Alr
Krp3CdykPSfWVPRU3+30c9D7vWR9F9fp09ljaVGuOZ8WV582uQa9X19zXlRuBPL5TFrfhm24jkAe
uKItw7xVm4ANknaK2vPaANhmwtd9bcN1nbntYrKubcN1lbntmlJItwnYemtup5vXnvpRFUahhFtY
cd1rUg9jwGSW23yaNA+m/a7I5/OkAqArQNdup1vZE2OVo4+6TuqzAIWxShu27nQPobej1Zwcebct
wFx1qIXueOoxJ5ytBi9SJF4b4V+F9+N26gPyrQMUpdFWum24risM88BWl2HfjQhJH+/Ygt/BTcK3
cRjl5/s//u2vD//h9sdbkeK45k/L/CcQApZ479ADGEBi0zgd01/DvChmIEM4de2Mc/4atmWaWHcC
e3d6nM/DCpPoOKElnpQyBj9s5tpvX3MyxkTeaETo69d+73UaEA5Ak6xr2zN0LPvLV9j89TW/hYnl
7MqYvNYmXgvB+ZN6YZLX17yygomCCjprYm7DfCQi3RXCa5iXfzALc6qsrN/CH6LMcVyx3+dJC8Nt
TZrjqT+bcDuAguxMMj7ylPEgALne1rV5N5cKQQ3AMMVfqyzlzOMT3RrFsrf0YQuwU4Roo4YSIh0u
OOtJVp4WP4xZV7jEukrIZlmMYgkFYeHaSqqsH62Op3vB4swNiRPyrWCOpYEsF0gh3QpdydJ7Wcm7
hRig5E1gkz98rcJpNnhi8m6nN0X6XpGdtVsbW/C7NId8v257qkSD//A+vAVr9SoMeA3b1E4aLx/p
NWzTJ0AUAt9+2vrXMC8tYNkr9n1bm/e4wLihOIx9Hea1E8AknPY6XanbMO+YwRuER5B1JYiPW01v
sENz5ninbWbfkq1r25MBVLByRppewzbHrMtRIXljnXQvgaDnoDKDZcHaoIe7gW66fs27x8CcBsdh
ItjbFt7UowOD6yx8iYYxcGz1w9pYKVGgsx3rN1dKWOwBzq8E2ZwfYeU9Du0qb3v4nhZHVZyQ+5J6
HO1fYehnus3ahqYn5rwN20ogBqxhOuukg2GsoOqtjlUsPV6ARQKs0J5jsRSmmHtrn3gKQTLp3e10
o9uAgk1D9QMXrMBoWi2Op87MFQiSDG41FPICQdICn9xN6pPpGcyaceiQIEXSMcoYTodsBd8CWDHM
LIU7ZVz+V3w5WJsqM15wwOJhLB//qnQMCAJf7lelY/C11l+VjsEwePgNglTWr20Bd8blGxNGMUFG
g7MhSeLjXODyAT9vutdzwWBlQJXUw0lZPo6Jpaxr2+LLGW5VHdnxdK8xgHKAbNYcnnpo8YM1al3j
rwnEspazTvf2NWfaGL5PA36Vhaxn+B7+kg4JlYOqHbPEoMdrq4UB0NrcAfRRfpYijNIsx5M2O3AS
5lWzaFJghzwgTrH0wrwcwHhnFjMgyKC/BLdVQ3lTa8fAQdWVIB6J1HkxBoAlhWehTucHKCn2kSo0
Eoxp9frNQbNKJCKljViTV2gk6NQz4P4slrVA3rRBq8ZfU6hBYFBnAbfwPdAlDumo8amv9JGMqism
L50fteRc0Hfl4w3+WnZnwU9K56cCTbuz4HMGg5Wupk7hvysfhwKpXuH7wDFsVubNqVhbMuAO/Vu8
IPn6ZgiSFislx19jxMyqej9kC98b3ePz9lSwBZkFimKx4prF6GZSnZBvxeisY4R3XEMJYVw+ATCU
2BtsLJgwFbN4UuVtkCZeW/oS7crbIL04bbnRrbGOETIeHxn4FgwWnbcTnwEUuH60fMUfns8Cjjvc
lVL1LTL6GFhrJu8W+/F359Ervwjrw0SJpbB6GbXyRNiMr/dSL8KWJ8IS1sHT0hk8vE3qsSRgXSq9
ntCpPNEfxvHIyc4aiGBSLYfA9p3q9DXpVtnOGtcx0kqQLdIFEQKVreSYII011SOd4v0a5hFWZ021
XW7PM0GG8LanVMcFzyzDFoCfmuOCR/TGajZoyhxOSlhnMs4c4fOkkhkfsPMi6zOzGL2HB9XTurZ3
0XtohdZHSF4RWlI9b5U8s37COsAs03hthZYUH7OQWRP9QXb7utP90jJ8Bkwy42bBToH+QLXzGkKw
UzjtmcmilSAbwuoVvj30pOPphtcSuKBWeighvNusTIu5r/3JwzpWolh2OmSP6Y1jWCpOkPZLyMJL
O3KGER7XVng1dF5IDQkCKAGDC/eoh0I+7yrDeFsKJaQI08PSag6VA4u3TNLlyj6vTWd6eJiTt61k
Pc2QmsRKtdQx79o4Qdq2wGIaeO7JyZvH4FBcNUMLftgCQSIAgNfkPk7baSJtlA9rg7w1MFViQYKo
QXHBT4nNBwvaTTR1CSfVBGZZS2Ud5s23wiVLDY7PamV8eZ8yTlshvR8mZTENfAEt4VmYIHHeYAu5
QJDIAJ2nm8eSBIm9qpfeNzVemLg6W79BJ8hbhYg765z9MMgb3LIrmPNMEBbTSL581F/DtqI36LcG
/VZjbakQpCG1ePPheTo6wXVVZ4w85DRldVFrsWlj8ZYC5coIycuqLDjHvcZml1VZANfDc8EDMQgS
cIc5HbLdlS3QIa1kp0O2WiW6UorT+mELdKVw/CTHa4MgMfjivJq9KkuJYlLq4VlgVRbjeI4LWzUb
BAn6KDlNvpdbVdaJSo4PIKuyGMfrsedQ2QQE7mrR+GuQNwGesFh6geaB/qgIQy5AZfGSYNEcrq2l
Do1kJblT78LLsAigW9UWu1LEkjAKdcTeYJPOS4I9xy5og1hCbw1vKDcsqbxLOD64K43F0EmS26mP
3jeIZYJT4079djebYXnooxb7b6zxInyVGtOtp6MMaJJYDUK3HVrhhsQuaBuMhAxvs7bCMjpmFVyt
H4bBBWUBdrw2loLZLLANjVHP+cjwgNpb/faNGi97t4pvAtj6xKY1fVmfjt6avqxP3Mwzgnfda34N
25CppNe95tvXtvqQDn/my2mvTyf0hMNXJdht2FYfAiwJqT0V4PMWZjIU5nusdPOQc4HDz+SlDoem
GR8IQh1O29fXtW3J0HYM2L5W4y1Qhxe9oouvtfnrWETN0DRupxvdBlyLDIexx8xakqGPa1uToY8E
mdfGO8BfvNM1GfrIrDUZ+kjeNRn6PGmZYjlGzCzWrpjUs/dHsFOFN85Q8EqQHTUzsGypO7H0X4OE
FCj6/oG81Lqdlnn9mo9dMMvJCHoKJUQGozRYYQ3PAktcMLRqrGrYk0sL3JURbgG7PGrq5x2w50nZ
uovF48PCSeEB4gCmyy4/sn4mQ0e+8Nrz2oRFUHAXnX7zeI33ZIEws4WsZ12N8HKlxDtlrRQ4liTe
aWVtqmVxzPIAtuVjponc2jyAnXA4DSfkW1Ci2cFKNHHS6wImzJnCCTzv8AZ0g0YS4Kce615eUipQ
cqXHazOWjqimHBJEE0tHahUNVQ3hMNy25rTlu3vZrMJNTvduV54SU9K9lHhtwvtCfdQWaiT4ztjp
sA/6TZXBaniCqyD5Oh925qJX2STeaWW+Q68E9yNPmTNNUq9I7zN5mTPFoW8W7xSCVNik58PaRj6K
Wamx+VAIEjCbennzXGB7ypSrWThpTYzSlLOc+/lrQEOM0pzXip6FvOYZpWlawlM/4bD27j2ud3DY
4NbEp37CYSjVFqtBduYCS6tTNRvkZLPLJE1j08bOXBVK1RnxbRjLubEx+7C2RiPOm2ehcuAlpVRK
chZwC0r02QQwOy7sOJddbq6LjgEXDO5K6iIt5gIzsKMP7/duDbyYX8PgmPXMmc5iYQvJS5xrmUWj
4U7hRkEs4YfEO2UyNEMXekO5pS8plqI5PllNGdPW0mOXgA28oAqLpvDIsIEXew21t1v4nHB8fzi+
idf602GBv/C6kvMa5n0G1pEyMn5mmfsTKVa81p9IkWfFRb2yzP1JZWVws3Uwa93C1pEB/nOtPZ11
ff3p6OVZcQGPa12b9xnyrLjIV4z3mW6z4kL0jEQ9E4RVqZCjnOK1tfK6khMQhFeZvlot3IZ5LNnt
1WrhNezdVaZfrRZua9uAGPtvQjHUeG1mDDHZiej709HjHaUmMEZOQjYgxrYqUA4rQb597UXSu61/
67DQU7l+VrbsvB2jlFn/fBu2X1cp7CA574jdhu2HpTPwNZ2K+9e2w8I7C7R5t0F7BMQY9po3laMp
gRC0tpmZiKYEQmipT3G8D9tCG/DC2Zi1xWsDQuDNUV33uTWAY5uWkac43ifdUvjpwOkczHNEO2Wm
HyumpxsOY/PFNhtyRTsdbL4IlLMyftNEPCppzPDBfZg/nzwqMKA9h3Tjrb9actOVvNuJYnHSYL4p
3ALbtIAaozkubB3xplDacCL+rj057HGWkCACj+2rbXZwYESh6OGDJzfpdgEPkIkN22u8U2b6xXIZ
Md14AQ+Ao33gAlvdwd2V+MiwTUuBZ6cfuDDgm1bVFgsSLAu7O8+y5uBrjFkA9M1iuIC8WNfRVWYx
XCCWbNPClm22Trr1Ecls9lnVydu7Ou808+ThAWRoA2q1OMW1RRngCkhLaiMmCGy85twk5uksBx+l
jnWYT4LO0MaVH7pv4U1o4ys/dF+bb/rSxq/ET7QFxiyuxE/ELMYsrsRPtFM2Vhk2rx/chokPuxiz
TVV6bNjYTbxInncdg7XNOu8utWh4AGcKX0qrHyYViGW3IR8mLZS3ZP4A+q7YBe7dkOQO4N5NnM1l
dQaYAp7OOm+srMbnVCvAIUS4O4dgK+BmrjTPyFG0NsYsrsRPYE8ZsxC4BMMRxAdKRp3hUa97txQ+
mAX712OFD+Vx1C7qjsyewocXqKrO7O6NVdhMgl3Hwy0wtDFaV+9I+cbe9LcAoJwR3/uvVD5c0NVp
y62xCsGJztxJsNOrHHyW2gQ6BCbhYCBN41NfoZESo/bxqQcaOrLkmbaMyMsnXGApncLfM/0wbao5
x4qrQt7UKkx+vDY204TrYxaTl/dX2Yk2lt4KQYJzoursqU9Fp9mIVjR289hYBWizfCBvm+kfAoHw
LDQWTVZLKTYfM+me08yd3Nfm6waYJWpNLOYCC7hxTGdo4zYs/8kPM16vmqGNaKeVb9rk4s+C3wJz
81n0g987c/OtzJt10U5nAbd5ILA1HWcyCWzo8QFsg7evAUtjMNZgKPkMgifv1nScXf/F8ltB+kY3
8beL/SYuLU8U4yVuHOZLAZYn2cipzzjgaXBfwzzKzQyMjnnj+T5sQ7nsVQoouQ7bENatBj36Gg5L
VmllHeYPMpsywC++DEd5UguZ7YUY/u/x2ph073p5vM90YzadGbO8DNtvIAtvD9be4rX19Kthyn1t
7xqIMpEr8TCWOtXzWmC0tlsQJ+KCzexmknXYBhJZqs7euPGkTLrblRoMJp0XlQucTzfp1tK985Jh
GSWelMqZ3cRHSLeZm4e32FZm7Y1m+uwQ3TUmCK/NQMrN4mGV/eTgDGgob7PPaOtWJP4aACxc++SO
895BBkiBHpnEXOisqkxFPxBksKoS58tiZrGB6JDqpHdvR8ouFVprCSctUFzcmD9ZvpaafUZ7b6WF
k85e7fBULFYO7DPKgLfXlh6ZCl8GkzZSyFP2aodvxB7L4dqK8ZJh97p3u8/MnhdlOKW60a1WdgtL
2QnS9hwWnIFamxekLTcPH5UFPrG2ZFP12cOuxVuA+f7q/R1xYShOfa85FiSQgiE17bG2LAbpnW+L
hDudfUahtzSHR0YTu9P14hXXdu2Z1w/OJl+BXZi5eWmzyVFAEBVlSrWOmAtaeP3Aeuoh3WYKX86M
wv1rG84tx9DNGO04l03s4EY5gmztSAEoxJI68+ELAlqBu3J274q2ADXIru8tx+RlRbto8mZ3y83P
1uPi6LbFLoyXtVopH9ZmsIA2ZsVhcE557RkaST+4Ute15+KM0d5ndF57Vqffdpx7XnuWFJ6FCkMJ
QReLlWots0Xd5ltuuXn2nuvFacst6c7MQh/VqZo9hc+e4mysElpAaDa+FNRr7L9NnCvWc3zqeTu6
4vw5Y7RBdd6OLs28S7Cl8Nk2eFi1mFmshmwpuVO/p/DZET81W52fPYXPtsFjSKxDGqshAdS9S/AW
DufkXYIthQ8LqCVJDASua8/Z4nPKdqQG+cgxliEcBrZWr2q2TD/LgABzU7yFWo7Z8TOHB3C+wWVN
x1s373Omv79d7DdBYn3EHbdM/21YlOm/Dwsy/fdJg0z//WtBpv8+LMj03ycNMv33rwWZ/ohut0x/
RJBbpj9a2y3THxHklum/Dwsy/bdhUab/vrYg0x+t7Zbpv38tyPTfhwWZ/mALM32pTA+va/MVxrzo
UkQ1Ju+8gXy9OBWQd95A5iO2K+v/sKE/llynkWMJkRlMA876sFNWZhftbd3plgxtrNbilYGYvLzo
UnrKOZ4U6I9PF3UJz8JEfzBD9mFtQH8DiiS7tflOWzavepYh4RauG8g1xUJeMou60oXoH7lwXlQW
dad+g068qJzP9hDRpLyoPABiUryFwhLY1sp6ZHxPhHlRuemVLn88p0X5zIsMfwC3ymy2A4ZNi/Vb
gXfUDADLwrPA5yPY+8/rXncA+S6E2RcmeiaIsUH1uPK5z+RlO3/e2XcE2Uqu++yPLCVkPWHdV3/k
YFJNdapoXY/z1s0qGegms296IEia6ZKV2Tc9MG1fF5X7h7VdF5WdRtrAznVRefT4a3zqNtt8oiFa
G9EfHFkrIU8n+mPxfovpBnuar9uq0aQs4E6lWawcZjK06mwYff+aL3xn11TisBQeGUjkwULO8oEL
fBEXON8+yJux91+3GktITez9Z6mvzNrSl0R/AB8pJgjRH1BukRoe54n+qqnGB5BNrxjuSyOUt5nl
5EXwHE+qEMsCheOkd7uBzPo57Y4geWt61cF62o+YvNBvJfXRcihvlXVlY2hvMUFYV9aSlnVtvotB
5RsCRYq5YRv6Y01Iax/O6UR/TKL0UN5mMvTqOhcQhOhPcu4lhfLGxygqvLwaa3I+rcx7tD02H4R1
QyU76fVdDFjAbRC3JiFBJvobbbbquJN3e1q5Qt5G8872m1cm6Ps4P2TL584OMpsx2i8qM0cvVwb2
UdU01pVZqRof59Zn8r05b3BbG6/MseLGCbnPg8+7cHwOOZSQzktuo0qKJ+1sDAqqyFvn53uvTOxM
/ibO7b9+tl0t5p06uFF1GbbDYb73ADxRlmEbwmLRyJBLe/QnlTWLdAtAv61re1OmC/fiKlLqTwK5
4tzntUG8O2BHS+va/H1m4Fxr52O992EembId8y9fqz+pBTayfzlR/UlucwP6M2uWY4IsOPfXsK0/
NYtGtEtfv7b1p14A7GtYmL58DduQ6b2w9rWF7Z0Mvrz3FTt6DfNgh3qy1OLWtqcvlc+OlrrudMOS
jJIxQ7jSbatKpZ6Eq1VqyKwzfZkvXfS8NkbJKpa2Sogvm5wAdtaxrVvY3slo059pJZQ3eMTURWWM
eAts5wfPIufwyMgwvuPXisY7vRoo2zpsK5tkYS3oYSM8WQSwZizZC9d25iXBixaqGngVwLml9vg4
T2Sq1vXDpESmCT67m9TDOiDTwY3G+u3KS5o7WRvkvPKS3a1ta6FVmBHLTuFvwzobdveS17XtvbGm
vFmroVgy4Qhod2XVn7fAW74t5eF26qG6Ud5GSTU8p7PpFcCujJC8zCSy17XjwrvXlwVIPUtIEJXZ
hCj7nW6ZxNmESBxPN4SlbEIkXr/tl4GpuIq6I7M3vWrztqrEalBb4m3VOiSelCDxeg4rOFmzYhZ+
9icu8JYvdLTXSBuWNKZWzWmkbW0shYUv7jTSBk+S8LZq8/K2ob80u9L3t5r847PrsxnWdT/8/vP1
2lX58PPmt+zRoshsdu+27P0WvnCYB98+CgWPmcd6dTzfz3W0ZaiDE5Xy4cCzF/rzph/d0evnacSG
vdJZKzVprMyIfYH0couV2dWka2iszM4mXdB5IzxGxL5sti8WC9fZpMu7pVvPal6WmrXi8aTsnqrQ
Zj1mL1OazaTFvgn7Qhv0o5OCraETu6fCQmls7hrbogIoOS5sX2OFr+lV5fRoihtrzWDtnGHfU5ps
q5WHM+zbY4dMaRZQQN+R93N2Ud+a8G+iLnuGU/fsoj2p2DW7+GvY1kooG7uFXHXH9iSQs6HTyFcQ
y54Oy8wuNkmnN2dPhM1lpnHk9COed7qkDZ8nZRAL3zo1sT3Jxv11m2in89kaE7F4C4RTFWpm3emO
uvhOk13VK89rYwnqAO5yk27dkmE24XqPHk+6XI60J7Uwn0Qc0IsrTzdks1yOfKTbiuEe1zaTkNeb
fcFO+YghPMPh17Y1dGIgvJnWcKcEZxmAxLF+S2neHsG5D/Nw6vYITiCWUvksulpZCbKhLl6O7CXV
lfX+GsG8HKk1uSOzZxcZcWzmBOltCSr8eNWYbkPYpTCnDzxlrjL31BzdNqgHn6WNPGIdwofSmsKT
15D1rFTtBkvqlMNWqVrJ+lTjUz+hHm8dayiWfE9tFtb0kG6zBBW6t45Qh0yoBzEaJSTvhHpwutTJ
m3/rrc5HSXL+QDe+ldNEnPnYk5CVj995xZX9pIOp4GK9hvLGNsgVwpti/TbbIKcsReJJjalgKMMR
coF9nxq0W7NQv82+T0nNJKSbZpZBweGu4drmHUrQuOWQWfMRHFZjxzZL4aiUhPPsdK/fKRwVrTK8
PfXD+AjOBL/rMF8NCkM5WtocjA3q8bpPFich7+5QplHmU0T3r/lcJd/KqTW7c7oh6U74DvfYSa9P
BfMN+9Guqu1nLvBxejC1xVuYj9PznZlYhxARwp3tXodsRaMd/nMbZvHX4PEmG1fi5ZEg7PvEBv/F
MWuDbthpwh5ieSPCqnCipYeKi2/lDPuCJ89fq7N1leQWnvraZuuqUhxB/ONBbbDOWt0W9rQh+95n
ldj5qZ1974vXvVuFL98TxPFKsfPDtOHg46mxdWbfJz6M6c+CBzssGoUgZbeFN0Wj0r7u2z3ulFct
i37dt3vcKYtG1b7u2z2erFYK7xMnjcWysexLtDkLuOE1Pjw60vBC/uYO5WxV2GO68eHRllJPMUFY
NFrg1uZ4bY2pufHJG2x8drBYyeOdkH8GiSO/E5nvgcT82DUkJ7ZXHeeFsPx4nZSvQgN0nAb39rUN
S95AYn68EbuAxNew7ZlRvm1a4fzoOuzNIzgmtUw9mR/v/s4S1NTmayPR2piaq/3sH3Ab5uHwxJJ2
lmgFk7IcPtmp6oNJ51s5aYyVvDuWBLOGzXbx96/5dOtMzaXTAwnoNrv+ylkNmh+v4eYBnrKCvcUS
wqBQqdnv1KOYWedexDHrbddf1oivO33b9bfRGwgFSVjnXrpaCgmyXEB83ulyAfGZ9bODDsNfHya9
Y8nXMF+9MhvtDJB3ZZavXpkvpQLmasx6vn+tms/i7mfWC5/3gm//iSC9Q/XoeZ84YD1MJGFYjs8C
E318iKHErJ8vpc7+qsuw77YjO9M/G4W+qU4Bh/3P/v3H/wN6uz4qZW5kc3RyZWFtCmVuZG9iagoz
NSAwIG9iago8PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoMSAxNjc4MCAvTGVuZ3RoIDYy
MDcgPj4Kc3RyZWFtCnic7VoJdFzVef7fvTOSLI2MbJwgLIOuPHiXJeOF2MKAbC1IXmVLdiTDIXqa
edI8GM0Ms0i2Co6AQIxY4rhsSUjqUFL25JmQ1qGUOi1NCAlJSihQ6uQYkhIKhgYiG2yNPP3ufW9G
o8VsaXLaczzj/73//fffl3vfHJk0IiqgfuK0yNetR1L/Mvh7oskvEbmYrycuyupmxojO/AKRRp2R
ru5f3fitB4mmHiRyJ7qCOzq/Lb6O57lzoWV1wND9v9628++BPwE4LwBC/r/nQRcNAs4JdMe3v/D0
tT+AruVEhXuDYZ9OdOgXRNOhv/Debn17xD03J4X1YvCLkN5tnGE92Q39QfggIlEjcuO2544TFbeA
p5Kk7+7XOt+so+2fO23lESrJI/nZ9wPj7+T9JxveLBjccKy/8OlJ0/A4iZiSkKFQrv9Yv3bp5LzB
DcO/K3zaoWc+PCApuD5CefQVyodkEVXTZojWuxPkJuYi5Awf1m+DtpnaWAVV8xtoBn+YFvOnwP80
TdGeo2pAOc+nKC+nqBaiJraNLtMC1MSLaLqrGOuDlM8tWsMfpxbXUmrhl1MV/xnuZ9N5/Ancn6EW
ya9kbqNq9gR03UYXsAep2n0HtbBzYBe65J3dDRzZ5TNg/w06n38az4OAJHwC3X0h/H0afBJ20UXK
55fhQzu53fuh77eAG2hVzlF1r86tp+r8+VSdk4fnfMBKOlfS05CziKa5ArgTbZX3vFBmbZIDtvzr
tAr4eZInW34CqAOQA4omdUodSvYpOk/SXG/Ya44+xZ/7PGILDt1FdHxAAjuaEu76lGDXpm53taRu
JxrSbTh+E+7XS9DeTx4gGl5HdKJf0j39sNdv63Xthm7Ez+8F/jrwS+lCl6VyWe32gLYHOaw9/g7r
GP4Zax3epR1I/p61n5jKZuC5Z/iwduvxx4neL7cheTXseACHgb+Bux+w/+T0IcxYEr1/9KFsnL2b
KuGUms/eSJ3Onj+RdFenStxNqfnuqtQ098wTSXZPajFvSc3my1P57gdTs923pvK1J1Nf5PNTu9gz
yZddx5Mv80OpqpylqSrE+zB0Y96H4MPRCno8iVlMNuD5AaL3fkR0bDLdkLybtidvpaZkJ9b+FvR7
INcHfJEd1/+GjqE3RsPxxaPhvT2jQdYvDUeOjYahO0bD++eNhqHF2aCdnZys1SbLtA3J+do9ya/z
aSe49mjySywneYR2D3Vr9cmZsPOednmyDXVpZC3DK1n58OnanuTp2gDi2T2UoONDOzJ6zklO+0h6
1g2fz86x9SAPGT1s9fBGVju8SftF8iCfeaKSieGF7KvD92lPJAvYpUNztRPDBdoLx7vZ28ND7NDw
W9qh5H3pOVM9OzKDav4yc/PB81Y90ayNmTHFixlTs562IXnH6KO0npOsK+BPpdAnQz8H/CPix/kg
5zb5KX48FZUgcZum6GTzSFoGGrKfXUHI7U3tVPBcao+CjtTXMPvb0IPFdr/J3jm6FXiRrVfShl6A
/CO8CPzXpm5ix1M78XwaD6V2SR7bz+RTqNl3cEffDufww6nLJEgctPscOGrzSNp4cLVCpj91t4Ld
sCVBh393p/7q5P4lbd+KIbM9dY3j2/3w827c907omwU71kfxTebvJP7dAN9ucPL3R/h3crmJ6bwn
tQf7bTH2eLnvgmfoRcB/QhdmJvlK+u6+IXUiG3Ja6XIJBZdRUf5zVOQ+iHOrATr2YwayIX1m3YX1
d6m6EGekZyCrL3djFiSsVOdctfufRoPsaQmwswx2lhVOd+QZ7ZbgGqTLJLijoAHyajFLsOW61gZ3
ldIrZ4jG+ez4mPEpy/5kvNbkfYOK85PIzcjZWPpRzt3cxz7WuTuKNurcfQnn7sAn3hNskLV9XuJ2
3djN6XM5uQI9cNCu93t4XzyKc/PIr/HauMG+p8+E9N6f3uft/dydSzgzU7MAB10l1OB6O5VyvU13
urdQG+BOibuuw/MB+5lNpu/wR2mpos+gO3PmKl61ruQOZOS2QG6+g+fnHKdi3PMUXEde9j36DuQb
AddA32rcFUD/aQ5+jfZtCaknsa5w2LpG0tPrij+h5FdATuD5KuDTYTMP98kSB8xmeCNwYVdky+l7
iHElL6Mv475GAvsxrcrV6QzX72gL3gnbcjsQx/Xk1VppgwToV8CX0PXsMPqhgCqUvQdpJ2JaLfXL
mFgh3Q99JmAhbK2DLxqbRv+A543sYdrgjsD+IM3H2i3I+VNuov+QNJ5KHZG6XQ9RFDqnA4STm2v4
+6kU20q9oF0PuIK9qXTfkjOf4g5Ugu8Su2bjAbGQrKOqVRYgV5sBl7LJqd8CUuDR0jWcANaotSxw
6ij74hqnhuMgZw81Ztc1DajnO6hlGPfHAM9k1/IkcFU2yJo6PTOdb9X2ul7TsFeekHvnmrwexNZP
L/Gj9Muc1XQA8CJm717tMQrxrfQa4H38RrgZ+80f2CK6kTfQAO734vlu11O0CusPuu6gxwCPAqKA
A4BnAC8AvgV4QPJLWej9sZtpcrZ/BfojuYfpeX6ALKkL9xdcd9FrOBeSuK/mp2mfwf3H4L09dxpZ
kp5bnEpmdMEfG7Q5ss9lT7JPk19rONGHui/J0WmVq5BWslY6iN9HfvdjgCg15dTQYzk/B+ANMWuf
Hgvj3x+Op2pwzrlcc9B/l2A/dfZ0nMtVkiZ/mjm/6qbhty0wbToghzI/9TTGJM/oj/zVR/9fPp/Q
Uxd7Hdd2/D50k6DP0156gVLauVqzpmvbtZ3aHvYj9jI7yJ+YtHmS4eEej6fIM9ezxLPCU+tp8Kz3
bPW0eXyesOfzolAUiWliujhbzBSzxSJRJWpFXNwvHi6bOXPqzDNn/TSF3/KwsZe+SS/CwmatHRau
hoUfOhY2TfJ7NI/bM9kz1TPfs8xzgafes8azxdPqafd0eraLAlg4XRSLGUIoCysmtEDYpQjdho+2
ElAIJJx6LlV47J+PfXvw3MFFg5WDFYMLB/FLY3DO4OzB0sGfAJt69N+IfjP1NwvttPzmzFfjuOa8
+uKroVfeeeWWV5Ycuu3gneiIdu1s6JwBuFwL4urARB/stmnsMnVtt6+aH7/dJRaYqIz8DF7Mz2Sd
fDov4TP4WfxsXsoFL+MzuZefw2fx2XwOn8vn8fl8AS/nC3kFr+SL+Ll8MV/Cl/JlrIsFmMkuZ1ew
IOtmIRZmEXYli7IYi7ME62G9bDvbwfrYX7Cr2NVsJ/s86+fn8c/w5XwFr2LXsGvZdewL7Hp2A/si
28VuZAPsJnYzu4Xdyr7EdrMvsz3sL9lt7HZ2B7uT3cW+wr7KvsbP5yv5BfxCdjf8r2dvssPsLfY2
+2/2e/YOe5f9gQ2yI+woe4+9z46x42yIJdkwO8FSnLjGGefcxd08h+fyPD6J1/J8XsA9vJBP5qfx
Ij6F3cceZd9iFruffZf9NW/g66iTuihAJl1OV1CQenCiNLMWDLGfGewB9iD7BnuIPcz2sm+ye9gj
7G/YPqLqqk1NGzesX7d2TWPDxfV1tTWrV1VfdOEFK8+vWrH8M+ctq6xYWD539qxzvDNLi6dNKTqt
sCB/Ul5ujtvFmUbldd76dmHNbrdcs70NDQvls1cHQc8itFsCpPrRPJZoV2xiNGc1ODvHcFbbnNUZ
Tq1IrKSVC8tFnVdYz9Z6xX5t26ZW4LfUetuE9ZbC1yvcNVs9FOKhrAwSoq44UCssrV3UWfU9gYG6
9lro21eQX+OtMfIXltO+/AKgBcCsud7IPm3uhZpC2Ny6qn2M8gqlWYvPqtP9VtOm1rrakrKyNkWj
GqXLyqmxcpUuYUqf6Saxr/zAwM37i6ijfYHH7/Xrl7ZaXIfQAK8bGPiiNWWBNc9ba83r+20xQjas
cm9tnbXAC2VrN2cMaJZ7VpFXDBwhOO996/Boiu5QcmYVHSGJyhAzacJ6Gif4Bg8RX1mZ9OWm/dXU
gQerf1Or/Syoo+RRqq5c0GaxdrlyIL3yqS1ypT+9khFv95bJUtW1O/96AsVWf4dYWI7sq3+z8A/r
wuKz2zt8AXnXjQFvba2dt5ZWq7oWSLXuxFq3b1El+PV2BGHKNGxqtSq9EWuad7XNAIKQNTCbW5WI
I2ZNq7Go3edIWZV1tdIvUTfQXms7KHV5N7V+n5akDu1bKkq+u4SWUpv0w/p0DYoyu26g1d9plbaX
+NGfnaK1pMyqbkP62rytRpuskrfImncI5sqURSWF2MZwp5ll5Lmz8kQrK+FtslogiHpcvKtXYqEI
5VKPsqKrV4pWrYTSbLDicEhslB488Fk1DXKJS9GahpKytjL78wEulTg+uWdZeVm6ikDI+GTbOalr
Nrd0aJ6oM2qzHByl1O046Gib2E8mc+EYhkSeLGdDeonPwuSCxqBGkWQVi4VFTaLVa3jbvOih6qZW
GZvMtarv2mbv2k3bWlW1nS5pGfVkry/PrDlY+isG8rxrmwckj9dZIjHQaBGarxpjtnzqUptaj31q
YKDeK+oH2gf0/an+Dq8o8g7sW7t2IFLXLp1sRcL3px6/qcSqv7nNKmoPaFVSv7fRP+Btbl2JNMjD
tDo2yTWt9DSXKC10FZfmuspKrwycUXr1VWWlZqCsdO9Obe9V2t6AluOeXep2zS6dzE4v5aystJJp
kXBZqacAaFirLNCm0LTS3p6y0jOKl5RWbtcqp2uVZ2qVPVplsSbJhr+sVCMw++WfArCFrX70jCna
LmHN3DTg3W5Vb96+L1/swu60Zfs+pq22+IyyMs2aupbWtqy2Ttdwb15tsZpWWmut3LzWmtR0Ses+
Tbu1rWTtfm13NgG7wq79GrVYrl37GW5Ta7Zd0rpfO1MuXl/yfdI0sta2X39Lm9V0luVf29xq9Z/V
Zi2WyO6z2igWW7BgQUx+1B2wwCYssD/EX+fv4rfrYbwn7aWn6X66CrBdUa5NWaAEXD907zwxQIFj
/eTHCXuILz3xKjVphz7ZC+Cf6uNucDfB65fwtncPfYFeRwwWpRTlRvrX3FdxJf5L/uaJBPldnwPH
/fR1up+97IivPgWn4BScglNwCk7BKTgFp+AUnIJT8H8AmPz/bryfv06ccml6dYGbT3JRrkYuLF30
7EXPapXPFv362XMXLZlSNmVW2ZSyfk7D/YxO4Odtsrhf/c2BaIa2NfMHmMVEmf+Pl4snG2fAVzg4
p5lU7eCuLB43FVKHg+dk0fPoUxR28Em0EL8wbTyf7qR9Dl5ApVqDg3uoVuty8MKc07WHHHwyLcp9
Uv7VyDUJT/7ctx1co8l5mx2cAW93cE61eSEHd2XxuGl63qMOnpNFz6P5eT918Em0Le+og+drFZOa
HLyALszf6eAe2pX/hIMXemYX1Dr4ZGo/4/IHxOJFi5aL9aYvGo6FO+OiJhyNhKN63AyHKsSqYFBE
za5APCaiRsyI9hj+iov1RFzvNjcbXYmgHl0fDoXjOyKGaOzWu8xQl1goHAbhcGw1ojEoE8sqVizS
x7E3hnwVm/WuQCKkxwNiTTgWMMXcFslRa0YNXzwcnVcuNnZfoUdFc8AI+Y20djMm9JDYGDFCirsz
HIrjEhXxAJSH/KZPxHxRMxJf2GIEE12JCtEYlzIdeszwC7izJWT6wn6jXPggqZuhmGiJJgylK5yI
B82QIQ34RUCHkGGEhN+ImV0hCEsriZghsKCLLY3KdEUgHo9UVVb29vZWdDsxmnaIFb5wd+WHLDdF
w/6ELx5rRopNnxGrlH7U2gajzYFwrw9ub9jY0ljfWLOqpXHjBrGxXqxrrKnb0FwnVl28ua5ufd2G
FpGf3xJAjFJ7p+4zZLwyHZFoOGJE4ztEuFNMWAAVqIkiy7A6dogd4YSU9YV7jCgCTiDtdmLjRrQ7
JtXoIgg/QzILXVHD6DaQAtEGsYDegwR2yIxCMj7KHdlfvXrUEIYJZVHhVxUO7hCd0XD3eM9kMcNd
hmLthcSIvN+MxaNmRyIOE3A3HDKkT9JB5ZXPMGITxVqRTlBGkWwi0aMHE3pHUBY0ZsQnFtwSChqx
mEqMihDxqtSYoXgYKmIRw2d2oufGZUV0RfVQXIYjZXW/35STpafHqlyS7XZSEYxxLmh2mzJIGFEs
IZGIyIdOEz7MXTZP9IajV8TialpVXypt4d6QiCQ6giaGCYYhademW98hEBjqGtkhszuSxtGWZZ4a
O0eC1UM7xJUJIyatyK5AgqMhJ6Roen+Q3LFAOBH0Y6voMY3ekXqMyofkQ9kNROC3yyr5MkHDLTWQ
vvj4hpAB6o73nROrl65fbGBokGEzBIFulZuqfDl5clBjct7y8+uhKi1sN7UcgURM7zIylYkEDUyd
6DFjJroCkfYaHQI4zMVthRNPenewUhIrHf0VkpKfv87sM0J9HYYfjIlQFzYUjJXYkIj34SmGjASg
uNPEqIVEswkbiU5wYM9F93/W6IhhZoyPb7VJ+h0JJmLCPycrH5kqojcFOlv4o2E5//45ibiJvrEb
yrDXRpU+HkVpEkYQC+Wix0iYwPrkQiwRjAODa6hi7JM5q0d1uXfI+qWr5zPvDAlsHlGfjh1YBMPY
T26NdpshIP70vJu62KGWsE8hkfZSIhYut4tniJAMIRqWfplhDK8wgjKpwD6Bl3AOmwVC9pt9SIvp
pCUeT+hBU8hNQe5sZjxuynxmvNDhhxlEgtKehFVD6cEgKiMF+vrCH9ebDz11IJTm12OR7fQACbzv
LMJ3ObD1ZJKPonjriQE6KQ5aDbAoRdRVB8UEFqIKrKyiIL4CdFP9NT0OKflk4G7g3oOrH5wXQy6B
VZ26wbkZ1C48B/EchUWpLYzVHbBhQL4RXDo4TNC78LwQMFqDGKNjq7IWczwTtAw2VyAi/SNob8Td
B/7NihqAzpCKMoC1NSoPAWVxLrVkdNSCIqP0gU9mZR6Vg7oRmq9Q/ghqhpQBTX5cx/puqizpytON
SmMoS3en8jjuYFJXXOmyPfWr+gho8KmsR7C6ENIGMpFQGalQnPGMnQ5Yiqk6CCc7W3CVWsLKO+m5
z7Gpq6xIqRZoT2B1xK+wiiGoOIxMBFJrQFmQlgwVi1B6Y6onQo7ldCwJ5YtwJHTlTWNW1BWqi+Kw
WUWV+PaqbwUyN7qO5qgqVqgIusH/x0k3qc73w0uf6uVmp4tltmRElZl81I6KMKrqHYYtn5PtDahs
CyKrB9RgTiS+EVRZ8Xpc1yl6HSjNuMpJuhgdWIfvekVtAS0f3xbVfTHVBbblTljwqRym6XZ3RJTv
EeWN5BVqfsXHmICRiprOJKer1aH07VA9kLYrc9ajrNkVTjjdnt2xcfXcrfhtb2TFg04+Q5le6FJa
DHAaThcIanOsye7qcTqwI9Ojts34B2QnvX/1qomUFEPFFXB89GfNcFDF16ky2P2RcpaezDCejCyt
vY6Niez7la9xNbcdaprsKDqcaoWcKDuzMjiSK5/K0EgmP8zHinEdNN4jMzOFPbjKHUSHN8HMhMZU
bB/HotxbgsrPWFbHjNTQru9I15jqOex4EVN6faB2Ovvch/eKUBRd4enqpO3qsOFXFbFPBn3caVWe
4c7enUZq8MGZC6qdxMxU0o5kREtIPUUyKzIqOw9zcUbNU/0iO+kK1RcjZ+vIfjnim9xdQmrOE6pG
pnMy2RHbNrPnRlZG9pVdMXteI06npft/bDd+UMzpfmpUuRlfWVkBqf1KdW7EMrGk9wq7g6Pq7Mmu
UpTGvj+kdcfUnirPeD/ZbxVyJzbg0UTzcfL+SOuzp91wauAfNa1pfeMrbWdr5IT0KZ0fvkOkK6iP
yf3E0/1BO6HM+sXq2VCdHnTmxrbQndU3VeBMn3npEzWWOd+knnrHq7GWs3fq9Ckge0pX+9v4mYmo
Kdcd6R7VM6azVyScndBAXwmHbkcXH+XhxznTu2GvMsNZOcb/igyPjHEd1vrUWp96J/E7GhPqajhT
ace4QXV+n7MWc3ok4HjcqST9jkyz6j6h3uY6HR0xZy+TEX9WRRxzzhnjzxJrUybfEbV/x9RkzzlJ
f4yfRd2ZkaBztvjVGZg+/6WmhJK295vsHcoYJXfyqY+rnpVTIzmCjkS56hoDNNOh9WUkYmrm4w7N
zlrUmc4/Z2Z15Xn6vSM9f2NnT55Wf1AZ0Z2s+pSU35nwsPN+8l+K31S+xrLWR853U8ntyJLyO93l
UzvhiFRC7VPloybPULlKVyGqzptY5uwTTg8bavf4rDObxpg940+XS8PZdYxMlf1qSu1uMcd0S1x1
i650isybQvqdzVTrZqY/x+dCd/JhqmjtjI/OSThrh9JVB85xZt220Idv+E+emz/+t45taax+Xb1J
bf8fkJ7BZ2VuZHN0cmVhbQplbmRvYmoKMzYgMCBvYmoKPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUg
L0xlbmd0aCAyMjQgPj4Kc3RyZWFtCnicXZBBT8QgEIXv/Io57h420JropWmi66WHVWP1B1CYVhI7
kCk99N8L2NTEAySP977JY+S1e+7IRZBv7E2PEUZHlnHxKxuEASdHoqrBOhN3VW4z6yBkgvttiTh3
NHrRNADyPblL5A1Oj9YPeBbylS2yowlOn9c+6X4N4RtnpAhKtC1YHNOkmw4vekaQBbt0NvkubpfE
/CU+toBQF139tjHe4hK0QdY0oWiUUlULjbq7f2gFkv3n79Qwmi/NR7pW6qmk9/fM5f8dpczKnPqU
JZQiuYIjPPYUfMhUPj8jQG8CZW5kc3RyZWFtCmVuZG9iagozNyAwIG9iago8PCAvRmlsdGVyIC9G
bGF0ZURlY29kZSAvTGVuZ3RoMSA2MDE4OCAvTGVuZ3RoIDMzMzY5ID4+CnN0cmVhbQp4nOy9d2AU
1Ro4+p0zs30323vvSXY3vUJCNiQBAYEgNUAggEgRhAj2AhZEAwqKIgoKNhQVCQE0BBRU7KKoKCpc
QS8iFhQVuSpJ9n1ndhOKet/9vff+e8zwnT5nznz9OzMbgACACuYDB7U1vauHrXvmwrEAX54A4E7U
9L6wyhnpwPrXRwFEBZNmTpg96r3PxgAongUw9p505VzPE09M+BkgB/slN18ye8rMtgO/zwHwHMfx
F0yZcc0lm9tfWAswUApw46CpkydcvGuWS4N3PIBQNBUbFNfRMgBiwHpg6sy5V38EG+qwPgpAftGM
WZMm0Mt23A5QMgPAsGrmhKtny6Yor8D+EhzvuWzCzMnKjfnvAbyD402rZl8+efaJtn0qgBD2y58D
9mz0gx/u+jp+2Xh12W9SGS4Dj8eCQyawfEv5Jlli759LRTZpBKsyHE+EAZiK13U8AMDvTuxNfMif
SrWfPjjWIgoRH/SDy0EEFDSQDZXY8TDelwPK74YpbCDmbMLviRy2wWGETvIlrScx+AqWkgi0kd1w
BL7GnmfgVfgEdhEdfATfED3Zjc84ESbDvUQP+0ALI2EePAyjYDXS6lK84hmow5IFsmAqbEIYBVth
CQzFdQShFibBx7Qc/k3KcGYg22EpxPCKG/GKfXADDIcXYTPswNUYYQbcjX3zsfd9uAfGQE8owbve
B8fIfbSM3ItjtHjOw/nZnYbiTKfPZ/C65NmWOtlsXeeY1NlOhuAqroclZJawagEtZBupwPvocK0z
caaJcC/CaGiGCBTBk/AlSSchKMenmQ1HyPf4nHfARlzLUHyyeXgdW9NUBB3cnfgZn38/6SBBnGcl
rnwSYl4Cl9JhkAZ6OIWYjMAhnEuLz8BgFGIveQLOATgnO9tIGd6zjPSgQDaSNtKT7EXsjcB7bkXM
fAzHaFmiA27C2e/D+8WQemnkSjKcTEpxBKPLDTgnGz0Pn5PBjYmv6S6851IBHsZ6B959vgDzceYu
yEK8MZiKWBuF1zFg8yxBijAYilhkgKsQYB4+4WjE1xZihxWwB65LfE10WE4DSm7oApbCOsTVA7CU
OgVRcFInS5PQdZAbsJeNFo5/Kv/zQad0FfBUp+A5pHcI5QAlgVRCKz4lxedbTdS4bhnoE79SQrJg
G/ZRMo1Mg+eQNxiOujDXhaUkpm7ohkuRdy+FXojnF8+CZ5Cf65Cj7+nG53wEQHxCCqdJfF7bjcsu
CCK/M5ruE+6vQ46rhdkolay9C7Af+asMbsfVK3GcAuxUivyxjUghnmhHLqtMnITMxF74RZDUyXjH
jwUprUNsMBldhrS9GPlmF65hEt7BCWXYezFMRKotIttgJOGhDxkBi2ATVSOnVMIw6E9qcO1v47pH
Ig1r4AqSjqW7Ea4QOHkenlsFPn4G/PicWrgKojgnWwHTFv1hVOIUaqd0PK/CERZcUXIV83AVUWEd
dZABPJ6MdiORu0243qWIu+uQr0ZjbsBaDzyvhnxw4/V3IzBNshbXfxU+50DoA148B+Dsa+FmCMAt
eNVdeDXTJy+iRtgM+YkfkWJX4xWX4p1XoITnwlQaJP1JP9KPBsgLeK4gK7A0gAZoEXL1ClrGLYKt
5F3k7YeJER6DNeQq0g+pO5XMQVpthp2oNRag/DlgMJZ/gT/hC3gUXoNn4V1Yg1RegL074D9I36M4
/j6BP3di31YB9ghn18yTUdOenneBMCebsXs+chVSZDO2PEuryGLSQALkDfIGnKIoVOQAuR/hAHkM
4W2yn3xGLkbNdoLMI8NIMZESCQnDchx9hPYnH5BfiYqEiRYpe1r+3qYcJZQjj5LHyTNkJrkI21aR
iaQBeS8oDFGAWBipwXWwYylinskWO+R4suNp1JTH4X6E4zjqYZQFPHElTE8n2+8nt5CPceVPkbdx
vBPpEOnOu8r/Hxy49lWChUOTjVIuh3cQQ/cj5+8k28nvwjoFZYHl1PORN8mt3c/a1ZZ61r/kD5Mh
DAQcMBAncdOdn3soU/hJ5cSG9D0j78Itcu8nQr4ZSoR+KTQKeQtpEdo7katZ/VdcKzvweYRneRqu
FOpTUEZvhkdgFWoSBGpFaiNfwAS4EDGyH3lDhRzwGGKiHjwgQjq8jefHSI1bsJfdZRWsIt+R38hv
KN+Xki3kBPk3CdFJiLVmlJtKCJFD2PJv8iN5GWd8A7HwMN5rH/oN78FuMp3MxRXuhu24xjLk5TuQ
A7XwI3L7djzfgAdRf9xG6vF8Cc/t5EFy8DS2u7HAOIXh2SnwA5C+eI6CX+Fz8jvSCz0twUah3sQ1
PIBSu4u8Q3aiHnwNOXcriaBkWMg4Us3dAG8K168mL5InyKuCjEeEM104E93nLsTAmfXTZ28cjdBt
P/9XONN2/B18jVqJ2Qz2JP8ncK7lOBMmCX5HEtga2D3+4RqSjd7ubwioC1E/G1CPXi3ApXhOxOsZ
1CJnZ6BuvRStWG9c81TBkoEg8wwcSY9UHk16ooo84OXoV5PZWJEgV96I1F9C7iGPkGbkwgSto2/Q
t+i/OMJxnIzzczdyTdxi7hHuPV7JD+bH8uP5Zfz9/EP8Y/wmfhv/Gf+taKvoVdF3ohNipdgudot7
iC8SXyqeKW4UzxXfKL5NvEL8uHideIP4XfHH4sPiP1wLXH941B6jx+XxeUKeHE++p4enzNPLU+2Z
53nc86TnWa/Iq/eavD5vyJvlHeYd573P+5SP+sQ+tU/nM/psPrcvwxfxXeCb4Jvsp36N34usSYPK
oCZoCFqCjmAgGA0WBMuCM4Lzg7cGbw8uDi4LPhJ8NtgSbAtuD+4KvhN8P/hZ8EioLBQP9Q41hCaF
LgldelR0VHtUf9RytOdxelx2POcUPeU5VXSq7FSvU5Wnqk8NOVV3auapG04tOnXfqUS7rD2tXdee
117dPri9rn1i+/T22e1XtC9pv7v93va17U+1P93+bHtz+8ftn7b/qyOno6Lj9o5fOts7E4n2RAJJ
4UE7wTC+hmxAj/NPxPjriPFPUU13YfxWxPhd3GM84dP4Ifw4fim/nH+Qf5R/jm/lP+WPippF20R7
RMdTGPeK4+IGxPjsv8X4cdd81xqP0qP3mD0eAeN5ntJujD+GGH/6LIwP9Y7xLu3GuBYxbvW5Uhhv
8F0sYNzzDxiv7cb40uCa4NPdGH8bMf4pYrxHN8Ynh6YfJQLGjUfzjpPj/HH1KYIYzzxVghiPn6o6
1efUiFPTT117qunUXafa26UCxnPbK9oHtY9qH4cYn9k+p/0uAeOrujH+FmL8c8R4mYDx+UmMJ/6N
grAsYUAcb+diiQMUbVqnGiXgbvQKppPG9jVYnyYo7khnZmdGZzoWr0UpmwvT4RL0jcra/9V+oH1P
+zvth9o/bH+fjWx/oH0FpsvaH8FzWfu89lvbb26f1p7fjjry3/UAXx1ImpRDCw7d9+WYQ7ce+uPL
pw5ddegFbFmK0HTohi+vODj94DWH2v4dOXTXwacOLv9i+RePfrEI4Iu17LqD5i8avxiPtZwv4l/k
fxE40OdAzYGyA6UHig7kH8g5kHHAd8B+wHCA7P9x//f7j+7/ev9X7Kr9r+/fsf+l/XiX/a/tf2L/
hv01+3vvr9wf2O/b793vsu20tdtO2f60fal5iY0WvSRZK3lIskqyUvKgBCNYyVuSrZL1kkckq7Gc
LYlI0iVycaf4N/Ex8bfir8SHxF+IXxe/Jn5VvF28Tdwm3ip+XvyweJV4pbifuJfopOhOEfCd/Aym
Y8hlZxtWzpWEs+rp3KDu+qq/tcddvbdxrUL+6d/2vo6A9pi/jW/iV5zbyy9Owj8d/JUM+KtTtbn/
bR3nXHkh371+vv//7egoX3ROy/SzV/H/4uDQN70VFvBTYDkcgdvQti+ChzCeexwjlCYkxy0YUxyH
n+FOtNi3wytwAH5Cy/002upf4AT6rs+iBX4d1qM1mYT26GKMIyajF/AW2vB30KfdDd+gFHyAPvoe
jNWmoJ9wN+yFD+EjtDTfwvcYbU+HaWh9ZqL9uQw96lnoDc3GWGIO+iZz0eO5Cv3qq1GersFI4QaM
9V5Az2eesL9wE3wHP6Dvvhy9Pko4whMRnIJ29BUeQJ9jJXRAJxGjVyyFBHoxD6EXsxp15iNERuRE
QZToBT8GJ+E/6As/QdaSJ9E7WEeeRu/iWbKePIe6tRmj8xayCX6Hj0kTWUQ2o6f0PHoXrehZp6EP
0kbURIMetg5j/i+JnhjQO9lOjMSEnvuL6PnsQH/lZfIKMRMLbIBmYkVP8FX0QuzEQZzEhZ7M6/AH
+vpfwb+Jm3iIl/jQ13qTvIXe2jvkXdTt7xE/+jlBEiLvkz3o5X1IPiJ7oQ39+nSSQTLhMHxNPkZv
8iB8Bp/DfoxM9sG/yE/kOPkZbfEv6EGeICfJf9Cj+oP8iT7OKdKO0WUniaKdxnCYUowHeCqiYiqh
UiqjchKjCqqkKppG1VRDtVRH9dRAsqiRmtCbyKFmaqFWaqN26sAY30Xd1EMXUy/1kVySR/0kH+Oq
IA3RME2nGTSTRujt9A5RmkhNf+Ju4m7hFnALuTu4O7kl3DLuPu4B7iH0DJ7g1nHPcOu5DdxGbgu3
lXuRe5l7jXuL202Pcx9wH3Ofcf/ivuS+5r7ljnE/cT/Tn+kv9Fd6gv5GT9L/0N85Meekf9A/6Sna
zsk5BadES0jwwR5FH+Nx/gl+Lf8k/xS/jn+af4Z/ll+PVnAD38xv5FvQA9nMb+Gf519Au7iVb0N/
ZDv/Iv8Sv4Pfyb/Mv8K/yu/iX+Nf59/g3+Tf4t/m3+Hf5Xfz7/Hv83v4D/gP+Y/4vfzH/Cf8PrSq
n/Gf8/v5A/y/+C/4g/wh/kv+K/7f/GH+a/4I/w1/lP+W/47/nv+BP8b/yP/EH+d/5n/hf0Uf+zB/
gv+NP8n/h/+d/wM2QgttIgWwBZ6HV8nXGEFvRv//ZngZFqIn9w3dyd+APvYDcAzl8Am4B6OuJaQS
7dDd6A8sw+ixlVxPjpEf+dl8Iz+fv5y/hZ+L+ulW/gp+AX816riF/O38HajpFvFXoR+2mL+Tv4tf
gv7BffwD6CGs5FehZ7Yc/bMV/PX8w/xqfg3/CP2CHqSH6Jf0K/pveph+TY/Qbzgn5+IKuSLuV+4E
6msxdG9bEgos5Dr7wE6OF4klUplcoVSlqTVand5gNJktVpvd4XS5PV6fPxAMhdMzMiPRWFZ2Tm5e
fkFhUXFJaY+eZeW9KuKVvauqa/r0vaBf/wEXDhw0uHbIRUOHDR8xclTd6DFj68eNb5gAEyddPPmS
KVOnTb90xszLZs1uvHzO3CuuvOrqa6697vobbpw3/6abb7l1wW0Lb7+jadHiO+9asvTue5bde9/y
+1c88ODKVQ89vHrNI48+9vgTa598at3Tz3DPrn9uQ/PGlk2btzz/QuvWtm3bX3xpx86XX3l112uv
v/HmW2+/8+7u997fAx98+NHejz/Z9+lnn+8/8K8vDp73is97xee94vNe8Xmv+LxXfN4rPu8Vn/eK
///uFcfj8Ype5WU9e5SWFBcW5Ofl5mRnxaKRzIz0cCgY8Pu8HrfL6bDbrBazyWjQ67QadZpKqZDL
pBKxiOcogWiNv0+DpznU0MyH/BdcEGN1/wRsmHBGQ0OzB5v6nD2m2dMgDPOcPTKOIy85Z2Q8OTLe
PZJoPGVQFot6avye5t3Vfk8rGT1kFJbvrPbXeZqPCeWBQnmpUFZh2evFCzw1lqnVnmbS4Klp7nPl
1KaahmqcbqNCXuWvmiyPRWGjXIFFBZaazf7ZG4m5FxEK1FzTYyMFqQoX1WzzV9c0W/3VbAXNXLBm
wsXNtUNG1VTbvd66WLSZVE3yT2wGf+9mdUQYAlXCbZrFVc0S4TaeaexpYJFnY3Rn0+JWDUxsiCgv
9l88YeyoZm5CHbuHNoL3rW42X3vYcrqKk+uqRi08s9fONdVYpnlYtalpoad5zZBRZ/Z6WVpXh3Pg
tTTYp6GpD956MSJxwFAP3o0uqBvVTBbgLT3sSdhTJZ9vsr+GtTRM9zTL/L39U5umNyBpbE3NcNE1
3habLb41cQhsNZ6mYaP83uYKu79uQrVjowGaLrpmkzXusZ7dE4tu1GiTiN2Ypk4VlKozC5O7+4SS
MJyVBlzUjVnCVuTvhwzR7JnkwZWM8uMzlbBkcgk0TSrBYXjUEbyq+WKkyLRmWVVDk6YHa2fXN4uC
6MQ2/YZKvcF/7IezWyakWsRBzW/AioxPulkN+7vKzZFIc2YmYxFJFdIU19hLqBfGole20mn+2RoP
Zog+qEXcTqjrkY3o93oZgRe1xmEiVprnDxmVrHtgor0F4tmRumbawHp2dvUYh7Oe+V093Zc3+JGT
NwvhrLFZGur+p9aY9DVTezQT03/pnpzsHzDUP2DI6FGemqaGFG4HDDurluwv6e5LlZr1VaM4O02V
qJ0TepEpx3YPZpVRymY+iP/EAlNf3CqRIlcKLcTTp1nTcEEyrZN7vf/jRa2J4+wqITt9WWqZzT0i
Z9d7nlU/a3nKJg4XzIfogGGjm5rkZ/X1QQ3U1NTH7+nT1NA0oTUxf6Lfo/E3beVCXKhpdk1DF0Vb
E22L7M19FtfhQ0wlPWJbEzu5nS3D8+OtmPUQsk1pgbz5LFeohLxFll9Rmc3thNkIGxDeR+BhPKbz
Ui0cuDGtQGCtS4T+Ndw2aEbYibAHgbW0YUsbtrRhSxu2VKCbTLgXuOdbAm689eZN1kDeT5U2bhMk
ECh3N7cIvDj3uFQ+PpUvwTwT86Wp/E5uUUtPt7pShnUCP2GaQKD4bKta+g7O2yoUisuEwsqulpWb
sMVdaUVXvhkBh+CqVuGqfsKU4KwrsX0ltq/E9pVC+0ogwlTejNRUqcKqFrUp1YKFSjlXx42APJxi
VCofyY1oyXPvqGzghuPUG4R0DTcM0yVCOl5IBwvpPKF3nlCeJZRnCeUKoVyRKrM0+4zULaRqlnIX
cUMhA1uGcP2FvJargSDmg7HO8kFcPyEfyPUV8gux3YL5ABynw7w/10eo98N6NeYXYJ3lfbk+LdXu
nMrZWB+PfRTvx9qrcQ3VuKZqRBJrWYKwBuGg0DIe03kI7yNwwkjCVeNZhWclV4lXxHGOOPbEgePi
eFbg2YvrhT3lOLYc0zhXJjxjGY4qwzuVIa7KcOYyJE8ZkqcMJFwZph6uEHIQ4gi1CA0IIpwnitdF
cV1RvEOUi0EA5/LSxWDA3JPK3XQRuDB30UUtLne8UkY3Qy1CA8JshPl0c4tIp6404Dg2NhthMMJ4
hHkIqxE2IEihItkTV9AKWsENpoM5Hrk7Y1NZWZ6Q5xclc4czmStteerKy7kMRFMGrEbgcMkZuOQM
fNSumhuBIuuEYQfC+wgHERjCw4iMMCIjjA8YxuvDwiixMO4nhAQCh0wUxvnPHiMSrnYjZJ8xC2tN
x5Z0rKXjNek4Nh1bD2JKhCtYfy3CEoQdqT6fwMw+gTl9OJcPV5uNaYVQUmPq5nwtVKZuRfySHurK
YsT7YATspHciNu9EvN3JOIQyIc7GnorUiCUIGxBE6Klv5TLwDOOZjqcPTy+eHjyRgughuuhSPJfg
eReed+K5GM9FSA3DhsiOCB1fOKtwXuGSwtWFGwp3FEq20Ql4NtCGuBxMJjQ8Oq3UVqmhPIwFFflT
SNcL6eVCGhdSc9w2VnV4rOrNsaoHxqruG6saNVY1aKyqz1hV9lhVK5kYN0dU+yOqpRHViIiqKKIq
jKjyI6qMiKpSS+rISFDBS0LaW0jzhNQnpE4yskUFsu1kDHilyPEkvNl7k/trbytPWty3eFulmN2c
rI1JZj1Z4/PuHO8UdzTZEkpmAe+LPM4Aw8mzICGReFTylmS8JC4plWRJYpJ0SVjil7glBqlOqpGm
SZVSuVQqFUt5KZWC1NCaOBSPsL1lg5jtvIKYZykvlDWUpWwbGi01JVIK/aFZzw2gA4b2JgOad06C
ARM9zSeH+luJHE2YyN+bNOsGwIBhvS3NxZEBrZLERc0lkQHNstoxozYSclcd1prp7a0Eho1qJQnW
tMDOvMWtQEh0wZ32VF5Xx64ZtZEnd95ZB6YrKywVul7a0j7Vf5M0pNLI6cMSObOCK3E2Lx8wdFTz
08665jxWSDjrBiDmmHO5lZbQoprqrbSYZXWjtsrn05Kai1i7fH513elx4MH26q3gZZkwDjxsHHjO
GeeixWxckGXJcS5hnOuscRvLvTXVG73erjHlwpjys8dMOXvMFGHMlNQYLjnGe8YYySHwCmO8kkN/
GeP6H8YE/3bMGdic3DvyXw6yFfqTTzZWXcs88wZ/zWSEhuZFV061NM+f6PFshSryScppDzVMnDSV
5RMmt5JP/JOrm6v81Z6N/a/9a3/ztay7v796I1xbM2zUxmvjk6tb+sf71/gnVNdt6jshc/1Zt7uj
63YbMyf8zWQT2GSZ7F591/9N93rW3Zfdaz2713p2r77xvsK9BK5HtpRC7zp0BYV8E1XIkYEb7N66
3ibN7F4CN/f0Wm60t/FAngIFesZKjLJUCKwrVhmrZF0oZawrjQVgqS7LjT299jbyVKpLg81af2+w
1Eyrxn9z5qQK/+O/OXPmzB03Z9wclgv/5sy9AoGRCebAnLmAT1CpFOybG7Ux082LEBYLOpqbM6du
Lgg0nXMFsNnmsuT05N2lK3BmMudMJoA55x6MMyKQBJxuzhUER7GBV6TYZg770AynAbbI5CTAf4Nw
D9gxd3ET0V5D4mAKvuq8Mdnf2ZFI0H2onoalIHkMw/M+IR1GBiZzuBj2wky4G+7HtnzyHqyDOKix
fS9whP16oQyWwVXwMQxP/IytXngMfoIolMLURKfw5W4nuQEeI8kvpkvgI/YtIy3jIvz3qBozSQ73
DLkZYjjLMFgOZngfZ8xMyLG+iTppGV41DN7hxkujiZzEL2Qn/1ZiIjxKyugn/HPwLhwjPh46b0ks
SqxMrII0OME5O15N5CZm4lXDoQGugOtxBfPhYdhN6mg53ZG4Q/gufjK2vgDvkAiyUwP6cxfh6Fth
BWyFl+B9+BS+JoSoSTqZz3b2RNCxq3NXol9iYmIW1MAgqIX52OskQVJJR3OjufXcvo5/dx5KuHDu
YXAlXA3XwRLhNwP74DPYTzgqp8PocG492KFc+Jr9bsTZw4jJt+AgkZIC0oPEyW3kWXolz3XsQvvO
gxExeIGA/bthJeL0CdgAu2APfIBz/ow45YgVST+cjCU3kAXkLnIveYI8S54j31MR/ZTjuJv41/nv
Oz9JyBMPJtbhfe3gAA96ulGkwYVIz93wHT5fJomSCvIhjdAoR3hlR2dnfqJvYl7itcQ+8EMYx5aj
V1sDA2EkrvoauAW2wet47W54D47AfxBLHJETHeLCQ/zkIjKUXCHs0/5EOqgJ6VdCZ9AWupeLcLv5
kfxzHZs7jZ0tnT91JhLPJJoTrybeFehbhPepQgrUw2wUMEaxLXif1+AwfAu/4T3ExI1rvYAMwOdd
gfMfJO3ITlJ6I32WJtD3Xcq9xVv5FZ2DOmd2rujclChIDETe4tDlskIBnj2Qm4ZDHc59M2LzMXga
KbMJuecT+JFYiIvkkH5kBBlFGshUMovMJo3kOnI9YnUd2Uy2kU/IfvIj5amYGhFPETqJ3kyX0c10
F/2EHuaAG4oRTCN3HbeM28zt4Y7yGj7K5/AD+Qb+Gv5aETpkYpP03XZz+8yOiR0PdrzamdVZ3Xlp
56LOlzs/6fwqoUjsSHyNjmgOrrEOpuAab8DnZ7v9q5E/nsY1fgnfwPdI818QFxyRERuu2C3QrQrX
PRBXPhIdpkvwnEqmI/7nk2dIC9ku7HK/Rd4hH5ID5CdKcPVZePZEKRhOL8FneJA+Q5vpZ3j+Rv/A
GDjK5XH5GFM04NMs5G7H57mfO8B9zVPeyOfyQ/l5/BsiTnSxaLlopWiX6E3Rd2KNeExKRww768XF
u/Rlvhc3A9ZgbMBx39EPaRm5gZ4iT1IneRnv5sRoq5ZW0Z7oGW1DLp8JBslKsVfspQbQSBrYHPQB
GuNG8iFOCXNR3oCOprfRBlhLtsMpegFy2pXcbrqGjudW8vfwvcg+jC5e5oGqyEmohErSC2n3ETQi
hWLcBp59ywsiKdcumklViYX8NyLKfYh6sJxQ7m0ymhwjtdSE2OpJ7wI/1jXkGOb9UAI/Q87fik5n
CX+IW0z70/3YNgOWkZfxGbfBDLqNPIp0KUF5vJzUklVcLtxIGhEbpTCd3gs+Opv6kJ+Hw6/kZmJE
yT2FtAnQS4DnVHQS7KV1SPU9REezyI3IpzNhEWmCKOkgO+FdejcUkcncS+3WjnRK2o+RjdwFsJGc
4t/i30LX+xRi0omcK0V3+0vk6ZV4l9fBy4WQa0pARNnXsvWoAS8ELf2NXE9nwDSygvuWPEErYTBM
5ubQPmR55298JZePGGtDbVIlLpWCqEzk5AuQ4t9AL+TGKQDiqfxB0c2szH3EnUjUJbyd40VpnQfg
WsTOBajdFqEsXQCfExMZR4bwCTqATyRGwDN0A38gYSZK4oUPEihhnVtIGQkkPKQxoSBDkMPHsd+d
8Yv4BfwV/PVom06h1rwN7oEH4RW0Jo+j3QojHi9EbI5F3TMNbUQO5EEhPl0v6I1aqR/21cII1KcN
qCUvgcugETXvQ/AsbEQLNQDxMQ6vuwSmY/sctFDXwY0o/wthMeqA5bAWPqBP09UY4d5OX6NX0mnw
OXzOvcHFyQjYy9/Bz4OhGAEPIXq8czFSyY3XLU58hHfLADtq/wKUUuT7xPeJTxJPdbyP863Ftd8j
7g3fi6u6RWH2X4FYTgN7Y8rvORvEd6XgRwCJD+EyAKkNQD4WnZtLAJRfAaQtBVC/DaBNB9CjvBgw
N8UBLJhbnjsN1l5JsDUBODYDuH4H8JwA8M0FCKCzFHwaIJwF+EgAEWyLPpuEbLw2Bz2F/GqAwjyA
YlxPqRigJ44px3kqLgSIY18lrrEK19GnE6DfLwAXuv4BxiVh0GiAwbiGIfgcF72SdDyG43ONVILw
Y7m6zwFGfwrIGggtABPwfpOuBZiMUeclKLFT1wJMx/lmoERfhm2zbgVoHAQwF5/palzntfMBrmsF
uP5wEm4cdB7Ow3k4D+fhPJyH83AezsN5OA/n4Tych/NwHs7D/++A/TEXEOEJHEigz0axpJUoN2Or
iGcFDuRiERae5zhqk0lY2/MErNLB11kigzQnygZ2lA3SnCwbqOkog4qyjjIGuTlerVcbxIQAD+0e
bmd7nH327+F3su8f5PRJ7mX+Q5CCFho2pola6W1xOZHL2N8hk++TtdHHQUFfiis92h3a97UHtT9p
Rdo2YgJKX9okJfuglT6+JUc6S0ql2+kDoIOfSS1YIpqT9SeOaTpO1h87cQxXUqYpw9Xl5hAvJxb7
faHw6QLeq4/YY7V6xGSKULTYPCL+w05byO0OkSPJHBGyLXGUN/CnQAFmiEAxVJHe8QFvWonYRy6V
Jr+VjmRmyLp/LyhLd1kGuv0H/dTvL+R8AzXWPVZqtXI9iwsTlcXZxmIuoS6WKYvV+JwJXbG4lXwT
11S7eonTe5UUq6MkmuhVnNdKf32hWgbZiknPWCJQUUE0J4911B87rDmcLIDmWMcxBrrS7PpjWiEl
Wp251Fyam1N1TXxYrIqYywp6pUOPopJ0Es/BUu8sLGmkunRIkyvTiYHHkoliqTy/ZzopLcakIrcy
HapimGgl6nSiUmCiFxnTwUwwge4vE7oKN91EBjSbhg5oDg4ZPSou6+3o4TA50hxllbLEYahI/ABx
zDUIhsThkq6jDhrriYERobCgKD/PJCkI+X1io8GUn1ckEiXbi4uKg6zPaJCIuX8YS4/cP2368uXT
py8vmzNkyBwG5ML2k2kShVYi0nHyNKkcC+77p0+7HwfdX941iPt9xooVM2bcf/+MoXPnDkXY08Hr
lHK5WJzKOzUz7l9xKRs0bM7coRddMRcodCYOcp08eytZCSfjPa6XXC+7vvRt8q5H1DNzRM4U/5Ts
6yS39rqjcp3k0V6v9pIHsjPihdk94vWh4T3EgZzcXH9pJUqYrAQp2xrPLSxciZCXm1eS6/fn5gZA
ZsDOygDJ4WX+Ui5T3F1Uc1ljwuFQK7FtdkXj6sA2sgQ8QDhR3FwC8ooop8gstFV5xyg3lkXF1t4/
b7e0ksACJpMDUQKYTELFwGMVZSds1mOWbNuxE2WaY0k+SbHLwqxI2g2aXRaQajrKkY8sRPNz9old
C1njLsw0u5j4NNZDvTecokNxKEUNc5JEYokklCSLWV9UnGwS+8USc7LoJ+IkxYq5YfHRd139/HUz
+juXT/NV+yJyrTXNWOmu9NVMGX203H+Ry6Y2hHN6lfZ12WyuzqphkxYMnd1v0q0v3TH9cc9VA9In
3Wcwmqw6pUHhd9gvqahc0rlkzv0WncokXVc/wqzXWajccN3wyXfdmPzESsIR/huIkYL4LQaHxh93
/Gb7PSCqsi7Uzzdwbrs7cGGAyww0qC7Wzwy8a/5Vd8J+PCCNZvo4SJcb0qQGry6aGVbLRXwQYrFA
MGAIBgMBlHF/wGE3OBx2u83usAX0OoNer5NJpQGd1qDTaWPBgN8hgnSbXqeVidKkAdDJYjwEWzku
rtNKdGOkUpAEBto9uhchjaS1kgfjamncPlDnkeBY/o90Aq2kPK4YnD4rnaZbs944TdL6gYx8qGNt
Vs0xm0VzrP4YK1lQ0bGs4nBFaSnqAoGyDPgUcRemZVki0r8UeCyAMDY/H68pFa5BYtfXMwnVCiQ2
aoNdRBaZBWr6wmFJSkiLgylOMJMRFkQ/0erlGovW1vnTOo1VazKuW2c06qzadZ0/WrUWtULPLSFu
t83m7vyyTmzVqk3SuqNmlc7q/PZbp1WnMh8dLTWqtVb2w20S6dxLPyBZIIP8uOUV+BAOwXG0Is/z
5Ff6MnyolrglVLKdrAA5zCTOpOI/3HEYso+xByBekloi2Um0nfvsIaufI1kdn+b5rXIl4442KuH1
dB5aO1tcCTsp2ETUyjNtOwh17BHIHsgmMnoLeX37k3Te1VfjmnYnvuII/AwqcKClapEq+E8V1rSZ
W4kLLEmJgwq8Kphi+6Sw0OGBktohxSz5eXBJj0EM8P5HEiO570QzQQMz4z1kMhOxyrgSKJX1If1k
Y2SXyq4kV8vukN4hW04ekD1B1smeh+fJG+Qt2SfkCPlWdpL8LjMrZETRSt7cwil6wRhZK2nBRY2R
vpjNEW6ftpVs27gdsXKivgP1QAovjfX1pBsxRUm6coc6xmrtWqucPqYwpGmtosCfo4JWtdIoesqc
ZlUrUPd9jc99VMS+nMgm6zfpqNzflvgFuMSJlpg0A1X9L5CeOAHhxH/AhGBM/Od5R5osTZpG2xK/
o/b/pcWZFmNXZCZ+ifszRI40d5pPN1Pqcuggi4RFKp8/zVuui5aLdCKRylaOlv3d53MD5WnWnEfa
iBgsJJpSaGj70BaiBBwTmLVUy5KkwRtNszQhi9VsNVmNVoNVJHbYnXaX3W3nxeFQeigjlBnixQql
XClTSpUSpUjMhXzaQBw8elucRMTBOMT47Djxq71xYrdiElJG45BFMTlt8TLxiNwEXYaMlJx5VI0d
FTdqXXprhcGlNVdoWWJyuXQVvtbEqXgcC2GDQ4uJXYOJVY2JOa3Cz5KwwaTCEiacAcdxLp2iIibH
xMRKToPVyyb5IW7GgtpgdrOr3BVUrtH2MrOk2x6f+eEYQh0xagRZDYfwX2GhpljQ2ib8h4Y0jKff
R42om8145ufpCrmjN01+sP8tWc4atRlLA27OclVrTMOqMq3ppX3vXFMVsaSXXrB4Dd2/p/Pnh6/v
Wei9p3zEnD1Ew8q+e8pGzLtqd7nf6u88tHPrVe+V+6wB4t3JpO0wupVH+d/BDhtbdFJ7a+L3uFor
BqnMHrfX6mrtvEzdRteBkqyMyzRKpVrzkkxKWYsIW3REJKLkJWnqN2kSnd3QRveBlk55AUQyqdJK
DdvoTehFmul7cTlM0WrJFNAQzYt0NjjgEfJekoNQQRwr06DXJDiGFceS/hJ0W73fTuw6q5KbA/UC
lbXepDx7k06IV3vaR6FLiYeZqo4ZLCWezh8NMrVVLrXyv58aywySRac38zkjmLZTSZln+wxiYh/K
UgT+3Iri8kU8ag8UXKC+Nu228G3pt2WsTV+bsU25OVOm0slNhcqSTD7Dn+mKGMKudD+aPcYEqu90
x0x/6jpMfLq0C0kHXkjhSPQiOYw6U0FUqK/GbJbJ5EpbK/ljs6Hch54sGYNeLMV26Zfa8mClis6C
GLp2Y8CF4xV0JkTJ3V0Cpzl5gskbJkyroQeh6TisOUZSGIIkhlDwHO6AzmIKekJGryUOer82Tsxu
Q5zoApikBOemm5KoxAMaSWOk2Jv0H4yoXwPFvWih4NVJxCm7ktJMYrEEJB10AbMs7XsJ/NI4zP3c
dZc9bRXLlBqtedrWCQ99FRpzZeenbcO8DP1XXH/kx1lTB6fPWHtjvUUiN2tyHh/3eVOPCXPmdh54
hHHhq4mveMQTIEk3zShBM4v6KD8vr1DbI9Av0D9YVXI5iOd5byu5j19WuLzkicK1JVv1beZ39O8Y
dpv36/9l/kH/pzmRrWXXbTH4kG7aViSgAwsZUrUikq7lsnEhFhD5HWB1edJDUWsrGbPJ49FFW8md
m0Ll+Wjt79yiKxf7y4taiSouN5ZzDkcpZ+uR3YYUcNCbXlBYS/NFYtUPbWR+kg7M+WfK7/DhQZoj
iPqBGhbZMGJ0HMYq8/2ZIhSYmZnypDp0FBQGgnoDLwoW+OPMhY+TQGEozpz+OPPjCSMKeu+RSEl9
YwmUNBJT0rgzPSFYdOZhI11CKdfbLNQEKnVxf5JInH7utb+1zjiapTZrNIaV6+95bcLz9S6b1XpB
47IHrx95T1SjVWgtI695cPW7E+kzBVsm3v/N2ByNTmNRz3lh9oClQ5mUkKYx45aWFRhkZk16+fAd
tw5bjlbnEyYp6L85wQsfxFVoqT3U5RU53Q4TovXI807nSya1UddKGuK6tLSXjB6vdwrlDOyH0l63
BxH/AsfxIq9L5cJyC6ShWUFL5HQwKTCBGttMRq6V3hJXE1HaFKfTDWoXQUlwtdHLwEvGxBUoQsTq
43mjEu3Qh0iOQDc5GgdiiNlYhvFlR5kGQ5wy5pVpfkTvDCNOFnR2lGlLReh+Ca41k5vf9pZ15erc
nEbiLST52i5PoauQUjH5Wq2fcFzHR+SjDX2Yw9RHSDvfZOlD0c6RZPwELtz+LsNd529deoaMpwc7
vMjnuxifI+ai8EXcp7DLHD5ZhrWHRRTLuDBjfMZlGSsy3rLut3xvkVoZE5sYE+uxYPf4pQaNJ2By
24jb6YUXCfvzwIT9pIIcjsuc5Twvh1BQ30r+HZeZy+W2co2ESNroAsigM7bgyCnBQCv51wsaayzI
y7tY+DTO0HlFHCWjV2TfMha1ClFs0mUtFfhY4F6LxSGSOURomS0yTOxiZ5xYpebTnIsiHInUNxJt
l6pAr/RczvX7kuqkS32Tef1vL3/44+Obr7psUDxk0Wj197cs27l2/i23eFQ6E+3PVAh/T+dkt/uL
LW/+Xhgs9pp0Vt2dbz151/oajcVEY0wPofbUIXZtqEX8kEOejiuzfIZAgc8VcXldobbESfZBdTyt
kO8preIHSIfzo6XiICJ4E+LXk8p9Qu4vCLQm9sblTHvg1QGpqhWvnMfzvNTAG6QhPiTN1PfQD9CP
0U/XX6O/Xb8gsE2/JfC54nPd9yq9goikEo84ZFUHPEHvZM8k7zXea9LnZM/O2eTblvmJ8iv5EaVu
tBTdGY1W59Eb3EaXyWm2aiwqHwRUyqAiJCc52TQrikYkQxLJFJnFaapALsrIE1ti5Rwns7eSL+Im
d7lBFC6XqSxfisshU5PpyczJ5DNfpLshDwIkAEq69gVfeQ6GMdbcbaSE3NTtrNWz8FPTUY8uecUx
tB+M1ocZlbtik6SaCkY9Xl6vUWvVOjUnVqoUKiqO8plx4tH7WsmzcSOE5OilBQPpUmyMiGJx4lW7
WY+CBFXhOGRIwnFIuWiaMsFHY3qtUbA3gh+UtDwRcppVBE5Bs8N4JcU7fh9g9Go6g3XIjEFPTL5t
z0tPznyxqKoiZ83H1w8rsZi0Kl1G+audO6yhx2bNXr1m8oTRZVQ/57KDjy//47ZF6z98+PZpqyf7
1FadWW7o3PiN94PnV21YfMuzQ4tRKj9KdHKfoFQaYf5GGcfsthhVVyYVizn6kkypUk0xgsFoBCO6
CUqzwqgETkPoFIVcq9bIeY1S0YaSSOhTm80yq+mHMxzjwwMFl6ZCUDyod4TQXhAmjPKSwf05ZpsU
epOIKMQC6VLo3E0da5ku4bjO56SmNJ1FzM8ICWKx+rZTb9q0Fo1ch1r4G4wGvhGigSDkkoXxat2T
vrfhR/hRydt4pzESGxmZTEWKNN5iTzNYmiz3kgelDyqWhVdHVsXWkcfCW+gOeZuyLbJb/nZEfw15
wktzDTF0bFocfldr4l8tOf6stsS/MIz4fbNWmp4eYG2Z6b62xA8QTHzXEvZ5mReki6THpf7yjAyx
s1wvyi4Xq/yt5LO4JiPDpAmVc1/ayitMg03U1EqOxRX5nnLNl9FymTXvnIACWfQE2ylkquiIwKiM
TwXWzInl2t1aIy916TxxcBhQD2VJMBrIEaEZdWtRI9mNmMSk2XHIxdDhdJjADOtfYwSoJ/WN0FjF
ftQUSRzdhH4+PsjRTej+szyeg96/yII1kQVLhJWIRWgzKCuMFhxuZG1G1mZkbWc5/XXd9lvYn0mp
QmH7rPiMLTP9GWVOP+3SQ2vWHLp0+tjMHh8vv39vjwzVI1fMfWT1lVetNj87f/6z6+fNW08X5T/Z
cN/nn983/smCwtIhE5vef79pYm2Pb2esXDV94rJlnZJZjz9+2eVPPYV6UY960Yx8EYR8UhuPSaR8
piQCWU8H2gLiEFOS/igmaRZMVGmuvAKlD5M8U340HDUyT0w9Jvdr3R/+XzNPZIl2AMllWpJd1cqI
bkL6fwd5iKcYXiU2bMndlftRLj9OqgpAKE0ZVqTLMjGuw5IqhA0qXh3IKJeLmD6Ly7NRocm95SZV
qA11loqujcsD5Wpboe1LSXn0RfoUFJxWXZoTHehonUTW+BqS3HC44lhqQ6X0tOIKh7N8ft6oSlOm
UbEW3Rm9xqDhxaJgpgx5JF2BPBIO+YwBpqn0JItnYaQ0AxvTMPFrvNi+BWLi7G7ddYbygvoIU1iN
pFuHYVkQ0q5tN4Gugrd8hs2DwoJw6DR5i4u4HZWbxo18rGHHmsu3F1SVhpaNvfH20aU2i1ZpDud/
TPIMhQ9Nu/TRRy/pOSffS1+fM/fil6c/2HHXwvVft1xZuzy7wqexaM0KPcn/JvPTd5ZtvvOOTfF4
BOks7IJwE0GF0VxuXKZuMSmkLSDWbSMm1Ak8MW1RKKxWx+ltkbKBmmQQwTZHyFmbI/p/2io5nXAT
a4t7DmLQsaR7/4TCZNLET+OUwiqKWyQB0kp/j9uNAbXCanPyg3UE/6l12boKHaezOlKvKerRZWM7
otnovbG1dEV0SUf2rBqf2y7EdNy9LD2jTF9gfgCDzo/Mer2ZAftRZ+Ir+infjF5BLrwUr6yWkofS
HtZSVdpq+UoVF5YF/Tf7N6TxMakU/Fwtumc6m9oUnBtVmNaoo2pXtou6eD7qImNq0aeSSNNbSc+4
PvtWqTQvXxn12vL1YyzWvMfYVuDFKd0lcClTXKjEyjToVLFyNhrcimOCM1WfYlWX3aPSOkIapy6M
Q+y2NLcynWjt6jBRedTpJGk4Gfeh2WQaqp502QbkoZTPf0ZLkmJnk5HchP6nZX9t7LGbe18xjNmQ
VVmDBj35zjWd7w6LlldkDouU96J0OMPhnUOGxKpnr3ZljBBqNUr9mw+Mu7vzovJItKw8M1bG/k7j
vsSNGCNroRz6kvqtoEns3ORwFehaEzvjMp2rQBXHpAJrmzDXp3KLkFsKqtgoMxbapNvjVKfJVvk1
3FSpx0nKi0pbSVpcXlSUV074vr2qna2cKC6z5kbTDvQaIy9n+7NaPlpdbZWLA1GrwvNcaa8ijCP6
xFUmea/CokCvvgEoIhi4rW6pjEpaSXZcYTIGYqZArDZKotvJN3ABvEFEyb1IDAgwfO44Ud/BnF6M
ETQnBE8IacRCN6TZYcFICyGBpgzqBVpdVFEVLBBZMiMZkfRIOBKKiMR6g86gNWgMvDg7lB+skFWm
gyVoGg/qHON4UOUp0kmVCNvi0l7pxByxjgdDVtp4oixISye9xdVdL226jEWXd9T1IqdQ3PVuJeX2
oF4xag26/LziLvvRvX2kTW4fmYxaU3KHnxN36RpujDVTd91Drz59+yV9KyKOnJpNK5YP0Gq0lrKG
lbULYo5BGvPtMx6+qGm6waDSW6pvvW/mRG3QQLIUPL9ixnUbJ1y2OGANVGy8pXPLK53/6auxaDyh
8p4F7uU9hswmtQQevbnmkWkdOym6X0YZOURuHnbhJSL2v3ZoAfgd/D2QCVnk+XikSIsYtfeKFsf6
6vrZLoz2idXqak3jbeOjtbHfM9URyMyMZhFKY3JNK308blItUa1W0YMqosrQqlQarVOu1fkzWFda
KJSfGQplZDr9mVEZJzSJxfmCs+aU0ZhVLzSZTCN0JpNe57TqtD4Ha7rADe757qVubo+buDPsbrfD
7vTZbbZoZqbLbjPY7TadVuuiMYxTYwG/Xy6TAnFF1FnuLJqVJbPGoiGbPmSzUlsbGQVR0ituyAzZ
42pZBWiJ2u62H7Ift/PonEefz6EhbSykayO9QIu8r5VXaBnva3CsWktAO1j7kzah5bU4dlN2zQzU
HMlNsEbkhRMCd7Jih7AbxqJX4SWi8OoW+XWhSAhdF2ZZIgtvOPvlUH1j9old57wt+t+rwtUSdFUZ
JLfquXOCX5LiSC85p4Pj/Bx3XcenjY8Ir4deZ2klmfO7sPf2JHmwUmh+gwXJa5YddX9JFnbu7gqO
ue+Yoj71SnewvJBO6niIve0eiTxUhzzkgDDkkUviL27IfCbyuvw1xT65aElmU+Qhz8rg6shzQfF1
gXnBOZErYkvkSwyLAkuC0uGayZp58tma2drZutl6SX/PQG+/wIDIbWmiPHVPTw9vj2BFZs9Ijbqv
RirLtnocXnvQnmnP9qszI9JrNNsDb2RzfTz9gld6bvM05dznecKzxSONSh0mawTAaaJSUYQQpzTH
k8b509PyPGFnRsgUDkldTlduXp5JSk1Sf1CtdCuzlRXKwcrxyllKibKV3BLPiAUBhY+qtUu1O7V7
tIe0x7Vira0gnO4iABqgxzEcseb3vybJE8wwNqbe4NcLGxssmkB6CeG6JrnDlNosPXsjI2lfAlGd
Qa7QhyLBTEMsRoJyf4xEdRkxCChCMQKnvWJmWxobG+vxCGr9Z1hbSUqhpAit96L2EUyPF4P3ouQ2
lJdAI6Mv1Tz02hO3XFv7xISOxaz+GskYP7i8+t6rOjeRdUOu7lX38KLOD4clyb3l2gfHZ68aN2zR
REZyWuR3TC8evKDddMH00vjVvdhfi0kc5C/k10MJHIxfHTOQbKiAwcCJTEbTCPNkw8WmaVmzDXNM
sy2bzfJiR1FOf1P/ojHmMYXTzVMLFzgeyJbn56o9dh8BTppmMhfnefwutQo4ncK/OaILFisW8a5g
pJjjaUSWFpI2eEMhWw97SJ3rzs3Orcjlc62lC88gQtKmd3Qw9AtvOZLYF1xPZtKTe3ylwi4JDGhW
DB3QHBgyGuMJB0ZPWgOwEMmZ+GGLyWR2WExdb9uZUUdJ79pxTQXA4ZS2l4ixCQR/MaXvmVeZxRUW
Fuiwhfs06eNozVQ0Yu69E0bEQ73DDqLZPOOZWq1RZ4pctHvamHEXjLsjb8E3C/fw7p6MJN+6bRb7
sMq6iDs2aHyfUcu2d34/brzRpDVnj6332y945u6Rz1xP2B8aYv/XCn8lyp4TVZ0y7r1Lfofidt0d
+jsMi41L3Es8Td47w00ZSzKVaOXCngyHl/15DdkD4S1eWiU1O5m+VdgywGZzgtMspaxeKMoQtsKd
Um2W2u0ymZwuszTiksmoS0oDIbWaqNUeNVXbsqIuF/EgtSlYY9tIKZGe3rs4LQzMbUUhEBIWVf+3
1wUoCwWeTLkxTa1SK9UKNS8OBcPB9GBGkBfrdQYdFXuDmfJAFvEY/VkkqI5kEZ/OnZXa1GIvl1L7
5Gifz5QP9nKG0U1yWhMKUsH8/bAgGU7hfTnZNX1D1uAM5+ULJt3cWcZaVpLc6VvrrYHegcVDOt9P
CcWokvHTB06be9Mvo3szqWh6edyKQeV1tdF+KA+jkB7ZSI9CoovbxrtnieeJOa0iLaLTORU+h7vQ
73c6OJmY+VpqVwXL41G1tUI8gqJVNNjMEb3eaSvIYgxOcyOFhc6scIztG9HMSCjkjLlbyYx4mY2S
kMIfCNkKIRR0AShsVCH1hdQO8pMj4aCOSi4EMlIrWyPbIzskOy4TyQpDoSyIaWI01ooW0RQMBtBo
yi7SZ+t+0h1nDn5R/1mWFOWOdbBd2RPMkmnqG4+haktps47ktiz7h9rrGGh+q99b1l1IaTShGol0
dXS3s5dBRNv12kLbvU/bRSVt13bK6TGpFjKc3sbQ3j6BUaRR0GHcHNbSsZYIe4rMd6aFnW7BjnVu
Pm2tOg+ylt2dA8YLPT+ydDxSaTX7+7VIpQL4OT6uQUTUMmVEo3HKvHZXoc/ntOfH1DnuHJoTKShw
xtCMFDEzorMaI1qt0xqKQoYmg2ZEgkFn1OcPWQsgGAgBWJEqMiuVSQuCsWAIoppobZSLMnxHAwE/
kJDGFwK7x05r7WvsewQ/RGS/SOvRENDM1yzVHNfwGmvhya1MjrpNCiJfk6IH2xhnm1QdZadpcS72
4Uwq1P8NEUj9uW/jUiQo/u80WJV8Tddp76KBWuHiHmKI77jhbCKc5S+o5H9PAqTBfLQcC9BylJFQ
vGSx50EPzdZUaAZruH7KPoERinrliMBaxdrAdnGbUsb7zf6QMuwPBYoC4iIoXQqlpeAsKsxmCitf
nUfyirLy8rKznIVyqTusiemJy2xB8xQrynQ7NZzXXhYqyg4VXVJYyOu9wTQO3b9pcY/BoKeZQV7m
uiQrK+YiBGy9wiG11C2lUmv5wlnnmBXh0zyNEIII+ox5e4dPm5fS1PcfwrbhWWquPqnnkhXNrrMs
T6Ucg7MfQJQ4AdHEd5CBkJ74bkvA5DP5u+wPGiD28VAj0TLLkkVThsWcesvXZY+Sr5awyjNb1CVg
ouR7QD67Ycf4hbvvGnzHj4vfWSxhe5MWndZMxB9cN3fbkCICX15488gkqQjG6BoDaelcUVhUu7Tl
jgebiKhpVq5BbXO95LaancNnTL6r/soHPjjpSSfFSGILMetVJglS9FKUqlkoVVXklbhS94jpuexN
ph3ZfDJUUKgiqQjB5hE8f42TOCNep9PjddqieUITZJPsjPzs7Lx8Z7SsN2vSqCvcFbQiUlVR0bvK
WZaMIxTiSCqMSAYRClNGKoaIBIV5MChPjwTS04MBZ6RnIWuqghJSEikoKSkscPb0+1xAiMyaF4pG
I56QLRiKRJIxQ1nPnnIMKPJdgQJXoCrucBesrtpQRZdUHayiVa10W9xeo3N5vVpXDo3TpZQbTPdQ
qqbj6SzK0e10G1SzPzgEwlcjKLnM+UMxjpQJuzdMYstYpCD4hBrhM7Kki3guq/xt7Z8r/+2qc+cQ
NICwhZrNNgPUhgpTHJNsNEQvpOmxgklyO9T7l1dqKVXd/crN+5eWc8ONWzo+EtR15wFB7AtYYPGH
oEFobLbLZnX/wVoKxneNsbpn06JO19khh6DILySbu8rtpq5+5LmvMQD5FnnODfvisWw+S+RXelQe
g8eY7ch29RLlK3MMOcYKR4VrkKhKGTfEjQMcg52DXUb21+CQc5RFwscSyEluoe4oAofDDU5r0hdS
oOZP+kIWHauHjUVao1GndVrcIasuZLVQGpKqQzKZlAWh2sEaorF6Fh+0dPtAjOpI7AphM+N/IOXf
UesvX0+ctc3mp3ef8wXFIcHJF3bd+F6nkXUamUz71qGsPoB46037xestMUuRrTKQX5hfXNTXO6Zy
indG5VXe6yub4k2VD8RXVm6o3Fb5Tr5eDUX5NfkjC3i1L1LUp6CycETuropX4zsrpXafPXeab1ru
vQUbYuuKjvr+iP1RJM/rDZDbhefIWXhOAwdx5HsQ1R6nNTNH2ErwxJbGaE6MxGJLc2OxnFxnZi4k
qZAGIiLKP4sQCjTFSUJk+Fm9NqQOuUM5IS4U8TFN6MzweSsL4kV8RW9fLujA5fUZvF4feHN9vIfk
hDL9ocyMDGuuz+dBSiIpLbSkONSrokIq1YTiMim00ms3e70WWV4rGfWCp3fvXOgdymsjT4GPXhs3
x2tzG3Jn53KQG8+tzeUO5R5Hb62yeBsZBR6oIEVxbbXXwzgCNOQ4Y4qq/m1k2Gn3WAgWy8qsmhO2
DgtWG23skwSmDmxWQSscs1TYjgkKo6NMcJ01ZckzZXAWZkXY11JWiLvKKiDuKMbEmoeJOYaJIb0i
uWlVt1B0Q/IDRcuZOwjZ/12XnLn3UN/4X9WJJC21CSFESP+kMbxd+oGcozAI+5Cq6yNXPw2FyYiV
wnv6NaddPdLAWlbS6rEs/w9r8nXmTbm9ItAwjbU8euvmheTtzqa/8nnHKSrqViCTMm+cW3lc+FZi
2vuZzP9ACRiFEuCFGfESdNELmYvOHEAApx1d9P0pj7yQeeQ0pLAzJ1stIzIb+nIuvc7qe+KaMz7d
P1KPvllyo/60B/YXvwxRhWrzn3zg1Gv2j2mW8MVOA3vWN98UkPB1lziTQUxNdo47R6QJWPB5duLz
lNBwvMdXziMu2gf6l+yEPfAR+dTxgfMknCQnnfIghJ1hV6ikr2Ok4ynXVtde2Ev2Or8jR52qUS6i
FKRLv5oFeW4M8jL0arVO71S6BcOqAV+tj/oyQj5fMOR0ZwumVZGXX5SXV1jkzFaIhLo0n5dKRbxT
YTcmJ7MQtcVtoZYMg8ViNDjtWelJqY7URmgkIxyJpIedWa2JRXGHk4DH4XS6CDUQlrpKAFxOlwGb
UCKdcYUrGHK7XS6HM0RYvb/DYS8pppwxZKdZ2eGiUHa2QqHk9SGlNBQuKXG6XM7iIlc4Du8Td3h8
eFZ4Q3hHWBSOhzMKwnFdoTq8JLwnfCh8HNta6Zdxo9NNxhO6hLxPKCG8w8FTymOQfE3cpPdwvIF3
Dda/rz+o/0nP662lr6QipoFMUIWviLWl2cl/9Y1YrY9EGi2aIzbhSxbWytz3jqQcs6yCqQChkpRu
5By2abjwhl0LpVmWiOgGza6I5Z8Ne+P/M++gUbAql6NH2Uj85K/fzXRJKCH/+GmNnz7c0PmiZqVg
td9mad9Clr5HepHS9wSLnvza5h2XHSVXxz6rOdcOdUTp3rONOfcds0sYzPM3IRdHyay4SUqJzGF1
0DcoURCx3U5Mdl6hFZgsLUOXlqZFiQ1GksyELl9GND09EnUG5bwwRJLPSSQ8hw6nQahjbG02G1CY
Ay5W93nznV6vy+kM2CnREVfyi3RiB30kFAy6QoEAGp9rn7cbQij5DizG5UQhlxOp0+EiGBrE7QDR
eLBQHR0cHR+dFV0SPRgVR21ZlHPp7Gy4XjdeP0u/RH9cz6v1RG+N9bi0O6RoZHG2JrlHEkGtcSTp
KpSlXAXhKyhhu6RL06uJFLU6MWgdmGjswrvrOmFj+f/YrfirSyhob6//H/V3PjlXk/N0Rsd9SVX9
jvB5laCqD9AZK5l2IkUCU/Dm9vJzdo+/4V477YWwd34HecAYUAVW0h5PvKV+zUp1R0xHLH9o/tCd
MJ2wit8wfab5TPeJaZ/lW823OolNY9MZTSYL/4buT/VJPfeQ7D7l43SdaJ3sceXb4rel0lvoYtGd
0vnKO/R3GO+lK0XSYnGxNF9Wpuyhydflm3pYpJk0oszWBHVBU7alJ5VsV+/QtOha9C3GZtMOS5tV
ul79nOYJ3aP6x4yPmzZYnrZKR+qHmOotqzX36ZeZVlkesEpr9DXGGlN/y4XW0erRmot00gxLD3WR
vthYahmk7q+p0UkVYrnULrZLM9RhfdiIUZmV8FK9WsWDxIwBpzYo59KCbCPZAzmwBkRwlSEosW6y
VV2b+gyefeLFXvd2/yKJbfumdn7ZbwvqkSe2mOQObYWuNXFy0/9V25cASFFcDVd1z3329PQcPWfP
sbM7e8zsMXsx627DwiIih8DKISsue8Diwi57sKImrIlR0BgPJIpHJJ8SFRSRQxdQ8TOoGJJgfsFE
YwLxR038REl+NEbY2b+qumd2dgE/v+///oWpel1dXV3He69evXr1GsXM0MjXu1lnnR2bBps4d53d
affWOXGgHRo5udvM41uf4lg5NPJu5lrP4uvXcKyVYyuOjZY6G35Ois+KJgNTZxOMbK3VhwKIDS+s
fJ1RjikcM7Y6gxw7sT2C0WKthSYUGIIYuriFNcZj0AQ5Cq1igYUBCAVZdYLCZtVYq8oqwPovNhxJ
HYHlRzZ8vqHx85efPwfVW1/+nGp4KvWXLXAhNEEzXLAl9eHTv4ENqbc++DT1e/xxdArsRpzkGsRJ
QqAInBGdCpfCrfYBv9XN+nPc5e4p7n0Funw2d2jkc5Hpd93qonI1+ZqNrk1+arzMevG1QElGBC0k
K4EQ8OWw5nBdmAqHnWhBEM0xIyHXFS9CYiDDx74aVVOnlaNYN4p1OU2AUHhYRH0fRmsyFOjNeBW2
UD4H+N0XC9g8GKs/L6HkSRMwMRTOkXcGQgG4c7x2B0kcf332j1NLp8+ecHXqX9DQ9Pj0bT9IHYcn
U31jKfrXG676QU6Vyzpv7g21LT/D/b58xKJYjmg6BibAIXHJ7QW3Fd+ReKBgc+KpvF/kPxHTsCtK
OsooXS5d4M7lCriiCLiiuD5RXzGtevqEpvCinKtzm4rnljUm5ldeU714QmtBa8myxHWVO4ofT2yp
fLn4hbJdiZ2V+ya8UfBGcbDYUImw/YUJumJNGINnd5VoyjCyLiww5GqiRdHq8ry6/AlFE6qnhacW
3BW+M/eHBbfGbi3eUPFw+OHcjQX3xDYVb67YCn5R8E7B36q/Kf4q8VXFNxM8FZXVExSJsmK6MBKE
SAAJBbkQWlK0IxpFjP/qXfp29RDcIFrpHEdVBGhLc6KOKB3SmtoLwRBs2gVPC3h6cJbHc7ASUCgs
LtxSqCwcKM+J8ElE4UMZ4ylE5cxXw6ewUqkujnVKzPCpU/xHThQRScD0vUOjDCBt/03U28QMSmwI
1fDmulirj60ryENBDDOECh8KEjiowAclEjio8KF8FfigRAIHFfigRAIHBRyibziOKBfCJqVatonJ
bGqQbWxpx0M+uhShyjG5YqK1ZhEs1dM9t2JBY01gwlSPgXXobFdUVeTfP6Xk8rbLOK3F6Tjw5BeI
lhE9p97+Y4aaA/MsgiPOOqxmvVPgKwwWi9LJccztUXjFXzF9p55K/T31ZepJqnUclWN9+yuIyotA
Jfz5PhAYOSTOFAK1BZzDWXtNeXtJfwmtLphQckXJIteCkj6hr/CG8rvKt+ZvKzkaOe5/RzgROV70
RcSClvAlU/wNgRsKf+S/o/Be/7/5txceFt4KfFxg9B0Y+RpogfmiHGHsojQ5yhH8Qn5BQBUsKgz5
Y6BCXmEWAV88hok8huk7FtOgxWskPx9rD/z7qRtBEbVFNALUEB9TluMBERhB6LR3neduD5I/YJ6I
XbXPDm4Jvh08E1QEsfxrtogMjDNnGIrhq67oHLsb2bT6VNOpJnLarYac+yHyBdmlRow3vbDM3pv8
rmymCkzfycoazF1+g7B/5Czq+bN7Cgzldj+aj3YlhBI0t6Tt9mQFJjaU+fYVoto+ZjGYU5ZhUI0X
LgvPP/r7Hz2yaPAuEV91P7K9K/XlR6t2X/X02tQRSpe6YiybevN7ix4rr33kH2T953ilfN7szqp5
DyJ5cx+SQDjErSaDP4r5l5Vd6Z5V1lQ2YL/Nfrtrg/vH1Zsn6aYJDRMpjBJPT3xq0nHHx44vHWo3
bqTVWYENvxcWiNHLki6nWckBWGkqLQ7RsQTew7To+UhNTcKSU6+/UxG7MzeRE6inFWiaCZCtzMqc
Jb4uH+VzNXA5YkkkFBEndkXXRe+OPhZ9LqqM8lMe3Q/9WdbAp04jwZBMG/L+ZnqDc9hCDjFIRsGS
GTjRSJcUYxtKSI4ijtu7lIzcfBTeGJMNeNMGSrJ9nGzHmxvJWIXTGyXJjXVA5eO33vlE7Mrr2rdP
nL/w41/+8Ye4W6U7B372sxcbphQ/+LvFi995dqei1oNH510f3s687e7m0jllfovHm3vHtfcc2VCM
b/0V73QufuBnnZOW+Wyu0OWX/+jWV/A64G5E1zVk9v6JmG/WGsrx9kzQ46/AG2iURlmOd2SsvL0C
rdr5EIsWGhQiI34Idr3AMBYfKgKBosB44p7rPEc9CrOnzjPLs8TTjajpOc8Jj8bztxy8gMN7lGfl
Mwh1ZLIdt2VywQbKBSic3jYZBah73icaOaKseD/1FLEJfhZ331iFXOpPGKvhQGoDiUOo3XMRPt6M
2l0MgweAB7Ee/8jXu/yMBx8EdCPJLjjgPqX62POp/1/Ul6ov3V/7zwlaPaVQQbfe/yP3wyoV65RW
6jbGRtnKeJvNyXtZScVmAkWwKAqKioqBN9+ik7TyUa3RqNN6LZIebWqkTNafFSPOFIpEo84Iq4uw
FsqL5NZgwAdhFxobygxmgSX46Gcp7/JpNLO0S7Rd2nXau7VKLV+Stc5pIrsmGGubZNcG2Quc/5Zy
m5zCJGylCkodjno8s4WVXrMSq6qK8nHrFnr4sye7d9w41ecyGXzSKuXhV34wd8MyspaVEhS1w5Oe
P7P0zRuoV8gGFlmtTrrztSt/1kJS0voWRp55CuBC0aMGamcxuNJ5RcF13vuYt73/cv6rQPcUeMpL
GThpt4MpszEMZ/MabPZgPk5CDL47QoEIE7ku8nZEEYlECyKR/AJvsADoyTaHs0sN8SndLjVax0Yp
tZqmvHoKBnh8c5rXW+b0enmnN+B02CgIfaiBiJadBUhgcTg5h8PpsOdHgnwkwEUMdEQfDAQMBj0F
oAZ7vo8UO2c7dzrPOBVOvEGpd1CRuG2J7aCNtqHr3SMO6NgPfwjs1Nu7C4nlUys27P246WwTsfdu
IrSS1lrgf/F4WndxEYOn8QZNRHfxrQnyMKM1qWy0S4ZQsnEJwbKLpVJb+1MLJzo4o5FzwGqn1Wiy
On4Ob1PBW7Y4OXThhFVSLCpqtTaDwaaVwvN2+tPsa8x90NpM8QQa2zzqgDi3y9Xl7vJ0edfbb3O8
qnyV+6tdex1zneU69jqr4igFGTvjEO2iQ+Gk3A4f7/f68qKOCqrCXuJooBrsEx0L4TX2BY71jqcc
b1GH7e+jGpJdKwszm4FMOccwVs5r5GyBXJzqCwvh7jAFwkx4dvjV8NthZfievHA4N88byAMGFcmi
NWv9WsqsPag9of1CO4Jo7h6lVqtSeg1KheDCWTjvEi/0lvNer4v3CrwTUHaHMJT6RkzYFLTAKRUK
n43j0HSQh7DFyXNOJ09BioY+pwPBDoqmIO2z2VEOOxVxDFFrRJ8zAiCkbRFaocmNBFz4vyBYI0ZV
xGig4CuwEAA0WTUBHvVfk1h6lId+HvJifjkvJioS/GAcAaFwghcjuQk+Iprz/HlL8tbl3Z33WN7R
vC/yNHkHqLVInnMgydlhR4/ZxTj6oUftoqvcbP+CnERYsIcSI+VI+Fq7SynYXkav4wCNXq2ARaLN
z8FXOchFGCUEylnKu5VHlQrly+huFEwhyvdWyXrvNMK2z3nmlIsZLhhejUVe58c8M7za5TwtmYo3
nUJ3ncznIMOq5C0crH8fJko64gFAmXYFgIFRWz9UHhivbf82678LEyT0n74zgmSsfCRjvUgNUi6H
y+6SpanpO10ZyyVq5LNdlMYxNHLmeTuTlrawMr4JUQ+29xunubFay6zWcWn072/9/G+33uwnTLAK
z0WHuv73LX9b+brEFXGCn647/++K2sweXJCOn/8d/ecsfjgb0cwg3v2lysRNbDmcEKgKldeLhln2
WbGJVVcZltibYldVNRtW2VfFmqt+Frun6sngEDsUGEoM1R9mDwcOJw7X/wF8lvii7nT9P8Hf4d+Z
oBMVWwrZegtbH2KCISaQKCuFgUSinmVZXyDBBQKJ0hDDMj5YykFYSiGJmYmYIzprhI0EIkLENSlS
H0lEyiPJkkhpRBiibhA9SOLWaVyaJJVPfZGAiUh9fV1VVV0oFIvl1mMhm62bqGQiECoNBqXXa7Db
vRAnW8zKuLIOodUSpVLpmlIaCaHUvbntXvQmfF83C5Fcl5f28pMPwAgxhbJJMyA/46wTMU0ehXge
5GeccrJpPTGPRxzfJGk8usgkNskiHhH7TmcHGP/w6s/H4C0fBm/5MHjLhwmyvjrGZLSjwMClV3UL
ZZ5M9nzZkWO70TPsEIrRYyRGT7JYa4MeJtfoeRzvGluEGf0RlkzKKRv5u2g1OeosZounzqK04YCx
1WGtkGhFSQEnulmPA8Zp5qTyUVyK4hdRbDGh1RnMrDfJdvN4U9VxCRUoYfzm0fgEajO8W9Jj/AOH
t6W2pp6+jVyfxSYNZfCO1HqC4x9hjL4WToaTrsXQxzhNoOYPD2dsW19JTZJgk12F+OInmW2kJvh4
Fs63IJxfjnC+FD6yDwRHPtnt8GM/A5+I5Va+7oUg1Ia0pXyIL+0IdZSqFrHX2pd4FwUUmkBr8P7g
1qDin4GvQ5QqoA3ZAnxIkVY7lcuLTMlOwpgxkggEC0pQym4mBmND1GuivjQWKyn1FpSC9HK0XF6O
8lbs+8mO82SMq/PDxFYmtyCUmxsOefNDwSBkghZA89rSkLUkUhCOFOQLkXxXgGWJLQQSp0OR2aWw
dIg6uBcx9YiFQZBoDkQAO4u9GxuNlWVLejNOk9OpZ5tOy4K0tF1Jdr5ratJrkyw+9+UYrneBCKgZ
KwNeOqfkXGc1WpPysh+l3cBpccqGm6vBxZad/zkubcyI8Lz//dTdpfjqExzMhRNg2ZwM3pRSTGpy
Bm9eomIZVMmF72XvuM8YPqp0pULACIx71NdAvSIel3yKjD018+G5x4kU2uTn+eGjWedj7kErg6vp
QZAHKuBS8apt6if822J0RJ3jTyr6rAOuNe5B7keu+7hNru3qLdwTrh3xveqXTM9ze1z7fEdMZ0ts
OsjDfEg/ZLnfRd0UuyP2cGybaXvs9ZLjJR+VaPKCQ9QO0ZUTD+TkBAPBPNZrdUQrAqAiCukyg7aw
YgieFBfB9XlAVxag9doAVm11F9KF0aTBkMc9wgS8anzDCAQhICIeYg7AeKAuMCuwJPBY4LnAwcCJ
gCbgqnLcXRxQ4ftdqsdUB1UnVAoVX5l/YBSNYMGM4Y9nSqb1kgVF+vBrvOk0Xj2Qs4aZlW61pXoc
Msh4gGfHg0CNlk2JkTOgHP34kbO7WU1Mk/ah1bRaNsTiUNYDwIeyWEdelb1rNQXKR31mObIOQ2On
FdL2rYwqdITcS5/jWPDi2w9sO/n7CetnDQ4ufV7QMg6dqeWR2Y/t6sYo83ry1mkvLps50LPyQMva
hzZ33fiCmVk/pb1a52QtOrMr/9GW4WNER/FvFmZWcs6Vy+cvwVquIjT28xWfAA/Ig+Hnsfy4Q9Qz
cSI7Bo0eO7628nEbz9ttQY9PTUO9EDE06Ydgy95IQCsE0BzWIubTHgBotVbvDZhRz1MqV35oHjAI
Ng4fjzBzXdwJjub46LU/yR4OPAin0urqOuwn6RSask6jKeuUbPH2bQ5Apu80yIMhzluhhcX64vDU
vKvzWvOeDm4Nvwj36V/yvZB7SHlEc0zxgeaU8lONxa4ogaXKy/T1cJZ+mu9q2KhsUjfpW2G7slPf
T92ku8m31r/Bt9//cnBvjh3NOGd26Zm8oZFPn/fZJfcYTXD1QmhBYwRsHMCajdA4ZRPMOsMJ8x/8
/RBUpf6594ONr2fZl/7s/fvuex//FJ8Mv/NG6svXDqXOvLGVOCOpJZvzhx/7058eQz/skQSNznRE
mfngzN6ATm/GGyZfiYUIeNP2Qc57uSf9JwP/kfNprjpsy7VPFmbkzMhtFJpyFuWuMK/gO3I28AY7
3i7ptXILrVfbrs9pz/3KpVS5eMbmijJRNsd1B/Mw81PnJtdW21aUN4SW42aecxObed7jkHRNYL0l
EFXrdytUnn9zBEJ6U1KzcIsf3uN/1U/5XYVcIIIHeUsEYkOZeyJ0hC84lDXOiNqIlWPT6hlnJXcl
6N8p2bZx1GxeUivh9TfiuVihl1YsqbIVS/Zsa/hQEJQnQFkp/Tq2EIXEEl713P0HXnt329Ijc2yM
xdH2+OEjqXNQf+TfaaMHU8krfpfDPXXw0wceP3b5bM5hKZh0PaTfPAINmBa+j3p7O/4KG+rvv7ww
LX95PoXnvx2SmVCcTIFBjc+Jkxh33OF2Ox1Bn84ezNM26RAZ7M4LoP5G5CAEA5wPGPScGn9Q0uHX
CoP4+2QQugpzAoNobTYEf7y7IH8wfe5ntdw/WJ1aQw4YoKXBKfT/LKaDS6svSoolD3+YCHabNKwG
s5hRutgH8pEIL3C5WMUTQTJESBPmMzwqM3WFylWZRW+pI43K2ceRFZTEYu77S8/v1q79Xe8HPyXX
3X/Y9NM//OGnm/6g+OTcSsxbnjy89uTADSduPAzflzB5ywcfbMGYTBGb3DjCZB4I4G2xQ2ffbKNK
qUnUHKqFeoN6w/or/n32ff4D9/92fuT/xm7kPfmeBFXlu8J9pX+xe5G/y93p/777x+7Nns2+F5Xm
fvt+zyH6EPuW5y2fSvO6xSUIaA1p8QYcakXAojfMcyW3ANgNsLu2j0RHUEjC5BYOdnEHuaOIFSk4
PpD/TBaKzjhNjlydPpU+Z06O14xhMrvsnAqxhD1uzu+jhkY+y7B6JArAgN0+7piGhJlAcr6nVhSd
f8r+0dPX/nai1cQ4meIvb/lD6gQ0H/4t1M3nj2/ceMwFH338zdoyM2+xMKXzofutFxHn+D+33Lnj
mbvwDP97JA0uQpiZAEfEHNEwWzmo/KHhlpIthl2GPQWvFRwr0Dk0Zq3hMMMEtYkYKIFInFO8AEAw
RmmUQ1AUXRBhbjgvCHKaogEvAKzAx4qcKq1GF0S4KOoqQCEUXEcJam4SjXGbaOu2vW1T2Pjy/n3w
17LZ+Axiul/DfEzksBqs6B8mjiPGnT5qGncMyZRf4EYDWugHBe6oH2I1ET7QesmtxDL54PSoBwiV
zZY2SoxDwkeHu3B45AUcvvDMTwZuL7M5OY31geWrBuAGwmiNw1PT0hO1D+PjuhWP2DV2lnXQjs4p
64jLEISZ30t9X/F9hJm5oAz6xJIpXDdHfRB4J+ezwKmcc4GzYdX10ZVFLfGWshuNN0dXl/04Olj2
aPTesu3RLWX7fSZKg7nBUsIgtEqlRhukgK+gxCkwDgGNpcm3sSQg6AoCYGNEjZaGKqiCeV4BCjod
o92i3amlzVqs4nxOe1Sr1LrKY4HB0D2hLaGdIcXB0NHQydCZkCLEJ/KbxyAr4RbYIgwNBmIXp+tO
YZZalz4RVj2OSWRh8QHgHjkLXCNnd+Vr0Jrp610+DcC7m4WaYhxFDWU4scgeH91kGfUL2gTLM5Y7
nNpEhUb9D1VWlGMuQpUn2LLSMZ4MbpHmvrCze/EMYqL/9ysGcu23H3/23Llnj99+5K67fvWru+46
Qh1+iHCMffMmFV6bR2y/r5yWP/H8Pgj37oUgNf3+X/9m4/2/+Q2ihUZECysRLVTB+WLRZtc5gVJA
G2xV9avugfdTW+AT1E64m9JtVf1CvUe5V/2G+g/qEy61S2NxEL5t5vwcxS12cpzDGbRE40TgKVxc
XFgYLw5GGZ3E743QuJior4OMJL/qcxbL8it2E7pDDJXHiZfQYBXEh58U0bw8NNxVQKFmdBqtwJ9w
QjRPPC7qJ4CAUHKw+GgxVTwE/2N39dTmzGlPaVFTM5xm+UTpabkkw/+uFtxN8oEnxuVWqlU5biXv
hy61R6I77KBndIttH1CNnN0rGPycJOIslPZ0JNc9o4Johj7lc8iX2muDc2ZvvGbphsXXohWGP/UF
WQv/sH/xxHhn9hENQr5I+Dk3f+qUu2cN/zNDpPQ1NxYJA8OfZZyz1aZp9GU05nYlWlIiOXWdmB/k
S3mRn8O38H38rbzaamQWcEhaVRm0C5TKoMHu4TfZkLRKv04Nwftf8KiMBh2AByDeVqDQYsOkUCgF
2ywOcrz3qnWjJtXMMBmLmrqvTo8zrgTZp1xsoXLrBZbTcg9Q99y8Dl6BGz7sJCquK77ElmpKy3vv
pa46/48sfoQkFtyyPanv01WkZV7wmFjAYOd4FENfY17oQTKcp888CAbhIDVIbzKbZmru1jym2e7Z
71F6NG68NepBNKvUa4bgsy8oFEG91GDRpFe55vECazXZN/rwdtUS0UJRNO3zG4yC1ztLARW8bz/c
C38HnKNbKeTIQHq7avhU3VfDo+ersK8UNM3hlmdanH3oTVlaUU6duPmWlBEvaqmpCxZcNi/1JekA
7fW34tYPnyf03XL9PUV+Qt4/XoZo+SAa142Ilsup+/eB6Miru+3Guig+wcYZSCzOYvV1y6y/sFKH
EjCfy8+JRfMTeeXV4bqcy6J1iRXcipC+3QpD1gorVcDNir6X817is5zPEudyziU0E3ImJFaEV5Rv
57aHVOHyUAhIzFqf4dQeTNp7gB/6/filBqbOT45pI/navzjk9wdDQU8IFJURnlBc3JAoLi5LBIsS
5RY9KcgU15lMel3Qgu1R0TpJMkZ1bibWqEE3Zy2M4PSp0ejinGg0khMszAnnhMNCeYIrL0+EOCtr
FUCIAyAErOVhThmCwaTHY0u6VZFkYVmyqKiwkNInWQvQJCGl4/BCWdsVgqGHcsKN5fvhFpCDUozd
icEEJSSKE9cl6ATmOd5KK5rh0RzTrR3UUoxW0BYjAM82Ki1fcQA+CgYlnfWowTh2xY1P5J2WtSxp
pTQ5YiBbDDqqb1fEJG2fdeTYbl8NNuc6tttTKcV8qRQ7iki8a9RUHGJbceLVVnkRb8Zjt2surasZ
nxfxsguyp43Gs2XgEJKBOU0OdnKaGPkq+9QTyoFyzZZzfb07h08ImVO5WImYMU4clUwy+p1ARr9z
gXrxpazl3uuwrYDQgREzhebUEHysmRgcnMGpydQDcE3qjqzF3zewELMG4sPk89TCjPqnF1HLAUQt
HKIWJ2gSE0ttvbYf2pD4YFiApT4k5y3AMh7rtG2yWIJOgEQ7AAULw8xiDjI0w/PZnI442bw0h7sk
d7t3LG/7B+ZtaeE/m2NDYMPeH5BU1UCpxBpzpbnKVG2eYK4xX2YWzfXmKVo2Yqgw7HHvKlTkwgpI
NXqWqpd6+tR9HmWFutQzRT3F06hWFmsqLyO0d2ICnNBQO2HCZbXBSpsZJ/kEFs5m32ZPsmdYBWAZ
VmRptsHEsmZT0JbjJ1M9CDJBKtjgCwb9vmBORbGUWMaUUWUN8bKy4niwokHEiW0n6mF9Q119vVgX
LIqrfJFYUZ7Xo4Lq/EoxCRpU+QHaFdBqaXVlRUVOjk1nNAkOu+gvL7YP2in7+YjXJ+RG8HVkMEJF
zteCuFBXi1VRoPZg7dFaupafmv+sM0vrgYCCmkyUOcAlH+hJazTZavDfOInVdOHBCiIOCHlRJ68z
KJT6nKgi1w+VKl7n8MM8Zb4fOg0uv+QNQHI2gw87NyE5wT16mFA38jlQoJ965H0kNLwP4Mg7ackQ
Sp6z1Jh/u2rJCWQUQxTvQrHk7LbJapO8khPB3jbqXVFyYjP2OkvEGE+Af72+c+LSQFXvhGsqppKT
1Q/PLIu1T2wg4KySosLL6knyh8ROmID00sbeKQ0NU5JXLhreSzyRPyDOm9I2/A6B762f7422Shej
SwWEwZ0Ig+cjDK6CnWLlcdVxDXVIdUhDPa7ZpdqloVerB9VUi7pV0+qmH3ZvVVE3+XfDPRTt8a/w
UwAqKMqnYSVNgdnmt1G2BmIwEWTHS5zSVGLC7sYb5NlEkjgZkMPkUOPETmN5gyR2liarVHA/PAkE
2CJavQGFGkmgLGvRaXWC6wQPeTwRMET4vKd4CxI+eSx5joo6stwpId7wWcTk/+snAC+KZpzbo9So
NSoNpfIoEVa5NV5J8swnkqc7Y9zFIQT58/NuTsKh1cT/RFMTEq8q5LXfBSgwFlUuED7nL/jJwutm
VV1DBv0vxHb8Byvn3rg6W/aUEWLdwslR353Thr8YlT0X3lT/o+G/j8MCCtw7ckJRg7BADxzwcrGK
tSvsnMNOvwXf0h+n/qj8k/q4XnW9usNCtVFtig5Nh26FsdPSZm13aGwB2hzQ0nqt2hAA5FQ+X0di
k4PEotFWvhNABhSD65D4N0TdLjrZgErEZ/ZFlKdLdVB1VHVSdUalVA3BD3c7EQtJrxzQ5HR6uGk1
lufTXrfHHP49AOxIOuRGzu5hOBPn2D/yIZqyP9xt9Fl8oyu6JrK5gff79HZs+M/hwIIVjFazr07P
oUCjQ4EaBxbs2M+LpDE1p2fRTRTYOYujlsOBlcNbb0Mjh0QWATodEqQ0OKBos78GFmS+TZFxiIe1
p2kNSbaeqSZ1+rVDqc8he+g1aG38y5Ytf8E/+NyrqTPQchC7iz/z7z/784lHHzl5Auuu0codUyj2
dVgk1pXozNW56FdedBVspJqMrRCNiep6Yx+8Kb8npv+l6lXde+r3tO/nvlfyseojnYanC+mb1D+m
N9PP0Cq7h5AlH/fyvMcbtEuzjJ49PGZKmRiMy7MJNEbj5qTNk0SIaooH9LpoAG5UqIE/maOKBMwa
qHGVFQKT4DN7pf1bhZcvzVZ/E7Errfw+XUOW8BdbwX+7wWS2girPUIzXBEXEXNIoQDzqJSN/ej43
NOa4N/YxJBEZ1q9gNfYlKWqMNnv6M/03/6/e1PDLf/nxrwlFdWUptR9958HNx45tfuAYvXTzNYv7
jvbsTY28mFJJ1ntILkgSgabj3qNv33Pv20exPhCN3TY0diEQh1dir4tf7TJXRzHyVZmrd4An3Tty
6DlgiasVrHKtCPSCm11rYj8Ed7lui22OPFL4QOzpyDOFv4hZngjBh6Pbhe1RWpLtTdmKGIn/6m2H
ZdYrsdo5mNWmBXfgyi1yJlksZJuKAh6dFutocgNgY1AdhryWFwZ10Kw7qTujo3WukvwAdh+1xb/T
rzjqP+k/46f9fHFajZutmyEHtxB7RYOKjWHrai6mmPlWTpo9sC7JfUwcCbI5XCF2x5nHFQyhkY2O
G1lJb37J01WSWjI8TkHzzOtEl0s0uqluolS788OXUsOQfuXknccefPAY/lFvbcYjeO719IjCb16E
cO8LI6np9x49eu+9b78t+U9XLKIHsP90kbvZBAu1s3Qr2LXsBvanqketao+kSPEflldWbtt+agda
iIiiVl4w4UP2O8RZeTPJCftggd7EGfRoTJRqI7QCzsTowjlJUKDS1TFowkPrJLxccuvM6jNqSu0q
ApwQNodmhyQV2pmQKsQXDv/EmeU2Bh+llE5SErfpZNGb9h0JLdXf3VAZDY9FHp69Vs5kZz1pUUgm
rTG+Ey6l56SoJx6fMv0W3qozWUMJvvLhg7CPyNcr8TL6CDnxRC89dn9jm8vKq60h14LtqQQZAdbi
oF5Ky9pH8fdvEC1Nhn8X13N1nokUeyVYCDomPyM8U/nzql9b35r0Z+u79ndr/zjpP6ynEn+ddN56
NvH1JFZvVdmVtdpJfqvNbqt1T7ozuClxwKyfb11U1VG1Inlj1feTG6o2JLdyuzjdT5J7/dRVmoJo
KFIiXlaTcDnNJrXNUA0SpcUhRazCbDLQOkBb+ORllwUsgXrdECzfQwvYoAD+VPREKgIBkFQ3Vgdm
+bBxMu1zNZTMCyWjtoCI50I7mvXEhV1RGOWn1KtpVUQX0F8rExYxV4GS/hkW4JMMGVtlPJJNo4bK
1VmmyrLvDFZytFhVOYkVPDnWHEetzQ+S7mo/rBRQwE5Cl/Y6px84nLWXTfDWIIHFlayp8lf4ATfR
QoRi4oGRBLJhCRFk0sO/J8kldJ6XRj4BDkSjkxFx1nKViEZ3B+01nlH9qeS+kcjJVWgm1aLFQZJD
QRWeV52MDV2hYDKeSCdzaOqczOnNdR5cDuoZnOlFLD5wOMiaSNEcfjHXUdhdcpYBNqfKMsAedaWc
GwnLXkvpm6U1J94/q5pz+10zkw3Ftz03uXnJb998c53GZiQm2LwjtLnriS1XzUm9uf7KYxt30AVe
hKr3+Fx2via3qrqgvCbPY7Y6Qzdffv2TbUHO5PI9i/DXFvMX1904eWY8LiSW13Suw/h6H5Kpkvgk
JnhLDJ9zQ6Pb5aae0O3VvaZ7R3dKp1xjus20yfQL0xv6d/Uqhwb7Md8BFLBHtGkUCrUmCBlOa7OY
GQvLKXlDdAg+Llp8yXBYnYQQqAwBXs+tVwzBp0WusFCjFSKBN4CH8Qiebs9BjxLN8x/tLsLLMfxV
GrKdcTbtegUfmJU2JC/wJyXtY7jcOr3epfUDndvgB9I+BtkWboJpErdw47eCIuVj9zXsNiS4k7PX
qar+1Y1vVHJGxmkU/rl64w5iLPwwHgx6Kabu4d9NW1omGPEXKgIz7uin4jiR+CLC/XgN6seF9FKQ
C0ZEg06x107l2aFLY9YSPmuIawwGrSZoljYs9e6Z8oZlbgBfF2En4Q1COBwQgrnQbuaEQBLk6hzO
pN/nM2u0Scas4gK0XhAAcNjxakIbZSyC5qgaqrEiO2+8IrumRnIkK9vnSOfLvvOkl9ZZs1bsqdeq
sPgBq+KkPpYIzioT3MvAhgjNjoQbduRDeQ+OmFTkZnU0GYXK0cu0RcVtzxy+SZwraWaWz/zNdtLh
X5BVwU2P1C/op3yk2++as+IlCZR0tri3k2h2uw/1dgguEUu2w+3sM1Za0Al6AbsFMQlmAa22krCK
nWBtp5ZZOriO0HMo0zYrK/ohdlSzQ7QZgZExxo20cSZxWBPUWVhpUkSt9cMslSP2RrMDe7VcTNzR
BLUUlFSMdU5Jxzgzo2K0UBAK0tetuBAAgpXjrFbOykKgk5WJbiapo5M6rSqU5IbgClFvpZJxS53l
OQtt2Q9XACvUikaRhcVsF7uFfZtVsC/D5xB25MCAbNqKBJuPiX32aZBlY19X862m2eOtUy9iinoR
01TyMbPQBUq2svEp1M6fpJ4kfmoh8Wt3J0zkwBjxOghr8PZDI21MOwMeniot59LzZdXIiOJ+NJJ5
dKG4Nc+e67iN3mbf6hii9tn3ODSAYqh19rvtz9lfsZ+wp+yaLdRO6ihFaxQam1PhtOVRUUWeLddR
paiyXa643DZfMZ9bYFvAL8hrh9crltuWOZbxy/JuUtxge9D+U8cvqO2Kp2xbHHupA4oh207Hi/yL
eW/Z33T80X7M8Tf7KUeB3u62F1AF9gLH7fztec/YD9jfUL7BfWD/K/yr42vqnP1rh0WyyjExGbMc
yaR7h1jYHYYgLITFMH0GQ1vCb4fp7vBgmMI23lQ4vJkYeAdlA+8dYnQJOUpBYzPvWVr6Cy18jth6
09j7hHYzsfUOyrbeCCu93jgx9A4KvHMTMfQeuUIsTRt6CxlDbyHL0FvIMvQWZEPvg/AkWj73IWw6
iVWD8KQYUoB5ENLzFLrcZMCVFKxJoyppCAiC0WhQdTmh85c8xBvTEbCRF4vLeTGvIMGLObko8PpQ
wLtQYLYk+KR4XR7MOwCfJBbed4oOeyMlllQnKJyPwvkokbEkqCH4pGhUCtfZoO2XnGIjl1Ri9VRx
OY52V1UnyGWBdIleQ2JUAonR8yRGheFYZO2OhFK0la9T3q2ksEE4pXwZfgiiWRTzVVNTZpY+jY2+
m7BNOPobJhbhTWmL8IKzH+ObwDn2zEPdWeyVmHxE8r9oE36BQr2pafUFZyIuligbhqc1CHvzNLxG
wYyKLrAnoKbpXHqcNWO20Xc6jV6/fN/Q8h3RjGHj9Zt2tw7dvQJriz/G8m0epDzDp2AWhbZT3PBn
1EPZVNqG+O0KRKX11I3iJr/Fz1JslWW+hXJjnYk/eB1cyXYFukLX1f8S/pL5LfvbwK9Dvy59LfFa
vVkDnODBIH0xA29i1C1IRt3E2FuQjL2pJEyak4hRWpNsMpAUkq6SZGkynAwl8ycl65PlyUQyKaYN
unNjsdy6hcrEEIztEeofqmPwxowbG3YHAnaDQQnsEBt3P2RWdiHUcE0pRfd3hx7KZUm+wEO5C83e
uKwWUHr5yTqdS5evSqo+3g/VmQ8LpUXeU9i8m2fG2ng3YWNubOhNDLrxiYPTTuZU2sJbjl3AOc6+
mwTK22Npk+1fjTPZfkY22f5qNxvC8YdYV4XiP+9y19ReYPQthpgKbCZemDET16HHGB+2zfZhW/Fg
5qmxht5owpZtvT8Utay+zuLTs3Vl+BMrVyDAorM7ai1oaqytn+hj6yAO6is9ljqIg/pKN4MgFNTj
77RBHAR0XqE2YUZBKce7axksSZdi0RnFrBzXD40c2s1wWCt9SDQiIFSDggAOLuk+AIvXUDoF9G3G
47Lv/0sY/KpC1BZ4S4Qzo9X1PzDy35nalzpAJqrUFz6X2RqBt6S2ha3o/kd43mqFbuhtxaTyEb4b
hq+n7lbbjfI2UHXqTUlFabSr0Vrzcg25g3UrX0CLRD0GuwZRz6bU9xUPIuophS8hoQE4WWewwBhw
lMNyyyyj6Dhn/VdQr7VOt14RXA6XW26w3hBcb10f3Gd52bo/+Ebw90ETIkG2lLWUWiXZxWc0xjNC
izvoG/RB3+agzxcMuoMhbD2+Y0+smKz2HLL5eLCg1KqVzOeUys2S8ZwWAuwyBU0tjmIHdMSJ25Sg
y1qKbch3iCtzc+PEiDyYHwpaS0sF6Xy8BZEpgBxgrQCWohusBQKNT8lqsYjjdnNJlwtRLoVFnHAy
vyRZUJBvAr7ZPqrbd9J3Bq81E7PxyR1GKSi7lSeVZ5QqJV+Wv59wa+kzLU2rmY8Rm0srB7KEHNlG
8XZNjOxe3i4x32/jud9V8ElfMuNzqzVMjUb6smsApr+6dkn0Grf/GKA6UzfyPpfRZidW5KvhfDhn
tXw2geFiw5/9kOAeOT4L1YgHs0abljDhWdTzEgoh5BrV9GBefBoA+nOETQ7wN1FnwqpdqDHpqJdH
vgLGka+BDijwCkMdJ25xgjo7QZnJ1rjZamXMQbsJUiwlGE2c0WgyGigTtBspAzSZBeBA0q2gN+hg
kyJp1tXpurCejbc3dRmggXf2Z6nWZsiWwqcy37CuHv02FWJpkutBStqIpvB0jdgSiRFnQvEfdiG+
lGZFYz+6M/4LPMQRQgG0wbSvUnWgHGa+ykO/O3wnVUVsGIYB1TP8lbRcmz58WR/xqjWdeq0HA2/i
79ymhuFWxSegBDy49zh7PEipETN90VduD3qCCR8+480hIBQMxywsQ5uVhdeIdWhZNkQ59wJBc41o
RpAYAIIL5B6LGY4plGEk2x9zxWPhQEA4BlyMi3Lxpd/sg9/LWOgREw4SYu8PfDyOBA+n6zSPoiYU
Zz6XUlJM9vtWW7EHY4v0mUnZ3K7cgo9nk6/V4IOuma/VSN8fUP28lHVMKvHrjC5+VvnUSWUeu92T
mHjDPKfLqBVKJ+bBf0SCRbWpzdXTlLTWgLhW6ZQWuLxyuoK2c1Y7rZheCZdf+z0nyxp0tPKKytSD
dTPIN4FT5+W+Oi5a84PwxuCvgp8G6W1B6CnMKcIfkTgmmhDgDaLAjwMHEdaKEjb8ORoUk6+lBRDg
ww8osFtn0rVmpW+GfQYQ1Kh3zdAs9W7BNSLuZ9Er9a7cpa5MJyN+jDr3JeoFUAYPwCPy58ulfpWi
CzsXxeTTlekOzsiASITqgZF0z2Y+DCP1u+Q2RZX2iEuOAZBuh4oyC+ppQWvk+dmJqfVlbofDnZh0
w1yeN+jSPV1YC5dXXaGgtUaWdZZNbk09SHraypGeTj2IetrKGrS0EnX7srqZgPw10BigCZwiIYYh
ElwYGaaACS6QYRosIrkwrMjKo0Tss12GVcADvy/DavAL+JAMa0CE+rUMa4FHc1aGdZRPmy5HDzr1
MRk2gHZ9+lmjag8lyrAJLCbfBpb+1hkWyzAEesMpGaaA2qiRYRoUGf4ow4qsPEpgMJplWAVMRrcM
q8FcY1SGNcBqfE2GtcDEvCvDOmhm0uXoQYXl/8iwAZSx6WeN9CLjzTJsAjF2MaoJVNCobgb2DgIr
EcywDxFYRdK3EVhN0l8gsIbAbxBYK4+RBEtjJMHSGEmwNEYSrMjKI42RBEtjJMHSGEmwNEYSLI2R
BEtjJMHSGEmwNEYSLI2RBEtjhGFdVnv1pC3vEtiQlW4i8McEZnBb2K8IbEUwa1UQmMvKbyPlSLA9
K53Hz1rtBHaTPFKZ3qw8/iw4TPKHCZxP4FICFxGYtEWTVX9N1rsMWemGdFvmgbWgG61W2kEzaEGx
AJ5Gv3lgOYFngC6wCv365FwCqEdXPQjGYTNK7yA5BJTSiZ6PIWgySW/+fywpnqmZAOaiO52gP5On
F6VNQ7H0vhJQjf4VgyIZSpDUieiJThTPQc8sQ3XoI0/NQeX1ol8PWIPC1gtqNYHUqh/d7yC5BDAT
xQMofQ257s3UshS9pQqFAshDpXSguvSgO73o145Ki5I3LUMldaK29YCrL/H02LdJ75qN2jsDtX7M
vUCQ9CXuqVZ0vZKUej1Kw+/77/eygFJxPTtQ3fpIHXCvCOga52khKXgs09e4RqtQilSrXtSKmWAW
evs00IB+9ajXMTwLpeLvHzSg8EqSPgWlzEUhHpepqG+moH8zSOo8YEQCGP7hNnSQUeq7ACfT6VIr
u0lfd8u1W5vphQtbL+FQF2ohbn03eh7nbka5pFZKWNFPcEIAS8ndtaSV6XfiNq/J6pl+8qyEG+n6
SD23kuSXaoKxv5NgRRvB1zaStoyUgkevjfQixtOF8tuWo/trSL4uVI90n0vv7PuWnklj3ADBCJzS
Rtq1XK5jK7rC6S0orZO0r5303sqL9leX3C7cY21ZpQzIZV7sfa0y9mCcWEqoVKr1UnlkVsklX2yE
ckmrxvaUhFcXYsWFb5bScV+vQSHmEM3orZ1yb/eS0vou+W7c+40opZO8sTdr5EfHQhqnsXSBe0d6
ay8ppwWltpMWfJcxF2RcXEVocRW6Gn0vpu1W0tMSlTYTDtaTxcEKM7l7svBWal/ff9pTuHYrSflp
vOoaU94AGf/ryWhm84p2GS9Gc3ahvBIX6Sc9jstfnmmPVK9s7Mb8CmOD1P8SVXXL+JHG0vE49G0t
GsWPaaTtF44c7mFc/mqU3kbKTremhcQSb1s1bgx6xvX3aMm4fV2En7fKXHMN4YEDWXzgu4x+ujyJ
JjGtrpFHY5TG0uVdOI5Sb0kt6CM8oO+idJweseZxfd3+X6rtaC9f+IYW0sOYytsuqJHUHoxBEzIl
NCL+PxGlFgE8Y1ahWboSzZICCkvQVRGavxPoVwywDNcIpss5i9HdEnQnIcOVoAz98FMVoBzN9fiH
S8ej1YdqNgHJDXHUX/hfDLVjPMW3EM53OcFf3Ke4ntMJl+gjfKAHSS9tZJ5eluG+zRkuky5ngOBI
n8wbR3lxutengUmoxzCtjpcmBuTS0pwTc4IBuR/xCE0kaR1y3zYgWJJ6lmXelf0GLBm1kXq3yLTT
QrCmLWt+Fkip6bp3kHHrJCV1gBvkFnaT1rQQ3GvNan8hodx0H6Y5uSQLDBDclehkdEbtJfLO0qxa
tINRaSJNd93y3If5b+8YXoRxT5KZ0hzgYj3eRXqlm4SjfdJDSu4iMoHEKftIXdIy2Ch/G61vH+m7
5YQPpHumFeVqQU+lqWCUE8b+i3gWJ/lXolLjKOwjHB2XGieywhJZnkpjxyrSzljmmf/Zdw0QTJHy
tv2PvCV9Lz6Ok2TKnre2u629uaVNeFqYt7xNmNG1qqsPJQn1XT3dXT3NfR1dq4TuzpaYMLm5r/k/
yRTHhQlzuzr7cUqvMG0Veq6kurq4CAWJmDCxs1OY07FseV+vMKett61nTVtruqgJ9V39PR1tPcLM
toEJa9p6enGRpbGqUiFvRkdLT1dvV3tfdE7bsv7O5p6rs27Lj6GnZs+dMU++2ibM62lubVvZ3HO9
0NX+rVUWetqWdfT2tfW0tQodq4SWtp6+Zhx39a/qQ0X1xmbOmjetYVr9xHnTZs0UZjUIV06rnzJz
7hRh4tQ5U6bMmDJznlFn1M1b3tEr9KV7EsPold09Xd2ouLW4CpnXox7qWtbT3L18rdC8Cr0SdUV/
b5uwdK2wtqsfP9nStYZUpn9VK+oNXA6q3MpeXEiz0NnR0rYKZW9e1tPWtrJtVV9MWIgeW968pk3o
Woprjp7sG1MZ3HEDzT1tQlsHKqxHaO3oaWvp61wrtPd0rRytVxd6V9eyNpJlAOUcfa4VdU9Px9L+
PlQ0qmbXqrbsBuX2piuF+irTFZmHEdwsrGnu7G9e2omq3dvb1pf9dExoXNXZ1ttLGk9agdokj0Vf
F3q0t7utpaO9o+XClguoF1f1daxaRp5tbm3twEPa3Cn0EAQrxMk9pG/R+/rGV6qzY2UHbhB6Cck3
0NVzfW+fhBXtqC9IYtcAQpH+pZ0dvcvxe1BZUnevbF4roPqjoepeiztutIfGvoj0x7T20cY1r1or
rO5v6yWvaelahbBtldyCHrneJHPv8q7+zlaEmms62gYIDlzYfJwPjWRbByIiacRwvkwbUbXQC/qa
W/pGxxg3rFmudfvFiyVVzjzQ0rxKWNqWLgi9p7lvAs7QOHeiUCTkVSUqo0JlSVVRcaK4WKttnI4S
i0tKEgkUVpZVCpUV5dXl1Ubd8r6+7gnx+MDAQGxleuBbulZe3oVq2ipMb+vr62zrmdzW27EMo28z
RhmcZ6AHDVGPQLAYV33apBmFQppNDKBsGDl7mtEgIbSc2NrTgWrb0INYzzL8lPSAMLetE6F7D8Ig
xG8wPQvCRFx6RwtClfaOG9ALuzv6WpYLreT9hQKpIUZyxAUG2vCYEELt7WxeSopoJ2wCj103oj6h
sVfCoraViDNhBBiteFd/X3d/H6lJTxviORgp+5qXYg5G8I2U29fWsnwVqUxrV0s/HgKChLFL9Fl8
ed/KzvjKvlXNK9viK3uXtEjdsaptIIbvfMenBto6UWrbf/4IvorLSEJyg5lkdl5JZuFVRE5GMhE0
ohllBbr+G5mP0vfnknkZz+FEiqMfop+nX6YPot8+ej/9TFZZzWR2Sl//hZTdNuZdbWNKI+UpfIoS
xXTFVMVlKKxGuZvJCrNVnhOXw53w5zQgK4eJKH+PrBVpxp77aQhpaouCAjTVTsIBJYQK+ikVDRR0
Y6NI4qb+V1U0VCoGXxXVOC7+pUatAErFokWLZmtoqEIJBo0CqHDCIgIsQX8bgpffF96G/+JH/nH+
ILncEBS3SX9b5h//8ntL5h8/o1dAreoe8mdQAa3q6q0rpP/kav6X66T/86inlGL+IIlAY9af2Dg8
/8slx9eR6FWjGujV84ByNrABiGLRTBK2Zf0NkqT8+f9a8tG6TSkSDTJqaNCEmB9PKtEckiNGAwya
xm1j/0mJI2P/WdTQOO7hoEUDjBc83Siljn9+/b3B8OUb2ODkUWCw8cI/kL9p3UdL/jU/1TiSAQZZ
LTTqgpMvv5cNT95gyQJEFq1kdNs2LXq68YJgNrnXuO7L+SMXBGc4LTTrLlIlBIicDph1jSu2Xr3t
YoF096KlomD9rQ1Bi3P95KUBy3iQuUhr03+z8w+e3zbyj+0jv3puZDx45v9HmTYdZAz3idowuHhg
NwDG0Lho27f/l3ItGfn2/+vRSKExW38vGwxPvtSF8C0tySKD/Kcb16VQmZvmj3zUOPKvi1+cxDSP
/lhE+cuxq08g7/PQULpBj2AYZP5gL+xXKCBKoQez8ysoaUNLkcLw2PxKJcn/YHZ+JaWQtoRSGB6b
X6Ui+Xdm51fJ+VUpDI/Nr1aT/IfRpWc0v/KS+TUakv9Udn4tLeXXDmN4bH6tFucn73eO5lddMr9O
R/I7s8vX02pyXz+M4bH59XqSP5Fdvl4h5z+P4bH5DQaS/8rs/AaFhtw3nMfw2PxGI8nfmp3fKOc3
nsfw2PwmE8l/c3b9DUqtVP45DI/NbzaT/GPG16jUSeWfw/DY/AxD8o8ZX7Oc33wOw2PzWywk/5jx
NSv1l8zPsiT/mPE1qaT8pm8wPDa/1Yrzk0Iy9WFUBnKf+QbDY/NzHMk/ZnwtKiO5b/kGw2Pz22wQ
4hjg3U2aUBzucRUwAHZcup2km4B9XHohgRnAj0ufQmALcGXSKdKQJein1CiBSpk6D8bdW4VhNIZa
ZeobMK682wDeXeVB7rhnnsVDacLz5PC/xj9zDDcbhEHl2HSIO9wK8sBl49IvRzAH8oE49h1wPU63
aIFBe/6f494BDyHYBSrAnLHplJ2MwQSwYGxZFG6jh9MDs/7cV+PaT70m3zONuUfKo3F5WHPVOfYZ
+gcIjjiMwGL85iz4v9bIDhplbmRzdHJlYW0KZW5kb2JqCjM4IDAgb2JqCjw8IC9GaWx0ZXIgL0Zs
YXRlRGVjb2RlIC9MZW5ndGggMzA5ID4+CnN0cmVhbQp4nF2SzW6DMBCE734KH9NDhHFCmkoIKQ2N
xKE/Ku0DgL2kloqxjHPg7Wt2SSL1ANLH7DDDmuRYlZU1gScfflA1BN4Zqz2Mw8Ur4C2cjWWp5Nqo
sBDeVd84lkRzPY0B+sp2A8tzzpPPqI7BT3x10EMLDyx59xq8sWe++j7WkeuLc7/Qgw1csKLgGrr4
ptfGvTU98ARt60pH3YRpHT33ia/JAZfIKbVRg4bRNQp8Y8/AciFEWvBcZDIrGFj9T9+Tq+3UT+Nx
ejNPi4MokDIkKYlKogPRieiIlArylUiSaEO0lUjZCWlH2mOJfZbk7NrjXnuPY+KJUjJKwW8R6VLk
hcLktQhmUkrUkOjh9pmKbKkIabt0aUCZ83LmQ7xtXl28j0vHk8Ztz3s2Fm4/gxvc7JqvPx3toD1l
bmRzdHJlYW0KZW5kb2JqCjM5IDAgb2JqCjw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGgx
IDU0MDQwIC9MZW5ndGggMjg4MzkgPj4Kc3RyZWFtCnic7L15fFPFFjh+Zu7N1jZtkq5J2iQ3W2mT
Nt2hbdrc0pZKEVr2Fi0UZHEBS0ERkKWuKC7UpyhuD3AF11AEy6LiLipPFBQUpKioPLWC7wEutMnv
zE1CW5f33ufz+37/+pLbM/vMmXvmbDP3JgUCANHQBhzkXDJn6tyGf3x6ERbcDpA49JIFV1nW/HPx
hwClOQCKH2bOnTVn0D1zHwew7MW8cdbsRTMvO/DWSICJnQBT11w6Y+r0N06W1eOIOxGKLsWC6O/I
A5g+hWC/dM5VCy9TDlsAQIYARI2Z3XLJVHL0kw6AylSAhIfmTF04Vz094TjWp2B7y5VT58y4a83j
PwFswzH1b86dN2NuispmBkj/ASC+Etjc6Yc/XOv6x9dT4rynlSolsM+j41sqWLylbHNscP1vo2UP
q97EtioEIjXAUL6x934Afk9wfTBH9nC4vO/DsRKZEwMfzAMZUNCABybiXa9CvBxQfg/MYg0xZgPu
JEpYDE/A3+EL8gVNg39hegxZDzvJB7ARNiBcCSvgfrgRDsIazB0ge8g9wW8gA8bBR/BC8CMwgghp
YILpUAFZ2ONKLKkKfhY8iW0WwyCsWw5jICn4YfA7SAIX3EcC8BT0wpPB58lj0Bj8HudZDkNhNYIB
19MP1XBd8Ajkw4TgCbgAZsN9cA+OD8Ee7O2CTaSBEjIalgY/QuwimCRMSdDY75qHY4WutvCFo527
TOHrJZKOMymHS0ghLAV98De8niaPETtkBD/GES+CMXin4xBnGkyGSkiB4aAgWhIHVqzPhg1kZ/BT
uBWuwd7VUAOXwkxpThnBT4KfYN/X4RHYSwJkEN7/g9LcH0KKa8hipM5BeBkpOQj2wiDsYWKA14bw
lSFdSdLVRswkhliJjXxNHiH3E4E8R8xQhfe0HClzH2yiJHgY58rGX4wUGwPvk7Ekl4jB9bj6IK3L
UByTtRaRMgzKg8/TNxBnIwO8u3IcwYStGFTBdRFAyuYzwLlMwFazJWDjjMEVYZCEPRjgLCQox/Wu
g9HIKR/CAngFJgWfhweJDudBydIIsBC5JAMuCn5KTYQEf6JpNI2FIYhcZClNY61Dub9K//VFZyF+
jBl2iAvDc7AEnGylcSYV0IlUpHhPa3FNJ0FM8EDwAI0mg1Ea3sF6N3HDc6RQolGEchEqMajoB1nI
u1mojzbgiP3hSuRnI3JHboSeyEWjJHpGaBqi55JztAxD8Lswv6+W1uljiSOzyR5WHgFWj9L0DeKf
hPL1Y/CH4C/kZ/I0WQv7MN/bd8EuSVJjpLViUmrEEZmMXobzGIRyOhzn4EIp/RVS4VFw4hp+CPPI
OzASvoVMUoR3fjvmlkIOzrmSWHDuT6M2GIk0qYFmwmFqNEIzzjuIdyriXW2QdAFFSY7CsaMhXZoB
6gbEZwJV8Iy0CmNAFvwMZ5SBsBj7sZZuvNMYlLHvgvuCR1FSkH7Bw8H9uAqzpf7VeL9qxKvFayoo
Uatl4XzSkffnYf9MlFUX9hdZf1zT37DP0OBXUCDplypsc5+kEfzBn5HrDThCJqRjeRU48N4aqYPU
kuFkOLWTF/FaQ9ZgagS10yK8zzUUuHbYRt6HdmhC/TcGriclEMQ7F5BrxsJVKBNuuBCtwLuQCDfB
y/A63A7z4QbUDZdBK+qSMigj9yNtS5DHxsLY4K7gLmx3Wfhql67+I/eNe6E05guwrW88bNGEda/D
dFpJbifNxE5eJi/DkwhA9pFLEfaRmxBWkY/JWnIB0cA/MDTD94jhI/gOrsaWG2gBeQ11kRF+gi9J
TJ8pwV4npetVsotsIuORCwBHu5wMxxUNfWTh+AjyDPvcAjP7WaLQZzDe80ac70a8ZuH1LF7PwK8o
b5PC5ZeSJYhrFbmErAr35MKxS4L/Qx/yAHlSsnAs/TLe7xdkBVkEb8N75GHynjRPVnMU0+H7I1eS
0nP3GomPwLo/i8nVxMFAokF/OvTRgxsQ//7zPBwaEEdoOwdCVFFCyElYidLJ8E0ik6R8G/I+y+/B
ubIP3o90L4ORs9mnDC3XHJTHOaiVEcj3uNrIFyhN1+Bqfox0NyIH3EQuRY1tlFZ9VXg1liBPtZAW
7DWH7EcueBVt3S1kPnkdta+KWjE1ARahJulh2li6RiN3hPqswesFeBPeJHPIHLSQb6NFUaO9uwYm
kYXIgb2YD13j4UoSBd3QjavwMLHAWVLfj9oRKjBOmRWmH7vbOryaUD66yHu4XndhEdOnqDdJO5mM
8ABe7SgB7eRmBBeJR20+mUzmrkGfZX1wPbmTPCPVXo6XGi8X/EKSEL49d7WT9gH5vquOJCO4Ivbz
f4UBtuPPIGIzItbhf4XfWY4B4Oq7pDlExv+TtqgdjsB+BKYLVahhxyAHMcjCKzIK8+CsqKez0JL5
cM4ZIe6TVoVBasgjjXKHPNHoPOCjNLheczGjgLmwjCxH3vobWU/85DAJ0kb6Nt1NP+cIx3EqzsYt
41Zyt3PruX/wMXwdfzE/hb+bv49/mH+U38zv4D/l/ynbJntd9p3slDxGbpSb5SXyMfIr5HPkrfKr
5MvkN8vXyB+Tb5Q/L39f/rH8mPxX002mXy1xlkSLyWK1OC05lnxLicVrKbdUWZZbHrM8aXlGkAnx
QpJgFZxCtjBOmCysFjZYqVVujbPqrIlWg9VszbC6rBdYp1pn2KhNYxMc4KCOGIfGkeBIcaQ67A63
o8Dhdcx2tDludNziuN1xt2O94xlHh2O7Y6fjDcd7jg8cnzq+cXqdonOos9l5iXOm84rjsuPa4/HH
U46XnqQnVSdzztKzlrNFZ71ny89WnK06O/ps49k5Z5eeve3s6rPBHlVPbI+uJ6+nqqeup7FnWs/l
PXN7ru5Z1XNXzz09T/Rs6Hmq55kef8/HPQd7Pu/N6fX13tL7r0BPIIg+QhCXwgLrJIqvI8+jjvgN
Kf4WUvwgqqEIxW9Eit/JPcoTPpYfzU/m2/l7+Qf4R/jn+E7+IH9c5pftkO2VnQxTXJCL8mak+Nw/
pfhJU5tpnSXGEm9JtlgkiudZis9R/FGk+FMDKD5WuEhoP0dxLVJcbzWFKd5snS5R3PIXFK8/R/F2
xzrHU+co/i5S/CBSvOQcxWc4Lz9OJIonHs9Dk8afjDtLkOKZZ4cgxcWzlWeHnZ1w9vKzi8+uPHvn
2Z4epUTx3B5fz6iehp7JSPE5PfN77pQo/tA5iu9Gin+GFPdKFG8LURw9DeDuDiYgjXdyWcHD9F2A
QBxKwF1kAeqa1h60FoHLmIwEXIHMQEZgECYXw0K045ej1agFb8/nPYd79va813O056OeD1jLnvt7
1mB4d896vO7uWd5zY8/1PZf15Pc4AL5qAvjycEhJHr3p6OovLjp649Ffv9hw9JqjL2JJO8LKo0u/
uLrr8q5FR7d/5Tp6Z9eGrnuP3HvkkSO3ofF6gvXrSj7SemQK5nKOiEfyj9gPDztcfdh7uPhw0eH8
wzmHMw5bDxsPJxwmh3489P2h44e+PvQl63XorUOvHHr5EGI59Oahxw89f6j60NBDFYfsh6yHhEMm
wy5Dj+Gs4TfDF5qXJUX+suIJxcOKhxQPKh5Q4A5WsVuxTfGsYr1iLaY9CpdikCJKHpCflnfL/yn/
Un5UfkT+lvxN+evynfId8u3ybfKt8r/LH5I/KB8uL5edkd0hAz7Az2Y6hlz5O0NrCsGA/CBu1Ln8
Q39qfyO1N3OdUnzwT2vfQvgEd8838yv5Nb+v5W8PwV99+AUM+IXh3FX/aR6/63khf27+fO1/be3m
i35XcvnAWfz/+HDo690IN/Gz4F7cedwMd8Jt8DDa58dAAytxOW6Au+Ek+pJ3oJ99C7wGh+EE+rpP
wb/R8zqFO+JncG/1FvqA0+AS9HWno1c7A72D3fAP9Fvehz2435iJ/vEHuDN+Di3+j2jb96Ovug/t
/z/Rb70VpeQyuAJ9ktm4u1gHLehVz0Wffj5cjRK0AP2L4yhLi9EvuRZ3K0vgRViPvs8ytHrXob/7
A/ru95L7CCUc4YkMzkIPevj3o6/wIHokASInCqKEIHkIPZG/o8e8Du2UikSRaNyBP0IehTPwM3mM
PE6eIE+SDWQjeQr3Ws+QZ3FH/jzas02kg2yGX+BjspLcRl4gW8hW3EF0oncRS7aR7SQO9/5a3A0f
Rc8zniSQHWQnSSRJ6DG9hP7oK+hlv4q+WTLuHp4HP9ETA3pabxAjSSVpxETeJG+h1/wbfAlfETOx
EIFYydvkHbKbvIs+0Puo2/9BbLgDcBAn+YDsJR+Sj9DP2w/bSToZRDJIJhyDr8nH8Al0wafwGXqZ
R+AAfE5OoIf/E9rif5F/k1PkDO4ffyG/kt/QZzpLekgvCaDnFGQbeEopR3kqo3KqoEqqolEki0bT
GKqmsTSOaqiW6mg8TSDZNJEmEQ/Jock0heqpgRppKu7xTdRMLfR2KqDvmEvyqI3k477KQZ00nQ6i
GTSTuugt9FZZrCyOnuCu427gbuJWcLdyd3CruLu51dz93MPoGTzObeSe5p7lnuc2cVu4bdxL3Kvc
m9xubg89yX3Ifcx9yn3OfcF9zf2T6+ZOcD/Rn+i/6L/pKXqanqE/0184OZdGf6W/0bO0h4viorkY
tIQEb+wR9DEe4x/nn+Cf5DfwG/mn+Kf5Z/hn0Qo+z/v5TXwHeiAv8Fv4rfyLaBe38dvRH9nJv8S/
zL/C7+Jf5V/jX+ff4N/k3+Lf5t/hd/Pv8u/x7/N7+H/wH/B7+Q/5j/h9/H7+Y/4T/gBa1U/5z/hD
/GH+c/4I38Uf5b/gv+S/4o/xX/Pf8N/yx/l/8t/x3/M/8N38j/wJ/iT/E/8v/t/kK3KMP8Wf5s/w
P/O/8L/CJuigK0kBbIGt8Dr5Gjajz/0GXA+vwgo4Tb6lu/ilsBPuR+/6NXgc/kZ8sIpUoB26C/2B
u8k10Ik+fjf5kZ/Lt/Jt/Dz+Bv4q1E838lfzN/ELUcet4G/hb0VNdxt/Dfpht/N38Hfyq9A/WM3f
jx7Cg/xD6Jndi/7ZGn4J/3d+Lb+OX0+P0C56lH5Bv6Rf0WP0a/oN/ZZL40xcIVfE/Zs7hfpaDueO
LQk7oaK/0zBYyfEyuUKpioqOUcfGabS6+ITEpOQUvcGYmmYyWwSrze5wpg/KyHS5s7I9Obl5+QWF
RYOHFJeUesvKfWLF0Mqq6mE1FwyvHXHhyFF19aPHjB03fsLEhsZJF13cNHlK81SYdsn0GTNnXXrZ
5VfMnnNly9zWefOvunrBNQsXLb52ydJly9uuu/6GG2+6ecUtt6687fY77lzVftff7r5n9b33rbn/
gQcfevjva9etf+TRxx5/4skNG596mnvm2eee92/q2PzClq0vdm7bvmPnSy+/suvV115/48233n5n
97vvvb/nHx/shQ8/2rf/408OHPz0s0OHPz/Sdd4rPu8Vn/eKz3vF573i817xea/4vFd83iv+f90r
FmsnjB83dszo+rpRtcN95WXe0pLiIYMLC/LzcnM82VluV2bGoHSnw26zChazKS3VaNCnJCclJsTr
tJq4WHVMdJRKqZDLeI4ScFfbhjVb/M5mP++0XXBBFsvbpmLB1H4FzX4LFg0b2MZvaZaaWQa2FLHl
zN+1FEMtxXMticbiBW+W21Jts/j3VNksnWTS6AZM31Fla7T4u6X0SCnNO6WMGjOCgD0s1SmXVln8
pNlS7R+24NKV1c1VON6m6KhKW+WMqCw3bIqKxmQ0pvzJtrmbSHI5kRI0ubpkEwWlGmflN9iqqv16
WxWbgp9zVE+d7q8f3VBdZRSExiy3n1ReYpvmB9tQf5xLagKVEhq/vNKvkNBYLmO3A7dZNrl3rby9
UwPTml0x023Tp17c4OemNjIcWhfirfInLz6W0pfFwXWVDSv61xq5ldUpl1lYduXKFRb/utEN/WsF
FjY24hjYlzqGNa8chqhvZ1RM8eBE2PTZrYRuaoatmpU0X27xq2xDbZeuvLwZF8Sw0g9jFgkdBoO4
LXgUDNWWleMabILfZ7Q1Tq1K3ZQAK8cs2qwXLfqBNVnuTRptiJqbYuPCiRh1/8SMc3VSSmrOUiPG
nCMnYTOyDUc28FsuseBMGmx4I0NYMGMIrLxkCDbDTyPBXv7puAyX+VWVzSs1Jayc9ffLHOjErjyN
Sr3Z1v3DwJKp4RK5Q3MaWJIxxzkGw/pI2u9y+TMzGV8oKnEhcY7lUr4wy72gk+6xzdVYMELyQX0D
dmss8SDNBYGt6m2dIkzDjL9tdEMob4Fpxg4QPa5GP21mNbsiNYnjWU1bpOZc92Ybsu8L0nY20a90
nvuL0yTFV19a4idJ/6F6Rqh+xFjbiNGTGizVK5vDtB0xbkAuVD/kXF045Y+vbOCMNJyiRk6qRU68
+FxjlmmI8fMO/JNLnDy9U6FEVpRKiGWYX9N8QShsjBKE/7FTZ/Ak6yVFfd3C0/SXuAbmSwfkB0wv
ZiWHE+addMS4SStXRg2c+iiXP8bhVzmQK/xqhz9WSsc7OpJix7ss/thmByqQuHMhC4hmfMN+o9Bo
abD4x2WiZvGmnPSc9PrrUdz90Q7kVxbKpLHipFAtDZro8Cc7UojG2+MtLvOkHD3JmkU5GPo4KVQ6
/BqHXyulkxwdei2bgVbCrTsXsgD+MAM2AY33v88hTvpLdvj1jhTQeJU9EJ6LpB/8JET8+oZm49RG
JnnsT+YY3+CXS+QVmBoN0ytWQqGR/kLDjkO59de58A+ltPG6kGQKoW79PjgC5ySa4aVZbhumQEpZ
nDb8wxLGlJZmFEPHyiFGm9DYGQw2M60qEYA2OyysemUzJm3+sZms1mkxojpodjZiNw7bDkNTsnLl
MJtl2MrmlVM7g23TbBaNbeU2LolLWjm3ujkipJ3B7bcZ/cNub0S+vJSUZMG24C7u9OYSb97eigTu
NIpTuxTGYehB8CHUIaxCeB5BDiJ3qkMVk8f6neooLsmriGIp8EJ+sA3jsRhjfvPoMXnmChMW+BDq
EFjlXgQZjnsKmhHaEVhXHrGdQgynYC3CCVaCQ/yro6hEwvKvjlHj8ipGsRQ65vlSvC8cbw3Hj4Tj
m8PxTeH4ynB8aTieEI7HhuPycFwWjr3hOC8c54ZjRzi2hmNLODZL8U8dY/Pb8WZ/QsI1c/+EuQht
CBzUY9i/pB1hHYIfYRfCXgQVjnBSGsHInZRGOI7tj2P749IIxweUtCOsQ/Aj7ELYyx3vUOksFSJ3
I+QgsLgegcdeD2CvB7DXA9jrASwBDDUIFoQcBBGhHkGONQew5gBQOMrtg5MIFMv2Ydk+bL0PW+/D
1vtw8frnOO51OgU3VGbuMdrUMd3sQRp04IJ34IJ34NyPcvtxrP3SWPtxrP3Yez/23o+990tj9eU4
blIHN93cyb3WUcmiVzcL081xFblcJQ5fiTxTiTdUiTdh4YYikXZheBSBIu8MxdqhOMhQbDEUb3ko
yLgazgVO7OmlE6AQ41LMs7iEc0txcTgewrk6ChGPlcvBUXKQC3Nw4nFcOubSMZcu5eyYs2POjtPM
wdCOPdMxzsfYztlYHhfR0hGvlzjW0iE4wonsvLyXOIGOh1KpibC5uiavuSKaS8V5puLs0zkjHECg
WGnsyM2Tuhk7htWEE6PH5lVouWQ6W8KVSE8jy5m5BIwzMI4Px+YO01DzNlJBG3AVAPkoBqkdg6SK
QfrGIGlicJ1jkDwxiDYGOSIGOSIG+SgG+SgGiRmDfBSzOVanEzvp7g57/trt9B04Qd8Rx1OLQNbK
TsjoWtwV0LW4waFr6QlKX5G/oqBmuU8+Rd4iXyWXmRU+xRRFi2KVQuajPq6O1nG8dAaabnFbamQa
k0bQWDXpGremRj6l4jJ6BS7iFHoYCD1MW5SAt9VGD2GZhX6KYQ6GIgKFZgznSqk2DNul1DoM/VJq
l9Sa9WmT8ppz/VjLvQhHETipXOpLP6WzJWwWehCxHMTWB4GjB+kGqVRDD2ANkwMW5iCICPUIPD1A
H5DabKCfQCfCQQSOfkKvQMEy0487CuLMFb30YzpByr+P13t4vYvXbrzeQYLGSfCudFe7ce67IYjA
gQ/LmxHmIrQj7EKQIXXexXtbR9/H0IOhiNCMwNq/C6sQXkHgsO4dhHexlI01BUMCy+kSWEw3Iabl
dCHCIoTFCNeiAC2nVyFcjbAA4RqpZC5CK8I8hPlSyWyEOQhXIrRIJZciXIZwOcIVWNKCOGZIOFoQ
RwviaEEcLRKOFsTRgjhaEEeLhKMFcbQgjhbE0SLhaEEcLYijBXG0SDhaEEcL4mhBHC0SjlrEQTBc
iLAIYTHCtVL5VQhXIyxAuEYqmYvQijAPYb5UMhthDsKVCC1SyaUIlyFcjsDGL5HGL8HxS3D8Ehy/
RBq/BMcvwfFLcPwSafwSHL8Exy/B8Uuk8Utw/BIcvwTHL6Etm/iSiiAiKEEEJYigRELgkRB4EIEH
EXgQgUdC4EEEHkTgQQQeCYEHEXgQgQcReCQEHkTgQQQeROCRbsCD43twfA+O75HG75LG78Lxu3D8
Lhy/Sxq/C8fvwvG7cPwuafwuHL8Lx+/C8buk8btw/C4cvwvH75LG78Lxu3D8Lhy/Sxp/OZ2FjPQ0
wnPIXMvpJQjTEWYgzJTqpyA0I0xFmCaVXIRwMUITwmSpZCJCA0IjwiSpZCzCOITxCBOkpZ8FlyOe
GRKeFsTTgnhaEE+LhKcF8bQgnhbE0yLhaUE8LYinBfG0SHhaEE8L4mlBPC0SnhbE04J4WhBPi4Rn
CuKZQjfCJMTFhOUShOkIMxBmSvVTEJoRpiJMk0ouQrgYoQlhslQyEaEBoRFhklQyFmFcRRDD8QgM
Ux1iqkNMtRKmOsRUh5jqEFOdhKkOMdUhpjrEVCdhqkNMdYipDjHVSZjqEFMdYqpDTHUSpjrEVId3
VId46iQ8PsRTgjgopi5BmI4wA2GmVDcFoRlhKsI0qeQihIsRmhAmSyUTERoQGhEmSSVjEcYhjEeY
IPHdLMiUcHgQhwdxeBCHR8LhQRwexOFBHB4JhwdxeBCHB3F4JBwexOFBHB7E4ZFweBCHB3F4EIdH
wtGFOD6TcHQhji7E0YU4uiQcXYijC3F0IY4uCUcX4uhCHF2Io0vC0YU4uhBHF+LoknB0IY4uxNGF
OLoYDrqEPEGvJQaUkrMoLb+h1KxH2ViHMrIWZWU6ysxElIwalJBKlBQvSkwOykUWyocb5SQd5cWB
UmFF6RBQSiwoLSY6C8eciWPOgLMVNpz1bzj79TjHdTjXtTjn6Tj3iTjDGpxpJc7YizPPwfll4Tzd
ON90nLcDZ2fFWQo4WwsdK+pN9/4y3XwrwjyEVoRchGyETmIQC9EzOouwDqEGwYuQg5CO4ECwIlgQ
TAiQlIQbZJ1WKVYk0zKKfgCoyUtSuEoK75TCa6TwQimskcISMble/VK9emW9uqVePaVe3VivHlav
LqlX7yABWIYtvhXTlqlXL1PfvEx98TJ17TL10GXqimXq4mXqomVqD6Yt5AfixYaPSOG9UngXC+Gs
FP4ihUelcLIUeqXQIoUm4u1Qg6qTnO4QyvC+T3UIdRh1dwjTMNrYIRSYd5InQOAJmMljHcJkLH20
QxiD0awOoRCjmR1CLkZDO4RKjCpeEHLMvwmdPBHjzF8I88wfCbVmv1BsXs/KOsxrpapo8zzBZZ4h
ZJqnh4onhqJKFm01lwlPm7NCJe5Qyfh4VbyqvZNsE/MV7W8r2psV7TmKdpeiPVPR7lS02xXtZkV7
miJBqVNqlLHKGGWUUqmUK3klVYIyoTN4VHSzp/IJcvbMGuQ8C3kpraEsZA/wCQAlSgq10LydlqGb
ULaJDvbHcyPoiLFDyQj/rktgxDSL/8xYWyeJGj3JL7MNJX7dCBgxbqhrfsoIv37sCP/Y0ZMaOmmZ
v61qhAU/fv0YKburqtHvlJKdBDCdF06LmC4Jp9swXRNOY/tG/2DXiE5FcIx/iGuEX1V/UcMmQu5s
xJyf3oKjjGvoJEFWdJORHd1tA0LMN91hZHHwpjsaGyFpgS/FpyvXFg+r+pOgORy6+j4pfUmGu36R
GGN+TmGuVpjzFWabgpWPGIuF7c8p2qsV7bgQocKUNP+9I8Y2+INpeGPhxAhctbGWixu2UR8tq67a
RstZ1NiwTb+O+qrHsHL9OrzJc+1QOH3YDmXTF24HDtYOHL9rZ6XlrF06i0LtrFI764B2m2qE6qpN
ghBpUyO1qRnYZt3ANuukNuvCbbhQG6Ffm/ghIEhthPghf2hj/R/apP9pG9dffWYM/cuq/h+yDcaQ
rk2lC9gpa7OtegZCs/+2BZem+NumWSzboJR0hQ9gnc3TLrmUxVNndJIu24wqf6mtyrJpzII/1vsX
sOoxtqpNsKB6XMOmBeKMqo4x4phq29Sqxs11s3yzB6C7NYJuk2/Wnww2iw3mY7jqZv9J9WxWXcdw
zWa4ZjNcdWKdhKv6MiZ99Q2blDC0sfLiULyZRkch1zcbhcahSZq55ZIIlAopy4zbeSAbINrV6I+x
DfWrEVhVVkVWBatCwWdVsewIPVyVsqxUMG4nG8JVGizW2oYCisAfPtVV/+evq6TP/P/h87+0hEj9
VSnVl1X1/5OE2nWVaz7+ua4+NxDmcGCYHy64ar4LkMZiTHN6s7u5hms2NQt0/vxGVvgS7qrYroft
rwiWkasAmS9MGuwY/uAooQSw4YCV4NgkFLEp4lDbAbhlOEgjmX/V1dgQgz/9RCqkVvy3APzfwIix
iZsmfZ+yKwxfBpYBq08M9KISP4DKfE8YQp+ZsIekY55d98JTGDYirIAV5Gail0rvho0YLoYb4R52
i7CcbflIAzyDO/898Cm4YIL0XcVfMaeDt7B+T/AnGAr7YJzUfhCW3Yf5N9h3/qgZDcoe3gH7SJD/
nui4x2EBWU7+zU3B8e/DEQL0lSD7vtpN8JDSHXwOnCDCHFgCd8HDJI5Yg1cGPwU5JCHu6uDjwXdg
KtZugk7yLFfPLw2uxZ5j4Ur4G7xAsvlmfnfvV4Ebgi3BjyAGboUnSDQR2BcGZZnBiZAKQ8AHF8N7
obsnFj6jNxj4PLgJx3dBBY60HLHeBa/BXviJVJF9vFMGARI0B98LfgYKKMe+qwmHl4ZYyTDyNE3m
PuB+w41zCtRg74thBsyCFpgHT+L1DM7yBCkghaSKVtEmegtdTV/n7uaX8stwZZbDDgKEJ5lEJCPI
WPI0+Yh8hNRaxC0NAM7HgvdbCdVwITRJ3xm6F96RZv0p9BKCM5hJWshS8iBZR/aQL+gb3Dj+Av77
4MzgjdL3I3VILwHSoQxHGIfr+xxshm3Y+wvEqMe55xMf3t/19EK6gCvg6rmLuCVcO/c4t5+fyD8X
KAj8GLwpuD64M/hJ8FCwG8fTghWyYARSehw0wLW4cnfBIzjqq3AA/kVsZCi5klxP7kG/i70nsJN8
QgJUTZ/miri7ua084UV+Nf9WQBt4NNAZOBGsDjYGe/D+psENcAty26PwBHLcCzhaF6khF5LRZBJp
xhFvJreSJ8nr5AfK04vpFs7JtXKLuWu51dxp3sEv5j+WLQg0Be4ObAvmBOfjjG8Jfid9L1QPg9Fx
GQeT4TLkjLmwABbinJcgza9nb3VI1x14B88izhdhB9LlKPwAp4lKeoshjeTgNYSU4101kKvI7eR+
8hj5knxLfqYEZ+KiRXQUnYXruZ6+QffRL7hx3DPcTm4ft49P4kfy45ELn+Sfk4FMKy9Tvn/2057n
e9f0PhCggYxAU1ARNAZTgzXB54OvBz8N/oiSawE38uUolKkl0I5c04kr9R5y4F5c66/hW+QhmfRO
hZ04yUhyMbkOKX0z0voh8iheG5FzniedeO3Eaxd5k+xF6h8gR8nX5CxB5qVO6sEZX0xn0mvpBvoS
fZ0GuGjOyNmQnl5uBtJ0KbeCewLv4SPuJ+5nPpaP5518KT+D/xv/NP8q/yl/VlYjGym7Rq6V3y5f
FdYce/q/LkOqaQGOT0kjyn8MUnwLfYtmoUTs+b9w3Up+hnfIUPia9CKX34rXdXAc5WgirSTfICc9
Qgazdy8ph/ujW8kuWAfruWfIJ/QGuB2lPxu+x5DQS0k2uYWmoja8i26Gr5Az9qC8/ERrML0HVzoF
9nB7yFzcMfyL3AHse9jNNBFmkY9gCLmFVMFsmgE2uIrsAenNLJnIE9lFqG9nMd3Lr6bf0dXkBO7A
1kpzvp1MhXUkA/ltD7kInqddfBH/EnLpMJRSA7YeQ+VkEfLmQ5SHJ+lbyLubUM5GoVTch9K7DuWk
Amc9CK6CSjIavdqfiQq05Fbk9skombfifJ6Gp0kvF0Bcw4LbJThOc5DPVwN7g2sb2OGp4J3wMpmG
cvwCiYKH4Au4kDvFJ6LFOMmnyaqDNDANDgZHw7uosTTcEbgADpHbUG9cAJ+RJHgwODtYgNy4J9iI
87wRLoXxsgqZCbXxVNyjvqpYJz8i98pz5US2WDZdNkY2QlYpGyzLlWXIBJleFieL4k/wn/N7+Zf5
x/jrUXaz+UQ+hjuC+nMTdz93G9fCjeR8XDbyZBrH01/pj/Sf9DA9SHfRjXQ58eMsDwXfCd4frA+W
BQcH4wOBwOnA64HnAg8GVgfuDLQF5gaae9/o+bxnX8+mnsfJmd6DqL9eJe8GzqINuDo4KXhh8AzK
W0Lw7mBZ4ABZhffogF6Ur/dRr96N6/IY0rYBNZxI2fdqA3AaupFCn2D9Ntgg/SpAM0yQj4M6XG8n
SuYNYW6cgbr2ScxxuFY6tAA+pPiFuCYXA3v/Kh0t7RvwTHA9Nx7H2CQJy5P0A2IJPArpqGWuRPs0
Ar4i5fAdXi/AC70PsG9ay59ErNvkG+G0/GHubFjIpv9nIEeQ84r+A8zuA9mVIZD3AChnoq+HO/aY
20OgntkPjvdB7JKBoL0TIP6pECTGAKQ0AxgeC4FpDID5IQDLZwAOxJE+rg8GjQLI+CUE7nUAniEA
OYcB8hNCUDTvv8C7IRiCeEoQhxdxl30J4DsFUPEPgMqPAKonAwxbHIILdwKMvBlg9PUAYw0A40oA
JrSHoAFpcNFvAE12gMn39MHUNefhPJyH83AezsN5OA/n4Tych/NwHs7DeTgP5+E8nAcEyr4NI2M/
7MaBAkpFk1xxEstk/EkOouSykxxHDSoFf5KAXjni2hTXKM0p78he7yjNGe9ITa8XfN5eL4PcHEEr
aB0YEOChx8Lt6hHZd1ct/C4c/O/BL/l8mQyiIRlcMBgqYYuYrU+x2vhBJilyGG1Wa54+JUGvT/E4
fA7qqEq0GHOM1FhVyuWZE0liJ9kkRsXlqaAwT1NKSqVsRZ4nOi/PXE7KWVY3JM/j9rmpe84gQzXk
aWJIDCtW6/Is8hw5lc8x6asu30aiQbqLkaeaes80deONhFPgY6EUaI414d+K2GzXUs0boNUlFxMW
5OaQBLnN6iwsKMrPS1IUOG1WeWJCUn5ekUwWKh9cNNjB6hITFHLuL9py/MaFC596auHCjcuaK6um
NFdWNpO5vTGp6mR7bJSDnkpVp9hio+KfCjV6ajlrwID7auFG1nPjoqopU6qw7MfTKmdaolYdc1qV
bkzSqgPVCzc+dc25BlOmsN/y+AIpP41fAMVQQR7eBhDcJSbHJfhaSsiskqvgFcI9o3om6vnoF4v5
qM7grs1YpQrH0RiL6ZiwkWoYkTaphM9QQnFxdEJFiSleJXeXVAAXX2zKIfHRxcWd9LA4xBSfYDLF
lxTHA0+8GVXpcwpq4uweu89eZ+ftVEMshJKJHpVPVaeaompRLVfJzSqPiqo66b/FaE20JZpGT9TF
RyV00l9Eo68mJTrno/S/uXfKEx6JG0yCINfI58rb5bx8B/kbctBgOkWMEjaafrV4c7zU20mbRD0Y
GdOIxnpjs7HN2G5cZ1QZ9UOfD/Ft08juplOnujW4wBie6sYV7z6GvNt6qrWpt9XrweJj0jqzhV8h
W8pWvrg4tPjFiliv16vQxCKjp1QuElPLyguLrDa9odA22Anleq8TiqwFTlJm8Dkh9CrBdfghTTDC
nzB2hN8xelLDSxAdPAhRwaOgCh7dBBYyBD+N7KWD1iZocpHB+XnsK6RyhVwRSths6ZgJMdFgZ5iV
kkP8JVconOkhpkpWhDhrMOfNu0xMycm3652jk3N9tYtTsjLKJm55+5KZbuPO66wXOO26TK+QNyHX
lGzyiKUj5o2aWl5A7nsuzlySWUyvEONMJVnFFkuMbtudUzd5h4/OXrJDq9OUZdqyjNnuuGhfhm1C
b+Hs4qEmILCTHOcT6KOoNQxiDM0CMMiInm+7n1H6mOYb8IzsRnERCgU+oWcD10CO72DcuAG50Snz
QBwIsEaMGp5QEyNLq+HVwg46WXp/bfIWAGKwpbC8CvSYVypVeuvd28gUCCsfTbemO6R+MIFL6ENE
I/xx9YvEImpJcsQ6dE6jU+4wOxKjU1wQr9a4SKpM7wITJ7hIclSCi2jjMDAo0lxgoRhI7x31vadx
HUlMoEh0WlhYoENa6xQFjNBIZCQ1I3NRIe/89sCSp+//5sC1Tz/4j6bC5qbSxskFUy8ubaS/fvFO
4G9ziOOxL94mLbMDhx5/cmn1hfOf+mLDEhbhLV4JwCcgBRwkdRvywi6xtKZwkWW5bbl9iYN3RGfY
XPYa+832t6LeiFaMiBoPs2GGfZpjFZxxKHRWjU1j1zj2Wvfa9tr3OpRqJqnlvgIWi3ElhWuFXeq9
aq4tisgJ10mObSYcRzrJDy/IbXZI7qTRL2hqTDJJvofWFEjxhWOluGNcIUrhyK0EahTKGPV2OgsE
Ert1rpzIDekoj7NEleEnJYjpFQUQ7i7Fw8dijLVRKpVZuUpJlXrndnIPmRxaqya2RkhRlDVcsKaR
p7olc/E1Fvm6u7XFxUTTW1bsSQHNaVSzrfNcLmQZlIXWJpdDkNg8USgEpHeBRH+FPCwLEQmQkyfJ
qw7BM7hnEs2cX3LDnCuHO5Njc+2ZZS0fL33tl5oVl+8xlY+Y9inZfUOld8R80VqZafcO8r4w+/sn
x9/VNgNXYwXyo4irUQY7xWgV2jj6C/lZT9m9icM8uQX74ZCeKkpSVMkll+lnZi2SLUpcWNxaplIp
VbEFYK0xp+ak0tTUIYpYMVpdEBubUKNQx+Wac2lurqtmiMxsZmQ6utnmkMj1QoqxAAZ10skdpaXJ
25HDOUSj0iQWcJyvoIDp262ahAKIJtGeJle+R5vvcXXne7rzXS5tsQfNU56niQUuVEee1m5mjlxN
rS5oaiVJjB5InfSQkkhOYozK6JaOV6hscDk9R8ewrQqRkbvtoknXfPnijwsrSzPTzO5072Wb1zWN
yroif7A3e6ZiUH3u/Pn3jEqOTTRkei++effL31TRZ8sfnTFn25TazBJ3WYIpKrZpvO9qi07BFWe6
vYR3j8yomDJBr4j2uqsrphxcU3crk3z2K/k6WSwYII2OEg3L01alPZzGeVMn6OtTZ+q36WVFepIm
lhSmdQbbNrvG+9IYeyUMCsWDEljcJo6blOVTGmRpBkOGwZZWbKg1iGlT0q423JP2eNrWtE/SYu1p
uWnvpnE6XarVYCxIFZ2FqdbowtRaXJwlqcSSlpN2rYGLTiM6UIS/nU9gO32APkgfEtWm4dD361b9
SyNf6FcqwqVbTcP1KalpaZ30GjFGb0CnxWBIS0pJMzK+0WqMPqOJmBQpyckK0egsULxMx0ASKMkT
EAup9BZRDQY+LjZGX5fiT6Go6kZjLU9vFqOURKFQGpOTk2AHnQapoKTTREMqJFmScpLEpPqkuUlt
SeuS9iapWJYm7aT1YIK7JXHTnGlt8qJC1HjD1zEmfyhvPizt9QZcrKy71+Vlxqx4RbaLZ66Nrpi9
KIuMVMleR01DUntNEslF1eBUX5qYEMNyRzYjMVm81VloQJpKDWKNGp9BxAqDNTq2QFqmKG2otSZR
ijfFFfd//61RsnL4Ye/k2VLbcJFTRVzhVBGXN/UYLm1qG2JPbUPMqSKOFeknvcQXlSYabQVGFmAR
aonQa3mtTWQe0Up8bEsMRULI6covFApJvJZwd1ew3yAr99UGumt9vtr63n3k+6GBA7LYniPFWVkl
Y0qysoqLs7OKxzzNVfUcIb8ElOz16RslzRALmfCbGKePJko9pKYg2/FWJZFuPzGlgPxkrGnnSAtH
uO3kNzDTtA5bpqQ7Yg02H4joOwGjEHSSJzbbbbymk9wtxiTWqNRT0lvSl6dz6dtJO6TQyaKuGV2b
NubcNGNE5QY32YE62MpeSBFVqPctthwbZ2P9481qj7pN3a7mc9SiulnNqfWu7cRHbgnp3FZUsxIj
jGIcMbL7WBMqDublILW8mt7e1qbuY7jg6MKkJBl4pYFPcZEkJQZ6mRHNoyLRFfFekMYkEXWEDokq
RDTLOcXCFAlTI1ohRHWyfV7TS7/1Bs5+c/Mo9BjGZInTt99yw6yWOy0p7lI6n1GerzhlDwTe/+jE
xLyKjLJKdfw11y5aeYFWzKf1jP6M6muCAUlLxMNqMRqUv5fRLaZaiIqOZs5mrhYStFqIjo+NAtCZ
iQd9y3UqJR8bo9UqouaqdqFfaUhUgmKuYpeCU+gT0IU4Z5bQGHkllerDvUwrstcLRDQUsnV9EReO
sIVjjIcig0Yq4g2mMDkRQjaoUEgkYWs0mCsJuPgid3YxtzjwQmK+3VWm4Su8heW1W/f02MszvOlJ
ObjL2hM8zHHcbdIOqFCM4V5RyRNfiYsKbVLMYpRusAbvf79cn7KdyEh2eI+CDmt3U9jH6b/3iO+X
5siYCy4Yw4BGEhxXMmpUCUJvejiBGjiDWPgnuRZQgxFKtyqzQJEFpJN2i0mJsVlJcVlJidGgJ3pD
Gq/Tpy7qDHlbjFLg8Y5kmuUMYytGgxDm0MJzA3K8qecettTcbBb2S9NH2BIzCCwbkp2NqewhQIMf
oVXo4V+CDHCjXrzChS6oz+ka7JrlWuZa5drtkttcZIP2Xfen8Ak5oPlEe1B/0PBt5s/6qIn6WfQy
7Uz9fLIwc4F7hfZ6/Y2um9z3Z97rVsu0ar0qU+Yeoh2sF0kFrVRXaC7QTqANWnVmCo6vZUgSUD+h
Ckst0Fgx0LJAzwR3CCaS9RnUqc3UOwyODGdmoWaIfoUmypuZ76aZVibSma4M4na5qJhIIj+JqNGG
OfRF03DRKRrFJDaYTi2qxBhRrTj3C4lQoQm1Q709PLgLDAhOBCNCEkIM9opRy/t+PCZihrQ4bpyo
pn2/MtPfQIV+hMZoMOj7puFya12UdqJbH6XRJuAM9a6MDJa1GPQJ2FLr1hekUF2mFXRuK8QRQhhd
PBh30l50hqyCEIXz0O/RdtJGUcW7rnJRdOUyWC4KDBqD3TDFwBt20J8gGyhtfNGlGaZ5TcNpOulP
m7Pah6BJOoU7aQRdsd7TlMK2WyHLdKrVhRpKsjhutBpoLdzSltMUikc4QzFaBRZ3hIQRxVET6pMZ
6pMZ7pMZ7pMZ7pM5oI/vWPcKGcrv0jdWZKewCLTFoe+GKDS4n/N6w06U9GlqknxPIijy+5uSZBKW
NRkJ78siJiaaclMDsXl5jM0DP9T6hl5Iht7MMmQHWXNBcna5VOqrzbv58SdI7dKQCGSXUM6KUTHp
0WqEopBUkFpyb+By3E0ZUSLuQ4mwoOUpINeLGkUsGaOEyG9tAum/7n2/MRQpFU3D44SCfBEJlM/W
M99tLWCZApYpcFt1awUSJ5iFKcJaoUuQsaRPqMNslyAXRF2h0EmXiTGuTLfS5TYoqUEZx/xXk7Mg
jvlfUTl5BcgqcXE5zk7asCUGd+0FMUjvLbpoX8yenO20AXTMA1LFFzTr5uqozlCUKQgFBa5OOkGM
Ijmo4fSFY16MbA56JX5gWwPXyF40UN3Mr0Wj7vOxrZ3mFC7MPGnJhdCSC0xB430IYe+g0Yu7C7bD
QJfGFTJqZba8qJSE+MT4pPjkeF6e7bA78jQ5di4rJcdOBkU57cQW67Rzudp8O9F44t12SI/OsBOH
2mpH5w80XmYmI7vBTGYEB2tt/TWcIkk63GF7kTAXxEtbQrSIAtrCcOoNC1t2FL+jBYVTp9oMzvx7
WnqfqPWJw7u/WFRfNLMlcJpMW5qf/kB74Kc9IW7Yc0flgrySB6eNqsw3ZRZKPPFLWUZZ0eieI47U
gvKFqMHTkDeuQN5IRd74QjRsE3bH7HZyE4SJ6beouWoI/yQrDOSRPxhRMcY03OROznQraLLSvoM2
4m7chkKtidOIKRYfaHZpqOZ9d2YaWzQtAakQPIhf7xJvDK2dS1o8XDevtAf3dbNVYNvwWLYNNw9S
JapjY2KjY6NiebnTke6gcp02Xpug5dCTsFipfJDKnknMibZM4ojNyCRWrSkzfGqSiR/p3KRpsDa0
c5Gh02GiiWyDo4gQXcZoXoQbdNzd2GwPMe+OPDv9lRL3lJyGVb7pawPTkf5E/dni8tFjHCV3zTmI
RCbFWShztcWue++5Ytr1u5ebPEjkEmLLvrN16tTh88Yz/8PE3q9EChfRnWJ8nNPs7CridND3u7cR
EsajOk4To8Roru8ncF86p9lrmRZPIlnZnty8/MKiIqiI6V/H/GxIRWDb/5ho/o/aXo1+Tt8vir0y
wGSoWKcoGvoNMrx9R6ST3VSrK3I7dYAQ5zA7fI46xxTHWkeXQ8GyLMk7mHhbCaHuaJvbQKOVcanm
VE8qF0wlqeVxKqJRWVRzVZyqk1wpRmWL+sLsLAyyGJM4IRuZJNZpKcopEovqi5qLZLqiTpK8ldgd
DmCexAQxIT5Ht05HV+le0dE6HdHpB48JMcy81nPirjnD3Hl9kaiP8xW1JakxSI7FALcaRW2oR0J6
W3JhXRrXqabWY02tEof1MsvRhJ23OERVnM8R1v9SjFsuFnegknCFFANDkgZMUWCgZs64CQNsB6Kx
EMRww4hVEdOKWNMi1rSINS1iTYtYsyJsH24ainJzpA1JdBrrIakiZXjzw4djRTiWh2MZcwbSMGFh
rc0sMLEgjaETWBAaQR0eQR0eQR0eQR0aQYcJC2ttZoGJBX/2PaNGaCJaIeQbJmojpiqixWTahLAH
q80PHwEwfSYdHZB7aDRTPD2lTFNZJB3GrWHuWsD6Qpy5OKtYYykqNseR3wL7WiSb9wZrHrZmgXeG
+8prrwgcrGdnjz9UJntyk0ejTE1HmepAmconW1DH2M12Cn0/Jd3fv0Fxon2/Kd1fFkK/K52Xnw+v
DBCkOCYLGvpHM8gUX5+r9KcCFPoJP4fdbot0cplqBXeKzu7O19nc+T6ogynQAnwcsG9AgTKFatwq
lVLpYgyBXtAWuxtTbuYPaezmfE9+c/6ufD5fxH1x/nZyJQhYEY2OlqHQarOhgOygE0ALGlzQmKQC
DVtYm0OKxWijuQA0Oah29QXbydPkq/A+hdmic0YywJ63nGKeEzN5zJfq9jF7GXGlbCFxsIXFIRQn
SvGmEAdHHCh7qKU93NIebmkf0PIcryMz5Q/cWP9HVgpz0mcfSfxR0Y+R3mS80ns6xEjF2UOQj34N
7I9sCyJM9DZjotmBAyEmqvWFeCgLeehp5KEK+tsO0NG3oZK+JcYMhRAfabRaXYWJbui3yBkImaHF
ZmpWcrJTw6rXgjAIwYMQG+GiYnXf75lvpwfPcVHkN81z87aHEIjpyKoZYia69lHo6qeiHbCIg0SP
WOyLE2PV5370HCoMoWF+N6M/m0lseDahmUT3NwgH/8DPOm1kJrbwTAbMArcJsdF9P0/ZfwT2E5ZF
hfl5ebmRESpMw3VWN+gEN7p1ZjKFrCVdRMaSPlIXzirWsr1BTSFxFegLMjNTaElxMdsZ2KxWgAqm
9g255jxPni+vLm9KnixP1Eb58gyVFkFAO8Oqo3W7tCRHS7T6oWO2ka4wc7f28/9c56xDeI+A4bFj
Htc8bMV4dovAdLLQ2ecGdmD+HEtvsbJqa7ja2q86ohPRyx9WNawqdMxVju3Q5JR1hmIvE8F4TChE
DOQskLHAGa5PD8eDIu3SWG0qC4wsKGf1aMzKwnFoPEwomImTs0DGAme4Pj0cS+PpMJHGalNZYGTB
n+l0SSiJEJHE8PltcthDSg6XaoWIaIZKFNrIc6Sw5HI1gVpJGM+iYKWMKhrsq/2QZS1kq1SMmcFF
dUzyzkqCS84EDoQEdIhZQzirbEgmyqhkEPYTtySwQ7Izh8h6joSFOnSKswGl1YHSaobvxWTkR4Oo
Fx3IpSp5n+Kv0A1QyvrwZtgRlhBVaEMsxsQpInIJ5H/v80eLoJc20HqcS2gmf9xIR5mGsx0xangt
U9UAGjphK0whuwiVTvxU6KsQg3Dvj4x/JZaVfF+v71iYw/5ST4aK6Z4PGI17V7PwAylNr5A044me
I79Tg4zEjJJXBr/k/4mUTId3NqUrX+6n0KLZjcbwkX++MNDn7/tN2kipzjRco9TFxMiFAgvVpctV
+hQmmrEo2TAXzZshI06j0jBbFgdKizJHKSrnKmVK/aCnt5HPIfL4NLxbCz/57/YdQwOkLY7svVLj
k6mM/foylSclJyYnJHPyeFmKnSRTnR29e+KSPHuiTZAe5Di0IQ8lkR0oFqFe+h25uOPp3q+Wrg98
x8hyx/TCeSUq2a8S0cpDROu95+rqK5bcQkaz7O7K3CpBV0XH9ZGPSHvpA0g9kb9CnHpj/g2lN5bd
Zb3H80DOPflPlu+2vus76jnticm0luTV5jXmLbQuypODR1Ve6BlpHZ7TZf3Mo9BYU31Ly2/Oub18
de7DpQ97lYnCbPENYb9wTDgtyFW5Ub5K4UZhr/CpTy6wH+bwuUsKdFZxUEmB1+r1PGy93/O3HJnH
utO63bujbL9HZhXVWt9sD9HZBUf53+FB4fk8WYw3piymnBNzPB7YHmJrMSaZloa0dUF+3oDdXJ8A
aQYYPHaChHtviEfQhkxJR6yoZgOiy9GRKsbsDBugQWz8tD+au80oIdKTxJg4GvlfHp6cioQBMtcf
jSaERrJeWtYvVdlf7jb8iSf2Uv85i7F6MZNGDJUV5/GS1CXONDxH9IDVAyDWjC2QCBubX1QAYmkN
BuOms2eOV4grBWuCwOgpiLHxvkJhmNAoXCEsF24THhaeFt4TDgnfC2eFmDjBKPiEDwReEKxllkxc
GRaUsqDM4qvGLAalLCgTh9UUeFlQyoIyccRYzGJQygJfmTePF3OspXw+yUBLOGgQWsLSUuYRQic5
I6pBqBfahHaBVwgE5+zvGFEoWaoSFrV1+KRo8yjphvDe0Uri7JMwiEkInWzE632CoFeWbicPs9+I
FKOwIN8qSiaNPLu5xUM8ksnQFHtYYY5H9FzrYd/s93TSG8Toq/JJc/7c/LZ8Lh+3ZVuGCgAWaVcW
pc3REI2+YsyJvoMXaSPW1HSKPUdpYhutbvaygydia1rndfczxNJLEckDHuas4LPDj2AwHRt+VSLy
oysrNLHepW+g7yht19jxzZHN7Hal+8aZeycz82vFAIv2b9YLIdPOiMHiMD3YzimPxYwu7LFSnFR+
pEOt7W8jG0mTqxVBwpQXPCKqYpN9VhEDiVrpOLqLuSRZLHCzwGPFwCpKASMu20jlMESDU0MI4/Qs
3ybGYsLKlsfKdmtYdORF5DSrG4M/2XW52LOo1qYmkvif7YBNSwaYbZKUlByx6+xpbTq5q1Zynnf3
Oc9kMAtryWxLSshkVwbaZ20ZNpg5y9vFC8tbRhL/V39iQwJ7SXHyoDRPCeaySgIvl/5rM2tx/22t
s8zMvlShhlyDGlKAU2ipo9CnjWYH1mKsvO/M43dH1v0MEDuuBjWT/Fh5RJmglY4a0F4dOehQcX88
6NCbaiU/OoK179Aj0sJsGk7d0cYCdljBTidyVKJqrqpN1a5SqAy20LFDWjzoNDqLLkcn6up1c3Vt
unadKoedP1g3hQ8bm0IvrX3TBD7fyGOh7Q0z2X+9Tw4bbS3ZLm2JC9kCXHONtBg7I1b7NWmdWn9v
uCk6+1/yT/CHQA16WCe6V5PVsgdU96sfiHsg/r7E+/TKEbRaVq0aEdNEx8vGqS6KUZZp06O55HRO
FdtJGzaDwZiAsag2K+oUU9jjK0PpgogRZm+s9b33oq5fJGYTvcopc+iiEuygiYm1kyQeUykUU/FK
rZ3EqTFIlCfbQU8wYPcePuGUDtqIBtimTathezjg+r2qxj8RePzYnsfff//xPcfIRXu+bF/15Zer
2r+kkwMnAqvv20EySebO+wKrAz/uOH1m+/bTp/DOFyNH/R05yooGP1tMvtf5uIPyZt5JM5T9jVfs
AB6J68dPoe257L/t6SOlgmm4JdXiArvbanNbQYyO8yFju6SHG8SNyjmdETLNkpqTKqbWpzanzk1t
S21PXZeqak/dlUpTDVkuiYdsuDW34B5c1NRrmjVzNW2ads06TVS7Zpdmr4azMAXq7iTDwvzUGmEo
1KFsMbzoC/VqUX+yh+2oCgk7kA55RSZDhinNnGZJ4+QZhnQ7cQgYDDJm2okzzW6PnHpex55k/0fF
oYiltvTws1cbOSn5j4Gqfiri4N5/Z5jvum/Jay/f/PDyBT+Qdft+pxC+enRSvffq0j2Lxl8wO3ya
/AuuVBYMoXJxmtNUZBpmmmD6NvfnXPng3GG543In5F2SJ0u2DnbXuCe6b3DflHVv0RNF2yzvWKJi
XbFuRZ7D5XIXZw2z1WZNsE10zbDNtz3u3up+2x233H2nm2YrmbtNQ1tRu81m/nM/5pXfcwJqk/96
otPvKNvsybrBTMaZiZmpbqujAOPOzfklLH5oqyev4I1QlShWji0wX5v1bNZLWVyWWFmYZakpxMXP
YnvHLLcndELo9mSzp7/Z2cqUwW79EImNMl0uZuVt4fExfmhzdl6BlEc8LBYTcPA221bbGzbOtqfe
1exqc3Eu9srP2ELXvwsYCyZEWG9Xqiz15xJUFOFD07B5Lh4zZOBzEfaeYq+rtVt6OBXZFx/DPYdk
qEPHQER68tFa7GKN5rWClA0zniWnyGDKy8/Np/IiQ4Gd5JgwKDQOtpP8NI8dcEPFnnaQ0GOOedJr
V/9lC6NISk5KjmwpaXp66BBe4se7/2iy9n56Ym5rRW32qFH6rPLaq3997L11jcMmVyy55nvyQSDw
O9488EDzw2XFjcWLNOYhWcXkulF7jPb69JJL2A/Toi4dg7p0GPlwS3qK3VHg6AweF2NtjgKSgkEu
2zNLfqueJVJJuXxoWqq2PGnojcabbCvL7hkahTv0kyIqxoJUTUxcgcoQncqXcTbmUoS27UdEJxp5
gxWDFvslvkXm5fb79Gu8W/N3x72VfzDuk/xvyn41nimLZTt8MR/7GBjOstIUI584JMWCPGFkQYoF
uc0YCkoKUxCkJoVaeycpEy2F6QLny6rLmpLVkrUqqytL7skiWa85qRhVH9UcxUV1Eq6DY75kGbJE
epXKbPfYKXbtFlPy2DlD3qBkfcHaPJInWpDJ8zx5NK+TXidGZcRlkiBq4vJEyWQ0i3PFNrFd5EXD
BbHhowuMD27G3iy/FXu3xxK0M9dt0YAFFQE73ZejEmgQUzQmi4meMJ00UVO5AuQ58g/knPznGtwE
5kjvGDV5TzW1Igu2ds9DNpNe6utmRznIpFjQ3Sq9Udvd5OtuRTjG3MaQnQm/Po3KjjmNyKwk5Dw6
wq9TSEYYuSsp/Cwt3ZmeTfu/7xo+WGT+Ucg6JSfxoSdx2J+UGoUUT3Gxx55riE27p+HWhiFFZYNu
2/DM9DNv1q0YPGgQslqWMzUpSZt21YUt1xXmW0npxrlX3Hl4/PoCi843fGWtz9moMYtierGzMinO
YG5Y13T35zZ7um/4A7W+ZO3MJGfBrCHOmoTY8tq/z1lz0cIM5juNQf25EPWnjZSKgugUDehBpaDK
i+3zaKL/eNAdL70ggC36nhxBReqAU21n+FwjGSElfM4R+1eeV1LMH3VlH46+/0oTqTOZam2oJpiy
0zFNp7MaDezMw6BHvSu9A/FiktqnP64xpkp7QSY1IpakHid9xyJiAhJAQ9oIpyFzSTvZRfYSGTsk
2czOSDrp9Zsdu59g/OJivCE9ynV5pUB6Ia0XE17vX56aJIaOlbXnzpfpuysl7SLplVulsxLeKSmP
AScnkjeGswm0ssRrbI2SUHdsxzXy4P7pZwXRole/NbbQ1hZbmMz2ZLGFSaFIF4oSQ1F8KEpgewBb
bKEdmw9CcCCkIzgRuuAAdwKOyY9GyXKVFWxXnBDeFWcG2yR/RhPeiPdfRWN4ZXWhM2Dchsf2/TfN
VwYcFydLi0vD+/B+z3Rxdywmk8h/GYpSRcqzsDxBjJeOgqXD6bY4USNqw0xpRPbUafr+aVHkWBhH
02QWZGRoaWo6r7IKoSUm7Dl7YgH5OTdFLz0FjgJ0vKlKjE8sUP2cI14dWlsvewbs8obOgnB9veds
j91goUqFUq6kcrPFZKFyo0xvhzROsBODMtUOFpp6zvWRHvcO2EuxZw4J6JOiCtCGuMIR2TpJbukf
Dov40sCJXVOevKm2orx8BFFLe6X7Z1+wbJBeMkuspJw70bvj5cCZyuvvWECrS7KyhxBmeHo3XnxH
VUVGKZ0Ydt+zStjtf4ey/TXyjZN+JRpmkMvjZyRc7lxAlsRfnbDQqSQg12mA0yVKJ7lTCnRMUkZj
AkQMumCvbm8i1wVBoDpPvJDgi89JmEIbuIvixyVMtNc7Po3/OOFXelr7W/yphN+Szjh0FuJx+miO
o46Oisc1dCid7O1VEn7xMvSqEibiWanTqi8JVWHMql7EOJ4VVqjCeiGiI0I7M1nfv23t70tFnlrb
Hf1LIzs0jkZKk0MP5tjuTIyR9f2nq37vO62B+ARLZ9C4WUcJxqkvJjodliS7wyG9fJSYlJCIAE5n
KJuA2QQtF341SadN0Om08cDeOrpCLEJZ0OniHUkeO7EnUq2F/VZfvC7BmQg6SOSc8W0JJOGYylQQ
VZCWpqJOh4NSorTvIM9CInDk2S06S5H0VaEzm4tx+4fxixqohzbgUDcOh3Ry26YTKS49Olkp3U3d
TQa99BWClH5HHcz/0oa+8VGMf9omBF2T9MJs3ztEAyNkWENKWJlFOLgpdPCRwI6Ns5J98SIGCdLx
h02HOQz+v9a+Bbyt4kp45krW29LVw7IlRdKVZMuWZb1syY/Eia6TOIkdHJs8gKQ1iWPLiYlj2bIc
E2iLKa/+pfwptJTXbkN3C7S0+ycNFJzQNmxpaSltaUuhPP6StJuGZxa+bZIujzh7ztwrW86Dsv+/
BM09d+7cuTPnNWfOnBkHMWEqE64cklgLA3VVHSTSHWjSKj8k0p3NAHeQ4CLC4xZ9moqFpfIiDwSL
Y2IfLjs79Uh5JI1qDa9l8lq5RQ6gIdiewku0l+JZcvNcFFZrg9U63/ZTBLhtPzp+TSwO8mRGqdqx
/Bsv3L+cebAp35muj+36M7fizCHFu6pUKL6QzYTPPEX/OBPgFsuyVd2s+cgM0rXvzD0lwZlBmB1X
iqXqCNVEKNE7TUqHcZomvvfw7BYS5mE/N+BQ+fUP72XRpIMd6SVn7pGCCXHdgSMbz76mvFvxEAmR
JjCiUrUlNB6lJY32xkBjujYdTtctjuw0fsaoLRHKhLs0T6meEX6vOqY63aghpEgxSnxv83SYrfHa
Jj+hN4doqLYpabDgDikx5hGSPJhsYLdN6Tidb3Md7a6jdXUhmxipT9oyFt7nUYd0U0ma9Cn1pWSa
u/xR32Y/9bM1BKCa39lSfkt8mtsgWtiKk1ctqOM4x29OPyav+3adOTG7Kga6dSydZkEKJl6MbErz
OHbzhRjVE2FcBM6dGMtJlAfhfwQK6WSK6+RFXp28OKabFx3HWLyFf6fA7my9d4yO9fpScnRrZUN9
eVG0bxI99ZLDRB62FdLWGLYzprFJ4e06dMkDv6bqN3qv6c5+6vZGT6jFVtlyydfFw88HkGrvXbv9
s5uaXfWXdz7REQ+F9l11/R9tiejCytJFUWewnC9zPLBnZhMLfspWLK6ucVt8C+sJd/bts0eUXysx
w9hYS68WEyWcVqszKB7TPK15XfOBVunleIO3kg/GOMEQqxSCbwffrv1I9ZFwtrK0EmNFggz3AFSK
On2S3VUA4BKVfpdYowtqLhL4T2b1XdEyUqlQWmOaopQqPcTvU6pNuhqfTu9FgtqImmfUFNU9atV+
NT2qpmr2bbMurXbWkSowuy8XbeVSSP9z9iP2d+1n7eq9dmovFLM7wv2fYXwQloJmpAXSsV7J6QP/
m1vGgF7N8lDrDNUKvhKtr8TrpSEtJILK76W1mhrv3D400rF+t8gHq/WGoKEmoKzWVwWIoZTC/I+E
C08DlZyikvMHSgIKeMrR2adMn1GYHlIzkp6U4dAcrC4LnDNHpEWOIzqw+r7uF2jNzPHX19698j2c
FQYY/RUbDlw/deD+O+74Rol5JplIzLzym5/NnKoN1TMTbpK52u69bv/+z4zdfjvYbzmQ6FtBosPk
XbHrZfPztj9Uvlz9puW47Xjlm9Uf2j4M6DQ2bYBrtGTM2yyZssGaDw0qvYFaOixd1Rstf7S9XPm2
7c1KtdNRaiAlKqvDZTeU8lreRV3T1Peon1wTAoJ88CjvC6m107RT1HIqu8+vV63xIDl4R2rUc9TD
9Xh+AxMiZ8TKhHY0SElQCMaDo0Fl0FH368/I69nomZvJgfAeY8659JljoMVO9KJooUdIngHhwCDy
GvT86zDRYoL7Rg6AKpD82dJU/JxpTwG1svjBxEeKyScYAf5gVXUdaMFad1lF9NLP3b7vW09NXRq/
LFC7uPeLM6ffvelRWvn2hjsU2wLpjhs7l1RYsq74w5+/+lYn37WkdvniT/Xf9Pqr1CugBl0Ccvam
LGdXiDGdXmMsKVOcNFJe7y3zCnytoI+VxQSh9tXgq7VMysxnhI8qTQLKVS1jYQAElDl2V6HFRW0r
SllpQFMUr/rDYq8PBsudL2oVng7dzRq7FaXMqtaAlJXqYYbo1aIImUgWZh7ck/Qo5aizrgop4/Ty
3fxmPsuP8kf4d/mzvOYwOlbCHXsKOyPYNrTC+sesNPHvyKJUEag2WgKWKi+pNkJSaQZBCpqKBEmS
lFCt3lCrBzkKGbwBqtfNlyPBZysTykCOfDZ4Wma/kBwV3P1MyxKJiOUpWY6sxQ7YxYEOEbTminvW
vj5znNa80HPvaiZHAUmMbv+nEvOHP0CpqQ/VUv3PfkODicRZDHSckyKOLAWqXgVS5CaV9D5RN22Z
tj3u+plLWYorax0LPMkBbtj2M9UfVC/ZXnK8rnrD9objr9wp1V8tH9n+0/t+wNSoWqniLEO2oYqr
nFd5BwNf5fZ6vxz4rvebgQ8cere6RKG3Vnooi2GrXZjUsHmjw5+c0vxGw72ngQfU/n2LR3SnmFSZ
3DCAeqjomfJwezzUM00rxBQRLbhjxgfAgpSXUBPpJs8RxVnQAaLBlARzXAoBwWHP57OrlT5e75nm
thwgk3o0cgIr0uy6OijtWzYEKpNH9VTvDFZOgmm5RbSB1ZXyWketnFUsNSWtjqqOYUnL4nB7jAUh
h8NsiyKILttxh+HHkHeCXTDMxCM6fGmPvDGNXaHRHtmGw+uBmsLI+u9oiwGTFfaNS/Ygd/b3oOPL
0946SALTZ39/wMzssI0o8MAcPskBIgu4co434F+Z5PpQK4c+elz451tzP1zjCTV7amZ+sef0zMs0
/ZvP/rZhVUz4t9jdQ9vvjtMre7YmbAvrahZULaP2Z1+ipisaOndeMrDrissvvwJweicg9Csg5w20
S/SpXeWualeTS3lPkHIm3tJA0Htxga0GZWwuwNaIlEW+fMM8D65O9lTIAQpS9FR9A6HzHb3S4ws4
ets8HZVi+8pkpdi1DpLUQkjAsKrM1PjcxDIQaSADkbo6viJeIVb0VGypmKpQVahMA1otN6DRkXD8
VMk0fUs0CL64j/M5U2FqpqgwBCdfdrVhhsctbVl+L7+PP8wrCd8Dl+d4Je9ITlP6vYIqBz44xrcW
wh26YFqA2gIj7sYg7wwCJ07MzlZ51CatoNtzGHh5YQdqg+zikhU6CniZXJTL0Mq5wJBrtmK69ZnD
G46km0PW4HVbB7toK4t7ODxjLDg76H9guubm73mb62KL1I7FkTXMCAZZn1mv/FfFw6SKJOiE2GKs
5hKc2lBu8FkSlqWWae+07+fen/ver34/oedd3irBFav6muGk90PfB9Ufhk9GTiX01ai9EwWLqXoK
FHoCPSGlAFSIgZBLjLkDkpC7KeUUyhKVGrihaEHGVh602OzOmNteZwr5AmpyDUdVMZ9bbzIGJ6kD
yHFARxhVArq92n3aw9rntErcsnVUq8ATAbq1Cq2zoceyxcJZnq5jhpVX6BY2C1lhVCg5LFDBUd+x
raDUzxzvZXvdJMf5mdZjGC2cbj2WllzlFmkyJ2v42qjHX+uv85KoB5KwL+SlEW/sXA0fT7gWJFyx
gDK+IBigLuc8DW+srKmuCgVKairhWRWRnxWp91TDrLdCNRd7Vd+YKlb3xVpeseo9ptM/9YNdbyDw
5yu3L7+t87eg8J2/XXNb+qGJiYfwp+hezEIo7cPfyKOKH1wzUFdHy3/1a1oemekYe/DBsdwDD6DX
ywnS/V2Q7mbyjug4oqUqlV1VrVKgU4iTzNzyigrHIe4Ps4auFO8Ri8cT5w3MkqdJp9Vqii1jab7k
9/mE4mqIHLGSiMtlH/V0NBNhmn5bNNFTbjCWQzU1ZjOvw+ijy8EM6tbSUWCAo0jwhcSHmcZ4fCpB
vQmacLR0b5uNFeSl1bYxaUokTdhPnDwhqVsWptor2acgY/PC3jBMjm3gPyccDvMLlutXxBuWXfXg
zjUV8SWdb3Wk446uytinlw9tZKFwb7JYOTbqgs26Oli16r5dM9fNRrHylI53C+HUFTNTRXmSKYt/
ghBosRpooSALyFMH0bP2iL50CYfiUwZAj5aia4UrLLbbyuarScnHy839QfFiIihn/+x4UQxbjEtz
3Rw6cC5n+8tLjS1pBYXPq4CKJU9Aro1wIIH0aiUzpMrKBFvctsWmsDncm745u2//zEk5ui09BiOg
5N3oRSkpC6QuukzE7T9J+dNMma3E9PQDaL2UmF9+eebaM23zlRfwaTvg5h7ATaJkWvwGsV5m3Wqd
sE5Zv1h+c+SnkWdiz1tfLf9d5OXEX6xvJkwPx/ZbD5U/GjkU+7H1p2XPlGuU1nvL74zcb/1m2cPl
D0TUGRja95Av+vckbreqeGs4sTCxmWywbvJvTqiPWt9KnLIqtP4yGBQa/Rnfzf5n/O/43wr8La6z
Bb4c4IhPGV/n22G7OfFM4Ofx532nfFriu892n//u+L/YDgUOxp+zaWD+fvTAyhSLLu2UIns62Z1Y
cUlX0rZhXcpiIsaElyxIxEiV9bRVbUXLILwsie7kR3rW4vXJA6tTLHt5N952iI3rUn5hZUrwtQnL
fWviPb7N8T2uPQv2uPd49nj1NhFed9kWVHAWi1isbNsq5nEJxhH75FgLg+z9wxUD7+xmkymwyHTn
B9ejM9lN5/5mfZHXLyquTPFRIXp/dH/0vWgJiR6JclHsrn9p6kiURqPxrH0vTGAV99v3w+WoXem1
77Hvg+msEp3qoj2Ysota+NXWJe1iS8o+5UjZ7ba2UrldhTYX2utmUWpWNq6YtcUBzFKTjJ4OHyEi
II6I61LoVhG1VpvNarUF/H68AzPLlkjE/b64uKAqaWPJKkfKkKAO2y7brrjCShJ+my8QjSd0DRIM
oJY64ocp/oW2r8GI2UcIsXF3PmqxWKUByqjTosVAtFukfTFSdJBWDk/Cq6gz8Gmto97vtyYOcR+A
/v2b6LAKHt+Ao9ITGIj/Kawd4HQDZht67GyH6FvEyj0omi3ETJwqh6pWF9ZRHad7/iD9v6QC975J
/508Fmab4E6cwB+IIxikFM1VXEJjM5hW/jh/+sQ78vFE5S3M+6e5JRou+Sz/EyU6J8MMrAjzDVJg
FxiyAPaGmVnLtuGXVgaAG/wBwBshvlt4TaumlaBu3Vg4E8CHdgBMURNiITzL5JAjuYzlaZsIdzYM
tlqATA437Ar3HvneI9+75Xu3fF8j39fI90H5PijfV8v31fJ9QP40u2KEF4uyhtlANdIngImfJfJ7
eBX9UDCODbdJicEGt5hM6S1pGyYsaByu1TJFA/LVz7yuGPXlL9wZwRqK+yGxYbwhW/XXAumhVl5q
zbDelA7iFqYaTKox8WDixmQBJn7kgYTIIHspQJD40QeYwMQjzgsu94jzYsODmNRgUv1xUeKf9L+N
uXAvkZ3VOLdJ+AFDTPq0GOPmh04J6C2GhhBEnvSS5OAeG8v1kt5cbmwM5rLnuoEazE2ywSONtWo6
L2i9mv6oyB303v0OGHERanmfdjMz953OtP9lumHmO3MeoTNd14ddkpv3FzMvScNIdfBJGEGuhxHk
EhhBKsjn8LyA81ZbL7xJlpkq581utJ6OCigsW6ZOM490YvMFjAvawt+P0wRHYYiUtubgABn+2OBv
7lcXGA+lKftcB8EseI2QEqr4FlmqWCHaj5jog6rvuL9T94T7oOeJul+5n63TWNieMGcgyYLRfWWB
pCXrzUav814X3ePdE93r3Rs94j0S1SU0R5qPpLk0ltYak81MTgCwiHhkTTLV2NTcsnDRotYfcnvn
G3oyOkwmY5ux+BnbmG6WVy15Fh9cIvnKBa/Xc4GyRaufosFSIhmEsWg0ckgqKuF/aZuYXrK4tXWR
nHvA02E6COC94gJPpDZF1UudPl2tTzmpUy9VpZLJqqoyHdAWaPP9crtYn2IOUxcOMp6FyYInVbmF
nZHyZbvSYp+m74lmj+CNezkvUtGL9PTC+49VW4JQAXMDVwZTQVZB8Ejw3eDZoHJLcDQ4FfxyUBnE
d4L4ThBqOkAiUZy3tPKL2JAfTO1dRE2L7l90ZNHRRe8tKnmOAQr2sG5TJL1IXJxOLhLbliYXTS3D
gOJVqwG6BGOJe9ZD8qne5CLHsrTsgpD/y431hlevveKR7CK66CA3Q5YBn21kuv40LilJOvv7QdQa
bDOJ3S15tkvhg0FJR8hOxPBGXGTvbcW9lt+34wsMXeXwhh0L2rGgHXton1tI2sg+AdPbWQM7jUag
mfkvW9qXr8Y/dbiX29u+v6ZvubS1BvVBrxRtVOHWlC6oMlS5tB43cXs0aoe+3E3dGqdbUVHqdFM2
w8Jaw+xwEckhkkZcgnbxT+EQg4lfNFmWJDBJs6UKyxK5cURe2lJLkcJUjhhW41KozcXuD8BVKjtG
8ewSKXyEnYdUZi7MyeQzkObdz91KQiuvOtPa+ktTkStqUztbciuvFJcs6XzKH/C7q1IMDAQqVyRE
kOqDneklbbgFWfGlhYmqurq68OKez8+k8FwZ7pZYpcXRPtMv3USrIsskWLKDEQIt1oBRuIqHSIoq
RBdO1u5yK45oj3g5NmMrrEzg0sTcVAtPk6gNR6LR2HkztoIxp9Wc90gyqVBu503bZBGNRWVdCLLo
wUmbmZ5ywaQtpaoOBnnepCu3o/hptKI7pZV2L6Xk6ZtJS7XOJg/xMqMpGp2KUW+MxhyN86dwrWym
Pqs7JSaDaZw8i6MsHLXsHJLJNLnwJG6WVnc139L92FXrkQ6MIJWxK1fuWFuYwcUruiUKtcfjY5vu
mLlhdjJywzJvTdPGmRvY4XfStkSJLhy57OwR5bVAFxPM3X4sXvk4N616Ufey8RXLC2UvVrzgeMX1
0oLXjX/j3leVPu142sVZTliPlR13vO1SvlLx4oI3uddVx3VvG9+0qAcqrlrwQMlD2gf1D5d+y6Qe
4gZVGd0O41WWAbvK5jOonT6lnkc3h44QDMk6SpTkCe4UkK2c2/C4VxPXjGoUmoOQ48agQJ4dVimd
CdPby5aaRb3Lb9KmLZiUsVh5bdqBsfJwlSQC58c2dClWyieoKe3SuXYFT/O1N8ycue1LZ8nNXzh7
65eo4sZfrez7+q2HfvC/vvgD+v1df7zh+td2X3viC7e+/dn+daMHJrY89BDhzr47s155J+AnSJL0
STF2xnvSfyZ0JnIyfjKpUrl0Qe4x39O+l0J/iLwROh5ReV18MOYSgkpLBH1KLMIeV+E8ojvsEusr
6zQXjQqVt+x+0qhQJx7PRW6uDPvczlOOq93qClW9rxIm0MZqxHIgLohCj6AgAi8IwlFBuV+ggrPR
dY3T6XCQ4H/AWMVMAIccEvycvJyg3ovLCSl5dU5enGs9zvZSHJNcUCwWGNcVTh4D2/0dpuykKOCG
ZE2tJxAK+oO1nmovbQhAUuMNe2nSV19wPxWt1cUTVcF4sD6gTFTFAoDgeR4oS13UtSBSFXWFAyV1
C+B5wUMlLTMwNRmX7Ng4U/tgtEZwC0MUkwj696KYFNQ+eq16qy5mwTSUyct+UqxdMiiv+LJ1vu3X
ssisO4tMulX3Xvo7WrPvjse77+Vsy2/bfM+mxfuu//z/GZvZz2QuEm1RfB2hFYn4zL9NP3vjSJT+
7/BNG8e7O9bedy9oQ/wbV8hVITr4uEDp3SpqYSZPlTOl4zt5bh+/zwwjurIozq5kbmZ7jjd6fqyc
8vx4OKb/zlv9d3g6DKUai1mIxJJmsW0lJL6qpNnoZMNOvJ4ZYXgsCl4fszmSNGTUT1O36DOik0vl
dOikbXQ9mi0gvKova6jGGaYEJmvIWWY/8aGDuse3xTfqU/kctUXeZ3l5ag1/HKxsdMB0nTghxfVK
qeTOZE4vxgwmnlPwnDFQYlKYA4Q3s6XbArvApBDVg43HUd+MCbNozZjIimFsVuGycDumYy/ixeZa
r7+zbeBKcXE4uN4X/s7UPMc1C7VSfGmqd0lnfbJu8SXDwzPPnuPyAereBTq1Fai7kvtXMaW1qFIO
iz01GL85/rX4N6OPRp+Kvqj9ve7FxHHt64mThtMxs46qS9RadWNNvDG2MrQipsFt6uIohvljrL+O
mKgm0ESWhFYQVYwEKmtSsRWxlbck7kq8T87S/wzoLCV6hUEbM8TL9TaDu8LrcMYtC2/S3xr/nf7V
mPF4y58Wvh9TCOU0XlmuaIgadEQZVlf67AZHnIsKQOk4JgY8BSdan9TJV4O0sUsnXdjTxhbpKVzx
6SM965I6+cqed3ZLz+HK3l6Jbx+SLkdF/bJUHD6urCbtC+Vv4FXUOquTC1sVBp1umhsW2+NRWzwe
Vfia1N7269rfbVeY2rvbOW87bRcDVcl2sTHV/uLixa2qctEVSZZfzQN3HfUpiC/t43wvOnXVPpte
JLhs1rYmjKrQLG102M8/yR/lVbyzQ/0EtwHskUpui6j3uNd4G4SGOG4ow3mhL5BscKzq3iMvm3Wd
lI+ZwxjgE2w59cRY77EwnkzAbNn0ibkTlIFhLS2W+XvI0OI1Swvj8P8Yiz1BZnWyEzuWYbICk3ZM
lmPCZutwrZSvgnz1SSvPpTC7B1OXhelgNFXMb3JgaPhrs44DaS7ProUtZgLTkAAsQ+W4EpMVmLQX
HUF4ztSZoqsFl+yCs8Ev+K8QjlxdHNQ8G9Nczc7ilI/dLG8sOnkjqFheP9I6ucJbK2R/2TOU67v1
tY13pU1+Sxxkp6reGLvxstvWVKVSD/5t3brez/1y5Q2tVp+xtpkXmqqauX/weqvN0ADetGBB1R2X
jnTu8HpKjenO9s50qL4mVGevqHE6Lc7Ojh0jHQOuBUZ4VL+sgm0+IF8FWTyk/DWpI9894ND4pukB
0VtlJ75gVZVbpT1V4jPrRx3U4bBFQiE6ajhq4AwMtcDxzmhVpTRRDro9ZcSGPuQe2xbbqG2/7Unb
Udt7Nh0PmZgxZSuxOSKHKKWpwhGFMGyysXMN/+/hXnNLDHc0gK7rwoMK2fraMTZo8hYrp1SAwUDd
hLOWuIl8MKFZPod3bp00mDpnoW1udS3pqh3+x5sa3DWLhMTMkf7Dh5me6mRa6Vp5XS2ztMy3zNka
rnHHuh+4mj6FDw/is4Oyp9oDmLpH8SUSIu+Lfp3faE1r0QmkMzqNQ7oh4bRQEjI2Gz8XPEJfMr1h
Uk1L1vb5Ry9J/ta5UWi+ge4vFe1iGYvitciRuxjNazIUD1B/KDj6fZ6QQ6XW+dBQ12lPeXwGvcbv
9+Fit4mM0n30KFVgmJIz7HuC0xIncaFpbjZPWagX98bVzjfNjzMLRtp8QtjSSrpV3sVE2cGdhWM2
pagF5OU5l48Ullu4VzrR1n7qivtXZb4a9kpWQbptyZ4heYg404YGdqymZsPqxkspw/GZr7ctToj0
n2R8h8EGeAjw3cJ9+iAxn31DNC9LmYR0SlEBY64Lk6bps2/gAOzDzSBNANjrflx3xPRCnXKVa0Xd
CyUv6F42vGx5wQZmes0r8Q9M+tWmTaZbTc+aflpX4u1Jp9ximh34eCCdapk+u19sgatmbUpNNJ4m
OmS82liy3Xu3lyujDrfD+zx9xfia+zXv8y2a5/S0W79Zv0e/T39YX6LXG9ku0yVl5clYLEKsVLT2
WKes91v3W0usVj4kwoNQCBi3ha8L04jb5DXyLR53xGukRq93asNAshe3J4Fut4SpDZDcEnG7MXst
zJ0x+7t8i43nW6iRhzl1ua4lcjB80Oupr1L9wvhT/unwM5GPjCdBG38Y0dwR/sfIt40P8T8wPsI/
Gn4i8kvjU/xPws9GDOawJ+ILRyMN4dbIsvAlkVuNN/I3h78YMVxm3MRfFt4UGTRexQ+Gr4rcY7yL
15UbK3hb2BXpNK7gVRHN6lQkvjLFaxbCb1mKF1anoIW80tkYrl+d8oapUan0mxrp2Uba2Khkc8LV
KaXoDya7lZRX7lc+qVSwQ414S1Ip6WVXUqlc5Pc7mQ+5J7XHude5z3nY+ZyzxDl77DE7kq8h1jvG
tpDM7iNBlyPaRGf+8hf2RwdaW/Fwv95CMC4DTPAfbaiIhc3s/QYZAC7Oyef8ESmuA00p6eBkeYrZ
VK2ed0urgnOeTHV5sVtTrSC0qbmZTS0j1ff8Qyy0pPP1znRzM43P/DXVlO58Em4+cw0AP8IjNehL
M6cULeEIblFp0t14o6G+OobxWi0KajiubKmFB3WLqrYNVTegyg+1KPHvxW5WXkPwrzLgfzMsRZgS
mODLMEc0tEaGFWSAlUJYSYTZMiWkgm6VYRUJ0kKdavIgvV+GNSTI/U6GtWSB5gMZ1nEerV2G9WRY
n5RhAxnUF94tVT3KrZBhI/m0QUWo/PdurzNslWFK9Ia3ZJgjSsNpGVaQesOfZFhJ+NkyJcRQapVh
FbGWemVYTdaV1suwBvKflWEtMfJHZFhHTfwJGdaTRvNHMmwgDZbCu6WKTaU3ybCRRC0ZaAlVKqBt
Rst3ZFhJgpavMLgE8nWW38qwkvgtBxmsgnyV5a8yrCQey6sMViNdrGYZBlpY3mewBvIN1oQMK0ml
1cFgrUxfCZboK8ESfSVYoq8ES/SVYIm+EizRV4Il+kqwRF8JlugrwRJ9JViirwRL9JVgib4SLNEX
YR3iyrpBhgFX1sUM1uPfrrdeK8NKUmvtZ7CB4eQBGYb2W29jsBHyeetzMqwkNdbHGcyzeh6QYaxH
Km9FnFv/JsOAc+sRBtuwPbYyGcb2nGFwGeTbbItkWEnqbAEG21n5bTIM5W3dDHaw8rfJMJafYLAL
ecB2UIaBB2zfYLCbtccsw8gDEq29rPyrMozln2JwJfKA7YwMAw/Y/sLgWsRPmU+GAT9lWgZHsJ6y
NhmGespCCGuK8K8pwr+mqF+aon4ZisobisobiuhiKNBlPdlNRkmGDJI+0g9XgXwbfuvJdgZ3kSwZ
gV9eLiWQZXCXAxjTPsgfYiUEyBmG96MALWf5ff+fNcVmWyaQdfBkmEzMlhmHvA64St9LkBb4FycR
GapnuW3wxjBc18I726ANefbWWqhvHH45sgvSgfNatZC1agKeD7FSAlkD10m4LmVtGIASu9iT8dn2
4veaIRVIDdQ3BK3KwZNx+A1CvSFy2UXKz/+S9J0e6Gtk9ltdgIN5pXx+hlHE1wDc74RrjuyAPPzW
/zuuBcjNAJaGoJV51hrEjQD3WKaf5SBFC/fYohHIkVo1Dv1ZQ7rh6x1kBfyWAe4R7oZcAdIVkF7C
8tshZx2kSJ2VQIt2+NfFcteTUqJjP+zDEKNV/jzOLORLvRxleB6VW7d7Fgvn917ipCz0EHs/Cu9j
6T4oJfVS4o0JxhkC2cqe7ma9LHwT+7yrCDMT7F2JQwrtkTC3k5WXWoIyMMw4IsO4NsPytrFakHoZ
hkXk1o3y17bD812sXBbaUcC59M38x2CmwG2TjCMwJ8P6tV1u4wDcYX4/5A2z/g0y7O28IL6ycr8Q
Y5miWiblOi/0vQGZe5AntjJZlVq9VabMiFzzhShUzXo1H1MSX53PFed/WcpHXO+CFPVEH3x1WMb2
OKstf9FvI/Y3QM4w++J4EeXnaCHRab5cIHakr46zevohd5D14JPQXJB5cYTJ4gjczX0XZXuAYVqS
0j6mx3JFeqxutnSuiG+l/uX/LqawdTtZ/QW+ys6rb5LRfwejZrGuGJT5Yq5kFspKWmSCYRzr3z7b
H6ldxdyN+gq5QcK/JFWjMn8UuPRcHvq4Hs3xRwfr+/mUQwxj/WOQn2F1F3rTz66Sbhs5hwa5c/A9
VzP2D6Fhhjlswy6mAyeL9MAnoX6hPkkmUVZ3ydSYk7FCfefTUcKW1IM80wH5C8pxgWJ95+B68L/V
2jksn/+FfoZhlPLMeS2S+oMctHC2hg2g/9sgN0JwtGwmSdIEI6QAaQLuIjCKJ+EXJ2i5biCr5ZJx
eJqAJ0kZbiIN8MO3GkkKRnz8Ye1IrTy0bCFYDzHAF/6LQj/Olfh+pvlWMf5FnGI7VzMtkWd6IAc2
TIaN2NtmtW/frJYp1DPJeCQv68Y5XVzAegeM411MVs+1KSbl2gqaEzXBpIxHpFAbyxuScbsCYMn2
2Tb7reIvoH2UYe3ul2Wnn3FNpmh8FlithbYPMboNs5qGyNVyD0dZb/oZ7w0U9b+OSW4BhwVNLtkC
k4x3JTmZG1HHoW7UwXOtGCRz1kRB7kblsQ/17/g8XYS8N8HqKGiAC2E8y7AyytI5nORYzVlmE0ia
Ms/aItVXrN/m2ptnuNvO9EABMwNQqh/eKkjBnCaM/jf5LMbK74RaY5DmmUbHWmPMVtgs21MF7hhh
/YzOvvM/+61JxilS2cz/yFcKz2LnaJLZutfvHs0M9vVnhG8L67dnhK7sSDYPWcKybG40m+vLD2VH
hNHh/qiwvC/f93cKxbAyYV12eAJzxoWOEXgv0dISj0BSHxXahoeFtUPbtufHhbWZ8UxuV2agUNXC
ZdmJ3FAmJ6zJTApLs8MDC3dlcuNYb320uV6o6Rrqz2XHs4P50GVF+fJL8E7Pugi+1bVeznpYWJ/r
G8js7MvtELKDH9tqIZfZNjSez+QyA8LQiNCfyeX78JqdGMlDVePRNd3rO1Z0LGtb39G9RuheIVzS
sax9zbp2oW3l2vb2rvY160t1pbr124fGhXwBmQjDJ0dz2VGobjc2YfbzgKTstlzf6PbdQt8IfBKw
MTGeEbbuFnZnJ/DN/uwu1piJkQFACNYDjds5jpX0CcND/ZkRKN63LZfJ7MyM5KPCRnhte9+ujJDd
ii2HN/PzGoNom+zLZYTMEFSWEwaGcpn+/PBuYTCX3TnXrix8K7stw4pMQsm59wYAPbmhrRN5qBqa
mR3JFHeoerzQKMDVLCpmXwa4T9jVNzzRt3UYmj0+nskXvx0VNowMZ8bHWedZL6BPMi3yWXh1fDTT
PzQ41H9+zwXA4kh+aGQbe7dvYGAISdo3LOQYj9Vhdo7hFr6XP7dRw0M7h7BD8BFWbjKb2zGel7hi
EHDBMrOTwCITW4eHxrfjd6AuCd07+3YL0H4g1ehuRNwchuZ/iOGjY3Cuc30ju4Wxicw4+0x/dgS4
bUTuQU5uNys8vj07MTwArLlrCAQCeeD87mM5oGRmCORIohiWm+0jNAs+kO/rz8/RGDvWJ7d68MLV
sibPvtDfNyJszRQqgu/05RdigQ3r2oSIUNOcbAoJTYnmSDwZj2u1G1ZDZjyRSCYhbWpoEpoaUy2p
llLd9nx+dGEsNjk5Gd1ZIHx/dueqLLR0QFidyeeHM7nlmfGhbci+fcgyWGYyByTKCYyLsekdS7vq
hIKmmIRiyJy5PiASsGXbQG4IWrsiB9pnG74lvSCsywwDu+eAg0DloDwLQhvWPtQPrDI4dDV8cHQo
379dGGDfrxNYC5HJQQtMZpAmTFDHh/u2sioGmZpA2o2C9AkbxiUuyuycGO5DBphreHYiPzqRZy3J
ZUDnIFPm+7ZCOYnfWL35TP/2EdaYgWz/BJKAMWH0IjiLbc/vHI7tzI/07czEdo5v7pfQMZKZjOKT
T/jWZGYYcjN//xW8i8lMwkpf1AWDV8k4xeH4YqXyZIKWwiD05kVLDDJj42JPV8iG4EWeK76g+KHi
J4rDkH7v77Z06GNbegnkSFOVLCs5cdGSK5mJWJjKopF08da/CQPxDnIaan0Tnlys3GWspos9XcWM
oF0MUxcv1SO7VHDyJ5lGuz8RRi7aeqVXuUS5SLlM2ahsVorKxcrVypaL1rj+79J5NfaCJqDMxUtI
5uKOi7eJmsmfFQEwZC5OxSybuPYRQv4LuPzH4WVuZHN0cmVhbQplbmRvYmoKNDAgMCBvYmoKPDwg
L0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAzNTEgPj4Kc3RyZWFtCnicXVLLboMwELzzFT62
hwiDTUgkhESSRuLQh5r2A4i9pEjFIEMO/H2xhyRSD2DN7oxnVutwXx5K04ws/LCdOtHI6sZoS0N3
tYrYmS6NCaKY6UaNC/J/1VZ9EM7i0zSM1Jam7oIsYyz8nLvDaCf2VOjuTM9B+G412cZc2NP3/jTj
07Xvf6klMzIe5DnTVM83vVb9W9USC71sVeq534zTatY8GF9TTyz2OEIa1Wka+kqRrcyFgoxzHuUs
40mc5AEZ/a+/hepcq5/KerZwbF7w3KGIAx2A0BNLrwBKgQ5AhUcxdAI6AWYCpoyBjh4lO4/SjU+3
5Ij4LdZjio3n8a0/3DDONPEoQk/E8JY3ijtkhGKKIuRSogjv+IjiBmERT2BWiZQClwkYJTCSMJJ7
f6xhJF9AgXy9w5CQJ5Cn8TIrhnNLcY/nvnF1tXZetn9hfstuv42h+yPsu96p3PcHjry3YmVuZHN0
cmVhbQplbmRvYmoKNDEgMCBvYmoKPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aDEgNDMy
ODAgL0xlbmd0aCAyNDA5NyA+PgpzdHJlYW0KeJzsvXl8U8X6OPzMnGxNuiQnaZYmbU72tmmbrild
aE5LW6CIKTtFKgXZUcuiiKBSF0QrSl3Y3EBBBddQEMqicBUV3LfrBgoietVLr9x7lasCze+Zk7QU
vX5/3/fzft4/3s/HnD4zc2bmzDPLs86ZpEAAQANtwEH+ZVdMnjv9AeMvAKq1ANq7Llt4lbA1cstr
AIFPAJTG6XNnXPHNga+DAJZMvE+fcfm10xMu2/oKQN0mgCENM6dNnvrKPZsc2OJehOBMzEi8Bx7H
9I8I7plXXLVoYfel4wHIAHz+0stbL5sMP8sFrHoKIHn7FZMXzVXP1JVguRnrC1dOvmLaYz8ffQLg
Tiy3ZsydP22uZjBXj0VDAFLuAtZ3+t7JLv1jF09KqfxJlaAC9tk4+q8Ci58fuI2P5p09q9iqUuH4
ErA+kSpgqNhybh2A7K1oXo9NsRUcoIT+H47V4Z7GIARXgxwoaCEA2HNFIuLFUtlbMINVxJg1+CM5
CW/AIaIiJrqfzoW/kMvhTTKduMhxaCeJ8AJcCRvhI3iC1JDr4Hv4B/mSJMMUWAyzyCr4Jfo15MGj
cC0UwDWwAUScv2WIb1y0G/Pvh1xYhyX3wmk4AXvgZcgmFNaQPeRVeJsMi4rUD7dFo/ASrIQ1sBlh
ENwHM6EJVkX/CfXwZHQzPIIr/BTxwKuwBR6DUPQr2Er2UUIc0B39GrE/iu0zTCfgtn7XS9hW7Lov
fmFrfdersYtMpxaShe2vIc8THfZ1Pl4HOUr1sDj6LajhAxgFU2EFMcDN2OKv8CK0RE+RfFIHy0EH
LnzuVhgJt8MEuBPX4VG4FRZIfbofn/PhrFaQ58hCup38Am/CA9GvcOyvgZ5MJQ9Jq3SWjiTTcW6j
+EQBA7z2xq/7peuEdN1HzpCTVE1z6Ad0BZlBouRD6oCxOKv3wlM4wq2U4Pw/SyjOzZ04Y2+SHDIJ
ezkCV2kKTJfWZQ22yWo/iuN4VJrvl7gmxHkbA3x6pbSCayQYB6v6IA/njcH9OGsFOFMMWDuncUUY
nMB5ZIC9kOBKrPkGxj/Dv6CLTIPnonnwAVkBZqDk+l5gIdwAjXBJ9B8kApuj/6TpNJ2FMei9yPU0
ndWO3f1R+o8vOgMmsBixUUiJw7NwHXijv0Z/xZ5UQxeOh8LlsJ6k4CoWRDuhgu4nJ4kKvsHyHWQH
zuvz0hz1zlzvLDHY0A9EpF0Ge5HW+sMypOcAUrTYN58DkKbYfPbOqTSf2HLvXPbCy/CYtKabpXX6
FilODS66gOX3AitH+jqCrUzAtW6ByTjra0kbfYTcHf0GaaQaXocdOMpnyXCJUxOlfjMuDURPSTw6
D/tRjbTfhOtJIRv+Bl7Yi6mtuIJ3UzP8A8s/w5W8m6jxbhWEkReOkfHY98nwA5bWYd+fpVpMPYnw
LBTCNmx/I46K0fGy6JfIJ5uxbzfhan+NM5GHpYC9UIMFcvCaEj2D/RDjvXgUW7sJ5W423nWj3EvA
p36FWghH/405t2GLZdiDdByDEy5D3huJq1kNKrAhdi/S/kvwAFyKPQjBGHhPev7KaA8+Uwv5UC7J
lzDWeUqSCDOxH+WYcx0+MRx7EEbKLYIbyG5iJBa8TpGb8JpJZnIFKBvXkLeIhz5K9bKHyKvkK+iA
uXCcmHBmo+QA4eEbchZl/3IyGHn9V/I+fA6fwVrUFh8RD4aTCBvbLdgqJZQmk3oYTp4iZpznt/Ba
i2Wxq0O6elt+iazHdo/H2/2VtUnykL/PtxfFustROj9IB5EVpIW4cXQgURZSEF1MR9AJ9Ea6kb5P
n6VdCM/QYdRBvXQ5Hc3dAKegAWx0AB1LL8drGl6lWD4M6Z9dnb0XvYl29b/vVzKUuugyOqxXkvxv
4QIu+m/Qyz29fPK/hd/yUD9gvNILUh962/8vdamVKtlFvkCJFkZadSIFX4dUdB3SiQ1XLYI6IYJU
GkIqfQ/z6pHi10itxXRwDGwxra18P6aVVZ+ATLkDM3qQXxUoAW8gS8lKcg95hETIERKlTfQ1eoh+
zhGO4xI4F3cD186t4B7h3pYlysKyibJJsntla2QPyTbKtsn2yD6VfSffJX9Z/r38x4xlGb8IKUKq
kCE4Ba+QLxQJ5UKlUCXUCkuFTcITwtMOuUPvMDqcDq8jzzHacaljlWOzkzoVzhQn70x1pjntziyn
3znEOdk5zUVdWpfDAx7qSfRoPQaP2WPzuD05nmJPpedyT5vnFs9tnhWeez2PeJ72dHp2e/Z6Dnje
8Lzj+dTzjbfSK3prvC3ey7zTvXO+lZ+ipxJO5Z+hZ4QzwTOVZ6rOVJ+pPROOnkWtj8YQbJDGvwH1
5FvkVxz/qzj+TzjoG/8tOP67uI0yIkuWjZBdKuuQrZbdL3tU9qysS/aJ7Ft5RL5H/q78VEZbxgYh
UdALJkGQxl8olPWNfyOO/8kLxj/KcYmjo2/8Ohy/xZkRH3+Lc6o0fuEPxt/YN/4OzwbPk33jfx3H
/wmOv7xv/NO8s79FIXJKdirlDMHxZ58ZgOMXzww6U8/Gj5IdqCVqIBeTatIZPUIakTBScFaMKBF/
iJ4+uwHvZzH66fH3ZPdk9aDlGoWenp5fe071nOx5t+els5+fPXL23bNvfNUMcPxIzPw7tuzYqi8v
OXbLsV++3HzsmmM7MacDof3Y9V9efXT20WuP7f4ycuyuo5uPrv5i9RePfnEHwBfMyoWjpi/mfTEJ
7/K/EL8o+sJ9pP5I3ZHKI2VHgkeKjuQfyTriPGI9YjhCDv/j8N8Pf3v468PH2VOHXz287/CLhxHL
4VcOP3b4ucN1h2sOVx92H3YedhzOSNuvfZHVkr+ofFz5kPJB5QPK+5XrlGvpPyW+OHuB3Qr06Rhc
cL+DHukzbLPhDz4c2tzcQe5N7rPflbwdgz98sosBtzt+t+OPa/7uybu4jr70ij+stZBr++8FKC9u
gWX0JKxGS+NWuAvugIfQwt2E1no7Ts7NqD9PwT/RrlwjWbNHUNc+jNLl36iVf0TJ/zQcREn1DEql
y1BfTEUtPw1ty0PwNuqwN1Gj/A3tvvfgHXgXNfIM1Mt3w4fwPtqzM+E7+DtarLNhFsyBK9DyuRKt
l1a0Auai7bsAPYarYCFajN/CIrTwr4UlcD3KvJ1ohS9FedUGN6IHcBJ2kdVkDWoyjsiIHM7AWbQ5
1pH7yQNwDnqIgijRfoqSB8lD5GGyHrn7EZJA1ERDEsmjZCNq+P+QTeQx8jh5gmwmW8iTqAmfJs+Q
Z1EKRMhW1Cvb0H78K2knd5DtaJnvIDtJF0kiyWQX6uYUoiU61LfH4EuiJwb0JfaSVNTYK8gL5EWy
j+wnf0G9aUKd+RxKaQtJIy+jfrYSG0knGeQV9Dx+QU16HL4idiIQB3GS18hBcoi8Tt4gb6IUehs9
HzfqbC95h7xL3iPvkw/Ih7Cb+EgmySLZqB2+Jn9FjXsUPkUNfxi+gI/hc/IDMvo/UYb/i/wbParT
5D/kZ/IL+ZX40XY/S86RHrTJo2iGovKnHJVROVWgflHRBKomuVRDE2kSTaYpVEt1lKd6aiB5NJUa
SYDkUxM1UwtNQ51kQzs5g9qpQFegFneSAlJIXaSIuqkHdbqPZtIsmk399DZ6O3cft4rzcZlcFpfN
+bkcLpfL4wJcPlfAFXJFXDFXwgW5Um4AV8aVcxVcJTeQq+JCnMhVczXcIK6Wq+PqucHcEG4o18AN
4y7ihnMXc2GukRvBjeRGcaO5MdxYbhw3nmviJnCXcBO5Zu5SbhLXwk3mpnCXcVO5adx0bgY3k5vF
zebmcJdzV3BXcq3cXG4eN59bwF3FXY28cQ23iHxFTnDXcou5Jdx13PVok2yFTtpOiuF5tFtfJl+j
LbcdDqBN+Be0c34if6P7OYqaex3q3ZfQBr6HhGAlys+F5G7UI/eSa9D+vY50k3/Qn+hpTk7/w6no
L/QMl0B/5dT0HKfhErkkLplL4bT0LGfmdBzP6TkDl8qlcRmcnRM4B+fkrJyNS0ct7OLcnIfzopes
gLgDjjHFgP6Gn5nPLZMrlKoEtSYxKTlFq+P1hlSjyWxJs9rSM+yCw+lye7y+zKxsf05uXiC/oLCo
uCRYOqCsvKJyYFVIrK4ZVFtXP3jI0IZhFw2/ONw4YuSo0WPGjhvfNOGSic2XTmqZDFMumzpt+oyZ
s2bPufyKK1vnzpu/4KqrF16z6NrFS667/oalbTfedPMty25dftvt7XesuPOulR1333PvfatWr1m7
7v4HHnzo4fUbHnl046bHHn9i85Ynn+KefubZ5yJbO7dtf37Hzq5du/fsfeHFffv/8tLLB1559bWD
h15/48233n7nXXjv/Q8+/OtHH3/y6WeHj3z+xdE/bZc/bZc/bZc/bZc/bZc/bZc/bZf//9guYsO4
sWNGjxo5ojF8sRiqGlhZUV42oLSkuKiwID+Ql5vjz87K9Hk9bpfTIdgz0m3WNIvZZEw16HmdNiU5
KVGjTlApFXIZRwnk1LnqW4SItyUi87qGDMll967JmDG5X0ZLRMCs+gvrRIQWqZpwYU0Ra07/TU0x
VlPsq0m0QiVU5uYIdS4h8latS+giE0aMx/Sdta4mIdItpYdLaZlXuknCG4cDnxDqzDNrhQhpEeoi
9Qtntte11GJ7WzXqQa5B09S5ObBVrcGkBlMRk2vuVmKqIlKCmurKt1JQJWGvImmu2rqIxVXLuhDh
PHWTp0YaR4yvq7U6HE25OREy6DLXlAi4aiIpfqkKDJLQRBSDIkoJjTCLDQfuELbm7G9f0aWFKS3+
xKmuqZMnjo9wk5sYDp0f8dZGTItPmM/fYuP8oPHL+5daufY68yyB3ba3LxciG0aM71/qYGFTE7aB
z1JPfUt7PaJewWbRHMCOsO6zocQGNc1Vx3JaZguRBFeNa2b77BZckLT2CIy81tGZlibuih6DtDqh
ffR4lyMSsrqaJtfathqgfeS12yyiYLmwJDdnq1YXm82tySnxRGJS/8S0vjIpJVVnqWEj+6aTsB65
hiIZRITLBOzJeBcOZAALpg2A9ssGYDX8NBF8KjIVl2FWJGFQS7u2nOWz5yNyD5pA7T+hCG1xdZ+8
MGdyPEfh0f4ELMmIo4/AsLw3HfH7I9nZjC6Ug3AhsY9V0n1Jbs7CLi7ZNVcrYITTB43j8bGm8gDO
ucPBVvWOLhGm4E2kbcT42L0AU6ydIAb8TRHawkr295akjmElbb0lfY+3uJB8t0u2RmpE5e37S9Ea
9XUzyyPE+D8UT4uVDxvlGjZiwnihrr0lPrfDRl9wFysf0FcWT0X0g8ZzVhpPUSsnlSIlTuyrzG7G
J0ZkHvxTSJQ8tUupQlKUcohQH9G2DImFTWqH43/5UFf0FHtKis4/Fu9mpNx/4X3FBfcXdC+xncMO
y7x02OgJ7e3qC8rqUe60t9e7hPr2lvbJXdG2KS5B62rfhfb6Le1z61p6V7QruvsOa6R+RRMOYiYp
x+5rPEiZLJR7IsmeSIoUJnkiCVIa/0yeiMVjBm2l6ixUlg0MmI+dkrgwQmJDbBzfYp3cxOib/ck9
Y8ZHFNIgHExYRRKlppIlFFrpL9bsaOSOSNiPf8gLTTfG6N8Re6zfB1vgvEQ7tCI3x4UpkFKC14V/
mMOWXmhBYve0D7C6HE1d0WgLk10tHpSXtMUjsOL2Fky6IqOyWalXsCLTtXib8DGO1b3Yz/gmovTU
s67iwFUeltD3zkYK67M5MGb8h1YHzpq/kmhPBYZ0pqjH+B3YfGR0NvaYDU4tPZcihSrPqVjVyspI
o/8PsPBSwuCJpErTopP++D5cldrfYSO/Qxeb1N+gQ/7ZBW1ce2dCUVsXRolFgWon146MlYKhHSGA
0IKwH0HelxNGWImwD+EHhCiCkruZfgwWrNPG3diZbhern+IWQyMCBQHDfJbiFtMNKgA75lyLOdeC
iNCIIOOu7StZhCWLsGQRliw6X8Itoo9INURuIfYwXwoFFnIL+55twbwINxf7OxfeRTiGcApBjob7
XNAitMVLZNDBXYGpK7B/jXhPQM+1Ygut2HIrfIAgg7kYtiF0IHB9ZSJCI0ILgpxrjffqA2621J85
WGeONObZmJqNtWdj7dlYezZ8iKDg5sTHMzveay32+iMEivVbsG4LzEHg0CKzx0c1EUsm4uxNZLhE
jZ0P0RAXpmFOhhqKs3cWjS2MJbw5hbs4O93QOdouVCdwGfhcBvYgA1vLYNjwWa1d69R6tLmyY7vJ
pXCKXCom0kZ7o6fR35jbWNPIMhs583Zlo5PMrdahg9aG0IHAJsCMDZqxQTMOx4xLY6aPdObaO6rL
OSNsQNiPwOoZsdyIT+IdZ6Rvx4eRik+n4tOp2F4q1k/F6U/FCUml78drGLCGAWsYsA8GbMOANQ1Y
04CLasDWDfiEAdScgT3RaS9tqR7EKTFfiSSoRMwhToFPKXDhFPikAksUuPQpGKZwKuyPAutMwhRB
MmbHSlZieh8ClcoDCCGOHTkJYM0Qtki5BLxUeCnxUmBuFI1Yxh5UaoNgLYLsQLZzS/1kZXWUvgbP
IexD4GApfQNrLcX0UnoQ4RDC60hWS+kzCM8i1qV0C8KTCE8hPC2VPYbwOMITCJulHHTh6KMIGxE2
STkPITyMsB5hA+a0SphaEVMrYmpFTK0SplbE1CphakVMrYipFTG1SphaEVMrYmpFTK0SJiRlhEcR
NiJsknIeQngYYT0CwxSWMIURUxgxhRFTWMIURkxhCVMYMYURUxgxhSVMYcQURkxhxBSWMIURUxgx
hRFTWMIURkxhxBRGTGEJU0jCFEJMIcQUQkwhCVMIMYUkTCHEFEJMIcQUkjCFEFMIMYUQU0jCFEJM
IcQUQkwhCVMIMYUQUwgxhSRMAQlTADEFEFMAMQUkTAHEFJAwBRBTADEFEFNAwhRATAHEFEBMAQlT
gD5SHcXwUYSNCJukvIcQHkZYj8BwHaUrEDoQViGslXKeQWBYjiKWo4jlKGI5KmE5iliOIpajiOWo
hOUojuco4jiKOI5KOI4ijqOI4yjiOCrhWEqqkC5elejrJYSXEQ4gvCLRzgMID0plaxDWIqxDuF8q
uxfhPoRVCKulnJUIHQh3I9wj5dyBsALhToS7GI0gtlYJWytia0VsrYitVcLWithaJWytiK0VsbUi
tlYJWytia0VsrYitVcLWithaEVsrYmuVsLUitlbE1orYWiVsYcQWlrCFEVsYsYURW1jCFkZsYQlb
GLGFEVsYsYUlbGHEFkZsYcQWlrCFEVsYsYURW1jCFkZsYcQWRmxhCVsIsYUkbCHEFkJsIcQWkrCF
EFtIwhZCbCHEFqreivhCEr4Q4gshvhDiC0n4QogvhPhCiC8k4QshvhDiCyG+kIQvgPgCEr4A4gsg
vgDiC0j4AogvIOELIL4A4gsgtoCELYDYAogtgNgCErYAYgsgtgBiC0jYAogtgNgCiC3AsCHVb0Q6
X4H0Ph3pfizSv48+Sx6iz5AZSH1nkQq/RGpcglS5GGnvSqTBGqTFSqTJMqS8XKRAP1KiBynShXTn
RPpzIB3akR7TcQwbsdcrsPfTcRRjcTQ++iC2/QC2fT+2vQ7bXottr8G2V2Pbq7Dt+7Dte7Hte7Dt
u7HtDmx7JbZ9F7Z9J7a9Atu+QyxNL3P57A4EJ0IJwgCEXIR0hFIU6mQ9oYRAAkEPFkwmtHJ4nUqs
NtBZ1AubIIlmsJB8JYVHpfBxKbxLCmeK6ZuSvtqUtHNT0k2bkq7flNS6KWnapqSGTUmDNyWVbkra
Q05AI9YrEdMak25uTLq4MWl4Y9KQxqRBjUnBxqTixqTsxqRqF/mBGLHWOilcJYUrpbBZCstYCGel
8LQUtkhhLN8hhenE2JkECV3kkc6aPHt1AnkIZ4mAnTwINSoW39/p3GPvInM6axowmt1ZMx+jqZ3O
MEaTO515GLV0OnMxurTTmYVRVWfNYIwyRE9Nif1nZ7X9mPNh+9POCfbHsIWNzoH2lTVv2Vc4/fbr
aortS+xdMrLDflXN5fYrWVI02WfU5NqnO5+yT6kJ2Mc6s+31+HhlDSvT2AfgoyVYlsvqdtr9Lox2
2se4ElwJpR17qAyU0EEyxXxlxwhlR5GyI0vZkans8Co73MoOQdmRoTSoeJVWlaxKVKlVKpVCJVNR
FagMXdFjYg57yWRQaFmkkLFQJqW1lIXsfRQ6g5SoKDTApBfoLLydjOFcOmsrLY3ouWF02KgaMiyy
/zIYNkWInB7l6iJqdJvkrhoS4YfBsNE1/gXmBcMillHDIqPQv+qisyJttcME/EQsI6Xb/bVNEa+U
7CKA6cJ4WsR0eTzdhunB8TTWb4qU+od1KaMjIwP8wyKqxkvGbyXkria8i9DbsJXR47tIlGUts7Kt
jl1AiH3ZnVYWR5fd2dQExoUhc4iv0pXV1/6XoCUe+s9/zP3SwxqvrdYgz3A483bybymslULzNqV9
njJWaRSr1CFV6pAqdUiVOliljnglc3pk9bBR4yPRdBx2PDGsi3hGCROx0zV0Vl3tLuQujJrG71Jm
Q03dSJavzMYpGIZkINWjc2L1ZsfrWQQ6h9WjcyxC/3rI7XOwHnZ8TrweOKX2nL+p56KzWT0Pi1g9
EVxSPZdF7Fdv62JXXe1Wl6u3rcVSncXxtsiNUh27ndWxS3USHgS7VMee8KBUhyPn69hjdfQDeuvo
B/yujue/1vH/3z7Tav6vVaRP3SxGyo3jt6qgpmnQxFhs1M6tkkgoKVx1v3U3/JX7HjT+pojaVRPR
uGogFDL7tZUk0KxIjCgwT4nAqlc4zDdYd8uAbJaqJ2J2Urwotzq3mhUhu7GiZLbDFy8y31DhsO4m
m+NFWszWIZK+Htb+f3ct+L9/rpI+/4uKrOoCMNfNqu37i+UuWOD3L8DrKgykWpj2+2EBzvaeXndC
TG1F26eVtnKtslZ5q6JV2apt1bW+gKWt6Dq0oiORsqCJsHauItgcCzG4mrXOUgtYJpH+FuDMYQli
ANnfEO4BK8YZ3BTIAIgejcPxnhti5T3nolH0tQEOxiH2eQtmIdyLcBAOkSaMG/FuF7wNq+AQqPH+
CrzuRdG4hPwAf4G98G9YC59hfgpcBe9CHdwPt8PtZCi8S6zSCfQ9MIewk+P7IRVqoAluxrLnUEZ4
wA8FkAZrZOWyv0d/Bh9cCzdTO90HObAQ7oaz0R6Wgxh6YITMq8pB7ClwCbxF0mQPQRbMgVfhK9mh
6EfR4yi75di7t+BnsgafvgHuJ4nkctJKFpHryWayWR4AE4yGFuzpXngTPiPJWPIU+YDewE2StfTc
DAp8ahocJuVEjH4NmVACM+E2eByeg5Nkk+w6OXtXnQkXwVZ4kWhpOjeJWyo7EF2E/dGDGUbh1QxX
EwHb/IWa6EK6j74s1577qqcrugaqYQiMwGsszIdr4Ba4m/DkRu5d2SwcdQu4oAovdqZ2IrZxOcyF
O+FZnLNDcAL+haOoIReRe8iXtFmWJxsnu1n2rnxp1BgN4vxbYCD2eSGsgYdgM2zH2TiIM9ADUZJD
8vAqJQNw9A+QPeR96qF+WkHncsXcQm6b7GrZtihEn5TOdI/G6xpogw54BB6FF+Ej+A/aEwpiIjbi
IVPJdLKQbCTHyTmujHuT+wl7cZPsGdm7srPyLOyBFypgGM7rYliCI3sYnsB+dMMPBIhKelPHk0ux
havxup3cS+4nn9IO7MOTMp3MiKu+XfZqdGl0Y3Qvrn0R6txGnMdWWI2rdD88AOuxtWfxekF6r3kY
jsNJXF+BhHBOxpIW0kbeJ1/RdLqdvsAZuTxuMHclt4o7yf1bZpINl/0qb5Bfd+7Fno97PouK0fui
q6KvoQxSY3+rpDGPld5/sred1yM1PwjPIJ634T34EDF9Dd/DObT+eJzFfMRWTxrJSBzJDHILuZN0
oB32NHmW7Cb7yEHyFvmQ/Jv8hxKqp8PpxXQKvYm20yfos3QH/Yh+Qb/ngAtzW7j3uO+4H7hfZemy
QTKkOdmzcpD75CPlM+V/V7157v6e7J5wz309/4rOi36ONlsG2JEyvDgvIlLdWBgPl8F06W3tVbAc
OXE1PI289xH8A/4J/4KfsLcqokZqMZJ0YicO4iPZJECKSQWpxv7XkiFkBJmEczYNV2MumUduJstw
JHcjdTxINjAOIfvJR1SGl4aaaRrOajYtoEE6gFbSgbSeDqEX0UY6Ea9mejmdT++gK+gD9CH6OH2Z
fkA/pH+l39FT9D/0LEc5GZcovVFLld42NnHzuBu55dxKroPbwG3ldnOHuDfweov7kPu7zCHLkoVl
Y2XzZVfJVslelX0vF+XD5S3yafLr5HfL18sPyf+t0CouVqxEGnhd4vAL367fRcq5G6kcsZ+BdXQ2
KLk8OCL7kozn/kO+gUcU9+DITnFNsumy6dxo6Zy4JNcwPCSl38Xrrb77Q7j6/5s6j8AGshT5PYyp
hRQpl34OG+AYaUDJNw25oQR5YhtSFTuDvRalyPnUy8SOlD0Rpc1yeI6uIqeInV6OfL6D5BIlpNKD
eI0jbpTZe2AHuYabAI9w28nF5BXyM/LEETpDliOrJVEuF35AR2cZcmYp/QrqaQaZSP9GvqCnyBsy
K/FDIUqu5+AAmyW5KCPyS+iM6FGU+kEm8eltZCX3b/ImlybVmsrVwmp6ExlMc+F70opj34mxOrpN
5okeic7nGqPD4JTsPvgRvkH+8aBEzkG5NwclLpOaM5E+X0QZyOQYk2DPki/hIbIHLCgDbpe9Cg0k
hHx3FVxPDmKd1cQBLyPF4ljIG2CFajoDeDKMjMSWl3HD4RD3AcrCV2EnpfA1N/vsv3vGck1n1/Ro
SDv26yD8ADeiXD6E81/C7To3qmcGaqaDcApzWGkNjKA3owRagG0ATEXMgNrMg/17UbFWsbaPcGb+
v4SnzwO5HOfzOGrU0X8Mirb/GVQ3nIeEIzFIjAAkvw2gr/rvYKyMgen4eUh7/zykXxoDx5MA7gl/
AJEY+BQxyLwPILszBjkrAPKwPwWPAxR5YxDsAhgg9IPXASpaAAa+CBC6BWAQGnK1U8/DkIY/4U/4
E/6EP+FP+BP+hD/hT/gT/oQ/4f8BUHZCUS4dPgIlVIk2hXIL5sllWzhQK+RbOI6mJShlWwhYVFfs
IreB2X+x9sfK4ecqL9aerhyuPVcJocpzlQwK8h06h86DAUGn/KzA7T8rsgP8gmw/urLERb6VbaQb
EY9PTCHAUT+QkTQCI7k0eRchWxeylk8PP3HuBATOVWqxOeIodciWnN2cyY0n3+5hL88So8dlH8sD
wIMXBouJyiRi9iTLnR55UmoXXbUtzBN+D7kDMsFOV4makCqsoo0qorL4usiZrbdLXW+eN7xb++O8
bgh1h7oL8mEeUSqUCpfTW1JcWhqEokJjqkEZLCn2upxYoFSkGoxFhaXBUtnBfH/HY5+u252Sn0OC
H6/bfSRx6vDmi+a58+Mx/eXLN7f85eNjZfVfvk1mfvxleW1p/m2LL5r/1JfxGAi8gD57FfbfRqyi
oDckGUMq3kS26Lv0Mh/x8aVkMBmsXwVryRq9ytoVPSVarTnFA2wP2KjRNs42w3aN7XZbl02hN2eV
F9u6ose2GS2xON3D4m+3ZQVY/Mm2/EIWnxDNReXF+nxXYbHehimIffmNffdtN32bvkPfFZOcY0Gd
oIofH4/n7nCOw87aSBfdIibyegPP6/W2pUZi7CJPiGaQqxMS+fRMPa9daSEWSyPfxnfwHN/FWZ9P
5018uno3mU4+R0rxayv92tPNZYFmKbUfSSXU3VxWtlye51ddrz2ANXpfyBA/rkXzPD9hwMVWQeFy
SMsSLCrSx5coWMp998M7dfkV9vpz99UWlAuD39nxlzyTM3tAWB4483C2ryor1e+tyjRy4/I1Od5A
yIADuRJn/RjOug9+FstBQ1ITfd6gdxfsTDoEJzSnNKqGxKG+sYljkpp8UxOnJ12T2KbZotmSuDMx
UZNkTRoFXELSYx4KXdH92zK8xVKcncfiNjExUF6ssak1YDDyli5qEdW8xyHnRI2tmOsix3cSAp4E
dSLWvVpMspRogbTAXGBMwFoxmFkrx7YlqDGmX21TJySkMDqOuIl7N1mCK/CLqA6o89WNak5tyewi
J3uJePiP55rPlV0XMGvP+f04ZRITak/4Q93durIyXRnR8WU4q8hD85pxWud7HMHYnCodpVAaI2/F
ecIPxkoVMvI+ecnv8OQmpJ6dkEe3Xl83p2VCR67R4Mh2B8pHnl2++cC0ns/fyvA7UjOnfEq+uq5u
SPXE0SN8KeaAM79xwXU7l1+5tRso/AP59CeccQFyyOPiO74UnxCEoCqoq4d6Vb1uLIxNHqsb55me
PF03w3MTuTV5NVmrXJ2yVniMbBZ2JP81+dPM75RnlKdT0jlBkaMTssEnDIBiYQjUCo2COs2bLatM
CeaIKRNgcsp0e4uwCBarrkq8WXhItVrzllc7CxbBCr7du0t1SKUolxerZqVcISwW2oV1glKWbEzO
kmcpq2Rl8gHKoXCRbIh8iDKsDeuG82F7WBibMgdadVdrrhXa4Q7hcc02zauqj1Xf2b8VfhEynGZH
iQOXboejxGn2SMmdHkzmlxeztOjCBIgZGAgYWE3pCnD4gNM6WhxUcOQ7Jjk4h7Tylnh95EqcW49a
znnEbJItmq3FgexQ9tLsldn7st/JPpqtzN5NUyGNHN+e4dEnmXaTSeBDEslXEMVeJBEHXQVJ2GC6
vzhpFzcM8rQ/+rvPNXefgNC5H39s9s9DKadDUpg3n5eIgmfE0cd1jD7mM/ogzUTRSwsSKVCJNnyM
5YoKTSgC3XovoxlJHAa5XyfeMfjOXdduOLXx5au+vO25zhkVvosKzVaXby0pnS2bPnr640019Wtp
2qDggQ2dj3z82fGPeg4crxufnZ5ddFGK4S3y5cqFz984YeoioNGvUf8YZC9ADgTIHNF/NI+U5RHC
v8t/GOA0fID3WEutdXSwdSwdE1CJGtL7/V0d3yvDdM6xYqpopLEv8Gb7c2BfrAScMDa6H1JxohON
VKNOiH9N5vyD48REUUOtaZb4F2pe6HtwHHvIQNwup/SlG5u19yGncxzJy8sJWK2UBPJoLuANCeRD
bkEer9M5UzJCui76iJhA8wyU5lltNnbnzMkz5ORgBcrl59isXEGeNS+N5gZygYj4RAohKGz3iFq1
2+XSaNSqpXkr8/blcXld5Npt+Q/Xmf0WZHowh1Av4oXrynRuGVtRUxn+Lc/zozhdnocCFWO2zrjQ
Zcu11x+oVFZWLtceUB2QV5p7l7yZzMM1Jw7lBWI2aCK9BODQB38jfzWUe6IneXihJHl7/l5bMGoU
6V4uCWCy56X64sqMwT0npdtCMXyWNFwfl8TFDZRz+n0Ds4xntTQnloc3pIGs7pnNvqV9La7+UFx9
G2TBF2JWKQlmjUufkb4w/Yn0V7M+zvom6zQ5naUxgjGdgp3Ev6+N5sRujvTprwSVUlpW1F8cZbnb
neOy0tPZvBuBGLB2Rq4pK1dFTSrIziSg9eymHYxrRAuvCUGSNklM6kjakCRnyfwkLinNj2J5r5ic
pAuhxG6EFjjFJDb9+47sBDBBtrqLmLY+GtNvfu0JprLQdJnX7B/e3avoQt3abqbmYlpOksMefXw2
5YUmSRQn0765lyNTBUtjgtlFtE9W5LOZfebLxSNSUm03PVc/+6Gey2oLRhL+s6WPzjEZ1Pfc+ulb
nDNHmsvHr4yU10256fW2jFy/t6iBjLtrzuSAd9ka1HzX4Oxuw9mtoD5xXGZ6ljPLleUeqr8ovSGj
wdngbvCMIzPILP0s3zX6a3xbnFtcW9xbPIbX9a/7juiP+GSo8XmT3uRb7ftOr4CKzKz0jAwbZPp8
aBxY0+JfQtsXm/MYy0AaYxsdPW9oVKtjKxXnRSyHFKkO9zuzQ6xAuyOT+GwZGbkur8Hl8uYXFeWW
ZRvKyrJdepevSF/k26jf6Num3+ZTufVuX62+1ncHuYNX+Bj7PCKaYrZKhssrFJUFK/KzsyBXm0tz
u7jGHZkpQXuQBjHZiQNhsteCjJeVCykV9goaqghXTKporTha8UOFooJJdSysqEiwCl1ktljn9fpy
kd35XDV2Oj+7uExPfNxAvpLZQC5veobMJmpSQhW2FtsxG2ezoRFUqS5jWYGyUFlrGVdWNrBSv5sM
BB7x6hINIYHP50U+ZjkpUJB9CpVIUg+YmbnkP4H8iyYTI6VCjE1FMaIiOlMZ42zU9Wh2h1Dfd7OK
qP4rz/nxphkpkSl/PgZx6muetzwZ5UIykw8sIe8VECgLlNrKSmWythK0MXt73vzm/2Z79YoFOder
I0odXFGwtNek6M2ldeL7MQEhSqJAeFKQYu6VGu3gPFdeguncT+J2nSGr3BVIKJSyEskvPR9m98mF
uKwgPa81VOXYDVmX93wcNhfkZqRmnWwI5doNZUjTG6LH5U2ywzCIjBftijRjGvUmNiVektSUfLDk
o7SPhE9Kvkn7vvh0mqakuJgRhY6AgRQX4oM80fJunvLstB6PGpjnTU4xUVvsFN3eYqezi4g7TCXF
QKqlGgNZDU8KkRVDQXq6pwpKSjKDuQMLqpjArhK1ZVXPVZEqWYqBejwpXIFHlCUIZbjoycUpZaQM
pXlnAuvAPWJSAiGvJbxTfbSaVo82McrTodhZbyJg0pqOmThTWl1uF+0Q01VifnGxSnR6ipeqVqrW
q/ap3lEdVSlUltqqR2Nmnx8lDEoaFDjD8WbxKWIO+Bf/UwqPNfsxTrOgkkhDnR/CJW4O+P0/MtKo
BEYoMe2PdiFbfl2Z9muL1u/XIQHNm29ersqTKMPM1MM8ElvomEtUGnQUGk3919qH7OCV/KOYg8TM
AxRefWQSMyX3VDz0ztVPnJqZbPev/5g4Rt9dWeDFdbexdTemKJJSbxh79WUNa012Te2E7YNvFe3v
1RWU24eQK2oLysg1Pd0XBWc/c+eA6vveeuQzp9PDqGFZQ8ionc6n5wZce668r6hwTulQa9q9fl9l
lolk+3z17ISliBLvSpR4g7nHxYZMfggMCc4oWahf6HqCPsG/qn/V9bHrk8Ff6792/a3k28Gn9add
Pwd/HmxQeVUlCUHV4FSaylu8O90qXjSLFhozNXQoUqoTL7AoEhDUCKbo/k6sWK3DtAYhESEZwY7g
QHAiZCEwtk/0Jsd+aoT90kh1Mn3vQgsFjLH2wMzq8vLenyApCfZKRy2aOQmiWjRh3zRotyQzUkq2
i66E2M+T1NUPhhf6N9uZgF1DNQdCv+74EDJj3RITsxP6G0XvxTXqOOg1iPS9NtY2tJQS9sZ7amIk
bBbtoiA6RKfoEzPFbDFH6g0vZiUH8nLjX1nu32SoamBFeRl6GiW94zGhIYXmDgXP4MFeD3gHu4mL
egcPlpg2WGLAqkEXma6f7qIuSlluRUy+83RwUO/ylqg0gQJrQR4aUh53LiHrgaSAHSbBejgKx0AR
gjDeHAUZiOUl0EWyRF2oqopZV0F+SGZJEGW3dy/K5MH0HighA8VcfmnwueC+IMc0RSAYDrbhzTvB
o0FVIBjC20nB1uDS4MqgMpg2NMH1Aj5JQc9C5PEsPoVfyj/H7+Nl+fx6KfEOf4xXsDzKW4YkBE28
CdGq79zF+WKeMZoOsf2I+YMmjn+eZ1IF5c7j26xaFnd2opbAGk1kePcJdOwkrpdqBlnNIHP2sSbG
e7cZk1iMTkViLEbpgvE923Q2Fh/qRDMmbu9jayfOnfAzcY8KhfnjLHkOVch8SaegC3mCmZN9qgMV
Rq++YGCWNEas79IHOyRq7WIGH0pnQQYLVKwPKZaQMh7L47EC406MSW9nJKuIOPo0TlyAmPTemCAx
9eZzjj4dJOUplFzMhOp7pqiI29rTEBIk9XO2tqAqY9STef4K+2AUKpX2ekeI7BAdkjJ6ry5/8MCn
RqbaYhWZmiKnez6O6yAxy0A4p8zvYlpIyuv5kOTElFK2L2+I4uwXOnNmr7pCeZOH8uYZlDe59Cpx
Lb8LdloPwavWD60nQYFcBGnWCutbIE+wJuWgMaU1WE02fY7b5vaX2Er8n8NR3dG0w9ajtqN+nSbX
kJapLdUN0dalDcmZZpvmv9p2tX9B7jLbMv8q2yr/E7Yd1udtz/tfsx6wHfB/bP3Q9pH/o5wPc/9G
vtH9zXrcdsL/Tc5Xuad1P1lP2077T+dkQu8vHWl1/Td7en/kyJ9Trb5ApiX3yiljP8vsQn9Iq0OG
93JpFnP85wd6G05F8ZAs8qJR9Mo8blf8dwp6SzWSRMnNtPlzUEp8sS0jJZTD2NlutRmsVlsa5Obm
I93kijZdKHeANQ0z03SAJl30GKsrmXZOrc6AI7Hl+NNyrTqihbQCi6fA7bbQ3JwcdSb22M90Lc8L
1nyraB1tbbHKU6xHrdS6m2Sho3EPKvr5yFIrtSSiJdou+r2YqrVq8zJtVp1Wa0VNjDfq0Q/0sWYv
jxA/sqj/p5/mNTNaT7FeakkJWeciy1lF5DdGxl8jG/klI4rxj/ZEr/uFthj6Zf7l18ccs74Exn6J
mfr8sXkgtf48ZCebQmnM+EjAcecK0kRFPxATkGvSMhGnvyv6USfWibEQID9faK4FzxtrJqK/UCG7
OBc13tIQM9D+VVvQODhunnWTS28eFnPlkln2R29wZefuizNEYUOvTXb2dTqrlxEKG87qmPeWCyD7
CanfCwXEINpVPJmgbyqYpZ9ZsIvf5TvIf+JT9dtz3HeBJxDzAugf0VpiEjnvY8T9OtGHlOQrIAES
4P16f0GIhPgKfUXBdv32AjVzBG7X314gK4g5A7aYsijItXpzMzMTrAwTwaf18iJesrf8AXvIHrZP
si+1r7Qr7PYivjBTr0XbvVAt8vt5GuaPouzmiwpHrzezBQvMk7Yx/TFbvCjQ3M28b7aniWXn3b3m
eUqJgGKWlPJ/MKdjJcyk8rEt5rjz921ubH+zZ9AFRjT5dOdfyrIrrnj5+tUvTJk0eNisWSfJhg9+
bzpHbpsxdVj+uMFv5TgvLx44jtlE96LFrEeLuYFacFashhRDyJaSrA+FsCwzw1kMgs5YDFyimwnq
smHFLBbV4bHF7lKHWMVXxXhVYkurE5WLtUpMk+lLPQ4uHJgUaA2sD8gCXUTe6aWJrIWklKpEvN3B
qfSeIQlso1NMKioBSFGE3WSDm7Dmd1qsxW53UVYKewBNcClGKzwFjXAxUVHEzPIiZpYXsYyU/KzG
rJYsLkvCbKzA1Xu+LaMjg2Z0od5ODSv2KWhA0apYqlipWK+IKPbjpLJNOnTAFJZhRqy+bX8tqWU4
NHyIxWICltWuu6iqjrlcfn8zmtU/ohpEs/oculkk0Pw1igAEi5ZZyPPnSZ6WWXpp4A91N4e6sZYf
HSqmAXdBVbRtW64pVNWFcaaBxU9vc/Gx+0ILi7/YxrwGlp/Bx2IUdizuRC3eq02bmJcG0tatFMwH
RkaDxosTNFZNVdBV1iDLd8+xXl51g/W6qvXW9VXrQyp3fdAatJXUD9XVW+tt9WXhoZN0Y6xjbJfY
G51NZZOGtuqmWafZZttbnK1Dl+oWps11Lm1I81WX1TfYZ5XNKpeTZmieP6/J0+faSXvBRpORGfVI
kT6vm6ljd9EfOgHMAWCXZPVjI6TO4TV78hLStfUBT6Yy0bxs7JKXc4OOnpN3NpLhL4eX5hf43IEE
h7Y+129KIompsy66blx1nmPhKwPHjl/c0/3wmLXFAp8j6LPaG0LeCTp71ayLhQGGxGD99eG9v7jc
PuYL3N8QsuqmmDzFdcUDSx0WS5bFdX34ykO3ZCFN70Gd/D1KJQ9NFY38QkBtkQ90rnQOnTNCKVAd
M0WSSjBauE2TWKzvij7IYrS7ZrMYaXa32ICJbMglvpRcXSZfCZX8IBikE/l6/VSYSWbqJvNT9VfB
fP5q/W36dfrNsEW/R/+6/qDnU73VrHeDV18MQf2t8ACv5F9EcZcUFdE9aGNuApr3sl6peOEupkE0
0tivEbrcHug1n1kJ26bsv2HyXt8GJnsGla3FbEo1GPT9hejSHaDnBbTikYF3gMcA4MERR55HNYg+
TVf0VVGTagvxwtiSD3nCd3F20R7bLgO1Pr1AXWCzJVA9r/IY9JyXBzfbo4weEnl8nDziCwCzr0fD
UpDjdB1iRifspcWoCu4k59DCRZu1mYGuLC4kmW2JVM2k5Dxpm9Ifty5jXwhj2jUjuQ11ahILElmQ
3IatJrEgkQWkv90oJefDvPmSXk7FhcEK7CFejYqSV6OaZqvM2Azj5zvNQt/zhPxGBLuIi5P2uvtl
uejjZH+gThK9eiaBLzq37MA7Dak2lpFaW1CZMTif+OmBXpXItjh13A96s6/PdGQzmY20eC/SYg13
u7jSKaL4cajRHi/XDXCMg28KZamFJOgsLKiHMTDOMbpwke5W5y0Fa2GtsMq5qmB14WZht/BawV/h
o5pvHH8r+Lbw26J/15gTSHHNUGGiMKPgSaELXin6zvGLcNah0fCJQm3RqJob+XWCAgnL4XQITm2h
Q3A4hSLsC655DUBNYUEBkXy2rL1xtzCdkaRZUVlRPqA0WFxUVLgbSajXb0NPTvrtKadjX59vOS7m
R4qJGtprC/K6/s5evx3ZeC46e6IbnUVBzBA18t6f1KyB3zjCvrjDnChxDGJIlsd+kDO/oKDwPIax
0PuznYKjN1cvcUmSmMzFfuMzZvjGyrKcY4sEPkuoEC4RbhMOCXKFsEn4XOgWZIIQLC9+Stgj0A+E
rwQqMC6w8TVoOdQ4tVoB10vrRSbJ0pZpb9Me1MrQctwgTiYFBkIKKguyCyoqsnAOLAkJKpWuUAtF
clIgOAc5+IIA6SAbCEcIn1IQKKChAlJQUMMH+El8Bx/hZQLfws/l23gZzw/ioaaxhoZqJtXsr+Fq
ampH/4r2BtoX8yTdUoNEjCZfDdOayHo1V2lTJbNTMkikGsxq95qSQ+hDWjDASjwjNF5k3C0arKyA
5aHK79M0bIcx1n4B6ihbaaiAvc5khmaBFhsoYKyDiKQ4JXa/E58vKE3sU1dN2IS0k1QWt4OYySyx
OePxZn/vK4l58/3xjgpM8ZbaQkKw2hESmBp2NmaGBBHRC6zvQiYOVMhIMoaEi3EAghYHgNVObNNb
pHgnIhcE1Nz9v2soKc3eG7abqaqMhyptZXLlchV7+4EiY/68ZpjfDH7iJ/oLHc5Sn9zYLyNYRLgL
PVClqdTru9D/nNdTGkD38pvagkJ7xdqeXwtzY3fhQeTpfwbzUEi8WFuQoQ+uPOlWJ+Hd3rqCsEhn
91yW45EstgGZFq6nh/rdcSubrCc3kxxPTHZkeoyWr79OTeFtsfuCBsJOUNC4LCmkaeJ9BtenrhOF
P7pkHtd012rXDtfLrm9cChsKnEqYBFfAA6DIc+cV5hc2uBrcQwvHwBjXxMLZ7pmFi+Ba/TK4D1YZ
1riedO90HXS97v6efM//3fW9+6w7TeW2uLJgqGuJe0nh964f3D8U/sf5iyvqjhYmqd3qwpnuWYXX
uW8tVLhFpDi3y23oZ+C/0N+hRC1Hen9a1+mKa7mdyKRM9qRLu0WJYrI89nO7BYWF8D8eSZDESq9D
YOg7vpDsHBfwhrwt3rneNq/cy1q1og7wet2FACISEjB2UMKtQN9Hacy4W4N9dgFxuZ0uF2PmJD22
53Lr2UmBQslzUMc8B9CrXV3R46KARLkUVYTLprYW+P22bKaIgbi5QpehyKnnCxlWH+qbQuYRthau
LKSFz7nIJPYIz7JE5HR0JIqLzv0acySa/Yz7CpFFJDex142oRN6JFfPnz0gsV/Xu3qtivIRW5/UH
iJlt/Me8QK2K7d37Y/Q9779t4HMXbp7o9fGCeEWuXLxd2ibpsUuuRrv4XagAyXlPXX7BgGVnQuX2
Ifvr8gc46sm5nnfPH7Eg+eRfsTdQ2T5PtbHnOMmwlg7MSs1mG7JIr1Hx3DrZ3p7pkAK2bSo/yPaS
myGRywEduX3rh2gh/NgNgW52zKf3tWOsPzLrmfulfsimMzV7bp2kXP3eUGYq8zlvix6VPcc9gb5n
OXlGNA6Qj08Y7RhfODthVtkCx7VlfyFfErWH+dATUM8mJCfyyvJscgjkBpoty5b7HF6PN89bPsYz
Om90+TTHNM/0wmnlC90Ly7Xr4DugRDCgQyRiQITsEhCzS4iYUl4sWkQzurs5bF/T43Hvpu9L5Ffo
HEeS8sqTk4GU5+VBXnl5kjch2W3WZJaX5XGlSZr8LPdh99/dnNvjTz6c/PdkzoMkt5MkG3hCkjWS
cM0IYfyZmKItEzVtGqrVNGqoxp7PiCpDWxbOX5lPJ+UTyNfmL83n8vNhkpmYZxjsdiXp4gLbM3NB
nbebq4BybsiOUjunsc4p7qIrRJ3CQioyk7VtaLWRCnX+NdLGBvo1Mff14h+Hn/uGHRH4JlTpP4lu
TXczI7z58/zdCH4kPmZVaQizqpKlgFnMNmkjscnfzOixmTkqSLnxvYwDSm2lUptcKQXySpS8fiZr
Y47wfHZEpdlR2nvEAL0JE3vZ6ZMciJjUdcfIsY98ubhzIb1c4DLUT+27a3P5xUT3+MSFaprunXHp
qgGCI0ck9hmbn1BOcEk+88arZ912ZWhc7eBDY/JHdEwcNmrudYYCtdpjsLqTctyF1RV3TBU8PRMk
Giat5qFZngxfGbON4KXoFyhvnoAAobtAFT0lelLTij1+EcRAIzQGWhJaEqcktSQn5AMJQBXMSV8K
CwJyybk1pJcXp5sgw5mSbk9L1uo1WjuxSwXqMvvXXr09VwljNO9SRZrdqzGxxUlqySL2LCFLzGrL
kmV1kRvEROc7KUdTaIqYxHxh8jO6vHIyV94m75BH5DL5QKekj60hp6Q0URGDU+sUnPlO1KDOFmeb
811nghYTc50dzv1OubOLG7CtYMEG6X0iruePzfO6/fO055rj595OstfT/ub4tm58wwqkI1jMtCYX
Onq96xQ/ChcvVEhsy7Nlk03Kjb3aqc/zm3jP4LZXFoTviNwwrniGyx24bFPP8e4vnyJ5z4xewc1w
5dr1Wbc0VJn50lJrwb3T5k24PE07PN89JDTr4IP3Ev8TAuPxldGj8hFynXR+aJ24zCOWlBdXeS7y
TLIs0i3Sr9F/bVJe5B5ronaL1UM1otVdrGaBRjSYMWWwFA9zjyNjTePdl3hmuRUqkqhRmtI9C+Fa
stC8yLOZfG/+1ayp8AxxN3hmwiK4U327ps14m/kh9TrNFvjQ+FfT3+AE/43xb+b/wI8mg4ZJAOnF
XTImLtBN7/fpJhDs8Z9m7c1VO8dp3Caz2qxWMz1jYu8hCWgcSSZfqsViNi8RhEwAcxd3kZjqs6cq
1Qlqhz1JY8pzk9xMdFqzGakkaMXSsuJTbMuSnNqRS0wkV03im/0sFh0ZjmItCZAQaSFzSRtanRGy
n7xLjhFNI7L+Z3n5u0g788e+md/s7z2R5+/ufaWMy44EUYnBNyF/ZWDxL+ZAZYBxdtxVk14bVx6o
lE7qSVta8yWlg35Xv3N6rjhn8+ydsKnvTSApjJ80Q8qRj/jWVcte8J3SPLzp9WOPPn7nw+tvDLok
Qd8Dmw+1t953ok2uO7NX0i2Fo95et5LYJ4+cEpWk/5kHdrdPvfWL28exX8HbjHbQnUgdpaRcDIyz
Ex8pxSG269fBOv1u2KM/BIf0n8Fn+pPkJP8r/KrXqvRGMBGjXlYKu2POBRonNPaCLVgK5IXYivXa
LTrSb8+yf1Hvk/33LN/vv2dp6b9neZ44ApBHbPp0Po/tTG4QK/h0tC/SJ/mI7zG/XQB9KSzJD9is
CqSAuW7idqfnEa6MH5CZznYjB6jnSscEInyUl/Nd5PltA4YOix0UOL8baSpDfyFmQ1Seq6xk8pyt
XnL/lzcxY6EyfiaQcI4/3Jksim8CsV1jp086KqjsrU1/nUVc/Q9gLpk1pbawTBhymc72w4sNnwwY
FuC9i6dMm5CgI5XSgtN9Pcn9rIZ/+b1oH1x823O2PHfhcKVlYO7FsZcpyPdrekbLW7knIROKyTix
bVLC9MzpucuLVhfJZf6p/qv8bf4O/wO5igWwDFbBff61uZtgoz8Cz/v3wxtpL2e/7H8j9z34PO0E
fC90O/RZ7mzPAHW5uzK3PH+IuiF5SM7w3Gs8V2deU3yL+iz5Jf+XAl2WOjsnO5dbZSU+dVBd72+C
22FZ5lrYArsgIUHaKEQFbWMCQJL1ekzk2KxWAoSy/yfBXM34Qm93jrXG1tev1hjUak3A7lXa7FmA
1KReQijNJIosu13Dm5dok9UlmRq1Vj8QfdoV4CSnRHWJ2oTQpiGavfRNCEI+WSZxbezo7OnuE70n
i7oHjX9eayaNZuTFJuRdxrVaZFuolJg21N278Gb/clTF1x+A3oN+zc2MbUlpH9dyyfT8CzT2Cj++
CSgJ9f7My53wnKorwEV2rTct+eTqb2vRPKw/fukNutThaxq2H15PXA9Vz+p5tv2jm6a0f3QjNzXT
76vIMp0zzn5kobTy08JTc3L++ujdxLzFfs79zk3Nbe/d0LKU6d1BALJXkJcr6bXiRF5BFpJrHMvJ
GvI4eZ68Sj6iCaPkl8kWyj+Tf5cuz7JlpWcWD0gbUDxW+uWIJ8hO6JJ3qXal7bJ22brSdzl3FR1y
Hir6LD3VqrLarMXjVBMtMxJmWA6mqyRZaUhGS87EXqJzsX//YbZY0nZzhri4HisasRQtvS5JCshj
/wiksKio+DwvjwVep01OSlSjx38B8283sCMD0pMaWY4/O9PndePk/kZA6AhUVpQNYLZPUW+jiWhE
Ol1OwQUKJDmkH7XFZuAtFhtIDsq2omJDUVf0W7EIPRnsi9NP7HZOWVmJyiMhwWJxuYqKluRk5vgt
S/w8r1MXWQZm2izFWr7FQixdnEV0FllMRSZL0UA131hE3i0iYlFjUUvR3KK2oo6i/UXvFqmKush/
tg38pInZ5LG3zLugiNF+rilUxKy/IqZx0OpgcafOJPnfTbEXZdoT0gac1iJmpIQsooUF6BniTJzs
TDHEa/Z/39yNaYlgK6ULGAEjVaMfxAg3vmkgdcGCg2a7jTa2D2DTGqwY6C3xJhmFxzx8c/xlGNNO
7LBzvPun2b4FsvBp1nEWiwmJ2lC6GruPxHCq05gU3xBsIlzcpPntW2WTvvek9O9LevmGPtHccdv9
j6hHjEhNr8wY/F1d/kD7yLCyPlx79ZyRmId+1HfS++i9MV0n1/UMG9ax0JfTs7T3TTJ76UwW2C3Z
A0rG97T1z+WuiYlGiv46yKYin3BgJ9ZdIMfhlLFxyRJMFpnF5JXVy8fIZsjvkLWbHpA9YNoi2y3b
Jd9l3G16Q/aG6bDssCkVYv/1hv3Tm9+8+eX7zshyEmVLvybf62GnOMeJeiKzZ8R/dz6ev905TiaX
M2q1GE0Go9GEAk6GvTMtscsUxiXJyUlqYL/lxk0iGIn5K9l/JzCh0nQYhUyT1mgyCmojoxbR2Ghs
Mc41thmjRoVoJEajQ8h/pe+F2wU6Dj2UbnQakYrQZME/rFIZN1LiL9z8ROkq1f8PZ9i4A3k/5r24
+j/SBu65emlJTs9+rLagzD5Urvv0054l56p/p6xQTjXh/P8D5z9IfxK7+fzUEm9d6iDvlNQpxmne
HamvpX6Uqtan6ko8qcUlNSW1wbElY4K3pu4yvunVyFNXlXyT9lOaLEGTFSzSFBqKU0Oecm9VsMEr
+mpKxqrHa2ZpZhmu8LR6ZwfbNe2GBzUPGh7TPGbYrdlt2Gfc59nlPaj5TPOZ4TPjt5pfNL8Yfgl6
5B670W6yeG0lWYYG37CSCb4JJa3Gu4wPGe/3rSt51vtUcJ9xt3eX74Xid7wHfIe9R3xflHwR7Dba
ZvvmlCwxLvEtLllhvN23omS9MQFlQlHAHDKvNO8z/2CWm4NeL7q4AOBJTTUaDGRvbCs2drIzmcsP
5LH/SODzeff1F23s+ICY6Dj/9sL7O6PqvMb8XRGaS/F/ZdArFK3OcUYP8I3sF3CxG6lAUo0+r5dt
yHqZc69GXrZ6ySQv8TIi1LDzQl4PhjEVPC2mgokGnwwavSU+j0aAoDdVpvYsSTceS7cpNEv0mXoD
+JYESo4F8vNRQ2dStX+gwISXIGLrYeEHgYaFRmGlwAlpA9SsQM2EoahuVM9Vt6llaNZ/LGq06tJM
DEzqUnUXKd06zNyPZv2ovqWzwcwJG36CybpukGRgNzszwEgZk+yF4/lD3Gybh1WX991IrjgsSjaF
YBHb0sLxd8a2YZvYXpAk/5RaFdvyxDCZefmB5t4dz/jWa2r0pJiAEjRowCAVhTOTitI2iR6ZMNXA
Ns0uxkaNbOhqlJadmpS+YwaSjHT93kzkSi/cSHLJyYVneXxUOfSUxGOuuPg7de/eJLQjvq9l1kRZ
zxGiHVjLtp5O1hUUP0fG9DwVe5kdk3vnht/o1KIhId283vNJnDGL8vcjWaxCjpyGHGklOrEwBFUk
xIf0g8lcmEvm8nP1bdBG2vg2/bf8Lzz7x0eE8KA3gZy9IRBTxcS4ju9/UPkCUz859mKkMyleVSv/
nd/HDsUlMvbQIugk+18Gv7X/UVDqeZ7RZHrMAbQCZKKhT2yZoOUDbHvGpmYCL7Y9Iy0WQW2L1Cb5
eUxN9fP3OpEA4zqVERg7ehKCyvMnzWNHzf+nU7zcl99eKP1eeIyZ6YOZ79Xv+1N9mufJ6FHZce4J
tosHw0R9lvwaukjNXcOT/9Pa04C1dV1335MACwQI/QHiR88CLGFAAiHzF8eIGLDxD/Zs48RNXEeI
B2gWkpCeoMTZ4q7pf9b0S900Xbo0/XH6s36LGxoHO1vTrknbdW2adm2W7FuXtJ/XzWuyeP3afP26
huycc++TZLAdd6v59N7Rffeee/7uufecd6/ldG8osbhZmQvj1LJHjU8ZXzMajLUNNopbU2bJ7GrE
SAXNH7et/gqu4tQdvnQuog2mtNTE8yZGb1A/dQcLTjl61w9iZ6SBz2SfnT29+kz2L39+39KXTkx+
bOPMmdl3Ssrn44/H71n99We/9/eJ4/ecnJm5+f0QPbz5eYgeZKDUy7plOfxn1kcaHmn+SvMTrX/X
/K3WYlegtX1XYHfnrZ0HgvHOSPBdwceDpcXM2FziNQWKg08GvsleYM9vfCn4QndZma0OnENzc3PL
lpYtrVu6h7tvkW6u/0z96YZ/D/7G+nrQYmzwNvQ0vL/rXcEik2SyFgUdzCE5rDXdXub19rDR+qfr
f91QHlx581kcZkEcZmYYTw+CCSgQQTTgzqZKfoQPAgw8MsRLvxYuw29dDfX1Uintt6yHTx3fL1+Y
Z7/Mf7qkK6ck1sWiYIv13D9u5inuBlu93+0usdlO1NXX++qKfe5NpVarJJ0AC62whnB7extq05zy
SPs90sOeMx6ZUlCW6o0hz7EtEJ6WWjFBYcVCa8PGUKV1v/VR6/etRuu/hF54mAcw5Ax/1QaxR+54
BCwBeaZBD2Au1iCcTzqQU3v6vRUWCGC2sjbKJKYlPZARr33PMQbLO1wh4nZIGCEoUH1hd6TlGoOg
u0Q/8dbk6S0IdKR37jyBwc2O1Y9yt/VME8U9lyo++9kn/uOTq9+/95NP3/fjD6Q+/JM/n189Qzlp
yk8YHqKFwmjk5Yf/5LcPfu/xW9T3fPfovpMY034KrPJBsMpNLCh9O/z2tnDvQGgXjN8T9hM+43CD
NNvwQO3pekMr2+zqY/1Sv2sn2715N3jcI/Ix61HbkdZFm9bwbvbe4P3sc7bPuD4XeMLmHGvctVku
YaVSSYMXYsVh+47NI8Fv2nCzzT+GKyprB21KZX/IJqzqfNgDgG1zQ2OjtdR0Ejfq2SHUcYSriwsP
hOZDHP5ziC2bmKSXOiA4qgjXhavCNcb1xlbqubnR2ma9AffWg3F1cEfX0FFn8zo63HUljJ1wu32N
xV63A8zrRKlPOgH2JXVjlqsTI2Dc82xxe0L31jxcc6nG8GjNmRoZo7DlNn+oZkXaerZbqpa6KfEV
rmncGIJ20hnJcLt0r/Qo5bouScWSqA/2/d3l0Ngy2h5NpBQ/tx3NJb1w0m3TLY6sL2d8wv6OXtEA
8SWLsL0rHlHlsTPDBJj+sDCGNv7TM8082/VRsrA7dn7xoScvSov//ek7Ky/RdPjGHff96P3z9/7k
Hvmp302SF+aJ6v23Pf+Rb0uRyCi55NWmszejde2n+BlMrKgfrKtNGn0SXODLMHe8HA63V7ZbQtK7
pftBSsWnLeclWJvb2U7PBDtc9Qg7Z3nSs2GIjUoR/FE26W52t3SKnZLOsGUIuc33MwmG+AvhOtzn
YbFUVlUxlwk3nMv8nTuaxpBlbVqMlogVYhs8bSO1FRfuEy1IlFJsjFsK8l6JVVWh4fR6muweT1Pp
jeWWHkvdoEUqdxtL2tp8rNjjqao64XPVlnrafU2Wkg5PtaeUJ74/7DF6VmTncnvnB7m32dpW1d22
1suIGLMfwtXLHAxfMOmvz47O9/VJJfphWFAnhX5Xz5PJq3X3f2rolvfs69o0vLHlkXNDazNjuzAz
Nma45+Tbb5zr6Brfc+ju1X+4UnTxVzDH/g1ocVR+4hxI8JUwvukv6bNVurpdoeq+lsrW4ObuzSFv
386i0bLRvluKDpfFimbKqjba/f2d9sH+bOVS91LotHlFesJ8FnzWj02vl1WYLGV2U72x3zhQPNRq
CdiV/kF7Z//HKz9ef67+O/Uv1j8/VHVWOt9wvunsTf9sedP+2/rX+y71vz5U2o5nGB/0/8Ivt7S3
+Hvat/iNzf4p/4v+i6aL5ov+4na/tc7s8HtNPaZe84vm4lZziz9mXgKwyE9aNJntJpO53d/aZTZV
FFtNZn+7scXAlOBAqBLsE09p4IlnxdsVYu5+5pGe81yieeXlcFlgIORx32r/hV2242Cvhor2CecF
8IvYpn/iBsXd6Zbx9cqyzRmi1yx+eOB297QEhgeH5ZeGXxuWh7Hu8HDVDcXOUoO7p6TFXVVmt3tq
+/u3sWL0N13SA2HT1zzPeeSXPWDt0m/C1jN4lH3Hg0z6PnuJya/hNjLpN2wba4Xpzzq4bd+2Y9sM
2248WSFZKlIVcsWK5FjeOXaEv2C5cBRW8Ufn03yNc3T+V6/WigM3AVaDK57BwSo6qEW7CNvmLa+0
pS2/a0u/CkWWV+kAN74DphnNxLcMmsTmZ7j/bBmW5HC/8Fh55TaesMid8aoAZzVP+Rf/2zuqB/09
9VWD/l11lkE/tocx5Beb7/1iI4dfZHLg/jTi5d+r8f7MMgQX9L28Cu8/w5kVvz/Gd5ys2XIB/DKx
exkPQIrTwdXO6kbZYcd9gN7LdhTShkL+zs9Lmyn4+bHL9hRuMvygbebGyQ9UuzOPnZ5cffoHR+7r
a/F4A6bKyh3+Fp9x052HP3azt7PzL34yMjI9ffcDO/60p61e8W8os8Bjv/wJt3tLndXitNT2vGPs
I19zN9Z1uO2tI7u3tQZ9rV3Oem+1s6pmYODWfR/q2gbrHTxWFtw16IfQoAXG37PGZ2Eq/Xq43cRM
dRPyhEGVVcOCtCAvGDTXB5wfd56WTru+5a/c0SHVNbe0uJi/AzfE/dfjHcFQB19VOVwtdperxfdv
/roe5gn4/c3NTcVlK4at4foSt63M1etrcVnc7t6aYKpCquhLuU66PuwywPp5+WyvyVXtwgiy6ctH
9IOlPz8qVXUf7SajETPXGxfEkY2tWy2vovZp80tJET+VIdb+4kiWfj4P1zhe2tCyNsFP/x+Antd/
7JbiGt9tD53qb/C0t2xZfSZz7PDgnpLbd1MOf5cPNNAUMMHMTesh+alV1W2vs7i2uzqaA03BCaV6
amijIn2DpqhzuwZRuOcoC4yz1GmYpe4y3MN8hunwTojDTtpOOg0WW5W9ymFxGjtkr3dQHrQPOg47
D3oTUkKGEE5e2HSHt1yW9/nkSq8UNoStt0rHYBrTf6l5k3fNKrhcyh/XWvdIP+ZkkPWpCLdOloXL
ZYUyWzXVmNn6Id+icvMm74+8kpc2h/Dkls/peAkW+CuGmnAp89kZflD53znbaB18DjdGwhMzbiSx
2Q3yi7IkY+M9NiseobIxp8FhsUthu6TYO+1h+3777fYl+yl7id3uK/P6fJIklypud1lZabFssEp2
G9vU5K12+JysaXNltbta3l8tVa+Ay7JYP+iUFKeeMityrsgPhD2swzpo3Wc9Zk1a77V+0lpiXQIJ
322TA7ZB2z7bXTYjBGQPPM4wdUHvMKrALdzOXmOyhT2Hv0uwufW89GmpjtW01epJt5o3RBrV9uZ9
y7XBQRsmDJqseH9uubYS7w9hhEp3WG/THdbfeNcjVPQTtReO1lg4rnCjMwyYnCehufMUtHWOQ0Pn
OLRyjueaYIv5qm7yb/y0In70g+/8Sltk5tNb+TmleX2XmX6+Yl6/65M8+ShKhRBLTnBwnKWTgqV/
xT3ZNnrZA3QxTPQ4V3gtB730weqY3nbixRemMym4k7ty0LuSw/ZK2AZoZPTA3p46zKTAha9YAbDj
Nx9eHBUgAW8PXHwrb/4SpUgzXQUG/ApcZAXlsvLmfy7z+ysi9D+Pbhz6e7bwDNW6f0xPaTfpe9j0
tajN1m2z6btc+QqnRGqSz7309equdhjiT+Fe1z2mZ57oPzXuaICCr4907dy2+o2vSnesvkd+Sm7H
M1F42NK5+qS0d3VZGrHSXtc2b8dY0RtD9H/fHjVO0u8P479V8VvEOP6dkkXAMsA+ARtYmmohbGT+
XJ0iViOlBFwMUdP7BFzCHpHOC3gD2yS/ImATqzfZBVwqN5o6BVzG4mXjAjaz6TK9bXnxV+TbBVzB
bjMruZ+Ov8t8p4AlVlZuFLAMsEXABtZv/h8BG1l1rk4RM5eHBFzMasvDAi5hB8uPCHgDs5X/UsAm
VlFVLOBSqbLKLuAy1mNtErCZdVv1tuWGt5V/ScAVzG+9ByiRjAagrdH6QwEboe15goug3GXbIGAj
C1ovEVwM5XbbgICNrN3mIbgE9WKbFjDowjZO8AbCc0rAgMd2J8EmoV8Oc/1ymOuXw1y/HOb65TDX
L4e5fjnM9cthrl8Oc/1ymOuXw1y/HOb65TDXL4e5fhEuRVnZvilgkJXtrwkug/Jm2+8EbGRbbRcI
NiPv9j4BA+92jqeCyv9YwFh+gGALlHvsnxCwkQ3Y7ybYhjKxPy9gkIP9qwTbobzeYRSwkYXsnF8H
0uPoEzDQ4+D9Yi6u0aEJGOh33EZwLfbr+KKAoV/HfQTXIZ2OCwIGOh3fJbgBbcDpFDDYgIPryA3l
Nc6bBGxknc7NBDcjnc60gIFO59sI7kC+nI8IGPhyfgjhDQVy3lAg5w0F9G8ooN9cUN9cUN9cIH+z
Lv9DbImlmMqmWYRF4a6wLzAsnSV4L0uyBHw0UUth2+FbGmC8RqA8RjUUKIlDez9Aw1Qe+X9iCuQo
U+hXBuL0W+e8TgbKxuDO++ti/fDXyToEFKTSIWgRh/sBaDMDNGjU6gDgy8AnzRbgOrWOqgGiKgvP
Y1RLYeNwX4T7TUTDFPWM3MWhRhTqL1C9TI567L0Prvj7E3upThqeZOAzDe1a2eGr1L+8X94r/r5C
R67nwn73gnQua7HRQ7JGSU7B9zm4p9lxKMN+/+9aUKBUBfnFgGKNKFNJBjGqE6USpEr/jhThbx5w
qjLA2zgdaRljo/DZDlpBeB+UKnAdheseKh+BkoNwRb3tAC2NwN9eKj3EylkpfZCHGGlRW2ezejnn
MkUyTwnqlnJSWM89t7EkcIjcp6A91o5ALc4lt5os2YzCJunpEnGp94k8LxRIJkttue3o9HDJzVF9
TgmODq5JlexZpbIZwoLaU0mKaMdHRG+z8HyB6iWBDl3mvE/tGpLRLW+RLAJLVOJrVtA4Bd+wPApl
ceJvmqQ3d0V5JQVfKDG1AMuiwHml/qaE9aBNTNIo5lRPCs0kBOYrachLXF0uKW5X661ifc+8HGW9
QCMnC9dJuHNpZwibdtW+UfoTUBKnHjMFms/rguvp8nGB0uG9ZghPFEqniYPr0bkibDFBYzEB3/L9
4tieIknzURohD5cu8HDtudrpArvl/GlvKSmkbo7w63aVvAzfIun/OGmz0FdMC7vI10xCXe5FsiRx
xD+b44fTVWjd6K/QGrj8+ahKCfvQrXStDV2Lo7x9jBHv6zWHEkb881CuEm6dmyjduW9LrNFBeo28
85iRP4T4HJGmX/qJiblD9wPXo30dHx+TOFYXhDbyY0zHt16PXFqcA418gHbFcaxrLLJG1tO/F7V5
Ka/vIUoSxlGurqOI84MWNJDDMAH+fwhKOxjOnH0sxHphtlTg2gXfOmB+D8Gnk+HadYLtFjU74WkX
PAkJuJd1wwdb9bAtsBbAD2JHbWlA2QCsKwIgL/zzAx9rR3yUPN9Osl+UKdK5m7yERn4gDasblWbv
mZz3jeS8jI5nkWxEE74x74t1qY/BnL6Xxura1caiwKZ7TvQEi0KOqKEhKosJ2Y4CzFdFM7m+CnvA
lZNKdEfF2ImS1agF87NCWHXaY6S3OGHC//GRc5gibqJke1MF/LfTyNVlqHtyvhZYJNvl4yQ/o2YA
N/rgPBXTLL+a0MddSsx96H8zl/kitL0s4dA9wJUkniSppOial0maMCdpTcA9pUa0cHyF/i1Pr0ay
myU/oEtmCmpFoZU+CvKe0P972lmA6s8B1gD9thV6dMQaoLXCMbGe0q0jQXz6c23+sH0tkqXwuuof
pBf9WWCNJ8nhPrSUUqcjUVX5gnJoVlX2JhNJDYqU7cl0KpmOaLFkQknFo35lOKJF3qJSAJEpB5Px
LJZklLEEtOvq7+/sgEvQrwzF48qB2MysllEOqBk1vaBO6agGtiez6ZiaVsbVReWmZHxKGdMi8Vh0
YEFNZxB90N8XVHx7Y9F0MpOc1loPF5SLttB0/8EObMzb7j0kHnxROZSOTKlzkfRxJTl9TRaUtDoT
y2hqWp1SYgklqqa1CN6T2YQGqDL+8X2HxkbHtg8dGts3ruwbVfaMbR8ZPziiDO04MDKyd2T8UHlp
eemh2VhG0XTJIgxdptLJFKBbQhJy3YPEkjPpSGp2SYkkoEsQTTajKpNLylIyiy2jyQUiJpuYAukg
HiBuLoNIIgowqSagemQmrapzakLzK0eg2WxkQVWSk0g5tNQuIwaFtxhJq4oaA2RpZSqWVqNafEmZ
Tifn8nQloa/kjEpVFqFmvt0UiCcdm8xqgBrITCbUQoa8GZ0okFVOFLnGAEeUhUg8G5mMA9mZjKoV
tvYrE4m4mskQ88QF8CR0oSWhaSalRmPTseh6zhWQYkKLJWaobWRqKoYqjcSVNBlcOxanSbbQn7aW
qHhsLoYMQSdUbzGZPp7RuFVMgyyoMLkIJpKdjMcys9gP4OLinossKUA/qCq1hILLS+jyjkgeY9N5
5iKJJWU+q2aom2gyAdaWEBykBd1UOTObzMKISKsLMRgdaAPr2cd6oEk1BoOKawzr5XgEsqADLRLV
8jpGxiKC6ukroyWScw2ikYQyqeqIoJ+INoAVJg4OKR2Kry/U26r0dvV1dIY6O02mid1Q2NnVFQrB
tbe7V+nt2dK/pb+8dFbTUgOBwOLion9OV3w0ObczCZROKbtVTYur6WE1E5tB842gyWCdxTSoKK2Q
FSPpYzftbVd0t7EI1dA40xFQEpjl0FQ6BtSOpsEVzWAr3kA5qMbB3NNgQeB/cDwryhBij0XBVKZj
74AOUzEtOqtMUf/tClGIRg5eYFFFndBAzcQjk4RimtwE6i4Fo0+ZyHArUuey8QgaQJ7wZFZLZTWi
JK2Cz0Gj1CKTUI/bG+HV1OhsgoiZSkazqAIyQv9VZBaY1ebigTktEZlTA3OZY1EujoS66Mcn19lq
UY1DqfrWTfBbQBgJ1b5qpgbvfKWqifVtVmRcMAq8WiuNZaVymKEuAnycatzBXr1mi2mxMjlegP9q
dUfFGhJXk29Z2/A+w98anjY8Bdcvw7eHDU8avmRYNpyDb2/Fc0zwvP26eN4DJTwiSlLL7Br6sPRq
bXfQ2pRn4vS8FI+lri6Di1DrOHsdMF/kUZ30R1CivWUfGSG9JNPzVTp9V2t5WET2eTlgTuRqtXcS
/Quk0evUEdsvskYY3+rReN4Wlmglfz3aSgoJ/lSskq7Kk9Ft3Ga8wbjd2GPsM4aNNxp3G/uh1AUl
YeMQlK3NIeb7OyRs+6fXbdujv4ckdqP0pC5cw0udOVs4fo36fCV+nHiHFbkUoWg5cQ197oFyzAEo
RNcdtD6PMPa/KKRXEmVuZHN0cmVhbQplbmRvYmoKNDIgMCBvYmoKPDwgL0ZpbHRlciAvRmxhdGVE
ZWNvZGUgL0xlbmd0aCAzMzYgPj4Kc3RyZWFtCnicXZLLboMwEEX3fIWX6SLC5tlICIm8JBZ9qKQf
QOwhRSrGMmTB3xd8aSp1AdLxzOXeYewfymOp25H577aXFY2sabWyNPR3K4ld6dZqTwRMtXJcyb1l
VxvPn8XVNIzUlbrpvSxjzP+Yq8NoJ7YpVH+lJ89/s4psq29s83moZq7uxnxTR3pk3MtzpqiZv/RS
m9e6I+Y72bZUc70dp+2s+eu4TIZY4FggjewVDaaWZGt9Iy/jnIucZTws9rlHWv2ri1V2beRXbZd2
wZd2XhxzRwdH4c5REDmKBCgFRY5CATqBQkcxByWgELQDJY6iAHQGwSGBQ1w4SlMXfc2Y/iZ+TChg
JmJkhWcAl2CPWDALQSGmip/hiXQRxkkQMoI8QmeyZj3h8IzDPUKuA6zy85oV6ZY/vtyMxzrl3dp5
k+76uBUuy2s1PW6Y6c2iWp4fMgawtWVuZHN0cmVhbQplbmRvYmoKNDMgMCBvYmoKPDwgL0ZpbHRl
ciAvRmxhdGVEZWNvZGUgL0xlbmd0aDEgMjIxNzYgL0xlbmd0aCA5NDA4ID4+CnN0cmVhbQp4nO18
eXxURfJ4VfdLZnIMCSFAICTzJsOEIwnhJkSO3IARCCRIgqxkMpkkA7mcmSQGlmNRVw2iUXfxVrxW
BJUBPAKiIIo3RsUbBDx2dWVRdj0RyHyr+73JAaLu7/f94/f7fMhL9atXXV1dVV1dXW/IAAgAYbAK
OIx01Njrm82jPQDGOwEir3c0etWrcPlRgCEXAQS/UVFfWWNblfQcwIBkAMOmyurmCv8d5ScAJh0k
KcOrnPbyvWsqlhG+k2B8FRHCW+E44d8RDK6q8V5+64DVVwBgGo0vr65z2AFufxJgxCCAXrtr7JfX
G4aGzKP+GOJXa+01zlcen/U0wGQjzXlLvdtZ31g/4RXq+oD08YDQnb31rzffTR+0KGLS98YQYqOf
+wvWbRT3JyZv6+dvPN0eXGlEYBBC/CgZqA1++PRtAMo+f2NHRXAlWMAA3X+44OGbqZkKTRBEoyMh
FUpoupcNm6iXKfugUjDSXQg8gd9gfwzBUkxje9gWOI2PYRjW4VA8Aq9hBvwLNsEnaIEvcAVux0Q0
4xFcBodgN2zEgxgHObAIvoLboRR2wMfggWPwOqyBa0AFO+yHDwnssAdH4QDww09QjGPgXRbMAE14
rb+RZZK/x8HP0A7vwWF4F+phLyym8S9AHHjhM/9n8AFsgw8wB0Pgn/AF1EA8HMPTbBI6MQUG0HWE
ZqaZSP7ObtfPJE+79ugXSQtcZK12bWRZ6CT5+/DfZKld+MO/i/dlQ8m6WMiDv8PN8Ai4cQbZ5oPn
oA02+w/iFLwEJsMMqID38C3iuBZugdMwF3ZRv1vqtB/+CHY0QS0+i6u5AZ/GMLgD4sn2R8CK1+Cd
ZPM4vIDNgX/DNoylEaUSSsl72rVfXDhAXLCHRTPGVDaBfcnW4WoWwYawyfBn8tEe8s67cIxNgkuJ
ewz55mn/Z7R6D+MynIseuBxqYZpcF+KS3F+RZ76S/v6JT6a12ynhdnq+lGZ/T8I1JDkAdvKbgP3k
Nzt5SgDJofXMkTCAvEgg5QsolZrvQgOOJ6/eAvv9jdgH10I/YLg8AKKlqFoPt8FD6IMN/n+zOBYn
Wg0CFy5ncYJbezoXfu6LVcICcafZGETo8BitTSLtA9oJmEkrtopo1XAPRsACMNJeWcz20I4opRhn
eByPw2P4b+mjgOcCXhIg/BoAD8WugGMUwd3hdRnPa+DZTn+uhlbpz4BPpT/hm4AvO336E+05saaH
QcR2LEVcHlSwJYIeANFP8fUvkrIAltN+Xwar8Va8gz2Hh0nrOlgI98ONdL+EIlXs1FrS+125S9fA
RLlH7yI9PLRPX6D1HEP7MxJyaYeNoTUcD9eyeMoje+AHvBquRTOLpz0wH7bAt1hHujdjX+p9Djrg
GTxN2GcEz5D85wg+pVHHZC4YCuFEWUuR3yQ1WES9SMBo32TStZYymEoaaFp8RZ54hDxbDLPJA6F0
7fL7acx66AuzyAv75fjBxDEINsIculrALMd/Bh7KFj/Df2hFd1Ge8MBROf4G6l8E94AVLqRR9TT6
Z9oHe0m/xZBOUupJwkriFrtvA2TQ6tSSL3ZhP7n7juMVdFVhFTdjf9aK+9DD/sKylL9iG34Ob8Lf
cCDaoZ1NZhFYgCPYRMoNOylThuNwNhYHY19ox0pkuBoriNdNvtqAGZiP+Wwc1kAJ/hMLMRteoyzW
Tn3a9aa87qZ9Q5LxLXyA5PbBQil3OA4irwuJnfLYeLib+hi8ybLxOorcwSjOimNyBfZ2RtrvhJ5R
6L9KXk/5r5LPY/TnHhe7mM1l17D6zmzye6H7Tvol+D0WaDw9oHP/nLkTCcR+CYDUQYw5y2oNmI2l
ySuDmWR0MIqWtRQtAjzgIRkdOIfirRhqaLajRPNSnL0n9RLnsAaDtJPb8LZ2Mhs/AMVAdQOcojgN
ply0AlfiDXgT3os+Ok/9rIS9xF5hH3PknIdwK1/BW/h1/F7+hhKuzFYWKouUm5VblLuU+5VtytPK
h8o/g7YHPR/0VdB38VfFn1Aj1L5qvJqgJqoj1TFqujpJnaLmqCvVB9SH1EcsQZY+ln6WBEuiZYSl
yHKp5a+WDQksITghIiEqoW/CwARzwrCEpITpCfYEp5VZI60WG9iYLdwWaYu2xdgG2Qbbkm1jbZNs
1bZVtitt19ius91su9f2iG2rbYdtp+0F22u2dtuHtn8kTkrMSMxKLE10JFYkLvky6HjI8ZEn2Un1
5PiTk05OOZl5MufkbP8p2tdUDsF6af163Ex762ey/kWy/gNKzwHrryTrr+f3K6j0UuYolyqtyjrl
duU+5TGlTflA+TLIF/R00JtBx+NXxa9Xw9U+an9VldaPVid2Wn8/Wb+xh/WFlkssrZ3W9ybrByTE
69aXJpRL69VzWF/QaX2rbb1tY6f1r5L1H5D16Z3WOxMXf0lHyPGIk0jWDz+ZRtZnnMw+mSesp2wF
bJA/mvJGNj5OdUUhQEcE+STGf5pOrZ9Oradnl4idjqSO4R3DOoZSdcL92HG649uObzr2d+w9dfjU
oVNvn9r32R8APj2klX9Hrjry108uOXLlkROfbDjSdOQporQStBxZ/knD4cWHm4/s+GTrkesPbzi8
7tC6Q/cdWgNw6G9i3OH+hy47tIieRh7KODTm0OCDeQdzD046OPHg+INjDo48OOxgwsHYg9EH8cDX
B44e+PLA3w98KkYdePHArgPPHqBZDuw98OCBzQdyD2QdyDww+EDCAcuB+IF7BE/Qs4YNhnsMdxvu
MtxpuMNwO/tW7oife1StwDZq0OP5cfZRZ1k7FM7xw/sRvMhf5R+c1fO6Bucc+aQA3qY/PX5uzrNG
Ukx24i3n4Gnk1/xyB53JV8JV7GtYB/+gOu56OovvgofhAao+Wsg1V1BNeZwqw7VUV15D+ekgfEMZ
fiN8S7nmO7iPzseX4UV4FMrAQZVEObwKTngJXoE36Bx5HfZRZVABb9F58ibVOpXwNZ3/78DblJWq
qII+SqfuYnDBEjohq+mkW0+1wWV0BropezVQ/mqkU/pLqhuXQjPVEsspPz0F99L5uIKy1Z+o/vkX
bMd1eAudPxwVDIKTcIrqjdvwdryDauAODKbKzwh+vBPvwrvxHtrX91I2DaWaNBzvw/vhB/iRzrMH
8W/4EG6gOnUjbsJH8FF659hM+W8LbsVtVNe8iy24Bh/HJ/BJfIpOWhP2onePHRiBkdgbo+i0/IRO
x2iqq3fSadiPTr1nqNLehbvxOdxDbzMxsBl8lMMH4vP4AsbSmRmH8bgXX4QTFHefUr43o4oWTMCX
8GV8BV/F1/B1yj9voJVOTxu95bTjm3Tyvo378R3YgUPobWgYDofP4e/4rnxT+RA+ggP0FvQ+fEzV
4nF6fziI/8Fv8Tv8AX/En+it6mdMwpN4iiqjDkymvE7lJFXxnCksiN5/DMzIQlgoprAwFs5MrBdV
9ZGsN4tifVg0nfd9WT9MxZGsP4thA9hAFssGUY0cz8z0HnAds7AEqtZGMyuOYYPpnEqkN4KhbBgb
zpLoJL6W38Jv5cP4cJ7Ek3kKH8FT+Ug+io/mY/hYPo6P5xN4Gp/I0/kFfBKfzKfwqTyDZ/Isns1z
eC7P49P4dD6DX8jz+UV8Jp/FZ/MCPofP5YW8iM/jF/P5vJiX8AX8Er6Q/4FfyhfxUm7nZdzBy7mT
V/BKXsVdfDFfwqt5Da/ldbyeX8bd3MO9vIH2RRO/nDfzpfgZfs6X8T/y5ZTnV/JVVFluZS04Fp6A
J+F5/DtVtY9Tzbya6ser4Xv8gu3hCp3Zt8lT+0G4CafCDZiJjXgjnSA3YxO04R/ZWqr+drPr8Rh+
zX5kP3EDO8FD2Ul2moexUzyc+bmJ9+IRPJL35lGsgw/kfXg078v78f58EFe5hSfQuTOYx/F4bqZT
yMYT+RCRfTAY9JdwujNq2Bn7Wrx3K0HBBmNIaFi4qVdEZO+oPtF9+/WPGTAwdlBcvFm1JFgH2xKH
DB02PCk5ZUTqyFGjx4wdN35C2sT0CyZNnjI1IzMrOyc3b9r0GRfmXzRz1uyCOXMLi+ZdPL+4ZMEl
C/9w6aJSO5Q5yp0VlVWuxUuqa2rr6i9ze7wNjU2XNy9d9sflK1au+tPqK6686s9XX3Nty5rr1l5/
Q+uNN938l7+uu+XW226/48677r5n/b333f/Ag397aMPDGzfxRx59bLNvy9Ztjz/x5FNt23c8vfOZ
Z3ftfm7P8y/sffGll1959bXX973R/ia89fb+d9597/0PPvzowMGPDx0+X7ucr13O1y7na5fztcv5
2uV87fL/T+2ScVHx/IvnFRXOnVMwe9b0aVOnTJ50QfrEtAnjxo4ZPWpk6oiU5KThw4YOSbQNtiZY
VHN83KDYgQNi+vfrG90nqndkRC9TeFhoiNEQHKRwhpCca80rVX2JpT4l0Tp9eop4ttqJYO9GKPWp
RMrryeNTSyWb2pMzgzgrzuDM0DgzOjkxUp0Ek1KS1Vyr6tuXY1XbcMGcYsLX5lhLVN8xic+UuJIo
H0z0YLHQCDU3pipH9WGpmuvLa6xqyS3NIXlbwkKzrdnO0JRk2BIaRmgYYb7+1vot2H8KSoT1z03f
wsBoIq18A605ub4B1hyhgo/bcu3lvoI5xbk5sRZLSUqyD7Md1jIfWLN8EUmSBbLlNL7gbJ9BTqO6
hDmwRt2SvLvlurZIKCtNCi+3ltsXFvu4vUTM0TuJ5s3x9V/6eUzXIwmPyi6+untvLG/JjXGp4rGl
5WrVt35Ocfdei2hLSkgGjWW2vNKWPJr6OuHFmFRSRKgvTNGMclpzBaV0seoLsWZZq1oWl9KCDGzx
wdxmy9aBAzO2+4/AwFy1pajYavFNjbWW2HMGbYmGlrnN2wZkqAN69qQkb4nsrXlzS68IHQk3dUec
nX0Sk+wCy5/b6U4UGllnUBj4VIdKmhRbyZA00TjToMWRRmz0U4I0yldOy+DyhWSXtkSmC7oY7wuy
URnU8j0l01LrsX/1pNh1SrAt8nsQqAiOzgCj/gDuS0ryDR8u4sKQTQtJOk6Rz+NSkhvb2F3W+kiV
buQ+KCimYSXpqeRzi0Ws6pq2DCijB9+qOcXaswplsVshIzWpxMdKRc/uQE/feaJnVaCnc3iplcL3
cVlz9PUZEzt/IyL79cmtSvdhv1/pdmr9+YXW/DkLitXcllLdt/lFPZ60/rTOPh3z9cku5rFMx1gs
l70UiQs7mcVDcbhPsdFvsIzk8jaDkUJRUlDN80WWTtfaklCL5XcOavMfF6PkrWuYrqYvPann8wU9
nnuoF97CSWElkeUXLWhpCe2pumKz+ow2CjIKghgwRp6m8FAJh0kTJ6fGyIcgG0a+myo5g2z0O6/4
u1hLZImIO19k0juW/0pK8FlSpAyRn3xhUkKY6PX1svkiZGuy+UIkTr/9bb4BJD9ykvGUJvnIcbmx
fah5raC4NNZeIraM+BVz+IKlXzT54VJULzlFpPzVxBbRhvPNTqJf2l4lf9K2lEUb1u2HJPBEjJxx
QUqylTCQmJpopV+iiGhSS2n/2FrSYq2Wkja/v1Skw1IbpWBWalNFd0spoVZf4XDRm6jG0j4uTSyh
YVzwzkoSW9FnsOUJVclwcikhfQLeiBA6x6TOK34n1lJCbpuEkcdTp2+NCJ2XZCHxvqLhwp1kXKgc
FyFbo+24xjppkq8g6RyzREkk2ubrK93SW/5Gdc41KfKs2fCs6TSnnjldHh1sLS15VjWvpbTF3uZf
VWZVI60t26nsWNhSn1saSBlt/h1rYn1515FdpVWYngJboiIy43k57epUaqcSzCbgEEFtKUErwW4C
Bcy8grgiqZ1KcAMBh1W8YltIr9EZbbxia8Sy0dv5IrZia7k5YgdbDcgvzbAeKje3x7Vb2hPaB7en
ts9uX9j+rbG9X3t8u7l9aHtS+7T2Pe1tOD6jt7Hdum/8voL2Oe1z24vaXYaIzHF8Pk12MU07H1S6
p9I9CDIIm03YSoJ7CDZLaiqfR0rNo555pFQpL4J6AkbjimAkQQZBAUGgZxVBK8F6Ah8vyggPncqm
8tlsNleiUjMnk/JTCRYR3ECwiyAIStlKWEXAqG+lfNpNcIRAgVS2AlYSMIigVjzNJlikUzcTHCEw
yJ6pem+pTg1iq+laSdcKtuKp1Lh683iCNizZGl9v3o7F+GnG8HrznoJ684Wp9eZR1npzAnWYiQcB
EUKQCgbo35+SclRvY0ZmL1bI+tHrjolFiRZnyDZetgMzBjpMhx2mlxym5xymtQ5TkcNU6DDNdZiG
O0xteEnGwPmmL+eb5sw3zZhvmjrflDbfNG6+afR8U8p8U2ZvLMFiMMEe2V4o21GyTZCtGYu3miCk
DddunXazeScuhGlsE1HTxOMOHA9xCj5p/nba02aXpU2gC+MqzbPjCN1qTrLI21DtZhXEp8zzxoaM
DZnQ+jQLJs+14tMZ4w2t9xtaLzW0TjS0TjC0jjC0DjO0DjG0JhpabYZW1RBtjDJGGnsZw42hRqMx
2KgYmRGM0W3+IxlJ4vOy6OBIcQtWRKtIPJKJVny0RqcaQyODC8HXh+ez/MIszPftdkB+mer7odDa
hqGU7oOsWeiLyof8oqwY34Sk/DaDf64vLSnfF1JwSfEWxOtL6MnHrmlDKCpuQ78gXRUryqnttFZD
rlobK+5/umptSQn0a5waMzVqSu+JeTm/0JTqbVLXT0xS95/8guZdYGYDyDdm3CTbjRn9DGafwfyI
wTzLYJ5uME82mMcazCMN3UYV0qhWOapVjmqVo1p9htZHDK2zDK3TDa2TDa1jDa3dR8XE+dblFxb7
NsaV+EYLxB9Xku/7vFBdSHZNY4W5Odsp6uhWUryd5cG03LmSnpdTUpJPSyn52DyNr0jnC81g8wQf
mxea0Z0P4omesx0s4ib5IF7Kiz+DL44VCb7B4qbxxUm+OJ3PKPm2FFhyc7ZYLJKnL0CB5CnoC5KH
azyWbjyGI2CRPBbDkbN44n4Hz+Bf5Om2cs6spF/5yXWJyCso3mKErBIqXeS9X2T9FBlFptlTbo/d
Ae/yryCMqrdQKv/DrFkwdWpMUuQkTA0O9wUTyUAguC+wxKyI3aEAbpDc4UQ26V0pmSmZoov2gujq
Jd4j9K6YFRdYYnfgBr0rksi9aY6uaMh15Wi/Hm+Dx+shJXfKvGcWGdBTAh4kqsdLP5DkoQHyKbt4
B50jiwC9JaB8AaDcBLF0j+dlEA/gP6zDpx0rQPZ3nPb72fu0MefqoP3MpasIdhMUSWwzzof36b4E
1lPL6S33bZgEgwl/G26mHidMRsSFrAg+gxG00QdDBBoomw+ht+MI/7/hQXqHvgTewqEwUeD+DrCR
3EK4F16DJlyqHPW/A1sxgz+rWCAMpsB+FgoRkAy9IYXmisALmVm5n2akswUux+X0fv+A/2b/KQiG
ycZkeAr2YQjllf3KKxAJJbAMTTQiDtzwKLwKb8AxTKCsejVJNMM9cJh6rXg129VxhX8TqDCGktGt
sA3H8mNKaRD4XyFaMoyCelgGq+BKuB7ugL00Zrnf7D9Be3kgWTcXroXHYR+8h2MwDSdiM8tkl7HP
eBPfx7/wz4YBNJMNcqXvGuEK0uIrOAWnMQyjxOc2uJGNpK3cwhfwRxWLMkMpVCqUo0ERpz/reMZ/
nX+T/wBk0uiVcA2sg03QhkE4AC/AP+NpdhnPIi+FK1OVK8i/EfAHqIDL5Sd098Me0ugtmmUUXoJv
03WQfcAXKYoyRXnRP81f6f+IjjAzJJFPR8M4SIeLSL8qWAxL4RbYADvgIByWf0mXiBmYixfiAnSj
Bx9jyIJYHlvAbmdb2C5ltbJJeanjJ3+MP83/OclKJ12zSFIpuMRfUJBn7oRt8DS8TNp8SlERQ94v
wkX0KiY+Z3sIP+SFvJV/r8Dp1o4pHTd0/NPfLv8SksFISCNZs6EYFoCd/LYUlsMaeBAegzfJrk/I
hz9AB5rxUmzAW/F9PII/siS2iK6rWQt7nD3DXmJHeSO/hd/Fn+RfkOXmjvf95f5G/6MQTfGfSHpe
BGUUrS5oktKvgLVwI9xOK/yanOMQfAnfwHdyrRQMxhDSPhsLKHr+QLMuwkqsxavwOtyMz+Jz+A2e
YAoLZpEsmsVS5q1kLraY9HibHWAn+HB+AZ9Mlq7nL/K3+UeKTUlXspRSZalyq/KYcjAIgoKDRget
CO5nfP309o6ZHYs67iJtbf5miII4isEkisIR5JN0uJhiuoo8u5b03EQ76pD4vBG+gK/hW9LTgNGY
JD59w7G0btlYhStwFV6BV9N1Pd6Ad5LPH8UtuBP34j58Ez/Cg3SdJM3jWAKzskQ2lqWxKSyLTaNr
BpvPipmTXU510mry6jq67mb3svvZg+wJtpO9wd5iX9J1inMeTJeBG3lfbuOp+ud5mXwav5AX01XB
l/IV/AZ+E9/Of1QuVsoVp3Kzsp6iZ5vyWdC6oBeCvgqODL5M5pq5ML/7B9JU6YxhyRSPjWw43kTe
TsBUiAidCK9hMnwMRWwlrmG5+BV/HneSxsH4OesNWWwzPoaLcTJuUYKDokXlARB0CU9jY6joeAnb
IYtW8Ub+LjuMX1LE38JSYCinvA/TIBtjqIrdjjNp9a0UccAsRN+EuygK/wHTcSBs4jOpuGvnGTT/
E7gMPOxSuC8CQ4/CItyPV/ASishvYTVezgZjHPl8D9XoL2Ims+F6FsNSsADS8Hv2H6xhfyZ//glr
+Qv+OPYe7bCbuDloln81ZckI5ahy1JjML+I5rOA05Vuc27EMfvYz4t+F02hnTIbX+SEs4EtYFh4D
rrzEHzh16+nngibym9jneBtMVL44+fHJ53mCf8lpI2RDAsR3MJzpX8q9QR18LIxXHLS/l8Npym8v
k20/UIytpBxzGiIphkbDV7gZXsUq2hu9KbvYKLNSZUn7QsW3WTFFnpH2xkWUczLwIXYPhOI7mE/R
Fa5MoUz+xKnNVPGPxSU40n+vchNfz9Z0LIZHoIT0v4w9B193/IWtYe+fHOMP4aXwKJrJr8OwiJ2A
Vf4rYaX/zxSDP1IGuIHOp1shMyiaMu/1wVn8vqBxkBmc3Rkcw8/DeTgP5+E8nIfzcB7Ow3k4D+fh
PJyH/6eBiX/TD6ILuPh+r6W3pbeNGgQFTql896kM8edrqrIb5M8iZSlo3zYC6JCtwBH6YaSOMwjH
oRD4VlKV5BK4AoM7eYIgBit0PBiG4wodN8DfcIOOGyFR/l2jwENgUAjT8VAWHxKv42FQHTZJx8Oh
Iiww1hT8OJul471gYXivzj+nXhm+uPP7zWHh/9FxBsHhHTrOYWz4P3VcgahOniAIN8XpeDD0NQ3T
cQMUmqbouBH6mN7X8RDoFXlUx0MxIvKEjofB+CijjofDmKjAWBNfYLpRx3vBiKjLxLe4FE669Yp6
SscVSIy6R+JBkv6xjgv6XokHC//34TpOPo86KnGDpA/RcaL3iZC4UdILdVzQL5B4iL6+Gq6tr4Zr
66vh2vpquLa+Gq6tr4Zr66vh2vpquLa+Gq6tr4Zr66vh2vpquLa+Gq6tr4Zr6yvw0G6+Cu3mqzCi
R+u2hxE9Wbc9XHxjvU+TjiswtM8iifciurHPPTqugNrnaolHCvl9duk4ye/zkMT7SPrfdVzQ90k8
upvPo7v5vK/gjw7TccH/rcT7SfooHSd69ACJDxByoufrOMmJnirxWMm/TMcFv0Picd3mjes2r1nK
uVfHhZxrJT5Yytmr40LOoxIfLulHdVzQ90s8Rcjp21vHhZwTAjd287+xm/+N3ewydrMrvBt/eDf+
8G7rEh5YlyJohnpwQgXYwUF3FR4mKKL4E/hMqINaAq/OpUI2PbkJF634JrRLcqhEqabxIwjL0b9x
/n8nKbVTMxUKqada/n2wxuMh2gy6a/ONgol0jYQUHRstqZk0opruc2lMJenglaPmkjwPgRsaqS0/
S6t0qVUD9bsklwqz6N4k5xM2VRPdQVyNstfTqbOYM41aFYaSTMHjph4PQQWNGwYXn4O/52zaXAVk
b0qP+WaSL3pwWhKkZ4Xfyum5hu5uWEI0Md//uc9VojrJWy75PVinfConqkvyOCRFaBV4FhrVEkXT
ykM2zYLZNLv4lvsMmitT4rOJqlKbR+1Fkp5LlEJqxSpNozXJpWumpBaBCUIlCBtccs28Z0VogK5Z
WS99Xa9r19zphbOt1yKqjiwU1tfT+Gb5/fla3UotRhpkhKhQJnubpZWBOYXNjd080yDHapES0Efz
XI3k1zQRe0FbSaeMXqekVUopYvWc0osiakv02arkv4g5pYSyTp9rc3p/xTOBiGuSESEoTmlXla5j
OT0JuoNo1dK+Cum9ml/0V51ul/CYs5uUJl3mL81XrkePiIkyuWc1rcv0lanVJf/SCg2RVvX0lBZX
Z0fF2TNrdOHrRrlzGqgto7vmbY+U5j3n3ML784hSLWf0dFv5rrXQ1qnnvhDe0Wb1SDkOolZIC37P
mqt6LNbKvVhLT13zir1dLj2t7VK7zGfubvksuZPb3S1uNfu8v+kpoV2NlB+Iq7oe8prk+i+Rq9k9
V1TocdHFWUe8WhZpkB4X8qs67dH06h7dIl+JaND8r+2qej0+AlF6Zgz9mkVd8TFD2n72ygkPC/mX
Ed0pZQescci7lttqz1gD9xn+7pIs7BNYtfSc0KFR5sCmbnng96x+QJ62J8VebdRXo2uPBeSdvY6a
tzQLvDIHeH9xHwdWzH6Gryv+K227vHz2DA7pYVX+a/uZGmn2iAhK75Qwj/J/JlFTQJyYaTAWJtAp
qVI7ip5S6DQfSzASRAU7D/J1zpHUO4p6xur4BBhDIEaNh3F08gsQ0sVqeUmzdKoiUslf4hpBdpy5
4x0y802X8St8KvTMl1nCK/OAm2oZpzy1Kzuzr70zywTkNMkY8eq5sSsXB7w+A7LIY2KvnllbNOnS
AplTZIIm3Y9ihTIlzaX7No9wrQaq7Jyr+wyiTnJKvR363nHIqHF2O59VKTWgu0uuW7WU5ILLdQvr
pTUOGXvl3exPljs34MNAJtdqgSYZu9o+6TpRPSRb5OAuLSqgq5oI7Lt6/ewT+dfTIxeJ2GuQMgIZ
4Jc8Xie9Ui/bLp+4peQ6WRNomdIrddHkdc9vXfp6pe+qZB4IeKacuBw0KrALujLhiP8yzlIlv/je
Wyq1XpnRhdRUWSss0uupQHTUSjtHdI75352rSUaKxuv8X5kl0Jd6RibplF3UXO+ssDuc6sNqUZVT
nVlXW+clkppd566vc9u9rrpatb7aMULNsXvtv8GUKoSphXXVDYLiUWfU0rhREyeOTKFm9Ag1s7pa
neuqrPJ61LlOj9Pd6CwPiErPrmtwu5xudZazSZ3htVe7HOmNTrdHSB49Im20OnSmy+Gu89RVeIdd
3I2uD6NRBYUp2riZRTpxo1rktpc7a+zuJWpdxa9qrrqdlS6P1+l2lquuWtXhdHvt4l7XUOslUZ4R
s2YXzcibkZ1ZNGP2LHV2nnrRjOzcWYW5aua0ubm5M3NnFZlCTaFFVS6P6g04VOA0Zb27rp7ENQsV
OqcnR9VVuu31Vc2qvZamJI80eJxqWbPaXNcgRjrqGqUyDbXl5BQhh5Sr8QghdpWMdNYSu73S7XTW
OGu9I9QSGlZlb3SqdWVCcxrp7aGMcFyT3e1UnS4S5lbLXW6nw1vdrFa462q69KqjueoqnZKliTi7
xpWTe9yusgYviSY162qd3Q0a4gkoRb7qdEXnYMLtaqO9usFeVk1qezxOb/fRI9R5tdVOj0caL60g
m/S18NbRUE+90+GqcDnOtlwlL9Z6XbWVcqy9vNwlltRerbplnCULslv6lubznqlUtavGJQyiSSRf
U517icerRUUF+UIS65ooRBrKql2eKjEPydLcXWNvVkl/Wqr6ZuG4Lg/1nEj6Y0ZFl3H22mb1sgan
R07jqKulaKvVLXDrektmT1VdQ3U5hWajizaFiIGzzRd8tJJOF+0lbcUEX6eNpBZN4LU7vF1rLAyz
61pX/LJYqXLnAIe9Vi1zBgTRPHZvumCYV5ippqhD08ZOGKZOGJWWMnLsyJEhIfPyiThy1KixY6md
MGaCOmH8uInjJppCq7ze+vTU1KamphE1gYV31NVMryNNy9V8p9db7XTnOD2uShG+dhEygqfJTUvk
VmUUC9VnZM1MVgPZoonYRHC67bRIFJaZ5W4XaZvnpgxUKUZpA9RCZzWFu5siiNKO2M+qmimkuxwU
KhWuy2nCepfXUaWWy/mTVamhCHLKAk1OsSZyo3qq7WVSRIVME2Lt6mn3qfM8WhQ5axqq7SIAuhSv
a/DWN3ilJm4n5RwRlF57GfFp8Sblep2OqlqpTHmdo0EsgQzCEefwWWqVt6Y6tcYr/jPM1BrPIofm
jlpn0wjR8ztHNTmrier87SHiKVUPEsl9zo9jsiXVIwtm+zm5lkjqUjj2O7g0Wefiye/GUyeLj4Zz
8fL1/Gn+CN/Gt/Mtv+PjJO2V5Fx8OTiHuLy/4oe6bnr9trfEhwW/ZWOzLEx/TfNP9EP+nDMqA5Vs
JUPJVNKUMz/kOnO+31gdHNnpqSXnlFQAdWiXL2G1v+KFWlmguuAriZ2LK5fmWypLQjv8D9zGQVZl
bmRzdHJlYW0KZW5kb2JqCjQ0IDAgb2JqCjw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGgg
MjI1ID4+CnN0cmVhbQp4nF2QwW7DIBBE73zFHtNDBE6uliUr7cGHtFWdfgCGtYsUL2iND/77ArFS
qQeQhpm3GlZeuteOXAT5yd70GGF0ZBkXv7JBGHByJKoTWGfirsptZh2ETHC/LRHnjkYv6hpAfiV3
ibzBobV+wBchP9giO5rg8H3pk+7XEO44I0VQomnA4pgmXXV41zOCLNixs8l3cTsm5i9x2wLCqejq
0cZ4i0vQBlnThKJWSlUN1OrcvjUCyf7zd2oYzY/mkj7ntGpVSe/vmcv/e5YyK3PqU5ZQiuQKjvC5
p+BDpvL5BS7SbxplbmRzdHJlYW0KZW5kb2JqCjQ1IDAgb2JqCjw8IC9UeXBlIC9YUmVmIC9MZW5n
dGggMTY1IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9EZWNvZGVQYXJtcyA8PCAvQ29sdW1ucyA1IC9Q
cmVkaWN0b3IgMTIgPj4gL1cgWyAxIDMgMSBdIC9TaXplIDQ2IC9JRCBbPGRiYTIzMWI5MDFkZWU5
Mjk5MDgxNWE2ZWYwNjEzNTQ4PjxkYmEyMzFiOTAxZGVlOTI5OTA4MTVhNmVmMDYxMzU0OD5dID4+
CnN0cmVhbQp4nGNiAAEmRkZzPwYmBgbGfyBS9x6IlPkBIvViQSQzA4g03QJWwwUkGS1PgtjKj8Dq
H4DV/wSR0rwgkukgiPTvBqvnAKnXSQCzhUGkUzCY/RdEGi+Fq2HQmwJXw+jiDLbxE1jEEkzKgUiD
WWA2D4h0vAQiJTeC1EPcCTFTxRMsPh0sogEimzeB2bUglYVgvzAtB5FxVWD2DBCpKgFWo8kAAFFV
G5oKZW5kc3RyZWFtCmVuZG9iagogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKc3RhcnR4cmVmCjIxNgolJUVP
Rgo=
--001a11417eb09f2a5e0538048405--


From nobody Wed Jul 20 01:41:42 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53E8612D0B3 for ; Wed, 20 Jul 2016 01:41:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOEQmglnS7XO for ; Wed, 20 Jul 2016 01:41:38 -0700 (PDT)
Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B0CC12B037 for ; Wed, 20 Jul 2016 01:41:38 -0700 (PDT)
Received: by mail-wm0-x22a.google.com with SMTP id i5so57426623wmg.0 for ; Wed, 20 Jul 2016 01:41:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to;  bh=SNloWeiANU6z7eno4aWlSJImwWJiKhq7GX3d18IDLrQ=; b=ovfjC38Lth3APRWGRrjkfmthTLQCOWYlPWhdrxXIkVZ7a0jny/weBi8Y4o5gDo4ZZA cOjIjdjUtE7fG6qXI4pug4IdlFLedPIBXvBci7h8Ppf5kQsyG5q2huniuLc0SClDqpg0 KPJvJf16r4yzn0Xxk9CMPNspKckUKPMrBqcA8uTDI/KjZyvyu/2dYifeQua8RfpO3Sym AjLiGCLDhn/RbH5U7ad+fLpVrvf8DimAkluZ6xup4ckMp5WHFQOOudA6L4sFw/NsDyZw wUwts/puxXD5Ryx95fnOSBPkf8tBfO/AbcRwAayOrHooMz8gXKLILpJUEgq3OIRD3hjy jUsA==
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; bh=SNloWeiANU6z7eno4aWlSJImwWJiKhq7GX3d18IDLrQ=; b=jVrWCNYpn6p44CmSRGzprFZ0Fgq0SIbCXINIrZKpS9qami1Gx+uVs0SvvFfllB8cM7 83cENUcreBWS1WwxMpv/QiMJ/9BBg3j8RmwSm+1+sCapyAHt40iXYoKtdvIoOn+kSv/c wasIMy1JFE7Hagf/9Ji60qTlCZZHdVt0nGhKwgjaIzPuk6SkUdwzL5IiQHhEE2e3az2+ pi20tz4YPRQ+BLFgegqrNvF1d7EJITnDz/OE8IEEowI89XNfDOng5pxmdmza28iNlsi5 hS1RikJQhkEOyDramKQAbxo5cuX4gJWWuMAMTTcOIOMF1zOG9wpV6FC14poQxU+W/id1 hMXw==
X-Gm-Message-State: ALyK8tI2hVKfZrUoNefwDUpVqg6dqiX4v/hqMqw1lNnbMt3vMfAUnTo59Fd9nLTTVgWK93qBt1WB/2rzs6nyYQ==
X-Received: by 10.194.248.38 with SMTP id yj6mr65051wjc.163.1469004096542; Wed, 20 Jul 2016 01:41:36 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Nat Sakimura 
Date: Wed, 20 Jul 2016 08:41:25 +0000
Message-ID: 
To: Dirk Balfanz , OAuth WG 
Content-Type: multipart/alternative; boundary=001a1136250059307d05380d2ba2
Archived-At: 
Subject: Re: [OAUTH-WG] some thoughts on OAuth on Token Binding
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jul 2016 08:41:40 -0000

--001a1136250059307d05380d2ba2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Thanks Dirk. It is very helpful.

Nat

2016=E5=B9=B47=E6=9C=8820=E6=97=A5(=E6=B0=B4) 7:22 Dirk Balfanz :

> Hi there,
>
> I recently wrote down some thoughts on how Token Binding and OAuth could
> be done. If there is time tomorrow during the session, I'm happy to talk
> about some of the ideas; and I realize that I can't talk about anything
> without having it shared first with the group. So here it is (attached).
>
> My apologies for
>
> - not writing this down in an I-D friendly way - this is mostly
> stream-of-consciousness listing of the issues/proposals that occurred to =
me
> (view this more as a contribution to the discussion than a proposed I-D);
>
> - attaching it as a PDF, which is terrible for inline commenting :-(
>
> - framing my thoughts in a very Google-centric way (the AS in the example=
s
> is always Google, but I believe the conclusions are general).
>
> Dirk.
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
--=20

Nat Sakimura

Chairman of the Board, OpenID Foundation

--001a1136250059307d05380d2ba2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Thanks Dirk. It is very helpful.=C2=A0

=
Nat

2016=E5=B9=
=B47=E6=9C=8820=E6=97=A5(=E6=B0=B4) 7:22 Dirk Balfanz <balfanz@google.com>:
Hi there,=C2=A0

I recentl=
y wrote down some thoughts on how Token Binding and OAuth could be done. If=
 there is time tomorrow during the session, I'm happy to talk about som=
e of the ideas; and I realize that I can't talk about anything without =
having it shared first with the group. So here it is (attached).=C2=A0

My apologies for

- not writin=
g this down in an I-D friendly way - this is mostly stream-of-consciousness=
 listing of the issues/proposals that occurred to me (view this more as a c=
ontribution to the discussion than a proposed I-D);

- attaching it as a PDF, which is terrible for inline commenting :-(

- framing my thoughts in a very Google-centric way (th=
e AS in the examples is always Google, but I believe the conclusions are ge=
neral).=C2=A0

Dirk.


_______________________________________________

OAuth mailing list

OAuth@ietf.org

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


-- 
Nat Sakimura


Chairman of the Board, OpenID Foundation




--001a1136250059307d05380d2ba2--


From nobody Wed Jul 20 01:46:05 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6CCB12B037 for ; Wed, 20 Jul 2016 01:46:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.723
X-Spam-Level: 
X-Spam-Status: No, score=-0.723 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, 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
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 87OmeJAiyJfu for ; Wed, 20 Jul 2016 01:46:01 -0700 (PDT)
Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.29.28]) (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 EFC2712B004 for ; Wed, 20 Jul 2016 01:45:59 -0700 (PDT)
Received: from [80.67.16.130] (helo=webmail.df.eu) by smtprelay03.ispgateway.de with esmtpa (Exim 4.84) (envelope-from ) id 1bPn8f-0000a5-EP for oauth@ietf.org; Wed, 20 Jul 2016 10:45:57 +0200
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=_26b367778be52644a5405fb55c73545d"
Date: Wed, 20 Jul 2016 10:45:57 +0200
From: torsten@lodderstedt.net
To: OAuth WG 
Message-ID: 
X-Sender: torsten@lodderstedt.net
User-Agent: Roundcube Webmail
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: [OAUTH-WG] OAuth Security BCP (topics)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jul 2016 08:46:04 -0000

--=_26b367778be52644a5405fb55c73545d
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII;
 format=flowed

Hi all,

I tried to capture the ideas we discussed yesterday regarding a BCP on 
OAuth security in a slide deck. If you like, we can use the deck as a 
basis for our discussion in the session today.

best regards,
Torsten.
--=_26b367778be52644a5405fb55c73545d
Content-Transfer-Encoding: base64
Content-Type: application/pdf;
 name="Potential OAuth Security BCP Topics.pdf"
Content-Disposition: attachment;
 filename="Potential OAuth Security BCP Topics.pdf";
 size=222647

JVBERi0xLjUNCiW1tbW1DQoxIDAgb2JqDQo8PC9UeXBlL0NhdGFsb2cvUGFnZXMgMiAwIFIvTGFu
ZyhkZS1ERSkgL1N0cnVjdFRyZWVSb290IDIyIDAgUi9NYXJrSW5mbzw8L01hcmtlZCB0cnVlPj4+
Pg0KZW5kb2JqDQoyIDAgb2JqDQo8PC9UeXBlL1BhZ2VzL0NvdW50IDMvS2lkc1sgMyAwIFIgNyAw
IFIgMTkgMCBSXSA+Pg0KZW5kb2JqDQozIDAgb2JqDQo8PC9UeXBlL1BhZ2UvUGFyZW50IDIgMCBS
L1Jlc291cmNlczw8L0ZvbnQ8PC9GMSA1IDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQi9J
bWFnZUMvSW1hZ2VJXSA+Pi9NZWRpYUJveFsgMCAwIDcyMCA1NDBdIC9Db250ZW50cyA0IDAgUi9H
cm91cDw8L1R5cGUvR3JvdXAvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCPj4vVGFicy9TL1N0
cnVjdFBhcmVudHMgMD4+DQplbmRvYmoNCjQgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9M
ZW5ndGggNDA1Pj4NCnN0cmVhbQ0KeJx9kl1r4kAUhu8D+Q/ncqbo8cx3BkSoHy0tLevSwF6UvVh0
2kqt6Wq82H/fidpitLM3QzKc93kPTwK9KfT7vfvRzRhoMIDheAR/84yAkIiElOTASQKjCdYhz35d
wCrPBDx/zRBZQbo19HSRZz/zDCb3I4CjAnEoGJZ51rsSoDXGZPnUACMNBAgilA6UNOgdlG9Ny67q
Os8e2ZSLglU19yysuGP14s8S+G8ob/NsEpEN9hMkHaHSx6BH9oMLwS639UsiowqDxrYzKb7yBk/w
D2G2XS/qfzAcTXlXpqNkkGTcUKH4zJa88Kx6X8w2iZAWGr1th44LzlzLE9dKnrm2Al00FZUrtXeN
Rrmd793D9X4zT6xaN+Y3XChWN0dYwV01n4c1l/L4el53gHcLNg7besM1m72EtAWL+x28+pIQq8Iy
vHLlWPWWNtGO/VeD+kaDPfHgFXoQwmAhD8ibSckVu0r9W9qdBrqpUePQ6fast9FMB4bRnmLLRTxW
nfgV0HHDUMZXEnHAJohGWpSyTTwz8AF0cMa6DQplbmRzdHJlYW0NCmVuZG9iag0KNSAwIG9iag0K
PDwvVHlwZS9Gb250L1N1YnR5cGUvVHJ1ZVR5cGUvTmFtZS9GMS9CYXNlRm9udC9BQkNERUUrQ2Fs
aWJyaS9FbmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvRm9udERlc2NyaXB0b3IgNiAwIFIvRmlyc3RD
aGFyIDMyL0xhc3RDaGFyIDEyMS9XaWR0aHMgOTkgMCBSPj4NCmVuZG9iag0KNiAwIG9iag0KPDwv
VHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9BQkNERUUrQ2FsaWJyaS9GbGFncyAzMi9JdGFs
aWNBbmdsZSAwL0FzY2VudCA3NTAvRGVzY2VudCAtMjUwL0NhcEhlaWdodCA3NTAvQXZnV2lkdGgg
NTIxL01heFdpZHRoIDE3NDMvRm9udFdlaWdodCA0MDAvWEhlaWdodCAyNTAvU3RlbVYgNTIvRm9u
dEJCb3hbIC01MDMgLTI1MCAxMjQwIDc1MF0gL0ZvbnRGaWxlMiAxMDAgMCBSPj4NCmVuZG9iag0K
NyAwIG9iag0KPDwvVHlwZS9QYWdlL1BhcmVudCAyIDAgUi9SZXNvdXJjZXM8PC9Gb250PDwvRjEg
NSAwIFIvRjIgOSAwIFIvRjMgMTQgMCBSPj4vUHJvY1NldFsvUERGL1RleHQvSW1hZ2VCL0ltYWdl
Qy9JbWFnZUldID4+L01lZGlhQm94WyAwIDAgNzIwIDU0MF0gL0NvbnRlbnRzIDggMCBSL0dyb3Vw
PDwvVHlwZS9Hcm91cC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJzL1MvU3RydWN0
UGFyZW50cyAxPj4NCmVuZG9iag0KOCAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0
aCAyODI2Pj4NCnN0cmVhbQ0KeJydW21vG7kR/m7A/2E/7l7rNd/JLYIcEl987aFBXNtFCsSFochr
S40l+ST5cvn3nSElm9zVrGh/SLCJZzjD4bw8M6SL47PizZvjjyf/+KVgb98W7385KX4/PGAFqxlj
XAhmCytYoRUrlu3hweefivnhAS/unmgYM5yphOj2p8ODfx0eFB8+nhRFJIBvBLy/PDw4PuWFbOrG
qeLyFleE5QpeWFZzLQql4Ue8uJyhGC/r18ODL+VZJUS5WFecle28asr1dHRfVP8tLn87PPgAi+LC
25WEULUw8Upfyk8VV+W7x/WE4JHC1dalPNT6Utq6Q3rRjh+X0/WPotLl+5Oz4rJyTbl4mI5XxBpG
Abel5fUsKBILioK7xHpK1gKsamslwmpvGHP2bSocLd/hA6unfOXJsuK6bG+qI4mmlmBq2NTontgI
V7pWJl2CMhyHTWuV0t6DhHZUHYnyGx7x6A7/TR0s0zWnRfVsJrs20+nemxpcpZAWjv7JaO/5LqOl
jJxxdJaIsfzwZ8VtORqvqa1LWTeJLNpK4F48XR2OBKxyM0UzhW9akFPZgpxDQ8ak/z7/J8ogI4vr
7sZno8qUa3SZ8QRdZjqvjlR5Ry1gRa10lnbC6lrbhPSqpGgdJA+Z0E5wH4vvVAgzU5s8PSRratck
pOvKlosCspAXMprjvm/w874lV7G85jxZZXyPLFOIMV1Sp6mYqi3P0lMxV7PUXivQ0x/NyH9YMrCU
7PGSYhSvZWcjaI4lGmHrm/c/KO4GvDPP7qpxXUHBtygGzWWd0q+9R4bNEzyw8U6skcvjxnv7Hq0o
m2oDNjURAxZNTCTjL+XPVxXFBUlJu4TLcwzmOdXLczUTameuM2x/rusxb/PdM3N5XnED7sR5eVsJ
KBfLJRbYdkmlGg0rJAuQSUlrb7aIdNKObuiVwU2EyVpawDaMSEjXwWNHuJH1DELRka4ijPT5iBDU
OxSdV3yUqM3rqk/EWX6ehDRMVRSom6msgeoT7BnTjr5iHC0e8W9ShlU9PlKGtbXs7OB2Gco/HoKi
DwHKKNaPHClCQo5vUtp2PgY7LW4yKlUja9bhPiZpXe06Wk1nmN0ffFWYorixr97UxqRSPXFkLVFg
PpnS3oH5GJYi2nYSXE4mIuKMRApzkJA6XPszkslzfgDqr3T+iHNbdaAeL2be6u38hvQ8jXko5qad
1Hkg1Ze0eliglDn+RaZ/IVWteJ4oAYjPdtSaoZMqGgpbcE89vPzxqeyaT1jT1eoNk0buN7xwwiOm
WKBP/aHyz66DUVY7iu0OPaQytUhWK47AGSV6FiikP0BzmaGUhGJhZbJMcM6tZlQkAFLYY7xnWsgi
MqXNCDZEYybT0xQHn25S2vUPtKpPHySmVBCToiPDY7HQu1Fcti+NlADhkhoqShlXCGNo9Abub3ec
zBYtUxjO+g4xRzktWC8VeBTe4pTgdjofsoKGxht7nyxBRtQdg82f5FAdhobmyuUKaETdcbFZi0MO
j18XlLGMYtl7MEr2jDUcJMbwOndxo2ptUtrfLsjEuknhnKH37uiFqJkJBwSOECNmpEcNoFJK+tU3
a6uWrA3QRLrc5aHL5inpwvsbjT0lHnHM4IN7sULc9rFdrfwM5G6gSRNO1obn6Sec8YnxmbYbuGS3
K2rHU8b95d5mlXvRiCfNX1buY86M2OMC6mnKRMNdju1GQvv3y+qI2/LybOhAuTG1TPcUxgGhWQGc
QLkxDlG4o9XrWdflWRcB+OusG3GWl5WDCvKtkjhopaOLYZpOGH14BUx98/xJwWsODgqxnKxABxtA
0JSUnARxqDuss25Abb4ohC51RU2BEYiJJuUmQb/ykZLQjsZjiGQyJnndyLwtC6d7ivip0+ZgqOjl
DTYiEdszrCr/SkIcYTqKbWJ+P5iQ2mA/lp4NmVugojBOG6Dn+E2e44MOr3T8iLM8exquLsIg8yv6
75TsdzXDHjZZgp5pyB7trpEu6TnM1kzkyRKQuXVK+gfg1KkvL4VPbXpPahMmHGq8RjpK9JMASlss
IehOOdriHJbblDbD66TGzj5PgmywUYpofUioUAolswPOapNd5BRCznrXNL1pmr+qEbAF+ey0xFVN
f4zHOrzlfwA/XJxXsjyl8VaD1TBmevB3PHidZvxVAvgH/FlQaQWTNevIHTYDz4tc7qfwr4nciBNM
YMEEpwAd6SqvfL2KueJ0SiJOSFVNR9rQvECImDbKvX8Zqm080WzjZo9hukChcwQRxuRpJngIgZh2
dAd+A3WEHo0LSFqqyZQAUWJ4SvsyPIBJQ8o8aZL5m6GElgQEiGR5Z+GVz7p3oUGk2gGpQi3N0kgL
vM1NheRevkgHzJmGlgibOru5CSVEcC/plpxI4N2dTj0t40JCAZYWdoeDDieA3nX1zgSAw/vXJYCY
M3RSzyjvj4qLYd/mys/2kkXo4i0Qrie0GRnH+WuMhCsn4wgBvi3zNBPC4c1kQhsQ7mJGBqrD+V/e
8lgBbUp7346+oYCQPsj4dDjLzhIiOce4T2gHYln3NrxqaZTgXTZPDeWzREK7ufWAQwsORQ4ILd7s
Rqxxq00OyCTe03fYMgZkCqBg09kU1aEoLnEGt1szcu6joBswdodi5KhPNDhQTFSagZuIhp5BGtFj
IZcHNMo7Ow6DsZbycrw61pknryGfNJ2IWAyPDiFEodDnrQ4hqjvJY+2rz4wc62rDEG0lPI+Ddw3a
+cFYnkbgd0bs2i95aW8466VcchTIVU/54UqR90gHh3OvrBQRZzwKCNfWw2OhhHcIXCqR0j69EPkE
efJzpVn57gK+fI9ZXJWT7ZuZ9QPg7tXfAL4fH8PX9+/wA/hjy9rnnu+o6Wj1gMgp/M8SU9EdfIry
eOonYduRtyv/rJ+uHCdPX8cn/rJiQY4llAZszFP1j4ZHtzj7ElvaC2iRXdleg/rn/uXY7747bFc4
wL4+9cI3Wls0+JErf1xflSe4p1BDr6rrsyXewHertw+U4JzXJyHkR37VCxAWhm0tUq+vqp/J3XFE
PYnGw/7Ye0yx46EdPnrb3731O7eY75UP7ZIl9jy0S2inIGH+vxbNPt4KIzs+AaWDCVpY32z95w7U
GxQucro+6hFKzF2i5yGiEvRIjEs/p03Y6Ej2j28iWiyYEhWB+vd1Or+ZzumBpvZZQHTaPzM8e+N4
9dMTKTbjiSkFA/A6wXbYBov0ZoT0UusJxbGxS9jogaj1GEokndaeLgsvKqDLyjoe0TCPK2PazUD3
YTEnq6NUAVK/8GSwp0u3vjHxyj8S4gbaLedtONTYGZlnPOkcPs5IaOch9Y1JFAVApNF56ysoaIgF
Y9p2PhltJJBws+H4+iPrePDKt0v74B/1kjvQQuAlKbl8P830Hpbsys4MOl31iuwc8ZWfHtr50FNY
DkCHq5TnvBJyk9Ax2y6347WGRtscfFp0RNO5wk+xIlp0ZA5h7fsGcpDDGo9lIrY9uQIfUna29u6i
gJp7VbaAMQBC3Xk0UpzBLifT1QTTItiKnvyHISy5y/45590oOhvKxMtRYcwZXi+KgUOSAvVOeOga
ovEWOaHtPRP2D8Lm4cKXKieupybtF9DCpKQebRb0e2morzLleNF9hHE47kr4odO9yh1F4Uyuy09B
Tuz5dUfXaYuZ93bgdqCRmavjE4qO7RajRwRJ9K+KWIOAOW996MxYZ6fhrcNitd8JlIBAbPIk4ZwO
gO7eM8Wa772d7Acgy4hM82GjbRMF48sVxqi0z/0vQ8RsbDMuITmgj6ajweeP/wPjXnwcDQplbmRz
dHJlYW0NCmVuZG9iag0KOSAwIG9iag0KPDwvVHlwZS9Gb250L1N1YnR5cGUvVHlwZTAvQmFzZUZv
bnQvQXJpYWwvRW5jb2RpbmcvSWRlbnRpdHktSC9EZXNjZW5kYW50Rm9udHMgMTAgMCBSL1RvVW5p
Y29kZSAxMDEgMCBSPj4NCmVuZG9iag0KMTAgMCBvYmoNClsgMTEgMCBSXSANCmVuZG9iag0KMTEg
MCBvYmoNCjw8L0Jhc2VGb250L0FyaWFsL1N1YnR5cGUvQ0lERm9udFR5cGUyL1R5cGUvRm9udC9D
SURUb0dJRE1hcC9JZGVudGl0eS9EVyAxMDAwL0NJRFN5c3RlbUluZm8gMTIgMCBSL0ZvbnREZXNj
cmlwdG9yIDEzIDAgUi9XIDEwMyAwIFI+Pg0KZW5kb2JqDQoxMiAwIG9iag0KPDwvT3JkZXJpbmco
SWRlbnRpdHkpIC9SZWdpc3RyeShBZG9iZSkgL1N1cHBsZW1lbnQgMD4+DQplbmRvYmoNCjEzIDAg
b2JqDQo8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0FyaWFsL0ZsYWdzIDMyL0l0YWxp
Y0FuZ2xlIDAvQXNjZW50IDkwNS9EZXNjZW50IC0yMTAvQ2FwSGVpZ2h0IDcyOC9BdmdXaWR0aCA0
NDEvTWF4V2lkdGggMjY2NS9Gb250V2VpZ2h0IDQwMC9YSGVpZ2h0IDI1MC9MZWFkaW5nIDMzL1N0
ZW1WIDQ0L0ZvbnRCQm94WyAtNjY1IC0yMTAgMjAwMCA3MjhdIC9Gb250RmlsZTIgMTAyIDAgUj4+
DQplbmRvYmoNCjE0IDAgb2JqDQo8PC9UeXBlL0ZvbnQvU3VidHlwZS9UeXBlMC9CYXNlRm9udC9B
QkNERUUrQ2FsaWJyaS9FbmNvZGluZy9JZGVudGl0eS1IL0Rlc2NlbmRhbnRGb250cyAxNSAwIFIv
VG9Vbmljb2RlIDEwNCAwIFI+Pg0KZW5kb2JqDQoxNSAwIG9iag0KWyAxNiAwIFJdIA0KZW5kb2Jq
DQoxNiAwIG9iag0KPDwvQmFzZUZvbnQvQUJDREVFK0NhbGlicmkvU3VidHlwZS9DSURGb250VHlw
ZTIvVHlwZS9Gb250L0NJRFRvR0lETWFwL0lkZW50aXR5L0RXIDEwMDAvQ0lEU3lzdGVtSW5mbyAx
NyAwIFIvRm9udERlc2NyaXB0b3IgMTggMCBSL1cgMTA2IDAgUj4+DQplbmRvYmoNCjE3IDAgb2Jq
DQo8PC9PcmRlcmluZyhJZGVudGl0eSkgL1JlZ2lzdHJ5KEFkb2JlKSAvU3VwcGxlbWVudCAwPj4N
CmVuZG9iag0KMTggMCBvYmoNCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvQUJDREVF
K0NhbGlicmkvRmxhZ3MgMzIvSXRhbGljQW5nbGUgMC9Bc2NlbnQgNzUwL0Rlc2NlbnQgLTI1MC9D
YXBIZWlnaHQgNzUwL0F2Z1dpZHRoIDUyMS9NYXhXaWR0aCAxNzQzL0ZvbnRXZWlnaHQgNDAwL1hI
ZWlnaHQgMjUwL1N0ZW1WIDUyL0ZvbnRCQm94WyAtNTAzIC0yNTAgMTI0MCA3NTBdIC9Gb250Rmls
ZTIgMTA1IDAgUj4+DQplbmRvYmoNCjE5IDAgb2JqDQo8PC9UeXBlL1BhZ2UvUGFyZW50IDIgMCBS
L1Jlc291cmNlczw8L0ZvbnQ8PC9GMSA1IDAgUi9GMiA5IDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0
L0ltYWdlQi9JbWFnZUMvSW1hZ2VJXSA+Pi9NZWRpYUJveFsgMCAwIDcyMCA1NDBdIC9Db250ZW50
cyAyMCAwIFIvR3JvdXA8PC9UeXBlL0dyb3VwL1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQj4+
L1RhYnMvUy9TdHJ1Y3RQYXJlbnRzIDI+Pg0KZW5kb2JqDQoyMCAwIG9iag0KPDwvRmlsdGVyL0Zs
YXRlRGVjb2RlL0xlbmd0aCA4Mzg+Pg0Kc3RyZWFtDQp4nJ1W22rbQBB9F+gf9nE3xeu9XyCk5Fpa
CEkbhz4kpbi27Igmsmsr0M/vrNKkWtnrKH0wyDBnZuecuaHhJdrfH54ffzxB7OAAHZ0co195xhCj
jDEuBLPICoa0YmhV5NnXPVTlGUfzFxvGDGcqMprt5dnnPEOn58cItQLwvwGORnk2PONIKcqMQqNZ
8AjuEEdCSsoVUtpR7dHoIYRpYn3Isxt89riq78hA4mKFyDc0+pRnp+Ar+Ht2IK2hXrQd3OARcR4v
lmQgcDlZJ4DKGepUDGwH2chGRNkIxF2UiZJUIOkl1e7J2z5jzh7EwQMLHZxlHRw+L4nGv1MJc8ap
ihBoAMJIg0aTG3y9TMGE6MJYg0jGEYaazst28iO7/Og4T0+FUKCXovIfQ0d8G0MxMmRsXYTE5Tqo
ux7uyFbHwfDkvimIogJ26+/lNAUFjO9ES3JkHSQV264Ih3pdLxchWtW8skjAQ/Eb3y+UkJYyHds2
FT5eEcHw+KEgDtfEQqukOgVoFDodbUNQtSEoZUJtFVUbKvVrom6gn4VtofEytLrHh0ThK/glmYdZ
omMkEK9wMS2fBJjUKaQXVJgYmoziNbVxeviaSPzlYxhKiHCG36UF41TLGPu4TqojYA4x3e9ZwsAI
4LHteA76Q217nEpcQDKubwTvqLdt2zD8ZdAPRsaPspqW1TxVZyBNqOo2duekkcpS32HqFqeMNcwx
330ZE+EPxFjMUjgDbf2mVxkXLKNXlRWUZP1CdLmoUstFKMo74FuSNHbU8rQwG42p+01a6Xo05daG
bCFxU+onUOs27FWLFz+JZIGARMto2ayNtoudyZh+yQj2v8m0kPhiRQYKl/NmE1ThOz1geLMG2ui7
ACvG02QTc6cp74B2Jm973BShb418+03RxuGLS2KSuYKhhJMuApQw5h6WRaAIFgwsMah1KIQxuKnD
fZIsfRFo7zh7n7LlLFx/ke1OvlwfvowP7fR2vlo4fHxfQqZQ5RLXQyIVPrzaVSmwUCN4YG9aBMKa
ayMQNisnhPM+BELrMB77S905Iszaju34sb5rdHsJPQmL6vXAUnNqdOwspZw0LKyryLZLUCBaio2T
/4lsYanYBmwk/wNDhIQWDQplbmRzdHJlYW0NCmVuZG9iag0KMjEgMCBvYmoNCjw8L1RpdGxlKEZv
bGllIDEpL0F1dGhvcihUb3JzdGVuIExvZGRlcnN0ZWR0KS9DcmVhdGlvbkRhdGUoRDoyMDE2MDcy
MDEwNDMyMSswMicwMCcpIC9Nb2REYXRlKEQ6MjAxNjA3MjAxMDQzMjErMDInMDAnKSAvUHJvZHVj
ZXIo/v8ATQBpAGMAcgBvAHMAbwBmAHQArgAgAE8AZgBmAGkAYwBlACAAUABvAHcAZQByAFAAbwBp
AG4AdACuACAAMgAwADAANykvQ3JlYXRvcij+/wBNAGkAYwByAG8AcwBvAGYAdACuACAATwBmAGYA
aQBjAGUAIABQAG8AdwBlAHIAUABvAGkAbgB0AK4AIAAyADAAMAA3KT4+DQplbmRvYmoNCjI4IDAg
b2JqDQo8PC9UeXBlL09ialN0bS9OIDc2L0ZpcnN0IDU4Ny9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVu
Z3RoIDExNTQ+Pg0Kc3RyZWFtDQp4nJ1Y227cNhB9D5B/mD8Q7xcgCNA2CRK4MQzbQB+MPii2ai+y
XhkbGYj/vofL2fXGJsVWL6JE8vDMnBmNSClHgrQgK0lFkkKTViSdJa1JSUca/c6TSh14smQk5gcy
TpL2gGkyiqxPA+SwkLHkgidjyGPAePIxYjYFa8hEilKSCRSdS5RSKE1WoPWBrCYpwWBhgIwwyZJU
WABAqUUiQWsjWUfSSKyG+cZLQpe0Dv0BhsNQlxwIimCh9DDVAe8j+jE/gBTUWB79WD9i0AlSQqE/
oI1o4a5MhsN1JeAHxhUmgUJpiX4oo3HxipSBaN6hDY6ggbLw2Ru0yWngHJzQwHngNfqDwjh4QoQi
SXJoEVIAhIRCaGFPMFBdCQoBLSZDTa0AhiRaRUUhIhZJQ4UlhYOkaOF0BM4CFxFDC6NgknYJh9ZL
jGN9Dycj1g0KOKwboFPA/AhjcWuEDOQRPZGMwzOEhbMIMcRUkNwApDBuoSvywViI5OGqR3zevevO
UqIIOu8uuouHftNdPj0M3cW0fbyePq6H++7slvRu/ITE+/dv32RIZMhn+QpwckXybzrgnjF7msvh
5/Rt/FkCIhkxp4RGUmf0WQmn/j9EL7ZRpTnpZauYqtRez/XqZiia63ZLZBXZzqIHphEZ/yoy2v+X
yPgyzZzX4dnIX9FmL/Ofv483TzPReQETe9iXEsaoKp9p8ekiTM/z2Sqfa/GZJXy+yhdafHYJX6zx
WdHicwv4rKzyqRafX8Knq3zNfAlL+Kr5Ypv5Epfw1fPlEL9i3HfecxJzbnHIORIsENtd9KiZkVIs
eMVtNSVds6TIYiFz84SuWlOcbhIWi1iL0FQJbZOwWMVahNUYzmdJFpxlYOOK9L5pdrkYNsyuflx8
szjJYjV0cZbQV6vTvE5eVA1tVjVZLqPzyvhqWfPtDCrWUW/mCRdmkK/mjI5zuLx74OrHlYaznLON
Y8kKs/1LtzGmGsD2rk3bvF3LVulq9fL7l6S2a5Px1bYt7MWd3bZl4GuiGYfDUaa/gIfmh1GVcfNf
qmDrjM3yocs4N88Y6oyxxWiWMEZRZYzNb5ddxKjqjM2Pl1vEaOqqHhiL4cgvSJae9WAjy/Y3K5lf
kofR1RmbeRgWMc7koZpVLO/AckBYDzZy+YtfF7xd6nyuw7kqsfGFpY6Ql9thOB/HqTsf18PX/iH9
gkgkZ/122OxG08+IXdm74mM2F2z2Ji1/mHsKv06GJ9JM9Akrb8Zp6E7T5ePm5vlhL8HFcD11n4f+
Ztjm+4TZ33/ZrFeb4eKuT/amjt82WKGfVuOGn7fT6p8eN7unv8bt92/j+L37MF4/3sOmXc+Pu2GY
kpFT97W/3o5Hz3/c4Xr0/GHVr8fbo46s9PPczINpt9v+vvu0un3cDuzr6eP9jysoovJrJNNPm3Sj
0l+bnVBp4uEnQv5l8vKvRJqw/17lWOYDNZ9z+fjJp0I+rPEZio82fOLgXTrvnXlHy/tM3rfxbor3
KocdRDJhn0d5Qv4ycLnmGsqFjasNv7SHN+ntm38BXk5V/Q0KZW5kc3RyZWFtDQplbmRvYmoNCjk5
IDAgb2JqDQpbIDIyNiAwIDAgMCAwIDAgMCAwIDMwMyAzMDMgMCA0OTggMjUwIDMwNiAyNTIgMzg2
IDUwNyA1MDcgNTA3IDUwNyAwIDAgNTA3IDUwNyAwIDUwNyAyNjggMCAwIDAgMCA0NjMgMCA1Nzkg
NTQ0IDUzMyA2MTUgNDg4IDQ1OSAwIDYyMyAyNTIgMzE5IDAgNDIwIDg1NSAwIDY2MiA1MTcgMCA1
NDMgNDU5IDQ4NyA2NDIgMCA4OTAgNTE5IDAgMCAwIDAgMCAwIDQ5OCAwIDQ3OSA1MjUgNDIzIDUy
NSA0OTggMzA1IDQ3MSA1MjUgMjMwIDIzOSA0NTUgMjMwIDc5OSA1MjUgNTI3IDUyNSA1MjUgMzQ5
IDM5MSAzMzUgNTI1IDQ1MiA3MTUgNDMzIDQ1M10gDQplbmRvYmoNCjEwMCAwIG9iag0KPDwvRmls
dGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA5MTk0NS9MZW5ndGgxIDE5NDA5Mj4+DQpzdHJlYW0NCnic
7HsJfFTV+fZ75k5mJpmZZCaZyTZJZsJkISQQdsIiGbKxhABZBpKwJSRsCgIBZBEQtS4NUjfcN9S6
VFwmg0gQF7S416VWa6ut1Wpb24JLXVqRJP/n3HdOCGj99Pf1+7f9fTnJc5/nvGe55z33nHPfIQMJ
InLjYqRZZbVTJ7+8efAcMrzVSZS6rrykrO6pl99vJXr7OCq9X14yvfSjvOV7iN6YR2TePbmsvOJP
P/2MyPDGs0Tah5Nnzaxd3jr+PKLP3iFxo21ybbBE0/K+JMNlR4gq3pxZWzj8y9+88QGR+BXu2tSy
snn1PbuOP0GUZ8QAZrWctc4XuuHwq0SN24mi0pasXrryiy+qbESD64iiU5c2r11NaeTH/aejvWPp
ik1Lpj716TSihTcSlSxatri59cjbw99B/xgfjV4Gg/0+M/oSu5DPWrZy3ca/l6fi3oYiopznz1jc
duZ7p3VfRXRoFvq/ccWqluar6i/sJroN1TNmrGzeuDpzZNZf0R7zQb4zm1cuTrlnzdlEz8Ef+8TV
q9au6/HQhRhPgSxf3bZ49RkPGNB+9GrczkFybqM6a75Ys8K7MG7C55RiIZkO/nXLzyS/8Obe8786
1rUj+oj5IWSjyUCc0M5E3SQOx+z+6tix3dFH9J76JGOxtMTlUBNF0VS0M5CDCmkxkfMy/b6CNGO+
uAyllqjrokagywxm7RW60EAWMsRFGQwGo2YwvkOGngDd28P3Jaqq9fkoAHccPAbzzYYcH4lbZJm2
PypWeoreY0+MRryMEd0qn8v3S8ZGutdYRs3fWHaE7u2b1z44Of/PknbfN9czHj9hNxi/W1963Z1k
Pqn/+d/c1vTGP+8zajq1fNf7yWQccKIvY/0p83AfTf6mNtofKe6kew6ge77PPc0ZdNrXxpFLQ79P
H/3p/7+kvU7zvm8b40i6TltEjd+xbtNJ9/uK5n+XdoY1lP19x/W/mbTDNOq71JNzpbT4JV3wfe4h
/tLzeu/9bj+pn+u+qb6pla7re7+vjaXouz2z3vqRvuQzNDx/cr9aJlV/lz4M91Pm97nn/03COHd9
17raTTQgqvPrz1DbQHnaLTTgXzuy/tSf+lN/6k//bclwg4hRWtv37e9v0UOD9DZZdNAQRdf8K8eh
JZ36GTIyvrVU/q3tjvd8eVL9lXQBsPlfObav3XMU7fh/2f//ZsLn5DP+3WOQCeOYAtwPtAFL+9jP
AFoiuubfN8L//KQdp4p/9xj6U3/qT/2pP/Wn/tSf+lN/6k/9qT/1p/7Un/pTf+pP/ak/fa+kRZDG
fyURAeSgtAIyiiwYBpKPjCS/vmenAZRHI2gMjaNiqqBpVEWzKEj1tJA20W66z+fo6dH7tKPNQMqn
0TQWNSfRFJpOM6mG5qBmc29N0fM57jMbeASIPWlQHqKeFsNT7y2K/O1GjiQHGKljIpVQGUYgvws5
/UQjbZp2jfE0Lai1afXaCu2IdlT7UPtI+1ybAw+cFE/J8DKHCqgQHkxED5UYUSMtoFZaRutokzCI
OOEQqSJDDBSzRKOYL5aLFWKVWC/OElvFD8UOcYm4TFwv9olD4gnxtHiGTOKIfu9PvvY3JqF/N1Em
A317EidG32cGtmnnEH3dG73sb9qnuEq/VO0qopN8pIiXpPtJuqfU6ytJb0+a780Yxvf3/j89af/S
3vr3w/9xRQQmty5cMH/e3MaG+mBdbU31rJkzqqZXTps6ZXJFeVlpyaRA8cTTJowfN7ZozOhRhUMG
FwzMyc7yD/Amu5yOOLs1JtpiNkUZNYOggnJ/RZMvlNMUMub4p0wZLPP+Zhia+xiaQj6YKk6uE/I1
6dV8J9cMoOaSU2oGuGagt6Zw+CbQhMEFvnK/L/Rimd/XKRqr66F3lvkbfKGjuq7StTFHz9iRycxE
C1958rIyX0g0+cpDFWctay9vKkN/HdaYUn/p4pjBBdQRY4W0QoUG+ld3iIEThS4MA8vHdRjIYpe3
DWnZ5c2toVnV9eVlnszMBt1GpXpfIVNpyKz35Vsux0w7fB0Fh9ov6XTQoqZ8W6u/tXlefUhrRqN2
rby9/aKQMz+U5y8L5W1+PxkuLw4V+MvKQ/l+dFZZ03sDEYrKdvh97Z8TBu8/euRkS3PEYsp2fE5S
Shd7pwnlShPGhhHCv8xMOZYdnQFahExoe3U95320yBOmQGF+Q8jQJEsOqRJ3UJZsVyW9zZv8mfJR
lTdFfs9alhzavsg3uACzr/9m4xflvpCW07SoZZnk5sXt/rIynre6+lCgDCLQHPG1vGNoIeo3N8GJ
5XIaqutDhf7VIZe/hCvA4JPPYHltvd4k0izkKg1RU0ukVaiwvEyOy1fe3lTGA5R9+avrD9CInnc6
Rvo8e0dgVzbIcYQSS/FQcsrb61uXhLxNnlaszyW+ek9mKNCA6Wvw1y9ukE/J7wjlvYPbZep31FvB
t1Nqq8rSc3O2xVdv8GgN8mnB4KvAxV8yAQUOPC49K59oyQRfvfCQqoa7RGpIdVI/yGjZpVNkkSab
lk7xZDZkcvqWIXkiY4rKDln69OWAoXdMfJ9/OjSuLQeU5ytfXNZngCd1GhUZYKS3bx6nQc5F5MZo
YZGPc4oq0rKxc2EzoBvdJJ9isi9Es3z1/sX+Bj/WUGBWvfRNzrX+fCtr/ZXVjfX6046skrqTclxe
xLkQZaJYZQylWIMV+R71WPX8ZD3fm51ySvFUVexrt/gra9tl5/5Ih+TDDoLTppypzTuK4kdia1bg
dPNXNPt9Dl9Fe3Nnz/ZF7R2BQPvq8qZl42Qf/qmt7f7a+gkefaw19Vs9m+Wt4qlSVNaVDC7A2VPS
4RcXV3cExMW1jfUHHES+i+vqwwZhKG0qaejIQln9AR9RQLcapFUaZcYnM7KnGmQsen3PgQDRdr3U
qBv0fEunIN1mUTZBLZ0GtjmUzQCbkW0B3SYTHlLyMkwxjttyX6t8PFsalrU3NcjNRYl4lPgVIeGf
SCGDf2KHMJhsoRj/4pKQ1V8i7cXSXsx2k7SbsTBEosDkyDOpvcmPcwoLqp48gpeiJrv0dfb01NVn
vug52pCJpTYPaKwPRefj7I/KnoZ6kyWaYJ4c2t7SLMdBwXrZ1pw9taUBy1Z1iCpTQ9HoITrSA2pU
6G3kckSjFjwbPEC9/XZkQtsbQg358qb1yxv05ewI0RT/ODx27jMqR96osKE93j9c35vYCjHZF0mK
xtiotp4tHmRxswaeJLMNI2/xo6ilyYfZNlJLLZY6n6UxHrYsxpFozFmsI8YTKSTplpZttceEooeg
Q/xKbR0it2RUtrmhgQev5y6KVMC9HSErRpTTZyojDTA7KJoqx4LfizBUWfUJ2U11J9X4N+JkkYPW
ezKjOGTPntqMw5/bW2HxF6nGFnlGWCN9HGarWXpuw7xr2XWdPXf5N2X2SYML/PLlIBcmeQ5gYVND
+6mG0Nz8wQWWU6123dzebrF/cwOeL4u9l6XRV463BlE4WvN1Gn7wYHSymAZxvhLnKXGuEtuVOEeJ
bUpsVWKLEmcrsVmJTUpsVGKDEmcpsV6JdUqsVWKNEquVWKXEmUqsVGKFEmcocboSy5VYpsRSJZYo
sViJViValFikRLMSTUosVGKBEvOVmKfEXCUalWhQol6JOUrMViKoRJ0StUrUKFGtxCwlZioxQ4kq
JaYrUanENCWmKjFFiclKVChRrkSZEqVKlCgxSYmAEsVKTFTiNCUmKDFeiXFKjFWiSIkxSoxWYpQS
I5UYocRwJYYpMVSJQiWGKDFYiQIl8pUYpESeEgOVyFUiR4lsJbKU8CsxQIlMJXxKeJXIUCJdiTQl
PEqkKpGiRLISSUokKuFWwqVEghLxSjiVcCgRp0SsEnYlbEpYlYhRIloJixJmJUxKRClhVEJTwqCE
UIIiQvQo0a1ElxLHlfhKiWNKfKnEP5T4uxJfKPG5Ep8p8akSf1PiEyU+VuIjJT5U4qgSR5T4qxJ/
UeLPSnygxJ+U+KMSf1DifSXeU+L3SryrxDtK/E6Jt5X4rRK/UeItJd5U4tdK/EqJN5T4pRKvK/Ga
Er9Q4lUlfq7EK0q8rMRLSryoxM+UeEGJ55V4TolnlXhGiaeVeEqJw0r8VIknlXhCiUNKPK7EY0o8
qsQjShxU4mElDijRqcR+JR5SYp8SDyqxV4mwEh1KhJR4QIn7lbhPiXuV2KPEPUr8RIm7lbhLiTuV
uEOJHytxuxK3KXGrEruVuEWJm5W4SYkblbhBieuVuE6Ja5W4RomrlbhKiV1KXKnEFUpcrsRlSlyq
xI+U2KnEJUrsUKJdiR8qcbESFylxoRIXKKHCHqHCHqHCHqHCHqHCHqHCHqHCHqHCHqHCHqHCHqHC
HqHCHqHCHqHCHqHCHqHCHqHCHqHCHtGmhIp/hIp/hIp/hIp/hIp/hIp/hIp/hIp/hIp/hIp/hIp/
hIp/hIp/hIp/hIp/hIp/hIp/hIp/hIp/hIp/hIp/hIp/hIp/hIp/hIp/hIp/hIp/hIp/hIp/hIp/
hIp/hIp/hAp7hAp7hAp7hIp2hIp2hIp2hIp2hIp2hIp2hIp2hIp2hIp2ROleKRA1hzMmehEzhzPc
oPM4d244YxxoO+fOYdoWzrCBtnJuC9PZTJuZNoXTJ4E2htNLQRuYzmJaz2XrOLeWqY2Na8LpJaDV
TKuYzuQqK5lWMJ0RTisHnc60nGkZ01KmJeG0MtBizrUytTAtYmpmamJayLSA283n3DymuUyNTA1M
9UxzmGYzBZnqmGqZapiqmWYxzWSawVTFNJ2pkmla2DMVNJVpStgzDTSZqSLsqQSVhz3TQWVMpUwl
XDaJ2wWYirndRKbTmCZwzfFM47j5WKYipjFMo5lGcWcjmUZwL8OZhjEN5c4KmYZwu8FMBUz5TIOY
8pgGMuVy1zlM2dxnFpOfaQB3ncnk43ZepgymdKY0Jg9Tajh1BiiFKTmcOhOUxJTIRjeTi40JTPFM
Ti5zMMWxMZbJzmTjMitTDFM0l1mYzEymcMosUFQ4pRpkZNLYaOCcYCKdRA9Tt15FdHHuONNXTMe4
7EvO/YPp70xfMH0eTq4DfRZOrgV9yrm/MX3C9DGXfcS5D5mOMh3hsr8y/YWNf2b6gOlPTH/kKn/g
3Puce49zv2d6l+kdLvsd09ts/C3Tb5jeYnqTq/yac79ieiOcNAf0y3DSbNDrTK+x8RdMrzL9nOkV
rvIy00tsfJHpZ0wvMD3PVZ5jepaNzzA9zfQU02Gmn3LNJzn3BNMhpse57DGmR9n4CNNBpoeZDjB1
cs39nHuIaR/Tg0x7w4nFoHA4cS6ogynE9ADT/Uz3Md3LtIfpnnAizmvxE+7lbqa7uOxOpjuYfsx0
O9NtTLcy7Wa6hTu7mXu5ielGLruB6Xqm65iu5QbXcO5qpquYdnHZldzLFUyXc9llTJcy/YhpJ9Ml
XHMH59qZfsh0MdNFTBeG3c2gC8LuRaAfMJ0fdi8Bncd0btgdBG0Pu3EYi3PC7tGgbUxbufkWbnc2
0+awuxW0iZtvZNrAdBbTeqZ1TGu56zZuvoZpddjdAlrFnZ3JNVcyrWA6g+l0puXcbhnTUh7ZEm6+
mKmVa7YwLWJqZmpiWsi0gJ2ezyObxzSXnW7krhv4RvVMc3i4s/lGQe6ljqmWqYapOuwKgGaFXfIO
M8MuubxnhF3ng6rCrsGg6Vylkmla2IW4QEzl3BSmyWysCLu2gcrDrotAZWHXOaDSsGs7qCQcXwGa
xBRgKmaaGI7H+12cxrkJYWcDaDzTuLBTLo2xTEVh52TQmLCzHjQ67GwEjeKykUwjws4C0HCuOSzs
lI4NDTvl3ixkGsLNB/MdCpjyubNBTHnc2UCmXKYcpuywU85SFpOf+xzAfWZyZz7uxcuUwe3SmdKY
PEypTClhx3xQctixAJQUdiwEJTK5mVxMCUzx3MDJDRxsjGOKZbIz2bimlWvGsDGaycJkZjJxzSiu
aWSjxmRgEkwU6Ilb5JXojmvxdsW1eo9DfwUcA76E7R+w/R34Avgc+Az2T4G/oewT5D8GPgI+BI7C
fgT4K8r+gvyfgQ+APwF/jF3q/UPsMu/7wHvA74F3YXsH/DvgbeC3yP8G/BbwJvBr4Ff2M7xv2Id5
fwl+3b7C+5o9x/sL4FXon9vzva8ALwMvofxF2H5mX+l9Afp56Oegn7Wf7n3Gvtz7tH2Z9yn7Uu9h
tP0p+nsSeAII9BzC9XHgMeBR2xrvI7Y270HbWu/DtnXeA0AnsB/2h4B9KHsQZXthCwMdQAh4wLrJ
e791s/c+6xbvvdat3j3Wbd57gJ8AdwN3AXcCd1gHe38Mvh24DW1uBe+2nuG9Bfpm6JuAG6FvQF/X
o6/r0Ne1sF0DXA1cBewCrgSuQLvL0d9lMTO8l8bM9P4oZql3Z8wd3kti7vJeoGV7f6AVec8XRd7z
gtuD5+7ZHjwnuDW4bc/WoHWrsG71bK3cevbWPVvf2hqIN8VsCW4Onr1nc3BTcENw454NwYcNF9IS
wwWBCcGz9qwPGte71q9br322XuxZL8rWi6HrhYHWO9b71mu2dcG24No9bUFqm9W2vS3UZhwfanun
zUBtIqaz59DeNk9GBTiwpc3uqFgTXBVcvWdV8MwlK4OnY4DLi5YGl+1ZGlxS1BpcvKc12FK0KNhc
1BRcWDQ/uGDP/OC8osbg3D2NwYai+uAc1J9dVBcM7qkL1hZVB2v2VAdnFs0IzoC9qqgyOH1PZXBa
0ZTg1D1TgpOLKoLlcJ7SHGm+NM0hBzAjDSMhjygZ6gl43vF87DGSJ+Q55NHi41K9qYa8uBRROjNF
rEo5J+XSFC0u+eVkQyA5r6AiLunlpN8lfZRkTAgk5Q2poERHoi9Rc0vfEqvqKnQuLmMeNkr3tSrR
n1MR5xZxbq/bUO51C3K+4/zYqbkfd7zsMMTFibi4njhDIA7V42K9sQZ56YnVArHDxlTE2b12g7z0
2LXEgB0W2WOubVZdRZzVazUEi60zrYaAtbi0ImAdPLSCNOETgoQDpFnkKITbW4F9vTdRRAm8zzvq
avPzKzstVFMZssyaGxIXh7Jr5TVQ3RgyXRyiYOPc+g4hftTQIQyldSGX/Iutnr9g504qSa8MpdfW
h3anN1SGtkMEpOiBoPSORCppyF+wdv3a/Px1C3BZsHZdvv6LnFgvc/nSKH/XrkNe/qzX85T/rYmr
gRauRVqnjOu+vdV/ehL/7gH896cOkl8ymNRj+AG1Gs4HzgPOBbYD5wDbgK3AFuBsYDOwCdgIbADO
AtYD64C1wBpgNbAKOBNYCawAzgBOB5YDy4ClwBJgMdAKtACLgGagCVgILADmA/OAuUAj0ADUA3OA
2UAQqANqgRqgGpgFzARmAFXAdKASmAZMBaYAk4EKoBwoA0qBEmASEACKgYnAacAEYDwwDhgLFAFj
gNHAKGAkMAIYDgwDhgKFwBBgMFAA5AODgDxgIJAL5ADZQBbgBwYAmYAP8AIZQDqQBniAVCAFSAaS
gETADbiABCAecAIOIA6IBeyADbACMUA0YAHMgAmIAoyTenDVAAMgAKJWAZvoBrqA48BXwDHgS+Af
wN+BL4DPgc+AT4G/AZ8AHwMfAR8CR4EjwF+BvwB/Bj4A/gT8EfgD8D7wHvB74F3gHeB3wNvAb4Hf
AG8BbwK/Bn4FvAH8EngdeA34BfAq8HPgFeBl4CXgReBnwAvA88BzwLPAM8DTwFPAYeCnwJPAE8Ah
4HHgMeBR4BHgIPAwcADoBPYDDwH7gAeBvUAY6ABCwAPA/cB9wL3AHuAe4CfA3cBdwJ3AHcCPgduB
24Bbgd3ALcDNwE3AjcANwPXAdcC1wDXA1cBVwC7gSuAK4HLgMuBS4EfATuASYAfQDvwQuBi4CLgQ
uIBaJ20X2P8C+19g/wvsf4H9L7D/Bfa/wP4X2P8C+19g/wvsf4H9L7D/Bfa/wP4X2P8C+1+0ATgD
BM4AgTNA4AwQOAMEzgCBM0DgDBA4AwTOAIEzQOAMEDgDBM4AgTNA4AwQOAMEzgCBM0DgDBA4AwTO
AIEzQOAMEDgDBM4AgTNA4AwQOAMEzgCBM0DgDBDY/wL7X2D/C+x9gb0vsPcF9r7A3hfY+wJ7X2Dv
C+x9gb3/7z6H/8tTw797AP/lKXnhAiLzzUTdV570HfNZdDqtpe34uZB20pX0OL1Fi+h8qOtoN91J
P6EQPUHP0Rv/gu+z96buTVEryabtJxMlEPUc6znafSfQGRXbx3IlcglG3wlLj6Pnw1NsH3Zf2ePo
7jTFU4ze1m54FdZPRVfPMbxfke8ZLfOGi6Dj9BafmG/ufqD7rlPmoJoaaS7No/nURM3wX34ffTlm
5gxaQSvpTD13JsqW4roEOfktepwluj5RaxWtBtpoHa2ns/CzGnptJCfL1uj59bQBPxtpE22ms2kL
bY1cN+iWLSjZrOc3AtvoHDyZc+k8XSlmy/n0A7oAT+0iuph++K25H/aqdtpBl+A5/4gu/ad650m5
y/BzOV2B9bCLrqKr6VqsixvoxlOs1+j26+lmugVrRpZdBcstupKlj9DTtI/upwfoIX0uWzBrPCNq
Xpboc7gac7AFHp7fZ8Q8fxt6Z2sbfJe+tUc83Qj7eX1anBWZR1nzfNTkXvg5yF62njITl8EH1ic8
4txVuv8nrH1n5dusaj5u7DMzN+g5qU61/jN9Nd2EHXgrrnJWpboNmtUtuu5rv7m37m49fzv9mO7A
s7hLV4rZcif0XXQ39vY9tIfuxc8J3Vcx30/36U8uRB0Upr30IJ7kQ7SfOnX7t5V9k31vxB7utRyg
h+kgVshjdAgnzZP4UZZHYXs8Yj2s2zj/JP0UeVmLc0/TMzihnqcX6Gf0Mj2F3Ev69VnkXqFX6Rf0
hrBD/Zz+jGsXvRL1PsXSJKKohzHPN9IC/EThVFqrvYpTRCMzjaUqmkFzHyE7XveJNE7s2+cuK7MM
Nj+GV7mBfAgGLCREaSDOaLDvT00t9u8fZdqpOad2isEPFpt3Iswt7nq766XCrrePxo8tPCoKf/vu
2+86PnnJObZwxLuvvTtsqHBmOnW4Yg1ms8vkHzDEMCo3Z/SIEcMnGkaNzPEPiDXotpGjx0zURgzP
MGguZZlokHmhvXq8UZvZZTJs8xfPHhGVkRrnspuiDGnJ8YMnZDtq52ZPGJJu1swmLcpiHjimZEDl
ivIBb5qd6e7E9HiLJT490Z3uNHe9FRV77G9RsV+VGld8tUszjZ9XnKVdG2MxGE2mzozklEHjM6fO
jktwGK0JDmeixRzvtA0sm9d1oTtN9pHmdnNfXVWYFn/PMeO2KBcNoBy66QBl9XzwoM0hpvs7IyKn
s+fjB60QViViIAKpUmU75NWuX236NTBQZMviAquoyvLnZH9ms9qSB6T7Y+wi0Wgjm8NmeMD/uP9l
v+a3+W3x6TXxwaggFRcXx48dW1g4f74zaawT0jnCcXS4cwRmPH8+vwopPz87MdGkT3mulqnFav4B
OTmjxwie5ySzX8s0rrcIR7bXm50QbVzV9cfTtZgEf1p6dpywiLDRnpKb4RuUGms8W/xOPHlaoifW
qJlt0WJ893PR9mhjVKwn0Ri2xlo0zRJn3dl1tvx/YffK/86F1ZVB+VREzwZSvckOUeV1xMmLHZdk
Gy4++Cr/RhwYmOoOoNwdQLnbbS2QlQtk5QJZuUBWLpCVCx7GZ0LqObQPmnJGYKb3oib4471xEbbr
/MVem84f7LVKNjgC9t3WQ1aDNTX3s2HDzFn6v0pXj+wU1g5zHRUfLdbX7VhROP9dfdKGv5bPAub8
/LGsMamuWKM/c0DOKOfI0SMyMXtuuZ4zNDFyiMHvd8rFnHBCGoW3aGbLmqnd9yfl5SWJnHW7WoYn
5k8aNGpe+cDurtSixmnhw6U1o1NmZE8+o/qlY+PrS3PE2tOW1kwc5PbmGs/L9RbUba4aUje5KD5m
VM2ZBlE4fVRa93z/+Jldvx1XP8HbXZQ2poYENfd8bLRFZWAXL9qbRuPzI7OSH5kV8BE5K+AP5azk
R2Yl/zF8xo6lZFFImZQjCsIJtcaDYhCNoqFiSEf0bGzp145KiEJ23/HLw8OGZrtiTX22pckd2aZy
A7tdGQbpt1xWRpshyuIKLDx76rYXLq2qvfrn5xSd3ljhsURpRovVEjt85pqZs3e2jhnVctncqrXV
I+PMMSZtvyM5PtaVl+up+/EnN916/IF5bt8gT2xCarwrLSE6tzC3/MIntpz96DmTcgpzTM4M7EC5
yi7FKosnL20IpBdnigS5chLkyklwweeEeDickAxvEw7KlUOpPDepkblJjayY1MiKSY3MTepBfO6P
xtzYwrHVnk6R0xHFq0TNxWtqRcyXJ9pJS8LcZwFcOvuOj+/s/lB//Nl3f3BT9b6Rq+658IGOLfe0
jTVcf/dXd9Twg55z+wfXLd/3g2nHnRO3PyH/xyo807bAswI6qyM1N/JEcyOjzo2MOjcy6tzIqHM7
Dc5AdHSCL8GHwad2CkvAvj1HHMoRr+SInBxTivwDjb06F9Rh6l3189e0wa1C/RhxRFa//pwNX1vp
/kznKVLbYoyxW7qulB4alljslqgoXLpNImzB0WCMhp5hEBZ7jHFyvCfewt5a4j2ueI/T0n16tCMt
IT7VYe4eZnF6dL97jml18DuX5nWYEyJ+J0T8Toj4nRDxOyHidwL83mdPp4x0M1zbm5CQYuoUA/cO
qE6RB2TkjVR42Dm21zvxNWfU20a5q9XBMXM3Zs+Mwes6YHH5UpMHuCxwtUK3Hk5IgxdTzA6PO8Hj
jO76g9lujorCxXi/9DI94pFxFt4ShdT5YPEw4bdFnLJFnLJFnLJFnLJFnLLJh5mWlGWVK9oqV7RV
noXWGNSxyhVtladaEgXcOAoDCfLicOLTeQDllCT/mR0Fkh9CWdKgGhx5BYG4Qzbxik3YTn5/YAkc
LRY4516T0xOZpBNLYX527+T0nSfe527YlDTOsrgyk1N9LkvXXqgUOVcW14DklEyXxVClzx5UqsUm
J8lmMUzselJp45tKdR0zmJSOzJ+ox/y5adb+4qSZSQ8kaRSZQopMIUWmkCJTSJEppIexi2N6Du3H
TMQ4anR34Wbv1s3+mjOiXo072p2ZlNJ3tCdGKEdl7vlQvI9RDaT6A3ghfffhpGM4TlGVHuuviT4o
huODXTJO26jIaYtlmt/nXSNHZ1IBkB4pnRjp+2llq2rSxgwZYDVHGTScqZYU/xDvgKE+B7uQEC0q
qrY3DouOc9pszpT4REQ/cfFxziHVk7SbpT9G+BM5aSrhSSpNOUBu9sQd8cQd8cQd8cQd8cQtv2VP
0XE17k6RHzlKROGLauR9zo7eRSK3VCXOg+iuw0l5alGIV2QAUenyJETjZLhfTfBXt0Y70yLP3pSP
02AC3RtwNE1cPdFgHzo0qbAwZkhycmrndzzK5T7KyBpms8XInRQjd1KM3EkxcifFyJ0UIx8MoopA
inxKWaOrrclJ9sLkYUNM3oHV3qDaKMXxCLFGwFEVGyDOcvQq59jTCkeMkJFXn3XlFzLaQtwl/Ced
MHrgJUbIEEyfH1O+xeVNScpMsBi6R2hWd7rLneGyGronC+yalGRfgrnAs8w3NCs5WmyIEhdaU705
KSvjPAm2E8tz6Ve7zDFmzYgXKULb63rtdw7KsqUO9Byfo92ZMSjFGp2Q7pb/D7DnqPGDqEwsv1za
Ekh1yalxyalxydemS742XXJqXJ2GEYFoHw3Fp3CNMiJznhGZ84xIaJERCS0yInOecRChRQyliLxw
XK1frhG5wPu+Puefssp7w3z97dknljB+MO3Kt3dd8fqOsmm73t516Ws7y/flzr129eprF+blNF7T
tub6BQMNV990vGPhnDu/2H3dsQcWzr7j05+c+eiOGXWXHFzadmhHVd2lj8hIAe+VZ7CS0iiPNnZk
mSKOmCKOmCKLxxRZPKaIIya5eJKc6XJ60uX0pDtsdjE9Xcai6fKLj+TM7hQxe00mG9y07nVX2/q8
cjhIcJz81vGf+qox9gkYtGcCG+7beGV0QmaK3B+DUoV7UNXyldPz9o2fM7/glhtmLK3I0q5svvHM
Cd1Dep/wPQMHmJOK522aM/P0kbFdXw6c3ELssdEKj0dTGV0eyHAMcY6xYNRjpBdjdC/GSK/GyKc8
Bk95f56MwPOKnXIqoJyRqXFGpsYZmRpnZGqc8guRaUMciDIeWh0QgUDSaZiBfZnVSZHtoscWMqT+
WkQ9NnJE6B9Ihmhfm5LEpAwtElgnJSQmipE5uTk5KqSymlxZGamZLqtxg3vwxLrxa9VkIcRKGDYp
tXLtjFx/ybyxvpGDB7rWxVq6u8pmpRSPuPzuspYSL7YLDr5oh00MGzmn2N/1695JxAs7SrMXzV5V
OmnpzHGu2PwJM4Z1v5eVrl0wfXmS2dQ9PXP8LJxIk3uOai3YN1PpTwdoEj7oxeGj26TIFE2KTJ3O
Np31qZrUaSgI5A8PJLjE9OEBnP5Zw7OG2zzJsq1HHkUeh0Ne0MQjH4fnYcMweR7t9egvj0N7UyLs
Yn4oTr7obUMOilwaQzEiJ2B1+saIMQGrTUx3yr/Gx0g1xjnGmTgBEdG+SZ6ovNrETpEX2Yd4BEed
Mt7Lz5/vOOqQS/XEmz+eC07ZoMaTXkMje19Lp34AMGktpRtunT9p1ZzxSVa8Yv6HvS8Bj6u40q26
9/a+3Xt73/dNrVZrlyVZ6rYty1ptyca2bCx5QTYYDNhGMhhjdpgYm8EJMHk4fAMzyYMkkwGMF2RI
JvKLYw1JTEgCZgkQZyGAE5NAEiAB951T1belti1PMu+9733vfU86+L+l0u26VafOOXXOqbq02ljT
t6Vr1uC8SPXijddcsbimeePnL0kt751tVnIMq9SpdJm2wab6vlpX9ZIrr7lySQ2+6tK/hzApEHJE
/RC5q0KJsK+hr6ZhYXNVTeslWxb137IsbXL6zTrBYRYhLvCEvd7KudH6hbOra1qWbIE5MoGuvwKS
H0Lrn3HkgL0OgXDtIFmS/2bFJ0uCAIEmkXylSNxJr6zb1eBCfECZ890Ufyw16UxOOUlFc0YXvVeo
E/xA0a+Akuwks3dSF5n6kJ/+46QgrlMLHrO5kGYga+DXwVJvh/U5hR7KedekcYBobYBocYCIToCs
YgEiNeSNt5xQ6g+CpCGbPGCbPGCbPGCbPGCbPGDbswxPfCXiNZJjMTkNNKGNLeYXu6fkhjqJsgVP
TYnIIL7QK7Sc77Bw2+ffOjZ61VM3txXcaLO6fMloZ/dof4qyJgj+ylvbjtw6t3X74evZcJEdn324
8u4V6fKB25ez9lL/qwU8g1PAldno8gOx2bh6TPokN48IfRSmR00KiQyO8rQmikMOUkiGsCNACukq
nK7E6QhOh3HD4rLF4UodW+oQ2xuzWRgV/JAkikzRyZWcLZZisfr6kpW8pGSzKVWKOzjek/T5Ux4j
l/+A+QtrdCUDwXKPic1/XYmFWMAfMasYHMbYwmosUZ8naNGwOMlgL6s0h72+MI8VMaNAoijByP7o
s0yxzP2L3WXkWLVR9+kxrklnIq6cSffpca5ZC2WF0WUnHKoELfiIxh2VOW8yg5MVOObAMTuO23AC
4eTisE7wLhamkkgwZDxIf6bSRRhPZotKRjs5RMz+yqAQk6FAxKrj8qfybyr01ogvGDMpDHht/km9
igfljdm0SmzDFoXWHPL64wKnzz/VanOZFOC0ahj27FmNXsUqTC4bs4TJ2twmjlWBwnjwr9QGqDe6
bWe/S9azVWB5s+z3UA3KoadyAdNc/9zMXFansdfqQYxriS7UEjWo5YlZrR3DH+cgjIybENYjoi2o
SbbKTUTiDfJVV7hSM940xqhzFsH+XVTL1zLN47UY1eLa2oo5ZWPYnTO9GMKhEOc9XdHV8oa+l0OZ
Yvx8RqAh1NBg0b05lhoabJRj6WpY7IbAIyQMjcXq6pRT2ZOaOtnXkWs4qieqgiG11VTXN7BZ3uN2
+Y3Nn+9fcF1/unXkqxtvslUtbGxZ21mlV+s1nMo9d9mG2rWfuyT2lXvbhuf6V/TNubbFodeDP6Jf
mW2Ptm+Y07O5K9pe21fn9oa9at5pcnpdYa+5fOnNlxyzp7PJ9iVz24C7DwF3X1ZsQWWoBd11CBRd
G6yXLUS9bDHqZX6R3ym/6sfwJzm3NUWcxVSAZJgI/1PEPqV4mnhitDkNsmrr64KconIMKw7Hutzt
fE8jFPcreqlFARbaG4uuUmqKZ5M2JW690LgUlK3oKqoEm406Ty/XXLZ3MNXZ3h5Xi26rxSMqVeaA
wxkQ1Ynujo7Eut3LE09Ya5flAq25+fG2m+a1DjQ48Tujz93ZLsSakteAfeE4sC+KWepCeKQ++3Zy
VphfeMdTo/NvH24Ry+ZW5x9asnz2ZTtAv1YCxwLs86gO7drvoatzIQQ8JYd+7x4kwcQ0qZv3z03Z
SKcLqRxGlzNkjNjofMef0xo6/BCvMwfNXexvqsjapTF0VJWPYeV+TS+JFFNnKEymK49NJm3OS84p
C0uzsjQ1xwYYhco5u3sgs/Yf1tfN2fLQilR/W51Do2REgyk+e2nT9bcEc4OzG5dlU3oSUvyz4BQM
zqhXzO04MHrXt29s5l0hh9HsEOP+YCL4zBPL7xhIRVJhtdlL9HQN8OVhxdUohhrR7pw/24x17kai
nY1kpWoknk4jkY5GIiyNz2HyHUCZAtcyMrMyMrMyssZmZGZliEBpzcF2XWPczRnLyPFhRxeoOnfA
2KvoIYszFafseVk6Kk+TQVmpCoKrOSlVbCxWGng0sA+rBI+FJP4XPHTpZXuWJ6rXfX71ojtyKouf
yJTmsXk727IgQSBRc4Itufa4syhA1/cu671j/7qR5+5cMH8eoysmhc7OB9lZd1Ou7fb1IEvzqgi3
BoFbD4FVS6Fa9ESuLFOfrb+2njUTbTIHSMrLHCwnfmE54VYhGU7tG8jCnw+1pb6SYkia9xDRtlpO
Fj5OljH6u45eCwaOI/wLBssnbuX2csw4h1/kMMd5Mm/Euhyn1xg3Gxmj5rSHCthgaW6woJRvpgrC
RjPiVEGV4WCJWFnPFT7GGq+nDFWxD8WdZ5/2tW/uzw13ZvQqnZJlWJWuftmW3LWPb22aveXRy658
cE36MXb79S2rWkMMw8SD3Tcsq7C6rCqjUzSYTXqd02FuvXHsxpEjt81vu+5LA+bbH6joWd9A1rmo
9BfmbsUN4AkMP23jiQJSxXPLVstdtFZu2Zy5ZWFykxelKsuiY9KLOZFkzqLaM/ULXLEzlR2BHr6D
RjDVJGJNHav5oKBjNcem4lUqKtbCuJWlEQyY+aJ1p3zgmLs5hVqpsvqS7mhtwPg8rHoK0fS8GkwT
BPbqW3iemJpbwh1Xd4XnRvRqWAvNdqNCo9M4avqb1qkElzkS+Ow3ah2xSTo1aw1EzC5BNTj0d8uS
BpPe7Cb7LXX5+9ld7L+jVrQQrUYv5qxiegHRsgVqGPKCAG/GPQtqsuAlERZkZf2C66nD5E9Z1SIo
5gwmEfcscnOmSrZGpSLSw1N+jecMUEjXqNxuVU2aIzzO1RImD5BHDAR4+NhAWTSng2vUVKliZ3W9
rl/yrtW6Zhb73uyOssDc12Z1XfpaYJGccs7SFfPMyYLpT9WcIMy1Q9RB4g4BKvkTKfgvVQTCdeCx
zVZYCmJxJdgzm12OEosy1wDLa209xYJmQyCJa2OTyynZmonF40ZW/o3dZTbdFvZUD966sOEyt2if
U/+beZsXV9Re9diWqx9aV84HqwJVmeqoP1K76rae5AI/5gUhn18/WLkgY19/aVVHxr5kdf97gaRD
c+e27vWtbnYk7I8szyy8YUm51yZW+MIVjJYJtqxobt28tCqaW1EbbJ1V43T2lLesiUUH5/beeEla
ow7mP1h1eWBWZ2LFBn9Dx9mhpiyjdqaTCeuced7KViLfD4Ef9yiszNVo+8FsLS6bSnrLgl2SDZez
47As232FRDFNGdNsMTUbOvI3bSFH7CtzQvCufCbdFWl39lDzSYP2yRxkYTFuPDdRSlcT1TRp4IJz
aGUfVYuFNddR0VnZelMb/EoTWMWleMHezpU7eoLOojwzpt6htsjA0rO7izWl6293Z8uGXWuJpbxL
+gvuV2SQFQXRnmey4UXha8OsTfblzolmzPR66ryopxDlPMdsQR5kvVhaU2apFdh0WOsnu5HklaGD
Tr6T8ufkmZRsDeWVZfosspksu0QYQQpx6/kMMJc3N6XIv0kWsHcW87G4sqks2Qj/YMTSy/n78TCM
OIIq0d0HFlWT/WHqLMD1Q9LvaNGwk41jMoAoeXs6pUfyfSUJ6MK4JjPRYPtyWqcTVVeQMVbAGA8k
/J0WWEn3K6iWwkiFmpqiP1sYLYxVcU4ywHZuhHfOsPt9ueEFgbRDw2FWpVEpw/ZgxmcsGj3Cg7JU
c3OZaXjHJSm11iCIBrIPpLCkOzrZf7mQHQU9uAn0oBY9mNNn63GyClflRNwL7tGLdHBV8vJXRUav
p1e6/FU9x8RRCOllHlx8vwVUw2VLpxFhSUFFbCGdItHpaReK6gFhEs6AswXePV0Tqk8VpWBSDOJ4
GuWQw0NYKlQY22zsTWpzyOUOO0zK/J3nywe+RC06Qw5nyKoxmPLP4msMOpq2grBIgz/MGy5Uk89+
jLdpDRoWFlWN3sHnn81HBatsO3Ar8MyKcnTv5Fq6dzL95sSUjOBPDmr5djpiWQCm3yu5QLKdF3ZN
7oXiRfBx+tDpnFvkdfKObIxG53Eamm9ejNsv3NUrZNNKdv9OT9o3n89G8s6+6kIWn+bzaSqfmjkt
yPczfST/0dd64SZpodkLNlOfw5+AkeWx8unuLnC+lTnDnK7W9vSsznSPs2T+S9PYjXJOU2gsbtsQ
a0lfHfnPTObFbKhVDrBlYVG8WDClZrWlvK2i8br5RHvsQbPKVj6vonFk0rIqRY/d5uVVPfd1zlrR
Vsmn+7sXRJZv6/RP2dhw43k29sIa9k5wTFhWo1Nfv3SRKzMnUdVWZgbj21Ncg2AGq9EDOVNhBgnI
y9H5s3SRPVoSLPp0PF9cleiWZsluJv7kGXlhIstSTpvuKnNGOousJ17D1O4Yfw63/4blyfrXlqdJ
Jn6x968sT+cwChi0hqxOJBp8CzhE9lO+mvNkkzgh4qSAYwYc0+OYGsdUuIxmd6bZQzk17R4KcdZ9
GS3WlmzOBM7dnHmW0ZI88TMm1LsZpslJ3pk0dYUhcpTDaxIhyizLTG65DBZ//treC/tW03X/uvXa
/35NfeN137gOrg1PuFuvXNS5sS3ozl65qOPKtgB++5ojd3fPvfngVrh2wfWmztvXNdauvr236/a1
jbVDt5PcQv4B9mXgDckt3EpyC8F6rSwlWllKtEXro5VHr6VOjLWQVqAJBpotL2QYps0rdPKLLppX
mC6tMI2MXDyt8IWhRNucXKREWCxWt6hK9vT2p9fdQ9IKNTSt0B5vu3Fe64oGF35v2zfvWMCHasP5
1qIt5N4DmWFJ1mt7WWvS2nPnk6PzbxuebU7Oq8rvWzIwe/gmGj8Dtx6WuXV3zg3s8utSRGFSWn0x
xUKNXIrEzmWopiA2JWegTstnoIpno4pnoCB2tkY7dS0pP8dXkNjZ1TWLxM58L1nzp4+dz+FZnVDI
fBblxV538dhZQ9TMb1Eluzo644RF1Zd9fnWiff6CMnKMzuIRVBfEz/mDRU7hE8nGsKkYQwvR5uTV
Rdbl/1QIogsJGQiiqXViHqeZwcsObq7DMZMsVCZ56KaicJlkqTMR4RJLkuREypALZC6a06S6YiZr
oNNKrA4193TBT036wqUB4HSGhgqRknmcUWrUars3YnVW1jWFzzcz0TlNjV5DMOLVcyxm19l8gkaj
UVsqehrOPnWhobmjvi1uYtVarcZIT8n0S2eYF2DEneiFnD7Tne1e1H1L95PdipKNqI/kDSgqFHNI
esp83gYV3ZjCb+T8hd0oug9FREzejCIhMrE57mfxR3RzXEvcIn2Oukrwawzay+qf1DP6ijcbtL8R
+oQ1wmaBLWw6/ZTsOHXZ3i0o4+R2k7zZNEi2D0o2m6Z86f/qZhPzQs3Q7Qsrl8+vtGk5spmUyi6b
VdZW7Y7n+pb25+LJxTsWRzqaklYVC96RVqkJ1XdmynJJayK3eOmSXBwb52+C+bY7LRG/GfxPd8At
huujsdqEP5RqXTa7bm1nuV608nqTjRecvMrmtJnDlZ54XSIQKpt9CZmLoPQ75mruX1ETWnUwiYRw
WuZ5Wp6LtDwXaVkh07JUpokQ6u2G9Jlwh9dwxt5RRbxvVcFsnyBiVyNnr04cK6T2uOkTDOemIWzF
dAxztZoPJCvs7cM5780mkew47Sw6au+Q3LFoeqdhgT3isagVGgV3qTfEGzXKaPd1CxljIcNwUqUn
Gw56KNAcRF47uFqj1SiMDjLuB0iej/0m+ARfyPnBE9DFiQTFiQTFyUZznBqpOE9dLvznwwVN88tc
8ctcgesnVDdJ4QA9Diorq1+WUT+JVTTmdGdcp3B2gmOmmEr2Ef0s2qtJkZo22XfexlR9w1Ta72GV
6LXavYKy9x/o0q+yFGIUe6ajsnXHfJXFD5oraiY9guuXLpx9+a51TKionWf/uGj1vOjAUma0WEP4
EwKfaQfwpxz98ggKS7CaEUfXT/emon7sKxR82CaP0ypfLVPuL72Kk/vt0u9zDWSzHrwKAcd5nFDg
UAIqWkI4EsJBUswGcSSIA7Q2gCMBHDfhbUEcJEkujWDtCAZAa+G3d3MaEMUgyTCS38hMBEn7evhg
MNEZ1Lk6dQUDSLf8UuQU8SD1HFKF/+hOUYHvZHcsRc91Tx52KVkizPYGs3ygewdmWCZ/gjO4Ej5f
wmnk8i9wCqw2++3esFnD5Tn2U0ZrDrrtPkHFPsJptHrVZ18j54o5tVHLLteLGhZiQgZAc9al1zO/
1ujVLKPWEW7XQYxxJ3B7PnrrCFoA5qkFhjaLJL+Ss3ADuUYrcCyIYwEc8+OYD8e8OO7BCQ4nWdzU
jJubcHMazybfUGDFvbycPiDXnBbElQ9AC7xJribXnJ4sJKTaNKeT3keYmeUX8dfyt/AcnxNtHXxN
Z7SzaW85Lid/KydWkzfbOi4vv76cmQ+19h4NYfLLhJODx7LZE8DJAr8zBXuIqJc26a8VGK2c5DMb
V5XsRU7D8pKi4k5Okf+YNdgTPn+ZU89+i2GeZA2upM8fh9/yf1ZwEF3YPSFRzb7GMBOMRgSx94tq
5hUGn2Q05qDL4SXTorKYpiaFuVejOXvd1BSZLCqNDmYIItWzLo0GZsgAhpcc6nMUf2PUWjJfSdCO
bpivDLr7CKoCxggkv0/sRgWxGM0V2AHyeJjs5zmwXbYNtmKVDWuItJaRuJV8ZjbCs8K4Xod1ARJe
kFnR6aoqk51kj7NTmAwhGrOCiAvpa0QYS4S3IL+pqM1SPCLPTrPnaTZP7XnOU5vjfl/YquNefYXT
WUMeb1TAGuzIf6zG5njAG7ZouRMvclrB7/ZGRUaT/3O50axXQHSuwuvzX4ILq9CbjfgZ/LjRbOBY
pVaV348XKcnpLZ3FlB8i1gO8wJuAPxG0+Ahyw1jriOa7cdKNHTR4duCYsd7IxDXYRZbkJhd2ziKM
c2J/p1Nr7tR2c4tQtxy0kt3sVEFpifIG2cJQG8yxGEhO7eQutplmdWwWFVNzg7Kq2hUQGOVNGp7N
f1vNR3y+kEWjwJj9RCmEAp6IoMwf4gWF3mLEjZyoZVdZHUYFqzYZzlYwJ806BawTImKwVvoIv6EY
QlaURMZDiqi7l2+Hbr35QsnZLzY2mUI676WPb6nISxceUSVgtTXscYetaqPGmfD7kyBRjqTfn3Bq
8GjRb2Sf1Yt6hVIv6D9tDKbcOp07FQymnTqdM00ziB+xy6EntagDxXLGSMSvsRxQKCo1bU1klcH7
K9vJ4vsmeWuFZqgLPZx8XYX2UvZILti3PT+WYpdXr7y5VxWOW32iWok1oke0zVnV6Ark1s5tWp5L
alWwnCgtjf1ra6/aN1yZPwaj8QVgNDC6gA9Gx/5s4HNr6hUfmExEgTCsUGZVsm1VdePq+TGnz6EU
vDaH0+x3iS1X7Pms+fzRYlSWfwtfh04hN9I+rbN7EP/SicKxK5WqYDMazJNcvk5ptAu7FAaz0yzY
tZi7S+eIuJwRu+4+f21F2vmCSqumaozNt7oDvFLJB0ik8pz0Mb6XfZDGvO79yDLG7HhG6wtDxG7q
QNkT2RPEham+8IifcP4k30tmNJAgM5oI+As8OOd3NhAoJ+MrD4TS5Jo+mwgWKmDAsBS40sSmfBH6
cw2MWIfs+8lBn/HD5ECPhgXlh66kjpLhl2Qor8m0zq4g/65ekKmYD/9IGzj/DqtV/BtIq3o/r0AZ
kAG7zC45h6f6KmeweK3OoMgpmUHOYPZZwaXiFB8YTGpOZTAblDsMJg1wy2KA9ubjg0wF04JMyHgQ
qXRnOEQOBso7GsFCX8gxIaZCFPJDIvzgf1YbQM3+HPf5YzGfUnAhLP05fz+HJAcyINMhpNK+x5Ec
7YXN2DjEC5+1CKIosN/hhfzJcMAXDoUC0I+78o/jPyh2ozAK5awsMbEsce5ZehCQtfp1d6FsBuar
cORLCd6kaJ88BVLB0v2Vwvjx71YPrr5UgY1ep+gy69n6xbM8/sbFNVjDe2x2D88o1j2fX3HylfzK
7+sFnYJRqhUbfvTqm1u2vPHajy/nlEowdzzh9I3Qo3egR0FUcwSJBd9HlH1ncj1EeibS4246Gp0V
epiqnjyVpira6XqxrpaJyzbEbhPxO55Z/fWs3uwSXV4DVqwaGhriGN5jt3oENXP5KOPc8uarP9qg
UCsZhU7Qfw8//spJ/PjzGl4LvVNyJ/KLQLp3sxuYfYrRot1yxxbwC8BunSgVaLaYODmvxmZl7lDy
dlF0mJR2rSVodwQtGpz/u3PqKmPs3ZMB7w+LpXzVuXU8D325CnztbykC1HI9dAR1wXppNzG9a7pw
ajSLN2TxvCyuzeJIFmfHmHk5i97j0d9Yh6+sw911uKkOp+pwHfzh8GaEiTAQN6ZwTv3dZ6AZVKnH
ENL9BSI8plffJFVWKmJjGD1tXtE2hq37Fasn348C9g++BCvm4M+pPyKSQy60RN4SSJUEb9z5wZrq
vNxKMcP0rdpNj23pv2lVS5QXKxZd/9g10Z5cuVHFMVil0+hi9b01g3cvTbKuOb3LqjbuXRF7wl6/
cm60a37WFcwOZXNDrV785aWPbO9MdG265ytDS77+j7svn60xiTqDyWwUXbzaKBh7bv3aKpPPYWpc
v2tN0+q5EYPdL972xMZ0Zf96YsU6gLcT9CR0Cp3OOc9L20WLabs08d6ihOlpXJKQI1loC4l5LORI
sIW8qGZ5jgFzhAKFcC8gi3RAzssE5MAHru8S+wQ+Ovn/9ec0WnLIOodY+o6ghpx+0C7SMoh67vTI
OpkperaTFLRImy53k//FmmkJOYFcPGBN/Bt6fJO4NTA5pdnSFPUCLp7740pSOBw7kbn6qdtufHxD
qnLTU7fugOtTRndqdm/l0itbbL456ztmLW0BC83c8+BH+9cu/9rHjz7wMb1+Y+2+bUsbnH17vrnp
89+/tSkyb2jrXSByTyDEPqKwowr0di4S8eGIF0c8OOzGEReOOOWTaUnKe5H4cJV015mwuxIjwlqU
lOPnpMzQpBxJJmWGJmUnMUmObBt9DvIhh46gTpAFHq4vHYA2Bfm0Tkn9uHy0GVgPn3hUwIJZHMPZ
A+HFSX4MqwrvOFRnz56g2Qvyc4IcCCieAyWcRakpT31QfgWieBBUUCmVBQ+9ISpn9wXqJTyi1BpU
Z1ep9DqlUmNQY+NfyN4/q9RpcBmnFx0ihJ7K0+DzKNpIfkLFu8yiS9Cwrz6o5Qw+u+Dg9cpvsxyH
OZVO+el9GlgugNtbgdsPg0y3ogdyhmQ9Tvlw0kuintxY0XTksI1IsY0uALYA9a6Z9OGaKBBqlHnd
+CxzC9IVmKMjMY6O5OyFWY2BQCMIX8XhGpuyYgnfOIYTRQ4Vcj0ZulFGsmYnJl8rozyi0cw5zCEB
ynkOlbKm+Galih6hfVihMWnO1hmtJhWrNek/Xb6xUfTU9dXSY3DgTnOMQu1oXnFV89C9gxW2BXdf
e4KpUZt0ii5yPljF+2wWn91uwNpVX7hhXSrV2xQKJUJq0Wc12XijNRJ21K26cX7rjvue3HpSI9L8
2uVgE74A/BvAiiNoJbDMQ1i2ElepgSlVRPGrKN+qCN+qxpi6nHbhktjChQ6IrnMkuo7BLTES9OWg
NpZjjW41X8yn0U+6A/QISkFk3cD5QzSQoefGiH4bZdE0ytJuJBNnhmkwNpPtyWYSfvZkmjEVXVmE
c1pS2Sw0C7b6MazLaTuXlP8hEFB0kqPfusmj35kzjfzk6W8IKDM0d1LMx9FjGGRLS2zki3t/Rcuu
pJ7TZFaOCU8dZbzQK56aRKuPZb/QOvL1q+ZsGWgyqZWs0aCpW3Jt29zhtlBqyfbeHTBXKqXOqNky
d2Nn3FXbX9e0tqdaS+Ik8B7MTUuvza383KXpQOvK5nnX9qXx1hX3bWiwev1GI/hhEU8gGgi1Lq1u
GMiFQD2sZqdJFcqtaEh01vvDibDC5LaZ7ILRDPNcccnogpaN/Y06RlXXd5UkFddVRsl+D5F5vwyi
0icVRuRHrxxBAsyjVgjiHoHn5dcezn0d4l3ZZnyS08LUjdC0DD9W/BTPFxII9FO8/Cn6Zx3J/Izy
OMZjpZz0CdJT/SBjQVxylPBVepLJKlunklMK78ovZ506BJ+xKoQxnD7g6tdNHk+n5onOXErO0hST
NVN5GhrgBuVcIlWzJ1mFRpmvUJjsEVcoBqEfPn32frNZoTVqmA+NVp2SOyZ63U7jpy/owcFVgqvL
dSUiZtAxpeiBlXQxcPMx0JpKNBd9K2dOVuAyBU7SDEtZDMe0uI0IaYAMsw1UyVDUIu+NVbixqrNq
YxWbqsJV5GUJDTIaA2gzYgq+Cl35Th0kPksz0Rn4aDOx1SL5+Ggzrm9ub97QzEaacfMYk8oZM1Ec
zX0YCKjq/1i2xDGG1ftVy0qcGOq+0EOTg7IHU100T4VsCy4kW89JQzeUHhuUX9qZXC/r2ccslf07
vrY51T+n3ALM0al1iZbFNWt3D5QzdQ+s2XT/inj1lV/Z2r9zVS4uPBmauyY7Z1Wzxzlr5dzuPcyz
l3zjkd1XNOt4UfS7bC6jwiSaum9+bJW/snnDniXLvrStPdl79T3/1H7rk5sqM4uG65rXtUVpxNOO
NrGHORvKIMvTZREfeb1XrxRRpubE2RM1/9mLCee9mHdYqTWq82NqwWO1eAUoaQxaJaxMatypFrwW
4jZDyQDefM7sFsk7DDryDoNOjTepRbeZvNkLJQhbFIV3HYgVJT//VCCcuSi9zawroR8WiO2ehg5O
EXcJpUemIwUn0+ISkkpJef1F6PeEVF8qkPrqEnqpQJrVF6HfF0k7MEPnkk51UXpUXz4NfadAhuFp
6J3/vWR86UIyDVD60fTED1D6kJBQN0WiTXy8lMx1F6EfmH9gWW95q0DWr1xItsD/FD01Hdkvd2Qn
6YfO2hmaof/vaTul359LriDQRtfuv5EOlNDJ8+jjArlz7r3/RTr5f4I8d/6vk7fB+77v7/23U7on
kAT6xf9dFKyaoRmaoRmaoRmaoRmaoRmaoRmaoRmaoRmaoRmaoRmaof83iO4nY4Q0/w1h/EUlQmr2
HsQhUfoAsAnZAbul9wCHpTWAV0inAEekpxCH90k/AByXXgeckF5BHNsrfRNwKTIBDiA94FZoR0Cc
9FvAYelFwBHpXcDt0ktIwAlSD+0QHKd4nNwPrUGZXSr9ConQBz1gt/Q+4DDSIhHqP0YOaPMXgE3S
acBh6KEDWv4QcLv0c+SAe54HHIAneuDO04AiPNcD7ZwCHIL2PZiR3gLk4Ske7ILWPNgn/RQwIY0D
7qTl3bR+H/ks9BBaw0fppyZIGUb3NopB+/cCitDDGPTnfsBuWh6Sfgm4HZ4eg2c9D0ieFYNn/RbQ
By3H4CmkZjet2Su9iWLQ81rAASkLuEn6Noyfg/omaOe3qAn++jbgALTfCk88DdiEnIDd0k8Ah6Ur
Aa8A3rYCN+5BrTCW9wD3wRy1Qv+fBjwqjQFOSPtRK8yUgLqh/fcAm6DlbmjhecARaLkbnjiOumFG
/oi64bkvAg5An5fD/RsBm6QRwGGYi+Vw55toOYzxJUBeehnQBVxaDmN8BTABM7gcRkrKu2n9XpiF
5XgfrZ8gCO0zgAP5TwE3SQ8AbpW+g1ZSrq6E0f0WcAh6uBKeSMojpB7afwNwp3QScFz6NeBR6WeA
EwRBArVoCHr7AWAT9HMIPvsh4Ait2S79AQ3Bp94DPCr9DnBCegcNwXM/BjnjQNqH4eknAZtgFoah
D8cBh6SPAIdBhoZhvOS7v3iJfIOXSyLfHeaTyLd39Unke8NGJfLtZNso7qT1u2h5N71zDy3vlcg3
ix2i5XGJfLfaUYl889pxiXzf2oT0ZTQMnKkAXC7dCDgg1QFukh4E3ApPvwL6+RPAJulVdAXVlyvg
njfQCNR/GZBIyAj89auA3bRM+j9Cxz4C/T8CyINUjED/xwB90iHAPul7gKPSMcBtFHdCr0ag/6S8
m965h5b3Ss8AHqLlcZjZEejz99EI9CQBOCBVA26Fp2+HnkwAdlMk2rcdnvgSoE96DbAPeL4dnvI6
4G5avw+0eDu0TGrGQSa3A2d+CDgB0rUd2nwSMyDbfwTcJ50BhKcDHpU+BDxOayak17EJ7vkd4F7p
I8B90seA47R8lOJx6RXACSjzwI3fAe4E9MGn3gfcJ/0JkNzvo/f74P6fA05If8AJuP9VQF76CaBL
+j6gTzoBCDYNsE86BrhTehlwN/3rXultwHFkADyKlIATSIsTwKvbAQekGwC3Ss8D3oJ8uA/afx2Q
hzH2QftnAH3Qtz7ch8yAO2GkfdAyqQde4T7QZTvgJtSJV1LOrKScWUk5s5JyZiXlzErKmU3Q/puA
vPQioEv6d0Cf9G+AO6XnAHfTmr1w/yZo5yPAQ9Kv8Sbo4QE8Stsfpe2P0vZHafujtP1R2v42es82
es82es82es82es82es9OqP8Y8Kj0CeBx4OdOqP8T3gk8+SneReduF527XXTudtG52EXnYhedu110
7nYDT7R4D4zoJCAv/QLQJf0K0Ac83wNzQco7pZ8B7qZlsLSA48DJPTAXOkAyF3vguX2AILeAW2EG
90IfzgDuk94DHAc+76VP3wtPPw04Af3cB899B5Cn6II798FzTwPuBEnYB08kNfukX+J90OZRPA73
/wKQ3D9O1gJAH8UE9GSc9nYcPnsGcDet3wtjHwdrqQUcR3rAoxQnCEKf1wIOSAOAW6Uf4aPQ/nuA
PHz2KLT/PqCPYgKk7ii0T8qk/aPQPinvpbgPVvGjtP2j0L4akLR/lPLkKLQP8wTtv4yPQ/s/BeSl
HwOCFgP6pO8B7gTpPU70F3AvzP5xaFMJeAh6chw++z/wBHz254A8yNIEfPZdQB/wYQL6pgXso/U7
af1uikQCJ+jYJ2jfJmjfJuh8TUDfrgEckMAuQPs/AR3giN8Aa6INcFjaATgiXQm4HWnZpTALL8Oq
wCE9oCi9DtiEzIBgGwGHpcsBr5DeBxyRNrMDMPuvAvZBawPw2ZcAx6UDgEelbwJOkDI89z7QOk46
Atgk/ZQlmkWQp+ij2Ce9yRLNIrhXeo3dSiwM4DjF49CTrcTnYW8mkgy4EWW5Fo683YRQmgkh8n+i
Iz/DFFnqsRnpb6TMICPLyWUWRVhRLnMl9yjAG6qXy8qSehXaxi6Uy2pUBn8plDUowB6Ty1rm0cn7
dWgZ+yu5rEdl/0HcucBXUZz9f+bsyZ57CIgYhOoJIHJriIhKuRkwKgJCRLEWXzUhF4jkcjg5gYBc
jhQxUl6NrVVrrUWqFK21Vlur1dooNFqliBiUEmpjKlhtlJRKzN9/yr7fmd1zCWBr3/77+e/jb3dm
Z+aZmd88z8xsghP3RCccct3rTuTJFJVmj9pT6mucZ7ETlsLjuc8Ju4TH+6ETNkQ/71+dsDstT4YI
+gwnbKa994hJvj5O2CtO9dQ4YZ/I8s10wn5ZmMwfEKN9C5xwUJzqu8UJh+RsXyJPpjjff4iWSLfP
4dkO2zzbYZtnO2zzbIfdaXlsnu2wmfbe5tkO2zzbYZtnO2zzbIdtnu2wzbMdtnm2wzbPj4iwGCfy
xDncw+Jy/VfxoqJG1IJy1vqwuEj/NUH7bwoW86aCULXIJWWaqETCYh7vFrGPiFFKxcp4lpF7GfdS
cl5EuUryLORdBTkqdL5iUIWuUp23mlgt76p1ml2+ghaEQTH5KtCwgthyQjHqCuu/YbiQcCV5w7rN
dZQu1X8jcZHWUuNojZGjyqlT5QjTxxpdZ5n+W4iqL5fpvpbzplj/jb6o7kVYP4t1L1W9dj9KSBmj
NVfpN5VaYzEc2e8TtVShp1IzFnFaWc2bKl2rrVP1M5bWAlVjRPcl8TccbbbttquaamAgrP964SLN
QoX+e4Xq70DGdEz1OJYcD5szu5awbnu1068aze1CnTPV4vQeKdbqdTm710uI52p7SB/Ns7W2Kq1h
heahzhn5dL7ViNn9L9PtV/23xyWqrUE97RrVWIfREUn2xm7jIidPLbGVjvYYvbBHaFlylIq1jRTz
tqpXvxLWXEJLinX9JU79udpiF+mxUikn+sDEE3p9tWM5FY6NnYeWC/Cgz7f0mK6zVFuiqmVJcgwS
3JzM9xY5dh1J5laWa494NfnLtO3MJkeJGKE5HUmeUq3vUl22RuuPIRH6MRZZriVX+1Tv+nId7WPV
Hl9b4CLd6ggaVvBWMVaue6wstbfWxPty/ZdLo9peEvq+pvtgW8kKPbq1uoUxbce12u/s0mHdB+UD
ZXoEK3QdZXoMF+qyCbYuFvPp9zSnbDQtxfafUs1JyieWO3/xc/Hn1GvHVd4SRrBOc1iatLFSnR7R
FrIiza4iuqfVjmXZusr0XXnK8f1W6bZHjqCUGillDQuTNZ2sVdUnaP7iHKW0J2bFsDOvxXS7S3rN
Lyf2PTGbHN+uSWkMqJ7YfbFn2cQ6EU3O2KV6zqrWc1fx5/bU5rm4F6e2x9c4d7tXdrhOW16dLlmq
/V/1piypR+Ws1F7zj0bo/5VfpHxirG6N8gF75s/VYxUR9Y+Ex+WdMy58eUVJtKa2pjwWvqgmGqmJ
Fscqaqpzw9MqK8PzKhYtjtWG55XVlkWXlZXmXlRcWbEwWhGuqA0Xh6tqSsui1eHa4uraMOkV5eHy
4qqKyhXh5RWxxeHauoWxyrJwtKauurSielFtuIassbIqSlaXhktqotVl0drc8GWxcHlZcawuWlYb
jpYVV4YrYtRRUjsmXFtVTAtKiiOEVZGquspYRQSV1XVVZVFy1pbFtILacCRaQ7tVs9FeWVmzPLyY
hocrqiLFJbFwRXU4pvpByygSrqyopq6a8vDCikVasV1RrKw+RuGKJWW5YaebZ9eGq4qrV4RL6ui8
3e7YYuovWx6OFtOXaAXdpmBxVbguoqpB4yLe1FasJHushg4tU10qDi8vjlbZdSmaSxYXR2lYWTR3
XtmiusriaHIEJiaqvhpy6E74vNwLxvUiPRYtLi2rKo4uUT1QrUmN3iK4jqjXJTV0vLqirDZ3dl3J
iOLakeHSsvCl0Zqa2OJYLDJx7Njly5fnViXK5ZJ9bGxFpGZRtDiyeMXYklh5TXWs1smqwuXFVL9E
5ftaTR2UrAjX1ZZROQ1SyeFiRqAsWlURi5WVhheu0M26eP7saaRGdYTxKa2zR2L54oqSxWlleVZU
l1TWlVIUxkoraiOVVKC4ikQryFBCrrLqWG44UXdNNQM5omJkuKxqoSqUUlWdyHzSFunsyhQZltpY
tKLEtpdk7cpMErom6QaMqKAWTFb5RFQZdmnN8urKmuL0Smlzsd1SBp7uwrEK1MUidTFoX1ZRUqby
LC6rjBzXoS8yFnokxpaWlRdj/LnFtZH65HeTOuNhgzjZJcnBzlucIjyWxfeWy/naEHyRCtnf/tn4
P7jc7inBoCSPa/IXzR8KqfxG4RfN36ePyq++rr5Y/qwslT+j/ovm79tX5Tc3fdH8p5xCfp5CfX25
dX719XmhvvcVIdFPnC6y2VcOFuPFcFb4MWIO8+q1zNKLxVTm1QKxTswSd4ivivvFAr5frhdPM+tu
J3U3M+4fmJGPSJewZB/pl1nyNHm6HCLPkGPlCDlRFspL5QJ5lbxOFssKWa1+XiVr5EZZJ++Ry+QW
Yj+Wt8ln5Dfkb+QmuUc2yj/I++Sf5c/lJ7JJWvJFl182uwbJl13DjZmuc43LXfnGfNflxldd841r
XEVGpavciLqWGStdq4w1rnXGWtedxj2uzUaHa5vxkevnxseul4zDrteNI64Dxt9cHxhHXV3uKQZW
ZoR6c2L0/V9wcg+cPAQnP4WTF+DkNVL3wclBOPlMuqQHTvrBSRhORsPJV+CkAE7mwckNcFIFJyvh
5DY4uQdOHoaTJ+DkOfXzMjh5E07a4OQvcNIlf+4yZJMrE04GwskoODkPTqbDSSGcXA8n5XCyFE6W
w8mtcPLfcPItOPkBnDwFJ8/ByStwshdO2uHkMJz0GEcNH5wMgIMhvTkxz03j5DQ4OQtOzoWTaXAy
F06ug5Ml6ncdcHIrnHwbTh6Dk1/CyStwon4a/x6cHBEx1K3ANlzyLDg5B07y4WQ2nFwLJ4vgZBmc
3AInd8HJFjh5Ck5egpM3SHkPTjrhpEd+wxWQm1yny0bXcHmfaxyc5MPJbDi5Bk6WwMlyONkAJ9+G
k4fg5Mdw8iycNMHJHjjZByfvwEmncY/hMjqMgPGRMdD42DjbOGycZxwxLjL+ZlwBJzfASRWcrOjN
ie+xNE4GwskIOLkATi6Bk/lwUgontXCyDk7uhJPNcPIsnOyBk3fhpJMcllgsM+HkS3ByPpxcDCdX
wEkxnFTByWo4uQ1OvgMn2+DkGThphpO34eR9OPlULsMvVrsGyNtcQ+DkHDjJh5PZcHINnJTDSRRO
1sDJnXDyPTh5DE6eh5OdcLIXTt6Fkz/DyWfGSkMYawzTWAsP9xhj4OQ8OCmAkyvhZCGcLIWTOJzc
AScPwMmjvTkJXZ3GySA4GQ0nk9Rv7+DkWjhZos43g5O74WQrnDxNyhtwon4z1COul0FRKgfDyRg4
uRROFsLJajjZCCffhZNtcPIsnDTDydtw8j6cdMsKl0dW4gs1+EKdaxKcFMLJdXByI5yshJONcHIP
nDwEJ0/BSROc/A5O2uHkMJxYxuVGljHfyDG+aowyrjEuMCqNqUaU8V/JmzXGdXCyFE5ugZPb4eQB
OHkcTl6Ak11w8g6cfAwnx5hS/b056VuUxsmX4CQXTmbByWL1O0Y42QgnP4STZ+Dkt3Cyn9RPxVeZ
0xfIs+BkOpxcCSelcHIznDwAJz+Bk1/Byetw8gc4OQwnf5eFrj5ygSssr8MfKlwFcPI1OFkCJ6vh
5C442QInT8DJi3DCHOtqg5OP4eSYbDLUz4yHymZjonzZmGHMNMrgZDmc3AYD34KTB+FkG5y8ACc7
4OQ1OGmDk6NwYhkfubNgIMc47B5nHHHjO+6rjKPuMvcU9zI4Wa/WZ6+H/7KyRowoWLVunTdDej1t
jY2dDQ0NnSpiRhriXA0Rrym93s6G9VykuEnpjMf5L94rEtfZyNOjMnql9LrjzuU1hNcdtq8mVSbD
Sej0eqXXv337w1zf+Y5WUL9eX/W6BbotSoFqm440NjToSosa4/nhrMYib4bwmt2O7kQLbAUB4Q2s
D68Pz8yfmX8FEo6HaSPZ18+YkZc3Y8Z6M0Oank5vfUODrs1DexpUHaZbmhkR1b6Ifu9VWcik80ca
uuPxeq+bHuXld+ari0ymWd/YWBSP2Myh6YlXVBGbBWF31m9YXiMs0nkw4/HGzU2bNzf2osv0StP/
9G9v49JV2rqc2rlUq0yP3VbNjemxG+j1moY03W22FnphRuJNeVltHrfwuO3G5mk1Kve9i80MYWY0
NBQWhsOmT5i+hnhDfD4z5RDETiOlsMGbykZfUw0Vcd2Ftqysovx8kW+4hDTy8+OmlKYRVzucuOQy
4oEM4cvwerOywkpBPC4N/LFNmsIye/wu1KmX6srP11EVUFc8bhiYyubNm/Ug667rzhMp2qxJ7HZS
0B7OT0YiXq+TbUK+HlI70q2boIbL0VbvzWrLoHMmijCez3cGzMozoUA1sWDCf9IZfNIbeDH+YnwL
cheiBsTrkV7fhIJ1XFSe9IN/wymCJziF6vm6ghF0vmBdmlP4MqTPE0/3CtP2Cp3gTbqFSihq7FQJ
buHDLU7mFwlln+MY7pRj+NzSh2M4nuGT0pfk7t9yDeXVTzQd5xrakfNP7hvmP/ANM+UbZsI30psq
4robRY3/jncEXChMeAdeoeMJ97D9w2f7B5aQ8g8iKf/QKQn/sCOOfyijTvoHkZR/ONqUf3gyhMcM
awcJ+3zC5/OK/oiiYZpYqwfQZ0qfV6npxsK6fR5ik6frFk+frGK+7vXKeteRpmygO267SCrWrbWo
nCrbMXXrPerKrDKynKtNlTMTSd0+v/QFm7gezH8w/5taNiE+r/T5J0+/WV00QzVRNy/ZYB1rwI91
M9RSp2nxeYTPcyxRV7JR2vt8AekLKefZ6LjPOXHlPlDi8948fdiw7GHDpt/syZAeRXI9RuQ3pd9L
hc/soLIdz6gke1FtiOgkt9sd20TSppjHlB619PXE46v8buHPSDpRPjk9nlVqlOJkqO+lk9ZrohxH
igcNy5fyJHzJnyH9yusalDM1Nvil9KdojXt80hN8SuzUE40tuiGO7kSj1tvVOu93PKNcVkWdttML
j1t6HN+Kq7CaJ4rUUKmBS/QkT+vT6uiwokk5Dp7j8QtPoCC/IH9UXElftmV2MomFhQ3+tKyYp1+6
/Ikpk37rHioLzwurjrtdwuVWzuGR0kNXlaPFXVK6CIdMETDd7l7OJt0ZbdIjjnmOhQzpzwineVtY
v1EB+yLJ7ZZ+s5HLMRrH5XTMcblwt5Omq8lPxWzzUjG8znY7ZYieHt0gWqRjtt8px7OXoyxli36f
8GNlKddbi/PpmdMj/T5tycrFevxeolOn2R2YNlVF/T3rtA/cTKqynJ6Ev/Vo4pLuF9eZVUZLZz/O
UrRNZiVdUKnyJBN7/AHpDzUVNRUxF22+M3wnDrIxrBzF75P+wFSnsYlrGttq3RbVcNsjk/3AJdev
X+eMqbIhRZrfI/zepE9mJVtq+7aqPHN9OLGopfzS76WY9kvbMW1rdq/C+gKmDCgnSvdMj+OZOs19
ctcMuEVAuWbSNz2krVH+EWfTsKq32n/qnIEMGdAsOt4ZkDKQxvl/yD1VV+v1bNf5n3DPgHQFEu6p
uq47qez/33FQrzjmtTINGUhzUOWY+lXKQx0XDWgX1SbmfE0ohjJcfm846aROqq4snN+TjNZDlzPJ
Ts53BtKOJv00P6lZkevtVJ7qdTw14BcBv/pXtkpykPz42jh68uP5AY8MODaunTXgJX5Gsd2d/OIz
VNzfvcF213UburUxKXd1/DUV17d4wCcDgZSxWGmGc7whabPNSrmvUpVyX1SHZKBPU3ZT9uYRm0c0
zmicoWa1W7y3eNd5dS2DRUkvH55GfLBwOqRXdl1LIm478Trd4Pr1dC7Pq0gNeEQgzY2zjutA+vSg
G7SO6i/OsmWEatnmrPys/IBPBHwql5oH++s50d6MOHtu7eGMTNAjgz7bF9XqveOZXrt4nerimniJ
Sr1koi47oUB5OakZIpgxIeXmauy8KT9ft+o45evW2dNlkqKQYfnTXT3cFDRl0Jvm6+uDUgbTxyju
DUhv5rNNzeH1aaJ3/4lKen0KBFIp2uV1PNEbOqY/CByfjztbOjWfMp0yu5r5+d121yZorXYF0KBs
GfUFI/ga6PWxkHB9rUpvePH9QHp2XCMoXcHk1kzRobsdacCpjnd/r3SpLx+R7v+ZHhH0uFyJGcCZ
ADISE0AfQwbVBJCYAQiF9TsdSswAegoIetQUoC3SJizBWcCXV9joGOAxHa9fD1tuNQuk4kwDLpey
WOL2NJAqf8xpHw1M6VeUu7vTZ4JgQAQDmSJTDNJyTvyceFHTWhZJtU4GvTLo72lubt7R07x9+/bm
nqCPF2eKSLxINKVJEW/OFEG/DAaPie18GTalXS/Gt8ePCW2Kx1S8R789lnpxzM6ni6eKWek6moIu
RqzXC2zfzE5e90aUPm9ahmPBTBnMahvcNrhz8u4x+yr3Vb4ye+fOHZte3qRORQsGZDB0pljqdDQh
RU1Lm+iI3W3dY7sy1e0e0Sy2a2kWKmzHXozrjkwub2pqqx+caZo764NeEfRZqbZlH9ez1FUcv1AE
+8hg3xfNF83tG0o2lWwq31m+8/x946+ZXJ+dl52nW7J9e3n55OzsyeXl27frnf6qZtNc09y8a1nI
K0N+pejAoe3qOnTA/qwp19rLJ+t0g2vSIp2+aJL63qCxzc2QvnByyJQhc3JRUVF3kXMFVfpaRrx5
VdMaSqw5vort20MuGXI3NQmR7EaW2wpl5OUJkZe62kIeGfKp1Oad+zo79+3c2ewUTLt8Qenrc6Dt
/bzmXqI/ipL12Z9I5TpcPjmYlnbogBob9SLZP/qq96772hJVqI+o+h1qcIKb6tUqb6a6O0HrduqB
HPXhqH6wUSKUnI8MRnyZ/KeMpiR70b2l945/YnJndlF2kf6e0kOjRiZ48rLZSJ4IuVyhNOuFOc1O
/SbTNIMTYAvmMgzpyqBNTXEmfF+GIlgojtXsT6yvR2R61B+jD2JQimCVtUm6ZYbZKX3imM+KZ7kZ
Tfu9fRHM0y91yLlUegbj7t2pLm1gDrkJfoP+CfX7ErZr6RermiGW2rPzilIvzMkmb5tX6RdnoLhJ
+4yjwzJU5+zWpmopuVCpUV/ffl+WMwVl6d8o+sUW1zXCKFkRrRT9F0XLloiJlcWxajGbFHnlvOlh
mBSWpX8ebooQ66kdkwJmxKn6vf3GxWrbRwxAjMsKC2eIYfPmXh4WeVfNmxVmzbbzqN8BZ4nTdMyg
hr5J7exB2BMNdGLMMuIUcboYVBKpjYiH9P1RfX9C35/W9+f1/aUlZdFq8Yq+79L3Fn3fr+9t+n5I
3zvUP1EQR9Rdmvp+ur7n6vt0fb9a32+sWlK1RK7R9w36fru+363vD+j7Vn1/PPmb3H92l1/w7oVJ
Aw5MGMbW4eX/3zsX4xD6l5+Z4gz9bwXVv25bJ74ptognxUtij2jXv2/26Z56nd52CPXvdA3K9cdv
pfq9g5xoPxs22M/vdaeVwd4+3tIrLoM9veOZw3vH+/brHT/lvt7xs471jo84Ln3U6b3j4/OEz5Ue
/yQt3RTy0sm947M38vRj0yNEofq3zZRZB1V5rkKx1vWQ622x2fie8T3R4o65HxR7M940G6Thv9Jf
LJ/138pe/ZVgVvBi10XBa4MPuFaESkM3un4VWhva5NqR6cr0uvZkfpr5qev3Qsa7FDfmW6GnTyq7
kf2h99LkQ0d2n0Q+yRySlBHIRKQAuVHLvcdLaHfmlsyfZd3tyOY0eVSJ2hmeRPx9C5Oyse9dSemy
pd/gk0guMr7/fWnykC065Tjp/2T/V5Ky69Q25JCSAe6TSb/cAf0GjDhtY5rcpeWlk8ru0z5LSHb/
7NOTUuDIzJNKoZarnWdviTt3la9ZS0tS7NLvZHcOHDWwdOADA7cpOV77wMdPJrb2gc8MbHfkk5So
WgZ+puuKK3xp9tCJSZk9dF5SSh25EYkPvVH9ycVh+WflnlUw9EbuuWe9NPyVs9/S8smIBUhk5HBk
zMj2kd2gfeSxUa+MfkDJyPbRz4/+cPSHY9xjMsf0H/NLpCV3KlKYu2Ds/Y68cE783OHn/nn8N88f
j0y9IPuCBRfUT3jSkecnNE9omTgKmTBxw6QDU0wtjVNe0tIz9fypjzny9JQe4o9N7dSxzgtdF7qm
PnbhmPzb85+flnvxNcg7ly6e0mjn5tlp57psqsp32eyZQ2bmzZw6c9us4VoKZ92opX7Whln3c6+f
9SrSNnvl7Pjsdy6PIHfPKSJX4Zxdc3bNepX7ARVC2ud0zPlsblzL1rk7tbwztwO8M7er0D23i/SO
wgWFBwrbr4gh35wXJt/WuV12yryVc7vmvTfv4/mFVzdfc811/a4bfN3wRe5FCxbtW/RZ4rl4DPJk
dVb1kEh9ZF2kKdIe6Yh0LXUvHbe0YGn50sjSlUsblt699LGlTy/dsXRPNBL9ZnRb9EitqO1XO6N2
Ye3ztW/FxscWxu6vu7quoe6Fuk+WmcvGLLtk2WPLDi0vWP5Z/eD6S+qL6qP199c/Xr9vxZAV/7Xi
6RX7Vny2MrhywMoJK6evLF25deW+m0bdVHDT9Tfde9OjNx24qWtV/qqVq55fba7OXx1d/cTq5tU9
a05fs3jN1jUdayeurV/7eLzwc+aqp4+fj3rPNvFlKVHzSHxzSuwZ5HN8b+bxHtfbT2xLP+msk5h5
0qT33BFvTomaHeItKbHnBTWHZj2a3XzaXczD+6d2MmvqOVg/mW/7FjK/3pu5Jevu0O7knEnevl1D
S1XZ0NOZ96bmTpslZucCPf/auYZkbkmwp96quVjn3a/SdX6HQfQ+HXqPmXwLJfZrbbtp3d0892tJ
rQ4fHrcqFKStA6mVYItq9wmz/6MnzP5+Z87fqOd7PctrPZTOLCB8b2ImZDy2OePF3GTPP/b85owj
cyIzoBq10uTsmBhR5rjsmfF2VSI1xkPnxdvj7WhTuT4hrXBg+9B5J9oE82BL2ox6knk2fV49cU51
Zu5mbU32LDo7MX+qeZ031BrvGLiNN/OyC88fP2fXALe9jukna9Zpn53ahlX1S6w+iVWl3+AB7tQK
ZFulWtt0brfKQdmXBvRTKeqNyqXe9xsc2p2w1OzT+w1mBeynyquw/Ta1jqavpKotetV01s20lbMf
Go5fJ+/qtTrudlbG/onWk/6ZXbuqf1bhqW3ZBbSnF/uKNcUxI5XmsQmObU9UbNqWMrQUvmeq0VRM
ZBf2v0+P9zY1NmlePXHg4/Q1scK22FrjHdnxeIctqgb1HDpPjYoK2ZamnvGOs3KHjbNhr3DDxulV
KU3UCmevbnp9/F+KXlPT5MQceqVNE2fFTcqJJdRK+6+JXou/sCRX7M+R45lSklzHP0f0yv6FRe82
vqAcz47eo6TJifzpvUuaKLu3R/pfkxM1//PWfTGxeVZ7l8wtU8yZQ6b0hParXY+WRv3GVDsdHWuc
OUTtgZw0hB3UBLVrst+quV+FlOjd0TV6Z6X2UJ1TO/X+iN0RoZemNOrdSTy5i1GydW58zoG5cbWD
0bGtzj7HDm9lF9Su3qgdjSo3xxG944npvRF5depWdR/4OLm3qt0Us8XwOQf0vqvekUL9ZrjadelY
4ZwDal5y0hB2bnns1dQOTZXboEOI3qdF9H6OvHqnltyvzSq80KUZ6VFcXBGzmZhi6v7QYruls17V
ulVNG7Qurbe3J544oul2cPZbdkyY6lQXdZqLOstFneSiznExXhAXCHXSwm597okKdegzJ6Q+kcWl
zlzRJ64ExI+sHrHD6pFF4hRZLObJhWKgLBE5slT0lUv0yS7j1Qkn+nwTiZ4/CTd5g+TtS94gef1a
30F90olPXi8Gkz6U9Pmkf4n0oeg6C105lP4u7XlH/b/z1pPqRBNjFe1Ybf2C9k40/mTdY7wn8oyD
YpzxvhhtfGC9YXzI167SvlufZ+JWZ4+ok0fUuSP61JF60UfMFFlgohgpJoFS6w1RBspBrfW+iFmf
iDqwDCwH9WCFCIqV1h5xE1gFVoM14OuUXw9uARvAraAB3AY2gm+ATeBZMV38EnQTPgYsMVIKIEGh
mCSvAPPAleAqUCHmymZxJj2uMK4Wk41rhde4AVSKBnWChHGzCBtfF2e4v2/tcW8GD4I9YqT7TdAC
9oK3wNtgH/g92A9awQHwBzEyI8t6I6PN2pPxFxHM6CD8Eei09pgZYqY5kue5YqR5Ps9K6w2zClSD
GlBnvW8uA3Bjwo0JN+ZKADfmT8Qk8wnwC/CpmOQZJc70jAY3iJGeIrAQLAVRsALEwc0AjjyN4E7w
ffCgmO75Ec+PwMegE/wVHAGfAjj0loBSUAbqxJk+ISb5+oszte0e0ufDqNAH+syXU7Hap7Dap7C2
4VjbNKxtHdZ2Jda2EGu7DGvLV6e0qBNZjKut29WZLOpEFnUeizqNxXjB2mr8CTs7KAzjEDb4gbhW
29l7+kyWvkmvuF6MTdM/A/3L0H8x+i8g9wJ034XuX1DqXHTfje7vou959F0tMtFyGC2H0ZKFlrPR
Uo2WsWgZi5bRaDlbnbehzmBBkzozZpw+g0X19Lfq5BSRjY5fo+PX6Bghb7B+iZ6x6LkBPePRcyV6
LpQV1uvoGivvtZ6h5HPoc6NvGS0rR+cptOzraPuG0W59QuteNf6Mt34gvmx86HhsX7SOQmsFWi9A
68VoHYbGEWh7U53WoM+L+gX2G3BmmL8zk6iZ5Tvi61aHWA9uARvAraAB3AY2AnVe0ibwqtUtXgM7
we/ALvA62A3eAHvAm6AF7AX7wB8sS7wD/gjawLugHfzJek28Bw6CI1ar+Bt+/gk4CrrAp6Cb2e3/
kP4Z+L+gB/wdHKMtltUhBZB6VvyTsQAL+y/rsHE9zyLrsHuP1eF+E7SAveAt8DbYB34P9oNWcAD8
AfzZ6nZ/AD4EfwEd4CPwMTgMOsFfwRHwN/AJoC3uY8CyXsvoZ73mybe6PReDmWAWmGO977mK53yw
gPRrwfXgBqvDUwQWgiWkLeUZBTHCy0E9WEF8Fc84z5vBBsK3AsbBcwfPRp53gm8Rvgt8G9wN7kH/
93m/hfBDhH9E+CeEnwOMkYcx8jBGHsbI02pZngOAMfIwRh7GyNNGmXdBO2CMPB9YrZ4PwV/oSwf4
yNrt+RgcJq0T3X8FR8AnxBk7TxfPT4kzRt4SUArKGC+XuF301yuXIW7Hdudjw2r1yiD2Y2IziV2G
le8wXhejheRtlyjAMluxzFYssxXLbMUyW7HMViyzFctsxTJbscxWcr+PpXVjad1YWjeW1o2ldWNp
3VhRBxbThcV0YTFdWEwX9akzXFqN60SGUQwWYkEl1p+wmlasphWracVqWrGaVqymFatpxWpasZpW
rKYVq2nFaloZyS5GsouR7GIUWxnFVkaui1FrZdRaGa0uRqqLkWplVFoZjVZY74b1bljvhvVuWO+G
1Q5Y7YDRLhjtgtEuWGyFxS5YbIXFVlhs1R67X3jgchqe7GXt/RVr78+N3ay1b7AKsdpofj+kh2/Q
w3c1v6uIqdPZBsPvOjS8La5hncxhncxhncxhncxhncxhncxhncxhncwR6i8abwK3i/NZK4exVg7D
Z1vw2RZ8tgWffRefPYrPHsVnj+KzR/HZo6yn/fDZg/jsQXz2ID57EJ9lvMUs1s3x+Om7+Okf8dN3
8dM/GgvFcKNEnb0m1rOOnsk6eibr6CDWzhzWzhzWzhzWzhzWzhzWzhzWzhzWzhzWzhzWzhzWzhzW
zhx88SC+eBBfPIgvtuB7R/G5FnyuBZ87yBqXwxqXw/qWw/qWw7qWg68cZG3LYW0bhq8cZH3Lwf5b
sP8W7L8F+2/B/t/F/t/F/o9i/0dZ//qx/vXD/g9i8y3Y/FFs/iBrYA7rXw7rXw7rX46yd+sIXB9h
f3a7dQsjMIP5/F3m8zpGYgYj8TCpm7D2i4097KRarGPGXrFQj14rufeTax8r5u3WGmILKbuHsm/y
Np+yt1P2ZcrOpGwL5b4mTMePvkrOveRsIedMvb9SNvNDramM9AtJ30X6W6RPQtNtpD6BpuloehVN
eTr/7/U+8R197xJ+2UecKReASlAFakAELAVREAMbWen7qhO31Blb6oQtdb6W3httFqcZz4nzjBcZ
/3YxlFX7SnaJ/Vi5T2eXONT4MzPDB7TgQ979RZzHeh61XqTEAPaUQ9SaTvlKcRkr2AJs/lpxmXG9
3n1dJjJp2SBaNoiWDaJlg2jZIFo2iJYNomWDaNkgWjaIkv0pWU3J/pSs1iVDlAxRMkTJECVDlAxR
MkTJECVDlAxRcjglz6HkcEqeo0sGKRmkZJCSQUoGKRmkZJCSQUoGKRl0So53So6nJ9eKUYRGaY6f
0nuET9XpW+r8HHAFmAeuBFcJP3s3P3s3P3s3P3s3v0/9ntatztFSp0Q5O40deozeFS1yhNUuR4JR
YDQYA74McsFYkAfOAePAuWA8OA+cDy4AE8BXwEQwCUwGU8BUcCHIB9PAdHARKAAXg0vApWAGuAzM
BLPAbHA5mAPmgvvAd8H94AHwfbAZPAi2gB+Ah8DDYCv4IdgGHgGPgh+Bx8CPwePgJ+AJ8FPwJHgK
/Az8nN1aE88Xrf3yJbAd7AC/Ac28f9naK18BvwWvgtfATuuQ/B3YBV5nB7GAr5Xrrd3u37CTaAYv
g1fAb8Gr4DWwE/zO2uveBV639mb0tdoz+oNTwQBwGsgGA6128w7wHQAH5gPWIXOrddj8IdgGHgGP
gp/xfjtPdpvmbwjvtvaab5J/H+Euq93zJXAGOBOEQY512DMEDAXDwFlguLXXczYYYe33jATYggdb
8DDunnHEzyVtknXIM5nnPOuw12W1ew3gBhnABB7gBT7gBwEQBCGQCfqALEB/vf3AKYB+e+m3l357
6beXfnvpt/d0MAgMBrTfS/u9tN9L+705YAgYCoaBs8Bw2jTOOuQ9F3zF2uudCCbxLh9cAi4FN5Bv
Ic9y0haRbzGoADeCOtJWgzVgLYiDO3j/A/L/kPzbrP3eR4g/Co7w7qjV7pOAvvpOsfb66IfvVOuQ
L4wN3aRPjoMdCTsSdiTsSNiRsCMpIWFHwo6EGX2+XF/QD5wC+oNTwQBwGsgGA4E6gU6dP3cmCIMc
MAQMBcPAWWA4OFuda8hX9kgwCowGY8CXQS4YC/LAOWAcOBeMB+eB88EFYAL4CpgIJoHJYAqYCi4E
+WAamA4uAgXgYnAJuBTMAJeBmWAWmC3UH/INyDlgLlBn510B5oErwVVgPu2+GnwVXAO+BtTpd2vA
WhAHN4N14OtgPbgFbAC3ggagzuFTp/DdCb4JvgXuAt8Gd4N7gDqj7rvgfvAA+D7YDB4EW8APwEPg
YbAVsALKbeAR8Cj4EXgM/Bg8DphrJXOt/Cl4EjwFfqbOAFSn8oGXwHawA/xGnYwHXgG/Ba+C18Dx
s8h8q1idFMg60IeZfzLrQB9m/8nq3EA3M56bGc/NjOdmxnMz47mZ8dzMeG5mPDcznpsZz82M52bG
cz/ON8pPwBPgp+BJ8BT4Gfg5eMb6yP0s+CV4DjwPfgVeAL8GTeBF8BLYDnaA34mgexd4XQQz+gp/
Rn8RyDgVDACngWwwUATMTdZH5n9bHeYdhO8mfK/1vvkd1iTGQM9mm0mjL+bDpNFmkzabtNlkljZ/
Yr1nPgGeJO0poGa5p8n/C949S/ovwXPEnwe006SdevZ7mfirpL3Gcyfvfgd2gdfBbhE036Ruvu1M
vu3Mt3j3tvWpnin30za+58z3/4e3e4+Pu67zPf7rTJukmQnlWu5iARFUQO4KXhZlWVyk6u7qIq6a
PXIxhSK3UmhNLwZhEbDcKUIFpGJAaddmiyLbUKBIGwgkbZNO09CkTYck08k0STOTaQt+z3OylYOe
cx7n/HPOHy9/mZnfzO/zeb8/n8/3+xtD6r3uWcqyfra7LrO7LtsB9yxl7lnK3LOU7cQI8ijIbTRs
K98nDJRPwr7YD4eE0fJDcRgOxxE4Mqos/xCOwodxXJQs/yiOxwk4xXOnOp4Gq2y51fW/pm6UrIhF
iYo4xmMCylD6necKTEQlEkiiCvtgEvbFftgfB+DAqLLiIEzGwTgEh+IwHI4jIM4KcVaIs0KcFVNw
NI7BsfgIPhoGKj7uHu0TOBEneWynUHGKn/88iU/385k4C5/Cp+VxNr7s54vgPrfiK9731bCq4mv4
B3wzjFZ8V5yXO++vp7T73Qr3uxUzUSuGOZiLec6/3bX1/9jUftBxoc99GD/DI/iVz6vHn6f4rz3H
w4q89+4JoxOjsG3iuNJ/CROyE0u/BV7puJ/nD4iSY5PdCjXxYM8dgkNhHk88ovS9ZKnT9+6rakt/
eXNsj/by+89fXfq7l2Pfo5T2W7loQuyC8C/xi8IrdqeVpe+2vDYQfSL2yZCJnY6z8HlcEFpjXwqv
xy7ERXblXw+b7S467S46Ky8Or1degttCpvLfcDt+gjtwJ+6Ce7nKBbgb9+Be3If78QAexENYiIfx
MzyCR7EIP8djeBxP4Bd4EotDJvnxkIniIi3ELnZPfJ176HPEnxd/PnZ2SIs/H/ui4+1hS+wn7l2+
FZ1ofp3ozNcr/zGkK/8J38C/4HthS+U0XIWrcQ1uwG0hL7e83PJyy8stL7e83PJyy8stL7e83PJy
y8stL7e83PJyy8stL7e83PJyy8stL7e83PJyy8stL7e83PJyy8stL7d84u/DlsSF+DIuwlR8BV/F
18IWued5eFbYwKE3YmM+htVj3xweJfd6edfHvhWWxC7FdNweVtKg9DdfO+ReL/d6udfLvV7uK+W+
Uu4r5b5S7ivlvrLyprCk8mbMxnz8OCwR10pxrRTXSnGtFNdKca0U10pxrYzO5UANB2rE1sOBGvGN
qqARFTQizi6RpESSin/9TyPxi/+Ut7pUceZkq0sVd07ee4+/SnWNqK4R0aVElxJdSnQp0aVEl+JM
DWdqOFPDmRrO1HCmhjM1nKnhTA1najhTw5kaztRwpoYzNZyp4UwNZ2o4U8OZGs7UcKaGMzWcqeFM
DWdqOFPDmRrO1HCmhgIpCqQokKJAigIpCqQokKJAijM10RepUE2Fal6soUI1P9bELoiOlP1U2U/d
+33rHXvvpz9GhclUOI0Kk6lw2t5vib/JqzW8WsOrNbxaQ42p1JhKjanUmEqNqdSYSo1qalRTo5oa
1dSopkY1NaqpUU2NampUU6OaGtXUqKZGNTWqqVFNjWpqVFOjmhrV1KimRjU1qqlRTY1qalRTo5oa
1dSopkY1NaZSYyo1plJjKjWmUmMqNaZSYyo1qqNytTAi46SM75HxjTLeX4ZzZDgzOpRGq+izijbt
tGmnw/402N+r98l/lfxXyX+V/FfJv13+7fJvl3+7/Nvl3y6OdnG0i6NdHO3iaBdHuzjaxdGuV2rC
r/5q3o1EJ8a+ZsZdjBpzbpoZdyWugs8Wcff7s67WzJgbXk/MDpnED1GLOZiLeZiPH6EOt+DHuBVm
Y8JsTJiNCbMxYTYmzMaE2ZgwGxNmY8JsTJiLCXMxYS4mzMWEuZgwFxPmYsJc3GciKpEw80qTPTMW
e16Pp/V4Wo+n6Va6Tz/Oq2v1blrvpvVuWu+m9W5a7Hmx58WeF3te7Hmx58WeF3te7Hmx58WeF3te
7Hmx58WeF3te7Hmx58WeF3te7Hmx58WeF3te7Hmx58WeF3te7Hmx58WeF3te7KWZdXHYSO03KPzS
+zOrlFFXdKqMGry+1euj3HiXG+9y413ndjm3wrkJnVIp05N0SqVsT9r7HdAfOfQuh96VZYMsG2TZ
IMsGWTbIskGWDbJskGWDLBtk2SDLBlk2yLJBlg2ybJBlgywbZNkgywZZNsiyQZYNsmyQZYMsG2TZ
IMsGWTbIskGWDbJskGVDdIZM6nizmjerYzXREfxZLYPv6YBdOqAgk1tkcvDeb2YOLn0zI5OHSt9m
8W4171bzbjXvVvNutazqZFUnqzpZ1cmqTlZ1sqqTVZ2s6mRVJ6s6WdXJqk5WdbKqk1WdrOpkVSer
OlnVyapOVnWyqpNVnazqZFUnqzpZ1cmqTlZ1sqqTVZ2s6vTxxWN9/ClZvLX3/3M6X9T3iXpZlJBv
s3yb5dosr4PkdJBXHpBPs3ya5dMsn2b5NEdlsRl8vTHsis0M78RuURd3hVzsgdI37Z7dHbslFKJx
/ndXdIIzCrGbVMTNuCW0xW6NKmK3efedoS/2YOlvHIc9sYfDnoT9bcL+NnEkPoSj8GFMwdG41DmX
4XJcge+jBtNwJa7CdFyNH+AaXIvrcD1uwAzciJm4CTdjVtgzls9ukfbEakOvXLbF7g87Yu70okti
16n26zHDszfJ8mbMDS2xeZiPH+GW6KDYrWFpbIHz7g7dsXtwL+7DwvC8/J5PxMIbiTjGYwLKUI4K
TEQlEkiiCvtgEvbFftgfB+BAHITJOBiH4FAchsNDjoY5GuZomKNhjoY5GuZomEucHVoS5+Az+Cw+
h8/jb3AuvoAv4jz8Lc7H3+ECfAmXyuMyXI4r8H3UYBquxFWYjqvxA1yDa3EdrscNmIEbMRM34WbM
Cs9H41XOZiquo+KW2INhSC3dEobVyWj0VS4UuVDkwG4OlCpsixWnYMUpOKNA5SKVi1aYghWmYIUp
WGEKVpiCFaZA/SL1i9QvUr9I/SL1i9QvUr9I/SL1i9QvUr9I/SL1i9QvUr9I/SL1i9QvUr9I/SL1
i9QvUr9I/SL1d1N/N/V3U3839XdTfzf1d1N/t1WuYJUrWOUKVrmCVa5glStY5QpWuQJ1i9QtUrdI
3SJ1i9QtUrdI3SJ1i9QtUrdI3SJ1i9QtUrdI3SJ1i9QtUrdI3SJ1i9QtUreo525U3aVerKXpHNV9
S7QPtXuovZXaO6JraNxI40aV3ufM1bTuoXVPbJbHtaHfu4ZVflblZ1V+VuVn+fAeHxr50MiHodhP
w2s6YIMO2KADNuiADXrpDbPhjzxq41Ebjxp51MijRh418qiRR408auRRI48aedTIo0YeNfKokUeN
PGrkUSOPGnnUyKNGHjXyqJFHjTxq5FEjjxp51MijRh418qiRR408auRRD496eNTDox4e9fCoh0c9
POrRIVkdktUhWR2S1SFZHZLVIVkdktUhWR2S1SFZHZLVIVkdktUhWR2S5XEjjxt53MjjRh438riR
x408buRxG4/beNzG4zYet/G4jcdtPG7jcRuP23jcxuM2HrfxuI3HbTxu43Ebj9t43MbjNh638biN
x21RDQfTHExzcCe/X+biDs51cG4753Kcy3Eux7kc/5P8X8a9LPeysTs8dxenF4RnOdjHwT4O9nGw
j4MDHBxSJyu42MXFLi5muZjlYpaLWS5muZjlYpqLaS6muZjmYpqLaS6muZjmYpqLaS6muZjmYpqL
aS6muZjmYpqLaS6muZjmYpqLaS6muZjmYppLOS7luJTjUo5LOS7luJTjUo5LOS7luJTjUo5LOS7l
uJTjUo5LWS5luZTlUpZLWS5luZTlUpZLXVzq4lIXl7q41MWlLi51camLS11c6uJSF5e6uNTFpS4u
dXGpi0tdXOriUheXurjUxaUuLnVFn+RSgUuFsW78LxdGuDDEhSEOFDhQum8aou4QdYeoO0TdIeoO
UbdA3QJ1C9QtULdA3QJ1C9QtULdA3QJ1C9QtULdA3QJ1C9QtULdA3QJ1C9QtULdA3QJ1C9QtULdA
nSHqDFFniDpD1BmizhB1hqgzFH3MZHjXZHhX92et55WxO2RxpyzGovfzg1hovX/Yun24Xd0ROBIf
wlH4MKbgaFzqnMtwOa7A92EHSetRWo/SepTWo7QepfUorUdpPUrrUVqP0nqU1qO0HqX1KK1HaT1K
69Ho+7Tuo3WfiLMizuqCjC7I6IKMLsiM6f/nDqD7/1T5dvCx0jcb//tq7+NHHz/6+NHHjz5+9PGj
jx99/OjjRx8/+vjRx48+fvTxo48fffzo40cfP/r40cePPn708aOPH3386KNgloJZCmYpmKVgloJZ
CmYpmNUNGd2Q0Q0Z3ZDRDRndkNENGd2Q0Q0Z3ZDRDRndkNENGd2Q0Q0Z3ZD5v+iGDIcyHMpwKMOh
DIcyHMpwKMOhDIcyHMpwKMOhDIcyHMpwKMOhDIcyHMpwKMOhDIcyHMqMrfGDY/8v5Jm8yvIqa9pk
TZs07bO0L2mcpXGWxlkaZ2mcpXGWxlkaZ2mcpXGWxlkaZ2mcpXGWxlkaZ2mcpXGWxlkaZ2mcpXGW
xlkaZ2lcyjErx6wcs3LMyjErx6wcs3LMyjErx6wcs3LMyjErx6wcs3LMJkq1MAM3YibUmxyzcsxG
+5rF+b/sGZV2x1inF8zUwv+pR+zdb7RHdWeq25K6rUy3bdFpB+m0ymjq+xNlhtW4FnPcl9/iWreH
QZU96Oyi3hy0Oo9410kULlB45AO7pkHVPai6B1X3oOoeVN2D/5+mzaDqG1R9g6pvUPUNqr5B1Teo
+gb/n+6KSncrRUq99v59y0gU3/tckUt7oq/Ttom2Tfwb4N8AbUt3Nh2cmEDfXvr2js2/BR7f7x7h
ATulhZ57OPTStZeuvXTtpWsvXXvp2kvXJro20bWJrk10baJrE12b6NpE1ya6NtG1ia5NdG2iaxNd
m+jaRNcmujbRtYmuTXRtomsTXZvo2kTXJjU1oKYG1NSAmhpQUwNqakBNDaipAbr30r2X7r1076V7
L9176d5L916699K9l+69dO+ley/de+neS/deuvfSvZfuvXTvpXsv3Xvp3kv33kQpzxm4ETNxE27G
rNA7pvGuvZ1QjA6ILY8mx16y43xZXb4S5sVeC/WxnfYZ+bAgtiu0xE3O+InuXk8OS+Onh/T7v638
jWjf+D+P/QtPpd8p7EtuCm9ybLHPXYKXdcArYX1slUp/Fa+55mrH18Om2JvudNe7WptjO/qiibF+
nZq3xy3YCY1idxiKR6E7Xo4KHOru/+TQEz8l7IyfitNwRijEzwlbk9Uhm7wsNCevhBmR/IHjNWFT
8lqYCcnZjrWOc2APnayDFTN5F3RlcoHX7/Oc2Zd8yOOFeNRnLA67kk/7/KX497Az+Vss81yDx887
yinZ4rlWrMUGj1PY5OdOdDtvIHQnd2I0dFcdGHJVB2Ey3B1WuTusOtbz00JzlT19lbiqbgsjVXeF
nVUP4GE8GXLR3+9VtYNPRapuoOoAVQeo+i5Vt1E1RdUNVN1J1Q1U3UDNAjWHqTlMyWFKDlNymIq7
qJinYp6KeQoOULCDghsouIGCHRTcQMEUBVMU7KBg6q8U7KDgAAUHKDhAwRQFOyjYQcEBCg5QcAP1
Bqg3QL089fKUG6BYnmJ5iuUpladUnlIDlBqm1DClhik1TKlhSg1TaphSw5QaptSGvUp1UGqAUnlK
5SmVp9RwdHTsmTA7tjz8O6Ua1eAeCj1Fle2xzeEKdTYj1h8eU93fiI3Yae8Kn1Nnf4zHw6p4Wfhp
PBmuVu1t8QPDlPhR0eXxj4QbVP7R8ZPCF6j2pOo/X809Ev9cmBM/N3xr729ndcX/OTwevzhMi9eE
FaXfX5LVH8ykl6wSr+C18LYrvsOPza6YdoV+nzroE7f6xB166Ry99Fl3hM9w7KXQ6l2lfnljrEf6
og9591rvXOOd28SWFlvCJ6wf64fTw3rvfCms8a53vOs57zjAO7a4XtdY/7qrHuvho/TpiR6fHDZ7
V7coV0VHqqydY+9cpbJexWoV87p3v6mq1ttFtjm2h22qY5vq2KYytqmMLSpji6rYoip2qoqdqmKn
iiiqiKKKKKqILSqhqBKKKmEb57ZxbifXSpO/L9pHPGUiX+x6z7ju7+X6PFaH3XTtpGc6eVMo+Pxh
nz/s84eTD3v881DwOcPReO8aEfl13rG1VPd2ws+YJcvl8kpo8eymWKs5UtJwc8jQrdXnbvC5G6KL
XXWBs+fpqZ6xavl9qHX1Wu8cosRuSuz2CT2UCJQY2dtXI5QYiaXCEp/YoJJaYlnVU4kDw2Xxydw4
GIfgmHB9/Fh8JGyPH8/nE3Ai9+ge/7zXzx373eVTRHOK3uuh7gh1R/ReD4VHKBwoHPReDxVqKR0o
sYASCyixQP/1UHs3tXdTeze1g/7r0X89VN9N9d3UqqX8CMVqk8+aREvwQrg+ucrxDTTjTWxEB972
WpfjFp+xNVxfFYU/Vk0IS6rKUI4pHh+HaSbU/LBAD/Zwc3fVg2Fr1UNYiJ9hUVgSJVTksGrcyunT
TJ/3TJ/3TJ/3uH6WTn9Pp7+n09/T1e9FR/Cj5GWB9oO0H/SuMjNqyIwaMqOG5D4i9xG5j8h7UN6D
8h6U66BcB82XIfNlyGwZMluGzJYh9T1ktgyJdUScg2bFkFkxZFYMjat0xfkq4EHur+T+vdy/N7aC
o414KbwWW2VVfBWvhSdVwZ7YWs+vV1upMCO2MfxnrAOb0Im3sTncFuty3Ioen7nNMY1e9EXzVUtD
LOPn7ciqvAHHHHaE62ODGPLzMHaGGrOpxeROmdwpHfwNM+rN2B6vvYv3worYnxyDVXgcYijNr/Gq
bYKfy8ypyjAvnvBzMkwfm2eTHPfFftgfB4ZzVOsFqvUC1XqBtfXW+GFhZvxwrx2Bo6Jvxqc4Ho1j
zLxj8ZHwL/HjPP4ojvf4BHzMz5/AieGLZuS/mizPcm0+1+Zzbb5qv8i8vCt+pnPOwqfCj+Kfdjwb
54S58c84fhafC9/WFRfE/8bP54brdMY39v7G7LM6ZGb8kuiQ+HdQE94yX3+TrAktyWm4JuzRJXt0
yL06ZI8qma9K5quS+cn5Xv8R/g234ye4M5qcvAs/xQLnP+C5B/GQxwvxsM95xOOfOz4WpiefwJNY
HG5N/jLMtJrNTT7j8a/xGzwbztdV51vh5qrA+Spwvv3BrVa5ucn/CD9KLsdzznvecy847z/9vAKN
nl/l8WueX+1zmzz3Ot7wXDPeRIvPasVarHP+BuemsNFrHTC9Vfd8XXt+cnP4T517vlV0ru69QPee
n+zxnBpMqsHkO1CHyT70h5VJdZhUh8ks1GByBwYxZAIMo+DnYliR3IXdfn4Pai6p5kyFeVXqrkrd
VcXDiqrxjhPCDFNihikxo6rC44mmRyXUYFUyrKyqwj5+noR9Pb8f9scBnj8wpKz0KSt9qupgn3eI
cw7FYTgcR+BI5x7l9Q9jiusf7TkT1jSaVzU3tOjw+VW3RZOreF3F6ypeV92BO3GX1+4LM3X+fJPq
fJPqfJPqfFNgvml1ftUjPmeRuB/zmU/6/MUe/xJP4Vfh+miKKXGdKfHbsZX55bH1/FWToFfHL9DZ
39bZy3XtUl27xpqb17Ev6tgeXdmqG5t04QpduE7X/a3O+o5OWqpj7tIxr+qYXl3ygC5ZpwsaVf8v
Vf9XVP9K1V/6LxXOVPFvRf/NvHpaJL+xYq2NLbVKLTcTfu+55/Gyde4Vr60K7aZnu5VrpZk1YOVa
bg0cEG2/1Wu51Wu5+bVY5K+aU/0if9MsWiXqlHmz1bzZKvJe83q9yHeY2evN7PXmySrRP2sWPGsW
PCvKPaL8h9Kex+q1NvmvJu1lYbkVbLkVbK0VbLneHNCbA1awtfrzaf05oD+f1p9P68+nrWBrk7d4
349xB+4M7aZ6u6nerjcHrGZrrWZrTfh2E75dbz5tNVuuN5/WS8+q+2fV+bNqut96st56sl7d9ltT
1qvVfnW6Sl0uVpeL1eVitdiv1raqta1qbava6ldb/epqq7raqq5WWYvWq6lVVrjlauppK9xaK0e7
+lisPvrVx1Y7yBXqoBEv2aG9Fn5P6W1Wh1a18AXTvNM071QPr1O1m6otVG1RE78zuTdTdrVJ3UnZ
1ZRdrTa2q413TON1pvE603idGvmEGhk1ZTtM2Q61slGdpE3WZpO12WRtVjNtpulGUzRlcq4zEVtN
xFaqb6P6NmpvMwFbTcBWE7DVBGw1AVspu83UazX1Wk26VhMtZYp1mGIdpljKFGs2xZpNsJQJttEE
22habTStOkynDtOpw3TqMJ2aTadm06nZdNpoKnWYSh17p1KzadRhGqVMo3XcWW2ydJosnVxazaHV
pstm02WzCbLZtOg0LTpNhk6TodNk6ORUC6daONViKmw2ATo51cKpFp3fyanVOr9Vx7fq+FYd36rj
W3V8q45v1u3Nur1Dt3fo9g7d3qzbO3R7JxdbdHmnLu/U5Z26vNM9cZ/dcWlffXp4NzpDl5Xus67U
UQt11EId9TKf5+maXXx9iq8NfG3QLRm+9vB1CU+X8HSJjijqgiIv5vFing4o8mOeii+q8oWqfKEq
X8iLeaq8qMqLqnyhKl+omnfRawmdlqjmXbRaQqseWvWo6l306lHJu+jTQJ8G+jTQp0c171LNu2jU
QKMG+ixRvUXVu1Dl7pJzgxxfCXep2FEZrPBop9jz4Rm1uTk6TGY7PUrLrF9m/TIblFWzOZCRWbPM
mkW3U3TNomsW3U7RNYtqp4h2iqhfRP0i6hfNTtHsFE2/aPpF0yyK0r1sf3SUK+VdaaMrpV0p7Up9
NCzdo7a42oirtbhai6vlXa3F1VpcLe9qLbQYpsWwq+ZpMezKeVdOu3LaldO0GHb1vKvnXT3t6mlX
b3H10v1h2j3CZvNyZ3hL1m+58ogrdpplz5u4G0zc0v3B78YmbpmzRvbeQ2X2/jdMJ8cvjk4dU67b
K51e6R57VLq32zOm44S97xr2KOvz233+kN1wyp42S+Hd8qykRIQJ9qRlKMcUj4/DojDoMzaPOdPq
7E1WkVKMI9FxPuNVr/yefsM+6w/OeOfP9/dj601kvpSjApXhD7L6mmy+R8dhOm6m42Y6lu6vN9Nv
WAx/EMOrYnhVDK/S8i/vuw/HER+4/57i/GP14nGOi5z/mOdK99zj5JyLDhbfkJiGxLRdTNv3foOz
Q/T94tohrh3i2CGOHWLY4dpDrj3k2kOuu911t7vudtfb7nrbXWuH6wy5xvboWJ/+guz/KPPVH5iy
6+n8rCsVxqZq5dhvivx4r5cbZV9T+o2eP08fGa921Rdc9QVXfeF/OXlKk2aK80pT5jjH0sRY5Ny/
nhgTx1bRnfYBu9xbl/H16+Gavb/d8ZYrf3PsN0ZPFfdmZ/6Oa83uC9rF/yKVln5ggpRWhhSlFvG6
tO6+Q61F1Foknxd96h0+bQkXm+3d2im4iIKLONlMxUU6IqUjUhxtlt+LuiIlx81y3CzHzVxttgdr
twdrt99q/6vJkeJyM5eb358cU3zGsWGR3F+U92YuN49Nj8Opvonqm8a+jcibIrvCK6IeoPwmEQ+I
uPQdzgC1N1F7kygHRDhA5U1U3kTlTVTeROVNVN5E4U2uNEDhTdTdRN1N1N1E3U26Km/q7rb6qR4V
lg8vRjGr4G47pV1R3G7kNY+GPOqNpniUcw9TtD/J2Z/krJSjVspRK+Xo3u8IM/Ysg/bxRStexkqX
sdKNWulG7deLVruMPXrRviJnT160uo1a3UatbqP23UX77qKVbdTKNmrfkbOyZew9claaUSvNqNVl
NJpoLd8lkket3Tlrdmlf946r5jj4JAefHJsqE632I/EDTZITQ1YG/c7Kxs+IJpkw7nmiU1wnFY33
Odt8Tuk712IpAxknx75ByJTOp8SB+umMUPR86VtZZ3jf1uggj0rZj8h+RPYjY5lfYq/wndD2gcxH
ZD4ylnWLYyvWYhM6ITuZjchsRGYj0Ydd7U365um7gb4bPnhn7tpZV0nTNu8KaVdIv383vmzsG780
bfO03UDb/F/coW/wODX2LeDYnTptN7h6mrYbPni3Ho2TeT46Nl7lpwPDY3ZLObulnN1STkzPiek5
auXtmPrtmErfrg3QabudUY4D73Lg1xz4tfvI/d1Hln47srTr6bfr6RfXc3Y3/XY3/XY3/XY3/XYz
/XYz/eJ5zk6m3y4mJ6bn7Cj67Sj67Sj67Sb6o3LR/NaVd7pi0RV3utouV3vd1V6PjvHqFrr1inGj
GDc6s7D3O+z/4dAZdnbnqOtz6bA49NJwNw13v+/SMs81ePy84wt2Wq85ftC1DR6n8Gf33nZOt/O3
ho1/4eJkqnVTrZtq3ZTqplS3uLv2fifVTZFuinRTo5sa3dTopkY3Nbqp0U2Jbkp0U6GbCt1U6KZC
d3SYPN+W49tyfFuOO+S4Xo7r5LhOjuvsVEtVt04+6+wqM3aVGbm8bWdZqsB1clknl3V2khl5rJPH
Onm8LYe35bBODuvksG7sv6I8Jv7d6JhoYXRpeDi6DJfj+vB4NCvcE83GD1GLOegJC6NtSGPYObvC
3dFu7MG7eC/cPe740DLuBHwMH8cncCJOwsn4JE7BqTgNp+MMnImz8Cl8GmfjHHwGn8Xn8Hn8Dc7F
F/BFnIe/xfn4O1yAL+HvcSG+jIswFV9BTXTwuJXhxXEvhd+NexmvYBVexWthxbjVWIMmvB5WjH8s
3DP+cTyBZo/fxFuQ6/g/IYS7J+wbHp6wf1g4wS57gl32BLvsCQfjEByK7nDPhKxzBjAY7ik7AWfi
qvBw2XRcjR9gRni87EbQvWxBaClrCSvK3PGUHxdWlH8Ux4fflZ+AU3Gax5/BJWFh+bfwnXB3+UNY
jG6Pt2AreFbeHx4vz2CH10Y8LoS7K2KhpSKO8ZiAMtgpVtgpVkxEJRJIogr7YBL2xX7YHwfg02FF
xdn4rp8vd5zn+CvH+vC7inxomeizJh5gf/ztaP/wZnQATL/oIEzGwfgojscJ+Bg+jgvxZVyEqfgK
voqv4R/wj/gGvolLw6Mq91GV+6jKnRPdEBZFM3AjZuImzAr1qrleNder5nrVXD/+J+HN8XfgTtyF
n2IB7sY9uBf34X48gAfxmPc9jidCPdcfnbAhvDmhE2+jC92ef8exF1mvD2DQc++FN8vKUI6JqMQh
OBQfwXGgQxkdVEd92emOZzqe4/h3+Da+g++iGleFR1XOoyrnUZXzqMqZo3LmlMm3TL4qqL7iByVt
ontCS3Qv7sP9eAAP4in8CvV4Gs+gCa/jDTTjTbyFFrRiLdZhPdqQQk9YZiYsMxOWmQlrop0YQR4F
jGJXWGpOLDUnlpoTS82JpeP7Qsv4fmSwHVm4Oxmfww4MYgjDcMcyfgSl9/0JISzVb8vKzYJyvV+u
18v1erk+L58a1pT/k+PXcYlzvoXvhKXlV3p8A2ZgJm7CD3ErboN+K6dROY3KaVROI/20tPwXjosd
lzq+ADqU06GcDuV00GvL9NoyvbZMry3Ta2v02pry7chih/eOeJ4e+m7puJOi8dF+0QSUlf5ll9I/
8YCJKP317gSSY//u7n7RPjg7mhydg0vDbDU+W43PVuMz1Pg0NT5NjU9T49PU+LToZp8wK0xX59PV
+XR1Pl2dT4/qoknRLfgxbsVt+Dfcjp/gDtyJ56MPRX9AT5jF0VkcncXR+zlaz9F6jtZztJ6j9VHp
L0jvCrVcreVqLVdruVo77mehbdwjeBQ/x2N4HE/gF3gSi/FLPIVfoR5P4xn8Gr/Bs1iCpfh3/BbL
0ID/CG2xT0aTYqdEk2OnO34eF4TZsS+F62MX4mse14T5sWnhqtiVuCpcZc92Yfxb4Qb7tgvj33W8
ITTFZ4TWeEs0Id4aHRhfZ9fb5q68PaqM94T6+DZ7kXR0fPwdx97S3wZy3B7tP/6GaL/xM3AjZuIm
3IxZmI0fohZzMBePhenmxXTzYvr4tdGk8euwHm1oxwaksBEd2IROvA16qvZa1V5r1syesF9oU/Wz
zJjpE7ZHlebLbPNltvkyfcKeaL+yONRW2f44AMfghDC97GOOp+C0aLKZMr3sLD9fFWabH7PNj9nm
x2zzY4b5McP8mGZ+TCtTS2WzoJbKHg5tZT8b+y/o28qPxIdwFD6MUzA11Ou0WTptlk6rLb82mlR+
HeZhPu7BQ55/zPGJ6EO6qbb8137udv4WbIWa0zn365z7dU69zqkvH4gmlueww/kjXld/Oqi2fDSa
VHFgaKs4CJNxMA7BoTgMh+MIiLVCrBVirRBrxRQcjWNwLD6C7/msS3EZaj2eg7mhbeK40FZ5cbi+
8hLUhqsq50LfVOqbSn1TqW8q9U2lvqm8Cz/FAtwN+Vbei/twPx7Ag3gIC/EwfoZH8CgW4eegT+Xj
eAK/wJNYHE1KzMYPUYs5mAvaJmib+BH0d0J/J/R3Qn8nxJkQZ0KcCXEmxJkQZ0KcCXEmxJkQZ0KM
CTEmxJgQY0KMCTEmxJgQY/Lj0aR9JqISidK/MB9/S6f0mEaln0p/e+Tg2EzTLDn2rwuUoRwVmIhK
JJAc+wv2SdMsaQfQYQfQYQfQYQfQYQfQYQfQYQfQYQfQYQfQYQfQYQfQYfIdYPIdYCeQsRPI2Alk
7AQydgIZO4GMnUDGTiBjJ5CxE8jYCWRMyStMyStMySui74dcVINpuBJXYTquxg9wDa7Fdbg+1Jio
15io15io15io15io15im55mm55mm55mm55mm55mmlaZppWlaaZpWmqaVpmmlaVppmlaappWmaaV1
t9O622nd7bTudlp3O627ndbdzqj0fUc9nsYzeD461OQ91Pqbs/7mrL8562/O+puz/uasvznrb876
m7P+5qy/OetvzvqbM62vNa2vNa2vjXrdy/ahHxlsRxYDyGEHBjGE4fCQyf6Uyf6Uyf6Uyf6Uyf6U
qX6zqX6zqX6zqX6zqX6zPX3Knj5lT5+yp0/Z06fs6VP29Cl7+pQ9fcqePmVPn7KnT9nTp+zpU/b0
KXv6lD19yp4+ZU+fsqdP2dOn7OlT9vQpe/qUPX3Knj5lT5+yp0/Z06fs6VP29Cl7+pQ9fcqePmVP
n7KnT9nTp+zpU/b0KXv61LivRpP/O3VnAiZFdb77U3Wq61RXVw/DMAzDsO+oMS4xGomKUdSoLBJF
ERBQMAQDKgoou7sICIgKKAoqqFEMEnFjEReCS6Ii0MDQOOwwwzDUyDYDzNDn/qpo/INgQOPzv/d2
P2/1qVNnr++83/fWQLfRHvwJXAuuA8/qBJ4ogSdK4IkSeKIEniiBJ0rgiRJ4ogSeKIEnSuCJEnii
BJ4ogSdK4IkSeKIEniiBJ0rgiRJ4ogSeKIEnSuCJEniiBJ4ogZaYg5ZYgJZYgJZYgJZYgJZYgJaY
g5aYg5aYg5aYg5aYY3wpXOMr8DVYIly8mIcX8/Bintki+D+qfF7K5x/1CLxZW7xZ29CbddYlZk/Q
G+92hFcz++oSPNuFeLbb8GwX4tluQ4uPk3frv8v5+hO5UGTIj/F+S9DzS9Hpy0UNvFwxXk7KVej7
Q54ugqdrHH7HZDH52/E8/YWHl/Pwch5ezsPLeXg5Dy/n4eU8vJyHl/Pwch5eziOSLiaSLiaSLiaS
LiaSLiaSLiaSLiaSLiaSLiaSLiaSLiaSLiaSLrYmad+aDJ4Bz4Ip4DnwPJgKpulWeM5WeM5W6K45
6K456K45eFEXL+riRV28qIsXdfGiLl7UxYu6eFEXL+riRV28qEuc6RNn+sSZPnGmT5zpE2f6xJk+
caZPnOkTZ/rEmT5xpk+c6Vt7dYlVBsrBPrAfHAAVoBKwJ/DMg/DMg/DMvfDMCTxzP/RfPvovH/2X
j/7LR//lo//yUQlJVEISlVCMSkjiwVtFNmsfpZBEKSTx5L3w5L0ijCnCmPDorfDoHqohGUlxrrVv
C2AAE0jh4ek9FEUSRZFEUSRRFEk8v4fn91AWSZRF0q5N2TqgEXlNOG8K4FpURpLIoBWRgWefyXVs
kOigGqojSYTQigjBQ3kkUR5JlEcS5ZFEeSRRHkkih15EDr2IHHoROfSy4VEbHrXhUftu0B8M0L2J
JnoTTdxJNHEnUUQr9Gw+kUSCSCJhTw2/kSnHng3eDr+VKcdezOc3eg5RRsLmXqJ78+1ykUPEkSDi
SBBxJIg4EmjhOWjhOWjhBWjhBUQgCfTwAvTwHPV74aKJ56ALfHSBjy7w0QU+uuBbopRX0AU+usAn
WulHtNJPddEl6ibQVQ9CH/iqD2n2lLod3AHuBP1o8y7AvNAO36IdfLSDj3bwiXBcIhwXDeGjIXw1
ivKjw28V9Il6XPSEj57w0RM+esInChpEFOQSBdVEV/hEQoOIhFy0hY+28NEWPtrCR1v4aAufCKkf
EVI/IqR+REj91Gba3gK2ArhewfVETZOImiYRNb1C1PQK0dIgoqV+REuvEC0NIlpy0fr5aP18tH4+
Wj8frZ+P1s9H6+ej9fPR+vlo/Xy0fj5aPx+tn4/Wz0fr56P189H6+Wj9fKKuBFFXgqgrQdSVIOpK
EHUliLoSRF0Joq4EUVeCqCtB1JUg6koQdSWIuhJEXQmirgRRV8I5mzH9Bpyv5zgtQDfa7sF5T3Ar
+DN5vfj8C+gNbgN36GIitAQRWoIILeHcR51x5L9K2b/pBc5rpF8He3V+VIgcIrhElLlFq+k50erC
da/Vm9zrwPWgo25LZNfW7UL6Xl3iDgJDwOFI737SD4NHhUfE5xHxeUR8HhGfR8TnEfF5RHweEZ9H
xOcR8XlEfB4Rn0fE5xHxeUR8HhGfR8TnEfF5RHweEZ9HxOcR8XlEfB4Rn0fE5xHxeUR8HhGfR8Tn
/V+M+LyjIr7qYqy+wOgq2hjdxbXGzeJe4xZxmdFDXGD0FDeYfxQdzd7ietlBXyI76j/IefoVuVC3
kRv1F8SG2RKGk1v1E7JIfya3iVqyGL21XZeJemJsapGYqZeJf+pltH5R+ttgz6X102j9NFq/2Oit
y/CtW+gFNYcq66Bb0MuF9DJALtDz5QdgYapEfqTfwcetkp/oxXKRHkvvD9HzPrlFF9J7C3ofR++S
3qfS+yLhyK/1DPkNY0LJy2W6h1yu58oEtVbqNXjFAuLUmfpTxvYpJW/Ed35N6UmUHiKXpVKUfpHS
V+JH36HGPdR4NvxuxzMY7TC8eR2895VmGzx5b93bvF1I83Xi5EX6FvMzPdlcK35r7sUjZ4sq8gz9
slwgPLz0GczgH/T0GXpUymVozRX6bbx0hNZTzCiBpx6S9tQyrUklMyuU25hVMfnb9Q7jBmHpuSIC
bKCAA6LABTHggTjIAFX0fJEJWug14vfgQT1bPAQeBo+AR8FI8BgYBUaDMWAsazhXLxXz9FLD1GsM
CSwQATZQwAFR4IIYiINMUBVkgWogG1QHOaAGyAU1QV1QD9QHDUBD0Ag0Bk1AU9AMXKMLjPbgT+Ba
cB0YBoaDEeA+cD94ADwIHgIPg0fAo2AkGK9XG0+ACeBJ8BR4GkwEk/Rq80w92zwHtATt9fvmYzpp
jtJJrLwDd6UEO6vExmZzJ0qwsXbYWKUsSxXJcnbEPq3k/lS5PJBaIyu0LStThfKgbilT5Gtd04qk
iixbX2IprSwnVW5FU2ssV9tWLFVoebqlFSc/g3L99VxrABgI7gH3gkFgMBgChoJhYDgYAV7Sa6zp
YAZ4GbwCXgV/A6+B18FM8Ab4O5gF3gSzwT/AW2AOeBu8A97XBdZcMA/MBwvAB2Ah+BB8BD4Gn4BF
4J9gmZ5tLQcJsAKsBKtAPlgNkmAN+BYU6NmRCj3XlgD7tSN6vp3FZzXQCJwKzgK/0Wvs8/gcowvs
iWAy58zTfpk087GZj818bOZjv0nebPAWmAPeA3PJnwfmgwWAsduM3f4X6X+DL0l/Bb4GS8BKsEqv
tpNcKwTbwU6wC+wGe8BeUK4LVAaoAjJBVZCrV6uaIA/UArXBOXqNOg/007PVXeA+cD94AkwDL+ql
aiaf5Xq200wXOKfpNc6v+TyTz7agHekb9WqnB9d7glvBY+RPJv8Z8CyYAmaCCr06KnRBtCqf7K8o
+yqaB2rrNW4PnXRvA33A7eBO0B+w3132u8t+d9nvLvvdZb+7j4OxYBwYDxivOwE8CZ4CT4OJYBKY
DJ4Bz4Ip4DnwPJgKmKP7AngRvASmgxl6duwqnYxdDVqDNqAtaAeuAe3BEP1+bCgYBoaDEeA+cD94
ADwIHgIPg0fAo2AkeAyMAqPBGPA4GAvGgfFgAngSPAWeBhPBJDAZPKPf907TszOi+v0MF8T0+8LC
V8yG+YvlCvFreLlSPC0G6yliCBgKhoHhYL9Oop+T6Ock+jmJfk6in330s49+9tHPPvrZRz/76Gcf
/eyjn330s49+9tHPPvrZRz/76Gcf/eyjn330s49+9tHPPvrZRz/76Gcf/eyjn330s49+9tHPPvrZ
Rz/76Gcf/eyjn330s49+9tHPPvrZRz/76Gcf/ewH38JlfMo4P9MlaNYSNGsJmrUEzVqCDp2MDp2M
7lyO7lyO7lxuztBF4b+PPPSvjjaY5XoD3iwfLzZFLhH18Jfr8WBj0HBT0HBT0HBT0HAlaLgSNFyg
n5LopyT6KYlm8tFMPprJRzP5aCYfzeSjkaagg6agU6agSaagIaagIXw0QgnawEcHlKADStSpOqlO
C7+Ps4TYP4jlk8TZSWLrJLFwkhg4SfzrE//6xL8+8a9P/OsT//rEvz7xr0/86xP/+sS/PvGvT/zr
E//6xL8+8a9P/OsT//rEqyXEqyXEqz4xaokzgLbvI/1q8K1p2ife9Ik3S6LZ7KeOejIx5mRiyuXE
lMu9YbrIGw5G6KJ4tt4Qrw5yQD1QH9xP/nS9QZh4lTfw68Rxcp44X84XN8kPxTnyI5HL+r4nPyGS
WiSaya9FW9a6Lbo+QsRwEdo+SybE2az7OiKHusQ5G8ndJE4lXmhLvNBUFonLafeT9LPs0+jpYz2T
8k+Gfc7m2m1EFfNFBnlfcLYk+F7KY79L1+gtWh7/+3QZz1nsjgvotTX+8ErGcCjnLLxlObmX4C3n
4y2Lw+8o3h78GiW5tTm7KHymWIOyTRhD8FsEW8XplPg1Z0tES2aYzbW6zDX41reO+ivZX7Rg/J9Y
FxKvmeR8ztm/KY1vIiYs5ayAsz4iztkBzj4XzYQlWooIsIECDogCF8SAB+Iggx47iOqyEzFeV9CH
Oc0nDvyIOPNjvdTqL1paA8BAcA+4FwwCg8EQMBQMA8PBCNESLd8Szd4Szd4Sjd4Sjd4STd4S/d0S
7d0Svd0y/P2LONHtHnoqYBZb5YfcyeDXTD7W7xLdbmfu/VmTeYzrA0oxW+YeF1nGN6KRsVScycp0
ZR0ulZ0o1Vl0ll3D75jrLPvoj4NvJZID9UY5UZwrJ4nz6MfnTjchkpllnS/OtlqIM1mtzqIuNerS
zznczf6iPj3tCPoPe4qnf9fkM9mF2jdRvjufN/PZHwv7Rq8mRi4hPt4f2s9K4VBLCjv4JRRK51Ay
h5JRSvqUKBU5YhMsSgwlthA33UVPwT0dqJcTd5dw16vAuEvD9hLcwRXUos0gIo5k6Uo0fCUavhKN
XIlGrkQjV6KRK9G+lfTZQRcF/+OJFk9lp6iwtRV6j6hxVJ9d4KzuoC9z608kvkTvZHSlzMPH4qrT
915qLabfGP3uO2G/MfrdGPw2C61l0W+EFvfSYgkt7qHFKK3tTM+ikn3Wgdzg+wK7EMl3B3dxpb+o
Sc0oI7apWUbNSmrGGUsqWDVqVrArNokrxGawBezHsg+AClAJDsIOHVAuHfWZsgtscZPoJrvzeTOf
fdE+dzGegXq6HIpdTBS/wx4uYMW/occW4b1Zpp8Pe0voley5bFTOgbSNnG3RtpUCWjSLZIkrVCfQ
GXQVzdQkMAOs53wD2AgYpyolbw+fZYwt+P7HUka2nznvZ2SnMu/9jOxU5p3HvAPGcJivy1wL5SqR
GVrdAmp8Qo3N1MijxmZq5FHjd5TOZMxbQ8tbpisY9z5qbg5rJcLfJehEf52x5K58duNzAKy4UTSE
8UrhGBdmrAkzVoXvFoS/qBPcvySlJDml3IcOpDqGeyP4NrwceTdWdQ/+bivjLqLHbdoP7W099TZT
z6V1h5ZNriRFTdFT7xS3gj+Du7n7HbifnRhXVzAAywxKb8JKtrLShYxpG/qymFa24ycvFDUimXpn
pATs0DvtPqAvuB3cAQaAgbSbkf5NoHxaTtJyUt7NrAbA+Ru5j5uwos3soHC28HARa7RNfxlq8RqM
r4LxVTC+ivTsg2fKa2llLa2YtHIqY8yklXJaSdFK8E3zDi1sCH6PiPFVML4KxlfB+CoYXwXjq2B8
FeJ00VO0FreCP4PBopUYAoaCYWC4aEWPVejxV3BWhBVuD2dFWOX2cNarrPRbrPQH2Oln2OmV2Glr
+bp+gjn9Gw/R9NBo8FvBaIqIJs4XLbDRFtaFOt+aJlpZL4AXRatIpmgdWc9nCZ87wHeilX0KOBf0
Ea3tvuB2cAcIxucwqrK03ZhpuzHDexWs4DZdGD6NmMW4X0mXykmXymHcPiXPDp9AbNPLsYw+qUVo
wR1ov/VovR1ou/VW89QWbK1Pyie3lJxSq7m+iFb7pNbKMta5gtqVcMNB/bUV0eXown1WTO+h5NeU
vDys+zFXl5KzlBw3rOvLA/RXwaoc1CvQmCkrKmzqpii1Ai2ZomRLeKlPaiu9pFCpexhZidzPZwW9
VmKZh2pW0msKdbqHEZdYDp8uo4iRf6ilSmawF6vrg64tFwatlNJKilY0LRSFfdvCoHYptVPU1tQs
So/hlGCdUuMZw0ZqN6L2GmqXyQPs2GD0ldjxQSwuRZyg9UHGspHWGtHaGlors6I6Ec4qxn32RCZK
uZiWDzKmvwdeVJu0uI9xFMiUMKm1j74LrDjp5rpBUCK1hBKF9BesVJIShbQZrFKSNr5jdX9wv7j7
6ftE7RPcn7BseF8oe4L7wRz/y/sAn/7E9YdlfuF1Z44/st7hleOus8iwskXUqs74coVr5dFaLerU
JmaoQ7ou1+pxrSHXGnPehGtNudYMf2BZOfRQi6v1+WzCPfGsbM7QEFYN+s+jh1r0FLRVl/x65Dcg
vzH5TcinHe5CUDrouVa6RNBT0FYW4zK5usXKIacGyBV1GV8WJbfQZl3GZzI+k1pbrPpcbwAakt+Y
Mk3Ia0q6WfCr5LRSwFiDGZpWTcaaJyLpVoLaBYw/mKFpNeJaY64dqm0y32xQHdvLYcy5tJvHXGpx
92vTV51gXlyvx/X6XG/I9cbkNeF6U643Y37MgntTnXZzyK0BcvVKxpBidTZatbmXdZhzXcrUo0x9
rjcADSnTiDKNKdOUMs3wbMF98sJ1zRXZjCNYsX2MI5txxBiHF65tQ84bhyu4jzFkM4ZYcFeEDOee
l17nQ6MPVk+G8z5UozQ9alNU+bk2wa71Wb8f2AW7/QwR/6m2Qa0zhfox++BqE1Htl7IRWvsVs/6Z
dkLt5qLqf2srtHJ+MKNfxl64E/8K7+PPspnQN8R/qt2ErN5clqW2waTdYZzasFobeSBVCqtdJitT
xbBPT1itPqzWwoqktsGo3WGj2rBaGyuaKoXVLrNiqWKYqSesVh9Wa2Flp8pYkdNZkVNYkVOsXM5r
6l+xIhmM6ixWpSmr0sSqS349ytWnTAPQkPNGlGtMuSaUa0q5ZlhNFOXmoblayuB3fRaJakS72US6
jYkqfkessJhor0r420LzjK7i90Z3cblxsxht3MJnD5R7B/2cvB4tcoOeR+TxXPhLdaf8h1KLw1LB
byCtCnMPn83+/sxEyS80PtKzw1Tw63YbSVVBJZ8uhGiBJj1V/IH3meJqca04S1wvbiD3RmK5C8Rf
xBhxlRgrXhd3iHliIWcf8X5C/EusFBNEPu9pogB18oIopMXXjFpGLbHMqGucLpYbrY02YpPRzrhO
bDE6GV3EdqOb0U34xs1GT1Fq9DFuF7uNAcZkUWY8yzvPeI53LWMq79rGa8brRh3jI2OJUc880zzb
OMM8xzzPONtsYbYwzjUvMlsa55mXmq2M883LzcuN35t/NK82LjDbmG2Mi8325rXGH8zrzY5GK7Oz
2dm4wuxmdjP+aPY0bzWuNHuZvYyrzd7m7UZr8y5zoPEn817zUeMG8zHzcaOXOc6caPQxJ5vPGP3N
GeY/jIHmHHOx8ZD5mbnSmGTmm5uMV81t5nZjjllqfme8a+4yy433zf1mhbHQ1FIYH0tTSmORVDJu
LJZVZJbxpcyW2cY3MkfmGUtlA9nQWCkbyyZGvmwmTzGS8lfydKNAniHPMNbJs+TZxnp5jjzX2Chb
yN8bW+SF8iKjUF4sLza2yUvkJUaxbCVbGdtlG9nOKJHXyY5Gqewkexh7ZB/Z10jJu+Q9ppBD5VDT
lsPlcFPJiXKS6chZcpbpyrfl22ZMviffMz05Vy4y4/JrucrMlRvldrOhLJPa/JUVsTLMc61sq7l5
sXWhdaHZwepvPWpeb42y3jFvs963FpoTra+sJebz1jJri/mCVWRp8+2IG3HNLyNexDO/imRGssyv
I8sjq82lkW8j6838yKbIJrMgsjWy1VwbKYpsM9dFtke+MzdEdkV2mYWRvZFysyiyP7Lf3B6piFSY
JZGDdsTcYSs7wyyzM+1MM2Vn2dVNbefadaW0G9i/ka79W/u3so59nn2FrGu3szvIM+yb7AfkufZD
9iOyi/2YPVp2s8fZ4+Qt9hP2BNnDftp+Wt5qT7Kfk3+2X7BfkH3s6fZ02dd+2X5Z3m7PtOfIO+x3
7QXyXvtD+xM5wv7U/kw+aH9hr5AP26vsfDnBTtpJ+ZS91l4nn7YL7WI5yd5pV8opSihTvqqUqi9f
V03VOfKf6nx1oVyuLlYXy3x1qbpCrlZXqbZyrWqv2stN6jp1ndysrlfXyy2qk+omt6oeqqcsUb1V
b+mrv6p7ZakarIbLg+o+db9lqkfUo5alRqnRlq3GqcmWo55Vz1pZ6jn1nFVNTVXTrGw1Q82wctRM
Nd+qoRapL6zmaqlaaZ2h1qhd1m/VHnXAaqMqlbauc5o6Ta2OTnPnVOtG59fOGVYX5xznHKurc77T
wurmXOBcaN3sXOxcbPVw/uhcZfV0WjutrV5OW6ed9RfnWqeDdZtzo3Oj1dfp4fSybnfucPpZdzuD
ncHWQGeYM8y6x7nPecC613nUecwa4ox2xljDnXHOOOs+Z4IzwbrfmehMsR5wXnX+Zo10ZjozrVHO
LGeWNdrZ5ey2xjh7nb3WWGefs88aF4X4rPFRK2pZE6Iq6lpPRr1oDWtStGa0pjU9Wita15oRrR+t
b/3NvdbtZL3mdne7W/9we7o9rbfcv7i9rTnuX92/Wu+4fd3brXfdO907rffdge5Aa6472B1szXOH
uiOs+e6j7hvWh+5H7ufWFneF+63lu2vdLVaZuz+WZ6VijWLjI/VjE2IvRsbG3o0tjEyNLYntirzq
KS838m/vNO+ySIHX0ftLZJ/3V+9OO+rd5fW3q3gDvXvtLG+wN9iu7g31HrZzvJHeWLu+N94bbzfz
JnhP2c29id4L9mneS95L9rneDO8N+zzvTe9t+2LvPW++fbn3gfeBfbX3ofeh3dr72PvcbuN96S2z
O3gJL2F38VZ6+fZNXtJbZ3f3Nnjf2X/2dnv77IHeAa/SHuql4sIeETfjpv1A3Irb9oNxJx63H4ln
xnPsMfHceK79ZDwvXtt+Kl433tieFG8ab2pPjY+Ij7Cnxe+PP2y/EB8Zf9x+Of5E/El7Zvzp+ER7
VvyZ+DP27PiU+BT7H/Hn4y/ab8Wnx1+138swMzLsBRlZGTXsLzJqZdSxl2SUZxywlwnTJX4Xwruk
6jWiuagvfqGXnqc36a3iTF1Ees1xS6T0FP0m71I9irNrdGfqLCZVlL5epIs5bkiflR1TP7harPfw
/p9r6jj97AZPnXC8Q8AHR+WspYecoJcffaG8KLdaV5D28ORdRJzzTUeP8fBsjtPnl3q99vVXtLCR
2RaeaIwn8XJodWK69c26RC/WW9Jnu47pfTso0Ov0cr1PXyWirN2posER11Mn6kzv5d7toYX/GTnr
T8Ry6OrL+mXhge/v4Q9q7wBbdJI21nIaIc5qKi4iVS+8+k/9tV6J/WA76Pbj9/+6fklP5XMkaKl/
rQfo/qSOWMfDsydVckztlP5UF2JBn+p/Mw7uQ7B6R9f6vuyXJ1gKgU4VIiNMjU3n+LT91WHbPNIq
0jl7mPku1n6N3k28X4Wsc7gL3/eut4d3aPvh0sfUL9Hb2GP+4RUPnoyGn98eWeZE406XSx511u+o
s89Prg1eZ4Xl05amV3H/HL3qBD2XH7G3zxK/O0HpN/Tfgh2tPz3pMR1df2tgHYHNHnNlxUnUZmb6
kTD17g/3s77lJOpjI/rtkLfWBvftp770ayGbvsa6HvtyTqqFUj0vZM2TtIvjtLDr5K3qOLXTDKuX
/azas8PjqoA5fvHXb06i/62HfJmuwI52/+QevP94tRn4U9jLYY+34dA7fb3eceqcwrse71OOGuUr
6c8lh97/of5Zx62fXl2sZC/stPfHBgx/7tA7YbD14Z4KrHpfmP9keLmu/kgv1InAo/9I/coj0qNF
Tfj/BtEu2CHpvAJ8w/xjufj7OhVHpMfjeaqIK0V30rPSeZtYvaU/7lUP9x9a9DPUj8I+d6WZPMh/
S78ppH7vR+v/0AojRE+9yH88ff1z/Rnr/6/02bH8feCI9Chq1xRtRBAJtUznfaDn0sLff7T/zcfP
T3HHAn7U7XVb3VO3S5eedkz9B2Cxl/Xf9Tc6cUS2KW4SD4oxpMaKccH/mRFvYLmzxHtEh/PFQnF2
+FThXLFIrBTnidVii7haFBqG6Gh0N7qLu1H0fxL9Ay0vBgYqXtxj3mb2FYPQ4/limLnG3CSGm0Vm
kXjULDa3i5GBNhejzDKzXIwxK8wKMTbQ5mJcoM3FE2jzmHhS1pP1xGTZRd4knpHd5c1iivWu9a4I
VK0WUyNZkSzxpf2O/Y74yv7AXii+ttfY34pvbG1rsSzQdGJ5oOlEvrpGtRcFgaYT69B0N4j1gaYT
GwNNJ4oCTSeKA00ntgeaTuwPNJ1IoelGGwI194RhqyfVZCMaaDqjSqDpjMxA0xlV1XQ1w6gWaDqj
eqDpjKZoul3G6ag5bbRzpBMxOjuO4xpdHc/JMG52qjrVjJ5OdaeG0cvJc2obtzl1nfpGX6eR08S4
07nIaWncjWq71RiAOhtp3Is6G20MDvSXMSTQRMbQQBMZw2JDYuON+wOlY0zyMr1cY773hveG8U9v
k/edsTjQGsbyQGsYqwOtYXwbaA1jXaA1jPWB1jA2BVrD2BZoDeO7QGsYOwOtYewJtIZREegIozLQ
EcbBQEeYZkY0I2aqjOoZNUw3Y1/GATP4m8Kq0GKM0GJMLGYiimKSeBabniJmkPMybyVeEa/jpWZi
T3ZoTzb2tIBd9wFW5YZW5WJVX5D/L5EQMbGCt4mVrSSqXi2+JboqEBvZY5uwuQaiUOxkx+/i3VDs
FuWikdjHu7HYLw6KJiKFRVYNLbJOaJEytEgvtEgPi+wjMs2+2KUX2mUWdlkgcsy15lpRzVxnbhA1
zI3mRpFrbsJea4f2Wiu019zQXquH9poX2ms1U5taVJOE/yIbqzU58hLVsV1Fmpsvasoodpwd2nEt
7LiLaCpvwpqbYc3dSd+MTTcLbboONl0gDGuttUWY1larUNhWkeWLmFVq7RF1rb1WmahilVuVop51
EOtvElp/g9D664TWXye0/jqh9dfB+i8V2aqVaiVi6jJ1mbDU5eyHCPvhKnKuVleT01q1Fkq1UW2E
o9qyTxqxT66hbnt2SzTcLbHgCYiIqxvYMxnsmc6igeqibhJVVFfVVTRR3dhFVcNdVDXcRQa76K/U
6qPupEw/dRc5d6u7han6qwH0MlANpOV72GkxdtoQag1VQ8kfpoZRfjh7Lx7uPSN4nkKZkeox+h2l
RnN1nBpHzng1nlpPqCco86SaSM4kNYmRTFaTyWF/CjfYn7QzVU2l1jQ1jfzpajrtzFAzKDlTzSTn
DTWLum+qN1mH2eptVuYdNZdxzlPzWJP5aj6jWqQWM9pP1Re0uVRhmWqFwibVKpWktTVqnaiv1qtN
rMlmVURf21SxaKi2qxJWcofyRWNVqkrp8Tu1izHvUXsouVft5WqZKiO/XJUzkn1qP+0fUAdouUJV
0HKlqhTV1EF1kN5TKkVdrXTw+6pORNQJ2IQjbMIRNuEIm3CETTjCJhxhE46wCUfYRBiwyaMcRzoj
hRlwirACThFGwCnCg1OGchzmjhCZAbMICbOsFF5sVSxfxGOrY7tEZsAyQgYsI2rCMptENW+zt1lk
e1u8LSLubfW2ihyv0CvkapFXJHK9bd42Udsr9naQ9j2f8qVeKWW+876jzG5vN+k93l6R55V5ZZQp
9/ZR5oB3gKsVXqWIeSlPi9x4IK2rBfzF0YpbHCNxW2TBYo6oEY/GXVE9HovHKOnF46I2vFaNnOx4
jsgL2E3kwG55HGvFa1OmbryeyI7Xj9ennQbxhqQbxRtRvnG8MWm4j3y4j5zn41PpZVr8BWq9GH+R
lqfHZ9Dmy/FXRfWADYUM2FBkBmwoMmGsf6TZcDxvGbJhBDacTHoKPChDHrRhwTdIzxLvc5wrsDbY
8CPSn8CBUiyGByU8uALGXAm/yvD5vRPyoAx5sHrIgzkhD7ohD9YIeTA35MGaIQ/mhTzoGVWMKiJu
dDI6cexj9OV4h3EXx/5Gf46jjFEiDku2F2bIklFYsifHgCVjIUtGQ5bMCDkx2ywxS0TVkAezQh6s
Zh40D4oqIQNmSktaIgvuc0i70hVVZSfZSdSWncN/yRZwX52Q++rJrrIr+d3Cf90W8GCdkAfryVtk
D1Hrex4sFBIG3CMcuK9SuCHr5YWslxM8tWV//kH9gd17ibpEyJDjHHUFHGfBcVeTDthNhuxmh+yW
q9qpduQE7CbVtepajtepDpQMOM4K2S0nZDc3ZLc82K278NQt6haOPVQPyt+qbuXYS/XiGDCdEzKd
m2a6/qo/OQNgOjvkOEcNUoOoO1gNpvxhphtB+hDHPaAeJB0wnRMynQyZzlVj1BhqPa7GkhOwnhOy
npdmvQlqAvkB9zkh9+WFrCdD1rPU87CeTLPeC+oF0i+qF2G0l9RLlA94UIY8mHcED8qQBx14cB7p
Q9y3QH1MepH6hmPAfQ7clyQdsF71kPVyQtZzQ9arEbJebsh6NUPWywtZz1O71W5qBdyXE3Jfbsh9
eWnuq4TjZMhxnmM4hpCH2Mq91x0kou4QdwjHYe4wEXNHwE0x9373fnIedh8W0ZCnzNiE2DPCDBkn
29sB12R6O71dIivkl8yQWbJhlnLS+7z9ogqckmKfB5xSNS7jUlSBTZTICHkkK+SRbBgki3TAINXi
NeI1KBNwR3a8TrwO+fXS3NGAFgLuyAq5IzPkjqohd2TBHc/T5rT4NGpNj0+n/AxYIytkDVOYZ38X
PHk9b+ul54qrRMcfi/P//3jpIr0tQPps/fF0V/CcJ3zW91Pb3hw84QqV90fh+ZrDfYbHb9LqsyTQ
n6EWTeqNuvDoJzon7vfwEzp9508f4S/70lejPIPPH9Xex9QoQml/9vOfy3zfTskPz/TO8JjORyvu
YWU3ah98/2TvCCWafUTtJKXyRfDcowap9BPGw+r6f+nlfj+aI/v1xI1h3vbjPV3Qxcc+m9O79Aa9
mivH/BXi574OPyU/+izYP2mrPuJ5AWOX36dLfuwu63XHPtX8pV7H/wvOCWvN0C+Gn5Xh0/DPAwTP
h/RrpL5IlzlsWcEO3quXHM7/Sf1sDm104/+cB0/BdMERJR4PnwcFz8rXhanNjOZIhkqv78ne3/Cp
9cYTl/vpLyztiHZ1ma4EB4JnXfrgUeX+09+l/h97/S/v+ZN46ef+i8rXHKe9jaI5Nlj3v2j1P7+a
i5BbAz4NOfW4L7jhpP+G+N/7ih+0d9Sojtx7J1n/Lb1Qz/4/zF0PXBRl/n5ndmd2FoY/IikgkhEi
KhEiIiEYGpGZZ56ZeWbuAgsZyrLsLiarzO6SmHmemZmZ55mZ55l55pmZmT/zPDMzz0zNzDND89TM
PPPMzDzn97zfXQjT8u/VDZ/32Xe/8/6b2Znv+3znz0Pw/kC0/ry+hqyf8dm9+ex9VfxhF3xjA/GH
Q8RNyJvxOUlvwOfLwVLH6H7bJqS38Xfo/CvX5MliWeO12fWYC97VP0CaDWtffbv+Htl3BFgE3dH+
zZWP9IKRf37eN5pD9b80s5TrL+oV+hP8Kr/ubLL2gG0lP+8uvOvI+D3XC++FHtHXYlt2X78ztfF4
4PMYPFgjL3yXBe/PNh8D/HLTvRF+j+USLf/9eo3xahfspTD6fIrfb75grVtff17ZwOcnmN0+40fI
VfT3IT/qiW/RfuI5zG8Nwb0G1B/Rt9Dv/Q0zXGQOC2PpF7R5DOfBl8G7SwZ4jsa7Tt8E1l77/Pb9
fejz71c2shTOvWjePoC/Yxdwz0+Je17kbMfZfJ1918WWH/iz7ResP/tDS9BedXE7u5L76Fe86GVX
WCHwjMVEvZ4+/0Ue4FWekFuorwjkaF0jP6P7nfil3riK0S3TV8Jjvhb8tl5fxPjzQa/zPBI8J7zY
eniJRhb8L3jf94J+InD/LPyCNt/RX9PfCrYZzb8F7ed5B12/8tFSPZyl+sdN3xpjl3081xhXBpg4
ebR3+fEReEYkeP6cII/8kD6Avr3F+N08B9KjyE3VZ2KuezTYSrNnW7AH3tQ9VzHaIr1Wn6dXILcO
Z/U8/WHyD7/DbDQP+/ktfbY+AnPrv/g9QNqyVfoSfW6g5+CsEaev+0Gbh/SdiCoDZ263plyQd+rf
BtLlM+bz2j5J53vTU0Hnz1I0TzdFvsR8G+i5h+ZPXKSd/8TKz7WcfxeXnmD68tIjoS264Pmrn2M5
P5LlexXH8L8v5T/p17luke6VLM35B84GHmV9hM8fudPdVPLItY9X/4M+Th+vP0v593G8v8CflAnO
QwG++LW+HGnNtfVDLaUHnmS5pjY+0w9iJqT5Eb/pQRyHTZw78Kvrx8E5jl+MAV5xX1fBuZvVfi/w
q2Is3A/+Pfjt0+D5Exz1L3M+X2zRy/RSfbW+gon0rVYfDW9tDTAC/XX9NL5N1qv02/Sb4Ucz9Uf1
R66hrwB/bHdN4w36pEBM2/S84Qvnr72eiz7/OrTBj96dAa8OfnvBr0/r9+vbvp+Ff9kFo/kHzjm6
5oljmEeKTZFKgOli7TtIP/Ks6s+9YLxTmp+54Ferfsnx/PiCs83NuVPgSVfdBXa0A2dfYN1bhP/Q
39Af1J9A7kl9T8B2lX29c+3jvcIeTzZ/zut/d2niuCeu/enKiz3rfj2XADsE//4nZr3rcMXiUs8o
/2Tdyzyi9Ffo2v4XV99TsyX2urRyWQu40DUzV/2p6zGSS/QR9HRgt9d8Xf46/UqX6uUzMNv/8ply
/RawnpPXbc9EXcM4rsf5/jPej7iaoxG8Z3+gZvDNjsbrIlvoPsOWn6xsD5ZdeuX9/tzL1bwDcUEb
P3o35Cfq0NV6fqUoEAkHrug03QsO+an4mK7txrIKJl95v1T/Kt7y0g/R3PH9u2SN1+QuN7YLZXdd
ea+/6NLqaite+Z0nxp9q4PelmyJ7/U3CL+GfL3k34n9tAe//+sffmWhW7vR/fyyXt1yeh7zaWf2i
70pdsi96guD7dwfpjkXTkRVy0UqNZfm1qnj2IM65X2A5n7sHvAaip0v4WboT8wtc79O/uo5t7WPB
K8oXfeOoI73lxO+gv3+RtZdqm79Hta+xZmOOrvDvC1oa++xBff1gXM2+Pf59m41j4e9rXTAq/lZW
F36X5mqidn22vkBf1fQeWDDHGUHwmub7TePocsF4F1x5f+fVv4onhfRtdFdiU9N3egYIfFO+7Dt9
l/H23o/0fdF3ky9R5yBdteIzOfkC+rYe517AM4T8FL+kGSWC9by89zUvUv9qnn/Yzt+3pHQq8J0w
eNX8p71DcFviz3/eCMfXV/oHlGaz1uCknwfvJjUEzmk61sqvfKSX2I7AHbZm0bpu1R/V/6TPId2A
pmd69Hv0ZVfY8vqfhzHzMf54P/q5i91VDtxR/IHtq0vfxbnahZ6RCXpm/QT4xAnwo1367u89kX4U
Nn7POFsfTN9fxRGwU39If5t/19/Sp+sb+BVzWvf0eW1/0mi/ohHdq1fofr1v8BvlcAQ+TPkF+ou6
E8fBbLC1VZh5eYkV+mv68uCsza/Ot2LpdM95jD6KbIHnEeeAV/+B/x5cJaHpKaDzrgXp3za+zX9F
431Ofwmx2qzgty3U92zy81toH/C7r0v1k/pfqUDgrf3gEwbBo7jblff6Sy3/lbexL+xlX6PHCtx3
/qWWq7lPhV/6S9bsqkOTQsLlzD0tGX9+5z7Kx7NMxJ7tqO4/wTr+SbNJG9ZV/xBnKP/7RN+r34bz
5WGm6oF5PRin4uwMxFStg9+XBe9UiKzpjWmyL/6J7aBnK3QP5rngFUi9l25BukcvYy31wBzcqKFR
i3Sn3kO/Xw++2aBv1PfQ0xL8jD2COWlfMH7tzFJo5uxMpX766sbFx/WC/iLwpabvq3gsd96TFYOC
mQfZQJbNMkgnpj2tab7tIee26aHnvqGZcrU+Un+Vz2G6pj/Gc2h10nndBp4BG3kV4x2lV2L7K+mL
gtwo8puP0Uz9AX7LQ+cCb9K/TqogjQvtWd0VbOMyYryL9v35pctcUOcoPRHAeQIdTXQ0r8d3I61W
f5Lv8FoRLBejF9n2S+jYDQ3q2NWxuwVRuIHZSJ1uDKnTTSR1uknCUOEhNlV4RHiETSddumeEamES
mylMFp5lS7g6HVvF1enYm1ydjq3m6nTs/4S/Cu+zt8R0sQvbImaKWWwrV6dj28XbxdvZDq5Oxz4U
7xbvYR+JTtHFdotjxBq2R5wqPs32ivPF+Wy/+CdxCftMXCG+zr4Q3xDfYF+Kq8U17Ji4XnybfSW+
K77L/i3+XdzCTopbxQ/YKXG7uJ2dFneKO9m3BtUQxs4YIg1R7CxXmGM6KcwxUpiTDEmGJMFECnMK
qcqFGrIMWUIYqcqFk6pcJKnKRZGeXEvDUMODQrRhuMEitOLvygkxXPVNiOOqb0Ka8XXjGmEoV30T
irnSm1DKld6EMilSaiE8LEVLscIjXO9NqJT2SPuE0VzvTRjH9d6EWq73Jmhc703wcb03YYL0tfSd
8DjXeBOmcI034Vmu8SY8zzXehLlc402YzzXehJe5xpuwhmu8CW9xjTdhq/yQPEH4iKu7iQJXdxON
XN1NlLi6m2ji6m6iIs+VXxTDua6bGMV13cSWXNdNjOe6buLNXNdN7CC/K+8SO3JFN/E2rugm5siH
5C/EXK7oJvbiim7ir7iimziAK7qJ5VzRTazh78eJmiIqouhVZMUk+pRQJVSsUyKUSPExJVqJFuuV
GCVWnKC0VdqKE5WblETxCa64Jv6WK66Jk7nimvik0kXpIj7FddfEaVx3TXya666Jzyj5Si/xWa67
Jj7HddfE2Vx3TfwD110Tn+e6a+I8pUx5WHyR666Jf1TciltcyNXXxJe4+pq4iKuviS8rTyhPiEuU
ycpk8RXlSWWquJSrr4nLuPqa+CpXXxPf4Opr4pvKq8oacbWyVtkublR2Kh+Je5SPlX+Ie5VPlEPi
PuVz5d/iUa7KJn7DVdnE04puFsRvuSqbeJarson/4apsBsEca04whHE9NkNLc6I5xRBt7mxOM7Qx
Z5gzDDeau5m7GdqZu5t7GG4y55l7G5LNBeYCQ6q50NzHcIu5r/keQ7r5V+Z7DRnmB8xDDN3MdrPT
0D2kXUiSIZeruxl6cXU3w91crc3Ql6u1GRxcrc1Qw9XaDH6u1mZ4InRQaInhZf7WnuFNrtZm+Jtq
UiMMm7lOm+FD9UF1hOE412kznOM6bUYj12kzmrhOmzGE67QZQ7lOm/EGrtNmjOc6bca2XKfN2I7r
tBk7q/PVl42pXKfNmMl12ow5XKfNeDvXaTPmc502Yy+u02a8m+u0GQdwnTbjr7lOm3GQuk/dbxzK
VdaMw7jKmvEhrrJmLOYqa8YRXGXNOJKrrBkrwsVwxWgPV8PDjdXhUeHRxjFcWc04Nvyb8G+MWgSL
EIxeJgr74fXCEfFFsEgmsBb4M7AozMNGFoO5W8Ks3h72ZPyZWAfMggpLhZc0wx/2YCr8If8/Dz3p
P2BwjxlOHjMCHnMwaj2Avxbwmw+hxeGshOUzG3xoL/hQJ5iDC3+9mZuNYTewGvy1Yh6moWcvPGwM
PKzKYoUwIZzF0RvCbYRI+Nxb4HM7wJIipLB0oaPQCfbOQmfkU+GLY8kXd4Evvhc4AB75TtILjRUe
gl/OIL+cQX65K/zyONhrhcdZpjBRmIg2n4CnbgNP/STLEqYKz7Duwgx47S7ktbuQ1+5CXjsdXvsl
5BfBd6fDd7+N+WCDsIH1EN4R3mO5wmZ48zzy5iK8eSawG3y6TD49kny6SD49knx6NPn0O8in30o+
PZt8ejx8+kvsRnGRuIi1FV8W/8xuEpfAyyeSl08kL98OXn418P/g6xPI1yeRr28LX/934BZ4/Hbw
+FuBH8DvJ5DfTyC/fzP8vsraG8Lg/ZPJ+6eQ9+8A7x/DOhliDbGssyHOEMcK+EyAPGYC1hEzQQdg
iqEjamE+YKl8PkCtHEMOsIehB9bmGfKAPQ09UQZzAxBzAyz8Xeu76F3rPvR+9V30fnUfeqe6EPOE
l/U0+oyPMwGzxVQWYXzKOIPdZnzWOJO1ND5nnMNyjM8bX2CtjfOMf2axxiXG11gcZpTXWQZXE2WZ
fF5huXxeYSqfV4CRUiTrJbWQWrAufHZhGZhddjCD9KH0IWsn7ZR2sgjpI+kjZpR2SR8zCbPOHlg+
kT6BZa+0l5mkT6VPmSI1SA3sBmmftI+F8jmJhfE5CSUPS4dZC+lz6XMWhZnpCyZIR6Uv0eMx6V+s
pXRcOs5a87kKPX4tfc1ipFPSKZYnfSN9g7Gdlk5jPN9K3yJ/RjqD/HfSd6yn9B/pP2j5nCyylrJB
NrKesiRLTMAMZ2KYLGSFhclmOYRFyKFyKDPIqqyyGDlMDmN5crgcjjKYBfl/dZdbom60fAPqxsix
KB8nt2FRcrzcFi0nyAmMK6DeBEyUE9HCzfLNKJ8kJ6F8ezkF5TvKHVlruZPcCfbOcmdmlFPlVBYu
3yKnof1b5VtRN11OR2td5C4okyFnoG5XuStT+YyLvrrL3WHPlnNQsofcAy3kyvlMknvJd6JkoVzI
TPJd8l0Y873yr7FdA+X70f5DshW9F8nF6KVELkM7D8sjWb48Sq5kvWSH7EaP1fJo1lt+VIb3kGtk
D2slj5XHYrTjZA3b4pV9aMcv+9FCnVyHFh6TH2Oh8nh5PHqpl+tRZoI8Ab2AAbA2nAGwdDCAp1im
PE2exrpyHsBiwQOexdqZ8kwWJz8nww/Iv5d/z3Ll2fJs7O258lzgC/I8lsE1YFEeXAEtvCy/DFws
4yiVl8hLUPcVeSm7U/6L/Be0vEx+FWtXyCtQ93X5ddhXyqtQ8k15NUq+Ja/F2r/K61gWGMYG2N+R
32Fp4BnvovwmeRMs78nvoeRm+X2U3CpvxXg+kLehzHZ5O0a4Q/4QY94p72S3yB/JH7Hu8i55F+qC
o6DWXnkvWv5U/hS1DsmH0Nph+QjKfyF/gfJfyV+jzCn5FPbGN/I3GNtp+SyL5TyGdQWPCUM+3NSC
ZZqiTC1ZG1O0qTXLMsWY4ll3U1tTO9YFLKcDyzWlmDqyu02dTJ1ZD1OqKRWWW0y3sjxTuikdLXQx
dUHJDFMGynQ1dcXaTBNiR3Cj21g3U44pB331MPVA+VxTLtbmmfLQF9cUEDhnYhmcMwHBmYDgTEBw
JiA4ExCcCQjOBARnYnGcM7E2nDMBwZnYLZwzIQ/OxHI5Z2KxXKuWpSm9lF6oBeYEC5gTyoA5AcGc
WBZnTqw7mBMiAeVh5WGWB/5UySIUh1KFMmBRqAsWBTtYFEr6FB/a8St+5OuUOtjBqDAeMCqUf1J5
kmUqU5WpqAVexbqCV82A5VkFR50yU/k98n9S/oS+FioL2d2cacECpsVCONMCgmkBwbSAYFrAz5Wv
2O3KCeUEevm38m+0A9bF0jnrQl5XdP6/t8yM3WkWzAKL5QyMtQEDMwEVs8K6mbGwdHOIOQR51RwO
jDBj/jVHmiNZlrmFOQqWluaWLNccbY5mXc03mG9geeZW5tawx5pjWaY5zhzHbjG3MbdBPt4cj17a
mttibYI5ARZwO+TB7TAScDsguB0Q3A4IbgcEtwOC2wHB7YDgdkBwOyC4HRDcjoVwbsduB7e7j0WG
DAoZxOSQ+0PuR35wyGDkHwh5APkhIUNZNGd+sDweMp+JIX8MWYw8+B/y4H8oA/6HMt+GCkwMFUPj
2B2cBbLsgHYDZ4FM5CwQCBYIfFB9kLVVh6nDWDv1IfUh1kIdrg5nN6oW1cJuVq2qlSWqRWoRM6jF
ainyZWoZyj+sPowyI9QRKDNSHYn8KLWCJal21Y4ylaoDZZyqE2tdqpslgFk+CvsYdQzs4JfAceo4
YK2qsXjVq/rYTapfrUPJx9THUHK8Wo8eJ6q/hWWyOgUtg4Oil2nqNODT6nSUmaE+izHPVGeinefU
Wcj/Xv09ys9WZyP/B/UPaHOOOgdrn1efZx3Uuepc1pEzV5YC5jqfdVb/qP6RFagL1JeQX6QuQpmX
1Zex9hX1FeBS9S8sVV2mLsPaV9XlWPu6upJ1Ut9QV8HypvomLOC7QPBd4F/Vday9+jd1Pcq8rW5g
yeo76jsouVHdiF42q+/DslXdhjbBhtH+TnUn8CN1F8rsVv+BtXvUPWjnE3Uv8p+qn7JMsOR9aG2/
up914FyZJYAr17H4sMfCxrPEsPow7CXw5oksNeyJMOyrsMlhk9mNYb8L+x0sT4VNY53Dng57mhVw
Pg0L+DRL5XyaRXM+zUTOp4Hg00DwaRbN+TTLALPLJz5dSHxaJCYd4M2NjJnz43Dix+HsN/gLJ2bc
h5hxX2LGUcSM+xEzbkXMuDUx4xhixrHN9Hsk0u9RSL9HIv0eifR7Qki/RyL9Hon0e8JIv0ci/R6J
9Hsk0u+JIP0eifR7Iki/RyL9nrtJv+ce0u9pSfo9vyL9nv6k33Mv6fcMIP2eODD1UPDmMCGMOHos
6ybECXHg0JypZ4Op38tyiIvfJ9wv/AZ2zsV7CGVCGRh2tVANHC14wJvHgZF3ByOfyPLAxZ9A/rfC
b1GeM/LuYOTPsnxw8dmsF1j4cuBrwmust7BCeAtrOQt/gFj4HcTCC4iF3wkWns4MxMINzfi3Afz7
DuLfd4N/30MsnCsMGUlhqAUpDLUghaEbSGGoBXH0XxNHv018QpzEenJlfzYoyNQ5L+8sviK+wjqK
K8HLbyZG3p4YeQfxPfE98G/OxW8St4nbYP8Q/PsmUi1qK34sfgJG/qn4KZArGKWSqlsn8YD4T1gO
iYeAXNstgZSNksQvxWPIc32jZPEr8QTyXOUoRfxOPIs81zq6UTwn6iyBFI8SDYJBRJ7rHiUbJIOE
PFc/SiT1oyRDqCEUlgiw/zTi/RnE+zOJ9w80tDHEw87Zf5rhZrD/Ww3JYP9pxP7TDZ0MnZBPNaQC
uxi6sq6IBLojn23IZrcYbkM8kEbxQBdDLuKBNMPthtvRPo8H0igSuJ8igcEUCdxPkcBgigEKwf5n
sHDw/jksihh/DDH+NsT4s40rwPh7gPGvZ3nGt42bWW/i/QXNNJkk0mSKIE2mlqTJNIAigb4UCfQi
faZ7KB7IQTywnckUA5ikjxEDyBQDmCgGCCf2byL2HyMdkA6A5R+UDsHCeb9MjL81Mf6+xPijiPHH
EOOPlU5KJ4Gc0xcSpzcRp48iTl9InF6UZXB6E7F5E7H5WGLthcTXTcTUo4ipxxI7LyRebiJeHkO8
vBBcHHGvnAZGLhMXjyIuXhhk4ZlyJspnyVkoz7l4IbHwAOc2Ec82EbfuQ9y6L3HrKOLW/YhbtyJu
3Zq4dQxx61hiz7HyZHkyOOXv5N+BTXL2nEOMOVeeIc+AnTPmbsSYe8lz5DngkZwrZ8nzwJVziSu3
Ia6cJy+QF4HHvwyW3IZY8n3Ej/Pk5fJy1OIsOYtY8n1gyStR9w1w5TbElbOJK+fJf5PXo4W35bdR
nnPlLGLJbYglZxNLziOWXCBvA0vOJZbci1hyFrHkPGLJ+cSS7ySW3E3+RP4Eazk/DjDjbvJR+Tgs
nB9nEz/OIX58n3xOPgeGyplxLjHjPDDj1shzTpxPnLiX6SZTe9abmHEBMeMHiBnfQTy4F/HgB4gH
FxAPbmPqbuoO5Az4TmLABabbTbejTa4oFkFaYhJpiUWQilgEqYhJpCIWQipi/UlFTCIVMck00DQQ
vXMtMYm0xCJIReweUhFrSSpiA0hFLI5UxOJIRUwiFTGJVMQkUhGLIBWxls1UxCJIRSyEVMQiSEUs
jlTEJFIRiyAVMamZiphEKmIRpCImkYpYS1IRiyMVMYlUxCJIRSyumYqYRCpiEaQiNoBUxCTSD5Oa
6YdJpB8WRvphEaQfJpF+2IBm+mES6YdFkH6YRPphEaQfJpF+mET6YRGkHyaRftjdpB92D+mHtST9
sF+Rflh/0g+7l/TDBpB+WBzph0mkH3YP6Yf1J/2wAc30wyTSD4sj/TAJMUxLloOIpT3rRfFJb6WD
0gGxQYqSAq7fWenMspVU5RbEG2lKGuzpSnowbslSMpSu7E6KXrKULCUbyGOYAqWH0gPt8Bimt1Ko
3AXso9yD1vopv0KZ/kp/1k25F5FMnjJAGYgI4QHlAazl8Uy+YlEsGE+xUoxaASVGHuEUIMIpR188
wglXqhQn2nEpLtSqVqrZHcqjyqOw1CpebAWPc3IotmlDyo1ZFOHkKlOUKUAe59xJcU6u8owCL0Fx
ThZFOHnK88rzsLyovIjeebRTQNHOA8pLyiLU4jFPnvJn5c8o84qyFPgqIp9QZa/yGfCfiHlCKea5
i2Ke3spJ5SRa5jFPjvKd8h22jsc8oRTz3EcxTy+KeXIp2smiaCeHop0scxginFxEOC1YPkU4BRTh
3EERzp2IcFohCmptjkHJWEQ42RTbtKF4pjfimQ7opRPimVDEM5nALHMOMA8xTCjFMKGIYe4F8ugl
lKKXUIpe7kL0MigYsfBYZQjikKEUsQwLGQZLSUgJ6xlSHlIOHBUyCmgPsQMdIQ6gO8QN5Fp0LUiL
rgVp0d1AWnQ3kBZdC9Kia0GRj4Fim1+HtglNZLeF9g39NesZagv1sEGkVGekaMeICKczoggew3Sm
GKajWooY5ib1EbUcTJ3HLTdRxNIZEUsl8g61CpHDaHU0LDxWuVkdq46FpVb1Ikrh8Ul7ik86U3zS
EfHJJFh+iyilI0UpHdQn1SdRnscnndVn1BlY+yzikw6IT55Dazw+aU/xSSAyuZkikzT1BfUF4Ivq
i0AemWRSZDJQfQmRSRdEJoth/7O6hKVTZNKFIpOuFJlkIjJ5FZbl6mvsFnWFugIl31DfgJ3HJ7eq
qxGfpKlr1DVYux6RSTrFJJkUkwxUN6nvYe1mdQvsPDLpqm5Xt6Mkj0ky1Y/V3bD/AzFJV8Qkn6C1
vYhMEigySVcb1Ab0y+OTDIpPblU/U8HxSB0wlfRIO6lH1KOwcKXARPWYehx5rheYTHqBiaQXmEp6
gYmkF3gj6ZEmqP9R/wPk2oGpqq6CAZKCYBKIORgg6QjeSNqkCaQm2Ja0SRNIUzCZNAVTSZu0U1h4
WATsXF8wOaxlWEtYuMpgCqkM3hgWExaHtVxrMJW0BpNJazCFtAaTwhLDErGWKw4mk+JgIikOJoWV
h5WzmygSa49IzE+RGI6HsMfDHkeENhHRV3uKvrpS3DUQcdczyM8Im8nSKfrqGjYrbBbyXLkwmZQL
25JyYSopF6aQcmEyKRcamdDmRLwP5Fc1TGKfMmYdimRFKkMaheREGtP0KTgW4VNDGo80CWkq0gyk
2UjzkBYiLUFajrQKaS3SBqTNSNuQdiHtZaJvEyVmPUBJ9G1F2on8EaTjSKeQzjJWJCIpSOFI0Uhx
SO0CYyhK/pHP1EBbRRnBxOtkI/WkdayoAKlvYLxUZ15gG4sGIA1GGhawBz9F3x5KgmMp0grk9zfZ
Aukw0rFgfifSyWD+TCD5WTDJSCpSFFIMUkKgrD+JyrOiYqQRgf1UZG/a54GynagcK3IjeZB8SBOC
2zA50J8/Pbit05BmIs0Jrp8fXJ8VTLmw4Xcs4tuzGmld07YEtnkF0mqkdUgbkbYg7UDajdSAdDD4
ebTZZ2P5E0ing5+7g/VON1t/jrFiI1IIUiRSK6T47z/571eciJRy2Z+iv/f3vxXftuK04G99pSnu
/ETH96RAP3RcxQXKUb/NUyZSzvefTW0E2hX9fWDPRyoMHn9YV9zv+8/igUhDjC2GN1T0rd1qHV/J
CGVCFTipMgo4tTIGOKMyATi7Mgk4r7JT7VZeyzvMurAy3Vs8/GDFgNqdw49WDK7dY11SmUWY25Rf
Xtm7dg9f6x0x/ETFsNr91lWVfWr3B/JBPF1RXHvYurayP+Eg4AbKb6D85sqhwG2VVuCuyjLg3spR
tYd5La8dOAL5cxX22mPWA5VO4JHKMcDjlVrtMW73ui3GCnftSeupyvHAs5WTvB5LSIWn9kyRWDmV
cAbhbKBSVAAMr5wHjK5cCIyrXAJsV7m89gyv5fUVJVeu0mZbIit8GvZs5VqNWVpVTNBkjt4JlviK
yZpalFG5AZhduVlTucU7OWAPYmLFNC3KklIxU4sp6lm5rQkLKndpMdzunRbEtIo5WkJR38q9hAeA
Ayg/uPIIcFjlcWBx5SngiMqzTWh3iN6ZRW6H4p1jyayYryUVeRzhWhK11ilo8TmiG5FbvPMtORWL
tPSiCY44wnaNeW73LrLkVyzVsoomO5K1LJ73LrXkO1KRL6xYoeUWTXNkEGY35Wc6egLnOAqA8x19
gYscA4BLHYMpP0zL5XW9Kyz9KlZrvS0DK9ZpfYpWOIqbcLWj2Lu6aJ1jhNbHMqRio9bfMrxiC43B
Tuhuym90eDASW8UObVDRFoevCXc4JmiDLOUVu7Whj6yt8RFOIJwM3FAzDbi5ZiZwW80c4K6a+cC9
NYu0obxWveeRAzVL630WR0WDZrWMrjiolT1ypGYF8HjNakKeP1WzTivja+snWMZVHNXkR87WbNTk
crHiaP3kAFrqKk5oo8qVmi2EO4DhlA+nfHTNbmBcTQOwXc1BYHLNUW0Ur1U/DXga+YkV5zRneWrN
CWBGzWlgdg0s3F4/0zLFbtTGlPf0cCzwhNTPsUy3h2haeV9PJMfyCZRvBRzgiQcO9iQCh3lSgMWe
NOAIT6am8Vr188vtnpz6RZZZlv3a+HK3J18bb5lrj9QmcfQnWRbYW2lTyz2eQqDP00+byi31SwP2
IC62x2szLMvsidrs8gmegU042TME5w7s9SuCuNKeos0rn+YZTmhrys/0lAPneBzA+Z7RwEWeccCl
njrgCs/E+tXlqz1TvMWWNfY0bWH5Os/0+nXU2pKgZaNnFnALR26p32hZb8/Ulpfv8MwlXNCY5/b6
LZZN9hxtVfluz2JtFc/X7yhv8Cyr323Zas/X1pYfxJ4HelY25Y961gBPeNYDT3s2Ac95tmprRxo9
O4Ehnj3aWl63vsGy016obbDssffTNo+M9Oz/AbbyHNY2W/bbB2rbLIftQ7RdI+M9xwhPNuUTPWe0
XZZj9uHa3pEpY1kTpo2Vtb2Wk3abdqBot2My4TRgA+UPOmYCjzrmAE845gNPOxYBzzmWagd4Le+6
YqNjhXej5Yy9XDtiZXaHdrw4xLEaGEnYijDesU47ztd6t1hl+2jtlFV2bOTI88WJji3ecKtqH6ed
LU5x7CDc/YN8mqMBmOk4CMxxHAXmO05oZ3kt7w5rlL3OK1pj7BO9SnGh4zSwn+MccGCVETikKsSr
WBPsU7zhxcMJbVWR3t3WJPt0b3RxeVUrwnjCRG+0NakqBXlHVRpwdFUmcFxVDrejfENxXVU+LBOr
Cr0HrZ3ss7xxxVOq+gGnVw30xlnT7XO1bRy9R4tnVQ3xnrBm2Reg/Nyq4Wghq8rGEZaGgD2IufbF
3nbW3vZlGNuCqnLgYsJlVQ7sGW4/XbyyajRmT8pb+9hXepOL11SNI6xrwvVVE4GbqqYAt1ZNB+6s
mgXcUzUXuL9qgfdc8eGqxT4j2lnjTbUmVC0D9ravB/a3b8I4j1WtBJ7kSJYG6yD7Vm9G8ZmqNecj
t/sQtlat9yaXyFWbfJHWofad3uwStWqrN5vnfa2sQ6tgsVrte2i7Ari/MV8SVXUYGFN1DJhQdRKY
VHUG2MnJgOlOGdvO6562ltn3e3taR9kPewtKspzqDzDXGeUtsDrtx7x9rWPsJ70DSno7pnF0xjRh
H2eCd4BVs5/xDi7p70wCDiIc6uwEtDrTffGck/gSS8qcWeAn4Aa+lJJRztzawyVOZ2/gGGefwAzu
S+PzoC+zRHP21xJKxjsHaQl8JvLllExyDuWzktMKxFzjyy+Z6izTskpmOEdhfsH54issme10agf4
cevrVzLPOUY7W7LQqQGXOMcHjjHfQP77+oaULHdO8iZb+zinArEffMNLVjln8H3inA0MbOla5zzg
BudC7wCacQ6OzByrYvbhnv/oyJyxUdqokfljY4CFYxOC/vkE93L1p0f2G5ukzbOsHNsJyP3MuZED
x6ZznzM2CwhPMsE4csjYXHiP4WN7a7voyG8o2exc4rOVbHMu95WX7HKu8jlK9jrX+kaXHHBuqN1T
csS5uXZ/yXHnNt84lNmFMqece311JWedB3wTbaLziG+KTXEe9023hTtP1R6z9HOe1Xrbol2ib5Yt
zqX45lqGuMK1/rZ2rmjfAkuKK8632JLmaqcl2JJdyd6NtlRXqm+ZLcOV4VsZ4Bu2bFe2b42tp6tn
7VbOKHzrbQWuAt8mW19XX/4ruAY0zuy2Aa7BhMOAgzG2rbZhrmLfTluxa4Rvj22Ey+7bb7O73L7D
NrfL4ztm87h8vpMBTlskuiaAxQV4FLEUm881GdyVeKNtgmsacLJrJlgcPzbOFBW7gLZprvl+Zpvp
WuSXbXNcS/2qbT4vaTG6VtSetC1yrfZHBZibdbZrXe1W21LXRpzjxFFtK1xbag8Xxbl21J6xrXbt
Ru8jXA3YD+tcB4EbXUe1JNsW1wlwsEWu0xjPDtc54G630TfFesodgvYb3JH+GNtBdyvfVr4H/Am2
o+74wLHtT7KdcCeindPuFC3Lds6d5u9UanRn+tMDDLM0xJ3jzyqNdOf7c/l54e9d2spdCJYOru7v
E8DSeHe/AAP392+GgwiHUi9WwrLSRPfA2sOlKe4htcdK09zDa09yRu0fVZrptgXzTsIx/Pzya8E9
CT7sH084iY/KP7U0x13unxrIE84ozXc7tKjSQvdo8GGwYv/s0n7ucQEO7J/XDBeCqbq1pNKB7jrg
EI6ctfqXBLB0uHtigKn6l5fa3FO09NJy93Qg7LA43LMCrNWX/z36V/Gz3r+WcEMAS0e754KLgpH6
N5eOcy8A8wQv9W8rrXMv1vqXTnQvAzrcK8E5t7jXgFvy32VXAEunuNf79xYnujfh7OaeObx0unsr
Zs9E907kZ7n3+A9YE9z7+YzgPuw/UjrXfcx7onSB+6T/eOli9xn/qdJl1cx/tnRltVwnBn07eW/r
0Gq1TildUx0FbzymOqYuPOAJS9dXJ9RFl26qTqqLK91aVVjXrnRndae65AAHKC6vTsdcQLNM6R7u
twNzdOn+6qy61NLD1bl1GaXH+GxberK6N2Y9eK267OKt1X3qskvPOHbU9SyeXt3fG1fGqgfVxQXn
5QXVQ73hZXK1lXOJ6jLtQJlaPYrP6dVO7WxZVPUYb3RZTLWGfvdUj/9/9r4/KorszvdW0zY9DtPD
MAxDGIYwDGEIIcYQQ3gsIcYwhKF/yBrCuoQwHbq6qrqquumf1Y20DXa3LSEsh3FdwvqM8bmuyyGG
JR6eMTxjiM9lXZZDPMT1sR4fh7gcY3gcwjOG9RmPed97q7ptkcmYs/tfcr7nc29RdevW/fH9fr7f
e61qsf/yAQcyeb4BOF/oG+zKtGz3HYt7CqbEdzJcw2z3DUPbIJY4kMGU+0a7r+LeheuZKt+4zLRd
15hdvgmop843CV4AfG64gTE5zoabsJ8KtzCNvqlwG9PsmwlzjNk3F3bgcQt7ST37GMY3H+5mRN8C
rHGAw8MxOdrBaXernMajGocU7sOpfCZ8mKRDuA3h4yQ9xbh9S10qJuBb7tIyIRyN4Miku5WJ+tbk
Y/B3kMJd4AvCI5h1wyNMr29djivCY0oKvejewwz4HoK/IMekXyPMoKTqymeOSVqIKCCuCJ9jTko6
OYqAViXS8FDbaSmzq5QZlnIgHZXyZY8P9UAavsCMS0Wylw9fYiak0q4yZlIqgxTOw5kpqUL28uEr
Seks9lPhayQdIukNZkaqBt8NHjy8yMxJNeCpwY+HbzPzUn1XPbMgNUC6JDWBFzNJLV1NZMxXSHpX
GZllqa2rglmTuK4aZl1ydDUwDyVvaIlVSfvC9wW6sy62VeA7TVGT4OxshFTqbA4NCMFOc4gRwp1M
SCP0dIqxdCjjhqv9nYFYlnCkMwRXj3ZGY7nCic7eWIFwunMAVkMnOgdDvcKZzmOx4nePdJ4MhYSz
ncOxbcL5ztHYDuFi53isEjzmROikcLlzMtIjTHdOxXYKVztnYrXy6uDd6c650IRwvXM+ZhBu7jsb
2yPc6lyI7RXudC7BOu5O53IiDl/tXIu1Cvc61+H4QefDyFkRBVUxWtQEtTFeTAvqYk4xI5gZk8Ts
YE4sKOYF82NheQXK1weLYM0lr3TImkIsDJbGeuRVnlgCZ9zi9mAZrLnA18f6+VPBili/UBysjh0R
y4M1saNiVbA+xvOluOS7/cGGUEDcFWyKnZDXWbbJYEt8PSuvMcU6sq6s52/jFV+wLfH0kSAHKVkr
iaagA1ZM8hrnEawxJ8XGzrUDVXx10Av1Nwf3xU6L5mA3rLNgBGJnRCYYU2KVw6IY7AudFN3Bw6F5
MRAcip0VQ8HjsfPyelCMBk/FLoq9wZHYZRznxKbFgeAYrKlhZR27StLr4mDwHHgNWEGDv4A0dhOn
XWRNHbuFnxK7I6fiseAF6NFJWHO5xeHgpVAAr39jq+Jo8IpyfI+kD3C8dAgpIwmr10MaJYVWHUoT
x4Ozh9LkY5JmiBPBa6FBcTJ4A1avsIY9lC1OBRflFeuhvKS0kL8SvA0jNhNcgXQOp3iN2b1XTsX5
4F15XXmoRFwI3g+Ni0vBR5DCeTizvF8trzEPbU9Ky3EUd6iKpLvkVFzbvxVWjrB+PFQnru9Ph3Ui
rCIPmcSH+7NCc3bV/lxItfsLQvN23f7iWCuel0ONJG1+t3//ttiqPXP/jtCEPWd/ZWjGnr9/J5Qs
2l8bama1Unf4EVk7EH9EuAvWLKxOikXUbKbUF9lq1kiHD2SwOdIQ9h3S8Ug6m49TOD4VyWKLpJFI
LqRjibRUOhcpYMukC5FitgLu0sprOrZauhTZxtZIVyI72HppNlLJNkjXIjvZHMyfJL3PNkk3Dqxh
tozUktTQFpYWuzLZFul2ZA/bJq1E9prLpbtdiywn3Y+0sg7pUYQmKY95MuJU1laQRiTW61dHgvI6
i93n3xoJs93+9EgPG/NnRfrZPn9u5Ah72F8A6ZC/OHIUc2bkBElPs8f92yJnIN3RpWJP+SsjZ9kR
/87IWdmnsGP+2sh59pzfELnIXvDviVxmL/n3RqbZK/7WA1WERbXsrJ8OMew1Px+5yt7wOyPX2UW/
FLlpFv3Brhr2tj/cVc2u+HtC47KHwmnkljkE3hCO/f3hfXLkZk33H4ncYe/6j0ZWzch/InKPve8/
HXnAPvKfCT9iS/1nIwWc2n8+so3b6r8YRVy6/3JUw2X5p6NpXK7/amiAK5CGohnJtXHF/uvRbG6b
/2Y0j9vhvxUt5Cr9d6Il3E7/anQ7V+u/Fy3nDP4H0SpuTwBFd3F7A5poHdcaSIuaODqQASkfyI5m
KKkzkBda4qRAYbSRCwZKImEuHNgebeZ6AuVRM9cfqIoy3JHArqjIHQ3URd3ciYApGsDzGw1xp82B
aJQ7E2iM9nK5AeB87mzAHB2Q5447H2Cig9zFgNjdz10OuKPHuOlAANKrgVD0JHcdbh3mbgZ6w5nm
ugCssLhbgUFI7wSORUe51cDJ6Dh3LzAM6QN/ZXTChgKjBxZsmsB4SGNLC0xEJ20ZgcnolC07MBUS
bXmBmeiMrTAwF52zlQTmo/O27Y6rB6ps5YGFSKWtKrAUXYCSy1ByV2AtuiQ/xVYXWI8u20yBh91X
bY0dquiaWcMVh9ZtzR3a6Lq5qkPXlW8zd2RGH9qYjpyDKpvYkX9Qa3NzwYNac2MHeGdboKP0IMRy
HWVdTbZQR8XBTFu0o/pgjq23o+Zgvm2go/5gEVvW0XBgDacHS+VVv22wo+lgme1YR8vBChy9HKzG
UcrBGryLcrBetjiyg9Gn7FQ8aR0Xlb0CsjNwsMF2sqMtUoz9+8EmvAY/2IK18WCbvDtE+OG+bVga
gvpJJGYb7eC6rrFFHY6ua8ruDdlXsY07nAc59m6H96BDXvXbJjr2HfTiue7eg1ToVWqN+r8IUb+m
1pGKekD9Bqmp36oopFFtUWnQc6rnVWnoeVW66iX0guoVVRZ6UZWjeg29pCpQvYleVhWrPopeUX1L
9S30akpdyjsoe0vtli+inC3uLR6Uu+XHW36M8nQg6MO6fJ0R5esadC3IpHtXdxB9Rfee7kcorLui
W0Hf063q1tF1aM2fIjX53w906EX0HHoJNaLnURNqQ7sRjb6BWtBfoH4URQPopyiG/gX9DE2jf6O2
ov9FpVEvoN9SL1KvUBSFv3HS4vcmqVepZoqlcikbFaNKqB7qCFVHDVHfor5M/XfqJ9RXUr6b8l1K
UnvVPsqv7laHqQ51j/obVFD9nvo9qlv9TfVfUwfU31b/DRVVj6rHqK+rz6l/QPWpf6T+ETWg/gf1
P1Lvke8xj6jn1D+lvqleUC9Sf62+rf4FdUz9S/UvqRPqX6v/nfpv+C066tSWl7e8TP3dlp9ueUQN
a7ZoCqlrmrc0b1H3NB/VbKN+rfmMppL6Df7Cg/qt5guaGpVaU6sxqjSa3ZoWlU7zNQ2tytUwGrcq
X+PThFQf13xd06/6jGZAc0z1Wc23NadV9fjLCdUezajmn1Vf0sxqZlUuzVXNvMqtuam5qerULGoW
VUHNzzXLqv34fSzVAc2vNPdUMc265pGqJxWlvqB6LzUj9RXVt1NfTX1T9TepRamfVo2lfj5VVE2m
elIPq1ZS/yr1r1LSUr+ZeizlhdTvpI6mvIz/X9WUV1O/n3o+JTd1IvXHKXn4faCUotR/SZ1P2ZF6
I/V2SkXqL1L/PeVtbZH2bEqj9lfPvZHyM91vdL9R4+/lRNQDaRrKw18b7xpToAWUoiKxre6+yNXU
vXO9ZrvoEL3ivrpFsVuM1YgNA+I58YJ4qWZCvCLOitfEG+KieNuw1VAg9hkk8fDb9W9z4pB4XDwl
johjhoK3a0Cr1KDja0THf40o6rfUb5EKNDodpcC118mbqEj1HdV3EKX6ruq7cG1M9T2Uovqh6odo
C3kTVaP6ieonSEu+BHtO9VPVNbSVvIOaRt4+fUH1M9XPkI68d/qi6peqX4J14DdLM1KoFCrxvwZv
SdGgLPLlWHZKVkoW+lBKdko2yiFvir6WUpxSjF4nX4XlpVSlVKF88g3YGyk7Uz6PCshXMYXknY2P
QPvTqAwycjhFwmUUFC4L08JV4bpwU7gl3BFWhXvCAxEJ90SNmCZmiNkEeWKhWCKsitvFcrFK3CXW
iSaxUWwWzSIjiqJbDIghMSr2igPioHhMPEkwLI6K4+KEOClOiTPinDifLPYmcUFcEpfFtYSsiw/t
Krs2SXT2THuOPR/OFj0hLfYiKFtqL7NXiA/jYq+219jrIcXSYG8T1+wclHXY2+xe+z57tz1m74M6
i+yH7UP24/ZT0H/qOVFhDfzN+ktkTLJBUlAuiBoVobfQFlQKkoo+AaJFlSDPoSqQraga5HlUg94m
b5frgXXwd5cvoj9HzSgdtYJkAO/Q6GXEgWQiD/KSLy73kW8tu8gb5RGUA3z0HnoNfRPkdfRfQfLQ
36LT6MPoOyBvoFGQAvQDkDfR/wApRD8E+Qj6n+gytG8apJj8b9gfRfPoX1EJ+t8gpejfQD6Ofg6y
Dd1Fv4K230f/D30SPQL5FKWiUtEOaitwXyV5f/xPgPvSURV5f7yayqPeQJ+j3qTeRF8g33vWABs2
kC86m1Et9VXKjL5ItVFtSE/eJTeQrzuNlEiJyES1U+1oN+WjJNRA7afCaA9wZwztBfb8Ovpz6htU
H/oKNUANoK+SrztbgUnPo3epCWoCWahJ6seIpqaof0QM9U/UPyGO+mdqBtmI/grAAsVI1JZoS1A7
eTvPqf2ktgy5yBt5Hm2lthJ5tdXaauQjXxJJ5P07v9as/Rrq0Fq0FtQJc3sbrRPdL8e/LMGPAyYA
k4ApwIyCOQXzgAX0Z/wEP8lP8TP8HD/PL/BL/DK/xq9D+lBQCVoQnZAp5Aj5QpFQKpQJFUK1UCPU
Cw1Ck9AitAmc4BC8wj6hW4gJfcJhYUg4LpwCGRHGhHPCBeGScEWYFa4JN4RF4bawItwV7guPxB5R
LW4V08UsMVcsEIvFbeIOsVLcCVIrGsQ94l6QVpEWedEpSmJQDIP0i0fEo/h/EN3StsUGTvCrulby
+wpv/6fptxHkRaLl6UTLXyJa/jLR8kyi5a8QLc8iWp5NtDyHaPlrRMtziZbnES3/MNHyfKLlBUTL
3yRaXki0/CNEy4uIlr9FtPyjaAakhOj6x4iulxJd30Z0/RNE17cTXf8k0fVPEV3/NOi6CpUT/f4M
0e//Qr1O5YHeY82uIpr9WaLZ1eT7iM8Rbd5JtPnzRJt3EW3+AmjzfrCBLqoLbAB/JfFFos11RJvr
qb+k/hLsAeu0gXwfYSTabCLa3EDNgB7voWapWfQl7Ze1X0aN2mZtM/qy1qa14e+107vTe2Ge0mDs
n0eUqxX0rgxQAagG1Cjn6gENgCZACz6nfonf4SoX5n43SJl59zW+0lXF73TtEhaeBD7H17rqhCXA
svsGBm9wmYS13w1cht/jauT3upqF9cfAf/OtLrPw0GUWVe5FnnYxovZ3g5TRuW/zvEsUM10i73S5
CSRXQMwB5Lsd5LjIvSKWuu/yQVeID7uiYtljkL8r3Pf5HlevWP0BqHE/Eus9ar7fNUBwxDXIH3Ud
Extk4GPcN7HpMUhfT7hOii2ukzgnOO0aFts+GLgcf8Y1yp91jYvck+DPuybi9SaDv+iaFB2PwV92
TT0LnK3SUX7aNcNfdc1tiuuueQwnLZ3A4G+6Fp4Jt1xL/B3X8lNYda1hOHlPP3/Ptf4scDql0/wD
10MMAblVBBq3FsMpSWdw3u7wjQhmd5uQ5tYJGe7MjXAGpbNCtjvng+AMS+dJHXnufIJCd5FQ4i59
AtvdZU+h3F3xBKrc1c+MXe4aoc5d/xRM7gah0d30FJrdLU8A9/sZIHo9WwXGzQmi27Ep4Jq4z5Mu
dnuySDm32/tMCLj3CSF391PA9cUAfZ5cIeqOPQvEw54Codfdl8CA+3AC+PoQ4LinmByf8mwTRzw7
hEH3EGnvBohjnkpyfMx9/IMgnvPsFC94ap+o46T71BMYdo88BXzvJY9BGHWPiVc8e0g+69m7WXve
F+Puc8KE+8JTmHRfEqbcV57CjHs2GeI1T2uc25O5OM6VCY674aETHLTo4ZN5JKEnyfMan5f4GN32
OBNju+KRkttEuKQHOAVs39kvc4DziGy/xK6OunOI3wB9d54AnJYuxvXZeQZyeA6+Lt71BMX7nrD4
yNNjV3v6sX+xb/Ucwedx3+zpnqP2LM8JzK/2XM9pzJP2As8Ze7HnLPYB9m2e85jbSZ9B3+07PBfj
/Gyv9Fy27/RM437baz1X8VjYDZ7rmDtxnQR7PDftez237K2eO3bas2rnPffsTs8Du+RFeHyJD8Jj
CWNoD4KfVPyZPQz+Rxlnew/U0+/V4DrItSPeNPtRbwb2OwlfmzRHiToxFJ8S9wW4Tdg32k94s0nb
Tnvz4vNMymPuh7knfhl8HunbGW8hPmc/Cz68Ugb213h8n4BB9svYXxF/DM+J+2KcE4D+kL5t8LHk
WQD7eVcIA/vYuF+Nw37RNYCR8JHYZyq+MdlXPuEjFT8Zh/0y+EGYY+L7wB/ap10TGERvsZ+7KCPB
WQD7VW8Jya97t9tvesvJeeAP+y1vlf2Od5d91Vtnv+c1kfPYhrEvwXYLdoTtyf7A2+hA3mbMRQ6N
10zsIm4HCi8S3YJ6MM850oCbFBsh8wW8he+Pc+BTtrXBrhL8Em8/1IF505HhZfCcO7K9YuJ+XB7s
zZHndTsKvQHcbkeJN+TY7o0SDsf9gT44yr29jirvALnvg/hHaZdjl8LjcRuPJZVR2kz6uoGPE/3B
PBzH+z3rffjUUafkJvcY7lMCG3kymSsxP8Y5MpkToSypB5fB12AMHI0eg/OsdNl5XprGwLENnm8S
11yUrpJzwFmOOZ/OeVm6Ho9fnNPSTUfUO0l4DOIO51XpFokpgNMco95lR8g7EY8JnNelO4TTsP/H
cQPmupvSKvbRzlvSPecd6YFj0vvQuepHznt+jfOBP82F/BkujT/blebPIzGZwpfkXhybKXETiXni
MQquS6kDX3Nl+AsxX+J2JWK7eBx27zEHE8RjGCX2wHXheMyV7S/B8Y4rz789fj8pD/0hf8N4ETuB
vrkK/eXkHI4b41DixCewMRZUYr8noIzrxrguARyLxbExrovHaJvEZq4SGR8Ym+HYKzn+wjFXPO5K
irFwW8m9uIwyJk/ZFtifo9k7+JRdmb3H4jGWg/GedIjeYcxF8XIOt3cU67Uj4B0n+hTnAVwG2xzo
H8l7vVOOAe8MOR70zjmOeecxku3NcdK7gDnCMexdIvo57l17Ko4BOCa86wSgjxjEDjFvTflUJJ/x
aeM2iG3CMe/LdCz4chL2hzloyZdPuGbZV+RY85U61n1l2PfEgfuL11jE/qDPjoe+inaVr5rUDfzR
rvXVkH4q5dt1vvr2TF9De46vqT3f14K5qL3I19Ze6uPay3yO9gqfF/s/4gMxP0FM0F7t29de4+vG
fNxe74uRNQv4wvYGX197k+9we4tvCI9Xe5vveDvnO4XXCe1e3xgep/Z9vnO4fHu370J7zHepvc93
BceAmP/j3Nx+2DfbPuS7RgD1YT+Ddbv9uO8GHvf2U77F9hHfbaxn7WO+FcJhMI/t53x3ybULvvuk
jku+R5jL269I6vZZaWv7NSm9/YaU1b4o5bbflgraV6Ti9rvSNjy+7felHYTHcP8fSZU4d6qlnVgf
nFulWme6ZHBmSXucudLehP5ADI7jD2eB1OoslmjnNokn5xXOde6QnM5KSSLzB3bi3CkFnbVS2GmQ
ehK6Gl8HxH0UHDv3SP24jHOvdASfQypE6WK6AYT++C8of0D/grKC7j7+dwB6HYnWHGu+tchaai2z
VlirG9XWGmu9tQHSJmsLvS6LNR/D2mbl6IeyWB1Wr3Wftdsas/ZZD1uHrMetp6wj1rHGfus564XG
i9ZL1ivWWatOkcME16w3rJmKLFpvW1esd633rY8YNbOVSWeymFymgClmtjE7mEpmJ1NrVcUFShiY
PcxeptWqlYWhGZ5xQjmJtBC3CJfE1/Dz4Al4n/+FEdDtd/5T9kGNYBu7QV4i+6AZZB/0ZbIP+grZ
B81CHOLRq0gEySG7oa+R3dDXyW7oh8luaD7ZDX2D7Ia+SXZDC8lu6EfIbuhbZDe0mOyGfpTshpaQ
3dCPkd3QUrC5GbQNzYJ8kuyGlpHd0E+R3dBPk93QcvRz9Av0GfR/QCrJnuifkD3Rz5I90c+RPdGd
ZE/082RP9AtUHpWHasie6NtkT7SW7Il+keyJ1pE90XfInmg92RPVkz1RA7Wf6kIm6gB1AP0p2RPd
Q/ZEv0T2RL9MdkObwNK/j/6M+gH1A9RM9kS/QvZEv0r2RN9V96q/gczklwbb1OfVP0A02PUUYtR3
1L9AHNjvOowlhQIo9FhXLdBjy3XLTcstyx3LKsg9ywMYeA2dRmfQ2XQeEYYWaTcdoEMgUbqXHqAH
6WP0SXqYHiVSSJfQ2+lyuorILpLW0SZIG+lm2owF643qY6A3H1f0JoM8H2uMCuboLdAerCtqGP8y
0B6sKxqiK6mgKW+DDuE98+dAO5pBh7B+PE/0I43sk78A/RJAk7A2pIMuvAf6hPUgA7TgNOgT1oBM
9D2QV4gGZBENeBXm/zLoLd4P/xDM+b+ChuFZf43Mei7ZA38dZn4Z5ZE5zqfSYY7fILNbQOb1TTKj
hdS7lBl9hMzoWzCjTlRMSTCjJWSX+2NUH8xiKZnFj5NZ3Eb2tD9BfZ86j7YjSluurUqajxL1S5aS
jULvo7st2y3lcaGLLFWK7NoodMxSZzHJQvdZGi2N9GE4s0HoIfq4pRnEDMJgoU+RXLS440KPWAJP
Cz1GaghYQopEZaHPWXotvfQFSAeeFvqSZdByLCEncVlFhhUZ3Si2Udu4ZdwyERdmzTKpyNRGsU1Y
ZuLPsk1a5kBOwpkNYt1hWbfMg+DnLWDhimkd5EvkDiLW1adrt0xxtaSGqfjIWpZlsU1Z1ixrtmFI
158W2wz072FCTLQqIVpZNhmpK/QsraMzE3KNziFy4/FIxIVepPPporiQGb9Nl26QFcBduoxIBch9
5fwjqxrS6kSPTJaQdStd87RY0+l6axbdQDdhsebSLbJYC2gHnGmj26zFdFtSPQmxbrMs01xCHLQ3
LvLoWxZgRkC/rZVEd+usO621WMesBjwS1j1YP6x74aiV9LbUSlt50iKe9FWuCWvKHJmlGdu8bYFo
wxIZ/WUy0itWJ9jOdhi/ckuVVbIMW4MwyjprGNrXY+0HXTZbj4C+B6xHaZX1BOjyQFuP9TRdAc/t
Bz2JQtkz1rPW85aH1ovWy9ZpaDHW/wHrVdJLM8zYFUvUeh1KmKw3rbegLmy1pEekpGwreHajlkbr
HWj/KvT5HpzvhXLlYHW91gdwtN3ayiBLFaNh0pgMJpvJYwqJLTfKwpQw27G9MuVMFcgupg6sVZQt
ljExjeRp8CSm2RJlzNgmGagZSoqMmwkwISZqGWR6FfvDFjjMDDAi6JqO6FsOXB2k6+kK5hidw5xk
hplRuoUZh/mF2bL2MxPMJDMFI1dK10CbBulZZoaZg9LzIAt0GTNBNBD3kswVLgcCGoNHiVkCLNM1
YMMDzDqc9zIPWRWzwGpZeDabyeaw+WwRWwpjzbNlWN/ZCraarWHr2Qas4zCyZM7ZJmsxaFsF28KI
bBsIxzroaixwzcuWsfugB/V0E1zpplvYGNZTSNvYPvYwO8QeZwrZU5ZldoTm2DHQRwfuG3uOvQDP
bAMN9eL+2dYs47Z1jgZmmLQ9hPlZgP7UgL4M8CpeCywwzOuAKaaYQXaFz7RkWybaptkGPofPx3YN
OgOjxRfxpXwZM8xX8NWgoZg51oHN8OgM2yZsE3IJywB3la+BujDfEQ0mJWWWAQ2Guub4essg32AZ
5ZssU7QKyk1Ae9b4FjgaZ1v4NsuktZIt4yp5jnfwXsKCCpPx+2yEWdkK25xtju/mY8BzSzLX8X38
YfI0eBI/ZFnmj2M2g3SNP86f4kf4MS6LB0ZnW2TmItyltS3zF/g+uoW/hFvCXoJ5wrrTwl5hZ7H+
yGLth3ZPsdcwJ7E3YI4X6QaYndugV6XAB6XsCoz1KfYuXc3eZx9ZTJyaA96xLHHpXFbbdNs0lwsz
eAr0Zs0S4Aq4Ym4bt4Or5HbSbcwCHnfLOF3B1XIGyxq3h9vLLHGtYD29QDA87YDnL4B/vM3tBAvW
AWe1wRUnJ3FBOocLcz1cP3fEEqK13FHuBHfaMsed4c5y52kddxFq1XGXuWnLPNS8wF2FNumgLde5
m9wt7g63yt2DNs5A3VrLGpR8YEM2jaXXlgZskwG2ZAK9yYZ7SkFXKmx5oL8rtkLLKFfMrrAr1n52
0bLAzNlKbNtthTAOKlu5rcq2i5mx1dlMtkZbs81sY2x1dD3kIrNuc9sCUDrE9bOztqitl/baBmyD
tmO2k1y/bdhKk2jq439cYf4BrTA55CRvNWTh/03GPIyor6lQpvkUyAjIGMg5kAvmC80g5kvmS+/O
vztvvgIya54l566B3ADB5xZBboPAfXtX966aV0DumvEaVqUz6XbDM9LJigaRFY2KrGVSSMyrJmuZ
LWQVoyExbypZxWjJKuY5snJ5nqxc0kjMqyMx74sk5k0na5aXyGrlZUSl0+kO0ify3qF5B6LMBsgr
Id+jfqnutLn2WVBfD/kZwNn3wXkZ9S0y6i4+Iy4DpjfBVRn1XsivPxvquyG/qeCWgjsy3lmQ8/oh
wHE4XgXcexr1I5A/+GDUnwNcgHqRAg0g7UmQvm3AOxkbkP17IA9QuAlKNqkXY/sGlD8bTDDu71QB
dr0P6mSYrst4x/SMaAQ0bwKzDBPM2zvMs8EEc/uOqMCtICDDdEfOjYuQzwFCgOjTMIEOvNP7wTDd
U+oYUDAIOLYBJzfB8AaM/h4YB0xsgknA1CaY2YC5Z0P9bcjnzcQ+NgVcq18B3FXKLT0jlgFrm2Be
qfMR5OvPBr0a8oePUa96jESZdCXPAuTCNe3jZyVDX6A8X/fB0BcDtj15f33mBuRsAnzvDsjzIa9U
8p2bt+f9UF8EKN0EZYCKTVD9JPS1SfydzLdxvlR4TG8wJ/hFv8f8JH/E9SR5XpXxTozR3qSxbX2y
TQlOSeaAuA0rtoV9Rlznd2dv0Ol1+bqeBvAAp8wR2L/og/J53Cd9GNAj86sZzxfwpP4I4KjsA/Qn
FH5/IOu7HsYkzs968Gn6s3J/9eeVcYA6MV/iOglwvTCfeuBFPYydHtqgx/XeUcZXGU98L/GTcR92
K2mcoR4DkuvA1wzgLwxpSrs2ztOGOUr4lPg89ci+0ZAht82QnXT/A7kv5O+ziu+Dvw15yrkzSTi/
CTb65aub4HqSf03ysQmsJmGDf034y/+In8wzP+kLS8yPfWCSv0twFsCwS8nBbxlMio0BfxjAJxnA
BxnA/xgY5TzYMPYfxG5rZXsygJ8xuGUuMgQUu1DsIM6LWLdwPZjnCD/FbaRH5i18f4IDN9rWBruK
80vCtnqU9keVOe99fD8pD/ZmAN9kGJTbbQCfZMA+aEHhJNwH8EGGUeW+D+KgjTy+WZl4mzfh48Q1
7WO8L9d9EJ/mP4mneDKZK8uSODKJD0nZfKVMhTwGmKN3g/7sLpGBYxs83zim2b1dOQe6YqyBY8xj
SvyyG2Ijw7rCYzCnu7FuRWU+M+Kxx+OlxAS76xQuw/5/UOE5rH/go3dDfbuhPiO0dzfozW6obzfo
2W5cJ+jY7pDCn3G+HFVis3jc5H7Mo6QupQ7SxqjMl6RdG3l4AwcnYpg4D+N+4rrwNdCp3QNJ9/cq
/SmXx4vEXNC33YPKuaok1G2CjbGgeRMo47oxrksglISNcV08RvuPxGbj5ifjr0nz47grOcYyK/dO
JI3JRtsC+zPMmJ+yK8OcORFjGbBdL8hclOCrJVmvDcuKPsXP4zLriv7hHHjFqNidEWzMqJORbG/G
TJkjjDmyfhqLNoljAMZSBWUyCA/i+iuUvPqxDWKbMIKvMzYk2R+UMzbJ9mYEH21sA3Cy74mD8NGI
PE64z0YHwKvUDf0w7lP6qZQ3wprOGAP0AQ6bCRcZhwCwhjOeAozI/g+D8CTEBMYxwDmZj40XZD3F
vtB4CXAFMKuM1zXADXmdYLwtj5NxRS5vBN9hvA94JMeAmP/j3GwCH2DaKgPXR/wM6LYpXR53E8Sg
plxZz0wF8jjieTQVK9e2KXXskLncBDGiCeJDE+YeiMdMEIeZIK4yQTxlouXxNfEKj0H/TU4ll2R9
MEEsZIIYyAQ+wtT/WH8wd+N4wASxkAliIdMJ5bzCuSaIB0xn5PqxnZhgjEwQA5guJulqfB0Q91Fw
bLoslzFNy+fw2xgvXHrhH/74NsYf0l6ZukR9Gf+Lqmoa/T1CqfmAIkApoAxQAahOymsA9YAGQBOg
BdAG4AAOgBewD9ANiAH6AIcBQ4DjgFOAEQVjgHOAC4BLgCuAWcA1wA3AIuC28syV98nvAu4rwOUf
IaRVy+e1WwHpSttWlBz6oM0C5AIK5POJvBiwTW6rdsfjPmsrATsBtQCDXI92j/w87V5AK4BWzvMA
J0CS69UGAWFAD6AfcARwFHACcBpwRsnPJuXx8ucBF5X8hHLfxaTrlwHTgKuA64CbgFuPczw+2juA
1d8jj4/FPXkcf1+QOUhGgwxcP5mvRaXsnQ14IP+38/E8fn+83uc0gDRlvuH8cxmP8+eyAXno7/V1
epO+Ud+sN+sZAlHv1gf0IX1U36sf0A/qj+lP6of1o/px/YR+Uj+ln9HPgczrF/RL+mX9mn5d/9Cg
MmgNOkOmIYcg31BE/i4FKTNUAKoNNYZ6Q4OhST9gaNEPG9oMnMFB4DXsM3QbYoY+w2HDkOG44ZRh
xDAGf58zXDBcMlwxzBquGW4YFg23DSuGu4b7hkdGtXGrMd2YZcw1FhiLjduMO4yVxp3GWqMBX4fz
e4x7ja1G2sgbnUbJGDSGCXqM/cYjm+Ko8YTxtF40nlHkLMhmx+dBLhovG6fh+Koi1403CW6B3AFZ
Nd4zPjAhk4YgzZQBPuFDm/7iAlJ+cUFLfnFhK/nFhTTyiws68osL6eQXFzLILy5kkl9c+P/MnXl4
VdXV8Pc5+5xzI8MVMUwh0JgCMhMCIiAFQcYEERAUEUXGIpMREBEpk6CRIhILFpGplCpGwAmQKaCU
SYpMZRZpChQoYECIgJTcfHv99vlD8r3PV/t93/s878OTX9Zde+21p7XXOfvcm0tZvnGhHN+1UCGa
FK2vKkYbRFurOtF+0UGqRXRo9HnVJjoq+pJKj46PTlBdolOiU9Wj0azoetU9mhPdqCZGd0QvqMl8
+8J7/4N75jilnQw+r7JO/jf55NTwx2SW5ObhT+vwJ+0nsvyYXZP8WCiLXa9Q7hv+DAp/TNZNNlk3
2WTdZJN1k18NbaeH9qJ76yev54S/F4Q/S37SZnb4+mNVK22n+bc37VDa8bST5t85eDItz/zLT7uZ
rtKD9BL2X9rO9NLp5dMrp1cx2ppGXzk9Jb1R2sn0ZumtzJ5kV6blm33ZKf0Zs1Z38k0biu/YcPmO
DR1NjaYqL9om2lb50Q7Rh1WE79soEe0d7WvW4dnoEFUpOiI6UiVFx0Z/o5Kjk6OvqGrRDdENqnp0
U3STqhG9GL2oav43e3diT3oPGfY00eHEiiMXQ66PXB+5gdfesKE/Cn1f9L9Hnm6Y6n+C3B7Z1q2P
3Jm69Qzrom/oDceP1E3Ffy+vgdB/Uj775I81crzXSui/YPgpNgul3QLkghz6MBn9EOQGyA2QG9re
hhwLn8fG+Cz4u1fLMDccUS1Kn6RXjNRrwriepeeDRNZHkOMoVdT6AM0w6qajuRO5BXVfxNud9KQF
9LFphM1AwxTkFORUryn6wciN8IAeNqA0ldL7vQeE/hB60hRLkRvoK9jYeZiOtw14k7Wo5y1Fb9kY
dsWmPz5X49PMhttFWnTr+M8YTvXN7nZHI7eAR/wRhuPFxnHhbOzpp6uEeiCWs/1+hu/h8y7ROIdF
dq5SmoV9G+zfRI7H21WYi/1N7y9G73pbDbt6B6QVkZ1LaAZ6hw2biY26JnTS4I8wR6g1lh3w013s
nVN4WIq8nNJ22BdiXxP5DNwMV2F/wXvOWHb0/2zkGxK3buBvMnJM9E5ff6fhSc9EgpsgNuqCP8nw
B6FzJtQY6lT8JMBE6g6AWbCcV0hpHyPvEbrHkTfAvXC210vWKLgAV8NsmAnzhJHypq2GdgWxnBrI
d6j0RW4BS4bMhplQ6pbDcgulH6M5gmY8mkV23UU2XA2zYSbMg2LfActx1FKW/jsSFciz6fl7yOvg
e6EmG2bCPNjajOULP5MoGiSk9cPwKnWzQq6G2TATiocsZuNNsdFz4Jv0+SrMxU+u9Nm54O8yzIcX
/PkwA/aGRIJ/0Xgox3rdwDIXng85iRjYLLGBJoaHGB5ieIgRFScpPYnmZKhZZ6gZyz3+FmJmF8yA
veE+IZGQa2NMZBNp4m0f8gVzTy99MBq3aUgzFne7RKmbiCYRTSK7O1E8G26F64jMZWaMY2184nkm
zArryr4YScyXk/+J27Q1H2bA3nArvAjF53HqHmc29uJtL/Js5IUhZfZ20s8uEfFW0tJGGvJ7lv56
VjaDdZTSq8gXgl/JDFtKrxQac6YVJqDfy8ruRfMpe6QaTCIL1Se/TQ2qG05Af5ZclI/8llxBnH+Q
00rafCiWTjH/14Z3k82mwHLMxgpsarMXDiJ3gUvDHGiuLw7+3Ygw2CerH/xWZsMnl3rPyJwEa0QO
aouszxHbS4mTVKJ3F7XW+J9KXW8FvZLSwTafB5I5awnN3jzAnjrAPpLdURU5i9J/hGMcSX8GUvdD
7D9knskw/jmZH6HJ1UK7XnUCc310R2NfEnkL9uPD7JFNHsiUqwN7cCD62fAuWJVWDsPCSHtZzcgy
2pXSNrLKZueKHB9SfN4X5uQFRi5PTO5DkwSPBRVlfcm3C4nnx8nbKyWL+vuJyb1i6Vcn9uJEY9ZO
Yjhe8rmzy+5ic1Y2VwTWZb/MsMkD64ixdexKy63sl3VwK1cQydUJUtfM5yZqTWIHTSIOpZUXpFe6
g5TqDjareOZexanEHm9FrTXBdfKD2DeW3ppIFs0Z2ekmwg/KlYWep4b5ZxKW0soSmAU3B/eKHLzB
zn1ErjLs3OOUbghpd6jI3YJalF5Ec5H+yww3CvZJrqO38+Vq6HzNNTGB3hag/4Q5r4ScxFhOyp2S
29kT/7u9qOE5uXt0KwjNek0iq8iqzWWMC2Sv6fpcB2sIdZJnNO5XeH4Xy6t4/hvy35Db4X+XzLyh
eE6jz8OF6mPk8/Bxv5iS+wrx/wArVRMPu+31V+6jzH1CH7KfRPg07l7Oe4MZhcTbLymdS8/30VYO
3hJkpN5fZTZ85sS7zvqOluu7Live9EGRvQeQ2zLePEZxnVxxnZ2YQD/J9u4G6aFuyNjvCHsrPUlG
ru2Ze1dnO6P+3DN3g86D9G0HdYl2t6k3VPY4tbrJPbDbTX9nOMtrYzw3Zx1Xev0lPt13jXwAb2dD
ireF+LkPn6meZ3hKaKKukpK7MjMDOsI8vE+tEXAmMXDOk9lbgYfq8Pf46YT8AmOfzzy3YoyDqXUW
HofPyoyZuywZxWS5azXyHRIVXIOG4a0v/eyGn8B/WzJAGI0yuvX052ZQRehfhQdhDvpkmCY5wd5z
iqWbApv6h7mOiNzW3oXiZx/cjp/t+NmOn2+wH4j9QNG4GWiaoelk71pFVtekJ4YHYQ76ZGSxL2nv
bGklx5L7qA746SB13e7I3a0sfgxz0CfDSmgSiR/uN/B5Cm/5cClcDpd5cgVsh892+GyHz3b4bIfP
dsxSO/Gsa4qlrskMbMbDZuRVyKtkFGZWF9B/4Wd2vCKbvi3AzwJqXcWDaBrTz+shd7KzpA9d/Xrs
VlmdSZ7cbX4Rng6kla3eIfYspwOxVPZO/jT39hU4BbSHX+GtAv6vwUNwGXV7wLbUXYP+LNzlmSgN
kmVcQbbQGyw23m5/rdnptBWM8OU61Yu5ymAGfsQ+KrMaZLOv69PbfcTJKTgzPKccZnW2EZOHWbXD
zAzxKbvMzEA1WSm/nOE8zkQulpWx3Ic8hdab2XhjLT4QjdaslEbfAftT8DpcCrdxJ780OEMroimU
dTHrK/KZkKw18hobOaIxkZDGCqax4uYcrabov5pzZSe/uDAw59aCPbITC/b4ZpX1u9wp7ZQ58ZrI
dccbILL+BP4O/VK5H/MWkhWxN/fGcl/0C+qmc180BMsv5bzpbZcsrTk/6u5yXvZKUfoZtf4kjFRE
XxYPt+Ay7J8hTsbLWuhVMrf6BHI72EDoJckaecnERib2m4ioo0J/CTYNiIoEsdSvs7LfIQ+mtAal
5YmW1niwZ9VlsD1tteCuYCFXwLYyY/oUV5BMcuMWrhrb5P5EL+KOdAbXoMXcH45DM5W7mjz8bIQH
4EF4FD+n4W74Itemo1xn1wj9L5HHw7Vk12tcg16T+zevFndxR0N5NcyGmTBPSuXk5Z9n/jtgWQI2
CZ4wtCcyToh6bchsmAnFwydYjqHWKtEYiqazaPyniYpe3Ou+CNNhBneGI7j/bMuZlDtYrxrxs562
sNSZkks9NIYyinN4rhpyNcyGmdB482vImTTYRMxs98uaWsXxtgj2g5xPvXjG/hLy6pCrYTbMpFTG
9ZLMlZcjcqRS8A7sIf6p5YWU+eGMoJfJPOgW3PWNCzkfZsDekFiSO7egGOv+FJZtJTf6Vf3tRr7k
f2n4DvpDITNgb7gV1pN4o3Qbmm1oXpd7Xf2R7FDnN9xLV4a/gi9yb5nEOagJ9661uSueQUS9SMTO
kPtAty2eP0N+idPrSvr2LfpvxY+XTv9PiMarGHI+zIC9oeyve6VX3i/kDBu8b2NedoR7Gm/F4SLu
ECayj+K5f3ie+J9H6dGQ82EG7A23YmPm07tHWvG/lOeKhmKzllprkeOZgWvM0jE/m71QWUotObGe
kROrd040fo70xFuNfAnZI0487Mf5F1gFSzm97pHTq5kNiYrd3kT6JhGrkNfS87WU2izaHBb34w2V
rJdfIehi5MWi9+8hkr+FL4W5VDLPBnJpFjbTsP+AHfcd+6g4GbUxGXgu8nrJwCauTC3/C9ZlGz45
veq38DwMb7WQV8v515xwpTQDyw3CuByJ8DjFaev3eOaZScRm+79wuslkh55nB61id9wHOR3r5Xh4
H2/Km2pqbcDP59I3j+dUHidisxZyDR3AWXikyMZDHjzAvs6DB9itefAAvf3MyG/Q4hpm6ZbcA+h3
yU7boUff1ssZ2fsjHCXUPDnRO4NX5XrHLs5CXoX9Quq+wU7PFE0wSLJBMAT9l9jnwu5wUXBNGOkp
Vzps/iSRE6mIXBY2wNst7GfR52JydfBKy3Mqr56fQPyI7Erf/Iuy+l5p9s44e94kHpb5OyRORO+d
Cs/U8sQymzNOE/Z1O7lGRNqzdgdZqQdEDor5JU3pDa5Za+VEbKJXckJrKY2058qySHaTyVfr4Fby
0joo19A0niPVQn8C/Qn0l9CfRn8UfS+8fUsr9uQ1jivjAbhW2vVzZUQBz2P1p5y4F3ONmyP27p/l
fG2yXG9m+Dp9lrzURM7aQUl2fR67e6PQzOQu8kw9eiLcTWlx7ouKy52PyYcF7IX5ZAwpHQ8zw+wh
tQ6TNzbJudvYzEU/l/6Tr4IJRl5Nn9t4FQ3/IPSSmP+PGek3rM5obB4PLUVTmXPQVzJG7y45I2ue
Kmt7ajvCqW0HOfll5iGRda/DuewdoqW8b3JREEet69whfCTncX+wZ04W3gxy7HDqDqfudOSl0pZ7
Py32ZV0Wcurvz4he44R7gB3hoXlDTuVeLfr5JPaXaZFe+VOQx8nZXD+HbG2G4aERfErul8x9o+zK
tV45uS7Qw7PEuT1NtyQS2jH2enqDGVdP8ROMgmOF3iJvOZlTdsRDIvtj/DH0SuazGzb2/Y4cspkv
pXqkXMV8Bz+lmP+19PBPcu7Wx5AvyWld10duJ6d1/SFjuVN64rODvMe9CkazgP5P1JcMJ2gTCd55
eZcn+CP3hH3ktG5GJ/2pKGd2PQ2fI0PKHJaEj8s53V8Ln5BzhP6XjD0oywykcQY/Sa1n5JyuyyBv
pDSf/vyTHn6K/nvey0iSmQmq03pz2JvxDoWNwntLuapWoNYuObm7f5WTu36N+anA88NcetgHprE6
r7OO6bJqJnoN3eVoEunnXE4xWbCFlTmhZLHXsjjpZMmpypSak4h/L3fUX2D5ClzlTyUfihyF6ZZ4
SMdDOh7aYZnHWa+WaLxaaA6jmeuZFXeo61aBr3JefpTz8qOcwppwvntHzkomEoy9OwjLo7RYlvvP
OnirI3W91siTLNFMEm+GOeiTYSWu7GZm/H2MbrBnToV6Hj6b4N+Orjl8Wc6epv+MAp+18FmLkeYx
0jyZK+9x8Ry09vfDVySK8PCxJfPTF7k989Ai6MhcCR/h/H5Mzu9mFB3l2Ze3j3Y7soO+wcNVvHWU
q5X0ymQe4bteVcOnvclGP4aMynnZnK+l9HWYiKa5N8XIGZ70rQ4a8q1XibX4Dn4v1DuF/m6hVwdO
krp+XVopg88OsClcgrdMO1d4uASrM8MvwWGS8SLbZQbiOjGfNzj3DeEp/TCRIwFXvT5S6t/LDO/E
sjXyAJEj28VbXCe5M/FjnAebMC4bG41Z5dasyzzkeDw0w+ZDeT6gn5H59xJYhY+JjXvkKqbPyOj0
cuRSyOOxOQHrUCsZxrOaZaWuv1hW3F+CvgGW77PKr4vsfoemSdAIzpJ4w7KCrKaJk6nkQOFefC5D
rkqf45nDl0VvLG/Q2xvsUN6pL/xAOUoXfoW8XN7LhqmF7yPXgJnyLnlY+gFcjP1YZMvyMAu9rbsC
eQXelsFv0XyLfAQbo3e7FMoT0TpwKhwNW8AjcLzQcYUqH00qVEI9EHk2fA/eFcryrsFh6l5FkwXb
UOtN5HhKc+FNNLTidkVzCdn6b0br1+BRSn+EOXjT2HSA3dGfCmXpw1I0y9G0Qy6kVk3kM3AzXAUv
YNkR+QZygByD5eHJWE25M6Q/2KsfRKPtzCTCBNE4jNp5HO5Bfxx5A9yLjZ29LrGWxkNDuxYiuy3g
ArjIrgJyKlRwNnwvJnenX9j5F43zEbxK6dd4nmNHh1zOzjw2MWzusWNBk0uvziDvC8fSknHFmbpj
qTtONIr5cSZgmRrrxCjm0vO59HYufRNmobkKL6C5R6isnAgT4GlarAaTYH14lrZsBL6F/A+YEGtl
2A35blZ2io1J0bsrkGvH5PR9ELkpeqLCjQgDIi14UeitxUOBzEAwTGR/J2v9np2Zwnfl3Ubsf2tj
A29v0Yfr2PzIXHWRXWn2VHniXzjTrnLBFdlxjHR0SBcmGZaDLeB4SsfjbbxozHyKvi36VKhCJsl1
AXl2SLHsxGwfDmc+iVVYAEVuI3r9JqX51LqPHtoIz2dEzL9zzK4II11o4xm5PzYrmaX9NnvIXHkH
mDG7f+ORE5mZzdhvjj0oT6WQR+PnBeT5Qs0u1h2IwBvMWxalrKZTCf0FmUPnFn0OmL0ERhTHLMWE
Jq6sLGNkrpzfQhuHfUImUXcBfsR+Dz73U/oBZD7VZUZ9Hs6HXxfebVjAGIuh+QS5EnISq9YZeTc9
P0dpBZFNxlhqNA9SOhLOpXQBM0C06/rIdqcnyIy5NdDbHfEVfBfPA/AwAM+HwlkS2Wa2XezrLezW
s6wCWcXxmPkH8GMz4W74z8IGMpPIO20OxHIalr+0OZBW9qFn93kT2Tvbka8XtjP9tNeRxWSbgzJX
3gPIbdHn4ec6MpnQvQPWgsl2z2KzHX4eZqf7DLlSODuwWWl3NCQDuLOYpebYHIA2bxC3LtcFM6vm
TKHZ+877cAS0uaI6/D18Af0o5FZwMBH4EvoPwmuBxPPkUJYZsNeOXtiTQ9y+9prCagbMf3mYBffA
DZB87nzCehUir4c3qbvXrhcyM+lcQh4IOzFL15BLUpqD3AF2j12THqI/hc+ZcDlcFu5f25ZE/nYi
/xo7ojtsh34zcmPsJ+GN646zldZjxAZXRodMritgmUO0IDvXyMaHkJeh74Fs8yqrH2QTUaXgK2QY
7k+CynizGak7vV1VOE/eY8JDYey3jNfQ2QZvkoe7kkmWw6exvEkeLsFY7HUqPsyrScS2ZIZmaJox
e83IKtfQl2QeckJK7tVYdggpHpZSujxkEtedocxhEv2UvJRE6S64irqdecaYzzP8RJ40JgafGcsS
4adr5NMpjflMTgHPlmvIpxydPUI3m/d/t3L25AmV8w9PPpnzBScy3m1xWwfFZafzDs5ukd0vka94
Rzir8p6X3J+rnm41WRd5IqFres9K694f5R5DZDfP+16iUaiveO8peb5kLNVxoTOIWu2FfjbPNAJY
1xsnexMPSz1z36t74eGWlAbdqNUVNuTzCTdgnJcgK65flhnTW8RGZHei/IWLO1SoM/QJvBlLtUPo
JNtaaPYLvYtCMwrhYv2GjAI/reWpgrvN+qG0h9CfjIcb8AScBj/V8jynptDdoOV0nyTnevcGmtJ+
T/opnyIrIRq1X2R1XGjsRd4h9n4z/CRRK0XL5/eq6Tmy+noxfVsmz7Sp9Slsiqa62PsbqXU67ImU
9kCzQI+VbIO+eUj5HJEXelsss0TfVovs5NIf7TpCP1++9QbZdV3ROBsplU8gN3BO8olZ+VRbZ3ea
YR156uJucN+UrOu+Jj13/yT7WmT3VfdVw/GuvLvtir2TBbsK9RBsZrt81tGdaVhPv274CXJt/T5+
jOxcxZK6bhvqvol8N96uSpQ6f6P1m+7dspddiYoebnn6WUri3+VdfjcwmpbunbKX3XtlL4u90wl2
EaofhFrjoT3eursVJGe6e/Ap8jX3lFw1kJdh2REPMer+AvkM/NKRGV5JH847vzSWdR15wmnyotHc
cuRd5gInX64FborkVXci79rLN8tecHKlP0KnpVtWNO4auXI5/5BrLkyEdYXGm6E6hTwTlnZOYHlC
djrycWesXE3wucdZYjjL+UauR9ITdRYPP0hP3FtKyafQvcvCIB7578gl+XR6ceT70X+Exvjx/hAY
n15P2BpeFOpzcLnQL4H+ltD14BtoqmPzlDA4jGVN2JHSZOS+yD2wPIMGvTdNGKmMfC+lm2A+GlrR
f0EegDwRdkYzGY4ROvTWbU7pV8i59CfAJgtmU7oV+RPk7+Aj8An0jEgXUNd62wVfgc/Cg1g2RGZc
+l+0+DzyFvpzCJ5H80e89adWYyx3or8HeQXyfOZkDfKLcCGsQa0/RMzVJ6hoV0dk7yIstGsksl8C
zS3kB+0aoXnLrpTI+inYF2bg7Wm7XtSK2FVDZk6CS3bVsF8Oz1CaLIxURrOJvtXDcjocbOeH1h+i
h1/YORGNuSaKbGeMefYWw2a0yGw731PKTLob8EDU+bPgNuwXwf3wYcioPRtp8+nneOyr4oE596P0
gfhxqxF7d2B/GpsPkVtgaWOsFYwK4z6UunFl6KfGph0ePofx6Csy6urMzE7sZ1PKHvEOUKsKbTG3
epbdd8zhYeoyt940eC9+PsMmBf/Mp9uSuivRs8t8G6uDaMvuxMo29vDzNTKW7uvUuoDN76CNEGZP
j7CRTLv3MFcrhM73aN6lLRuH98EHYBfq7kVugIdUeBb+iP5V2uqH/Ch+GJdP634jLGfgZw4yM++S
H7wlcDTsjo1t8a/QRsh6SodA1kVXoMXnIDMfQeNdpcWx6G1OYw96dnezc/070ZSGZAZNVGi8uTZT
kVXcy9hT1xsFP4BL0dvciKz3oNmOfILWiSvN3nGvUIuo8+1usiPKwaYY9vPQ2HXfiL4rTID0WZMz
g0x82l4RFd43kD3lERsOPQ8mUOtl7G8isxO9cfAIetZUM/9+L/TkKI+s5REPLlndGwjXYZ9PzEwk
fmy+yobkIp99pF9BYzNnHnXtmrLumpUKiCX9JGSv6ZmQ6I3sFsYRFT7XL59oD5jtCGMPKPWw1+Qo
3QQ+Iq0rJWcQ7w8xebeoJ2wNLwr1Obhc6JdAf0voevANNNWxeUoYHMayJuxIaTJyX+QeWJ5Bg96b
JoxURr6X0k0wHw2t6L8gD0CeCDujmQzHCB166zan9CvkXPoTYJMFsyndivwJ8nfwEfgEekakC6hr
ve2Cr8Bn4UEsGyIzLv0vWnweeQv9OQTPo/kj3vpTqzGWO9Hfg7wCeT5zsgb5RbgQ1qBuReoWYvMg
8luUZiA/jT4CGUtwCdajdDocDB+i1he0m0gPbc8Zr7cYNqMuo3a+p5QRuRuoy+r7s+A27BfB/fBh
aHtoV9yOazysigfG7kfxyTq61YiBO7A/jc2HyC2wtGvdClIrjtK4MvRTY9MOD5/DeEpnIxOZ3gFs
quCZmdH0X39GaQp+mBm3JfqV6Ile38bAILzZCLex+jV6bNzX0Vyg9HeQ1XGZBz0Cvos3u473wQdg
F0r3IjegVio8C39E/yo++yE/ih967tOK3wjLGfiZg8xcuewsbwkcDbtjY1v8K7Rrup7SIZCZ1BVo
8TnI7EXQeFdpcSx6mw2IXs/uC2LevxNNacie0qyjxptr9zj70b2MPXW9UfADuBS9zSrIeg+a7cgn
aJ1I0ES4e4VaxIlvY96OKAebYtjPQ2NXdiP6rjAB0mdNtgky8Wl7xbp730B2gcfqO/Q8mECtl7G/
icze8cbBI+hZU838+73Qs7s9IsElE3oD4TpsiGrPZpI8ZLtSrKZm/gMiRD8JiXk9ExJ7kd3EP2vt
k899YjVgDiOMKKDUw16TH3QTofrGParkqchuU1rFPsfQM4ymPefugfK0QS/mSUIHShfI38bqJPl8
mp7DsxRXNO4/0c8QvXzAQslfW4iml9DfL/Tqos+nbgal54TBCOSBsD3e8qwl7fYIn2ZUUfKMQs6G
C9BMDZ941OVv6+QpShrPT27yPCSeZyPL0C+Ruu5eNAMpfRvZxUMeHA2XMvYSQnciM9BNnpC423hq
0RC5of5c6oqNKuR5xd3h8xND9Xex8VPx05VarXlC0lQ0zt3ePKMvGz4bWcYzkGU8DzGMvVUoz6k6
F+6W3IvcQ8627l6RnTbIPSltjZyDfATLcchxyE0p/TO1zqMpbb2hORmTk35tbEpTKwX2pfSQJaUJ
yDcpfQcPVdD/CX0j5JqUBsi/Rn7N9kFk56jtA6VjRI51LbxmIqEamk9VBcNjyAtE1ndyli8U6ubw
CpqbyHOw/JvQ3y/0HPQuXEZpnNDJR86DKdgrbGbAmnAKpaPpwyzkvshLafECNmORd1A6FD/F8L8Z
Lgl7Lj0ZjGYNmg1wGmSkuj2lUTQTY+v5X9jF88aYPAlMwvPwsA+iPy5rpJsL1XHqroAz8cYTD/c0
mm5i41WLyWfVWlDaMva+YUx1NPpS2NQXjXvZ9hnPi6UPQSU0OSI7M9F3jX0i8Sn23hZKD0mpGbus
Tgk8d0VfHp9v0v+KhTdNPyfT2x/o2zGp5WcwljPoFxF146WW04i2xiIn4ycldot3EG7JfMJpQnM3
JcxFk4jNGeTSQv0QvWrIqm2jrTF4HkgPc4WBx9xWtxFS2F2iTmzc0qKR798xGZJd5pWSsQTlsT8j
st8WmxJoeto4ZLYTaaUEM1NaZsx5lVH3iMmz2aH0cClysdjjEmMxedp5N+xE69uYjTbIfcXSyadW
CvI1LLfhYSbydPSHmI1d6KuhuUppFppjeMtC0wLLS0KTcVgvG4f0vyNj+Tt9yCUSbCTPklGbU8AJ
Zol1hxNZqXzsY3ioS1tNKU0hfnLRNxaa/C7r0iG0EZ4mBvbjea+d/3A2pOetGUsuc1UWfUnYA8uh
Ybu32Be3iL0rRIK1lHmrLLKJ7StEstg8DWeieRzLBNpKwHI3tbZhMxeuobRTuH9TzVgC+rySMX6N
PhFuoj+DrCXjHW5HLZYminhqTUQF4awuJqqZDZkZZxCe3yYPbGT2NodtiZ9UVqqszVTUyqPWZixj
RHsKliuJzHiRg2R1J5G2nhWX/s+zOzrcI+KtF2tUBT5DDy+GGa8C1xppZVe4Z+eY0o/tXhZvJlu+
Ta9SqWXzqniewlPiPNWfuOov1/TCLkZ+jKg7jw15QNt9NJ26ndy/EPnrWU0Z4xc2N2I5AX03Zn6W
0OSl9eQKySp2RZbCOEqTGHUrxnsCzoC38Nya9XoQJsO00Eay3PhwHSWz/U5ypomH9eym94mKW7yT
e4tYvUU832ItRL7BvE0Mr2IV0Mio5zLSZvYqRs7JY3U2CCNEUYSrjD6HZX/INU5dljg098DfkgOv
kAMlw3Sjn02J0hRieC9RTS4ylouxFPuP0A/Fsj1yOvol9PwQ8jL0bWMHYAa774rck0srsTmFJ1mv
rrJbWdOHGVeyva7F/sz79WWkt/R8MmNJwrJrjHse6iaqysZnQriyRi5YLp6V4nvelCd/pxM+aRSq
YuiLiV4p0cSelE9Zx3rKJ+Fj/D1IrBhyfeT6yA3kc9qxhvJZeqPPQJ+N3Fs+PyafzDfyVuQ85Isi
y1/xmLrr5Ftu0DeUTwMaPx/y3Sw/8P02G4TydwRKyd+5x+Llrzli8fL3ILFPg6HyLTeRSfItNyIX
5Igcmxy8Kd9yE7ks/oPTwsgl5G/Ef+Qc8r+QrU0X2ADLPrC/fO+N9K0g1/Y5+D32i5FtrfP0OR99
FfSlhJEHGV1deInxTqF0JYygvx/LVrR1Ef1OfKaiacrMWM1NSp/Efhot7mSWbsIJtN4Sy1rUFcsU
5BTk1GAH+hvItfBj9dXoyWPINZCfwM9hYVwEmW/yiYuj9Ek0r+NtrXwHDh7ux0N95PrIDeTv5Y39
PuSysAy12tDnVPrcl1Wez0h/oJS+Be+h6Q23wnxKyxnWi3yE/DE+NyJPx+Yz+Dv0K5H3I1+VHsq3
cJjeShw24H15XVCIzLzJO+mx+gX/lP4UsBbyzrvRXJHSghyZSauJTYBJkFp4qF+wBUvqFjDqgvnI
p/H5Z+RDyHmUElEFR9GcxY98AkepYk5m3Hml+700YqiK//WIAUPU+KF9Rg1Xnypz8nu0a6skZU4W
hYWqjCqhApWofqlKq7rqPtVEPajS1OPqKeOji3pZTVL91LPqOfWCei20L6kiqpKqou5W9VQj46Wl
Slc91NOm1a5qnJpsMsdglaFGq0z+j0FbJ6riTM6oquJVirpfPaBamez8hOqtXPWo+o16RQ1QQ9Tz
6kX1uiqrdIfOndurtK6PPJyk+nbrmp6k5uClHN8Z+guTm6sZj/VVM/WQaqceVj3VM0qrmqqbGq+m
qIFqqBqhxqhp1LlDJal7lVzpfqVaq06qlvot+vKqlJmHe1SCqm78NlCNVXPVRrVXj6gnVR/T79qq
u5qgpqpfq2FqpHpJTQ97cJcqrpJVRVXDeGioWqi2qoPqrHqpvspXddRjaqJ6VQ1Sw9UoNVa+y7Rf
6sh++jH4NBwIh8PRcHy/PkNH6VfhTDgXLoEr4Jp+fUYO0JvhDrgbHoDHYG6/fsMy9BmYL/RcWApW
hrVh0/5Dn/211xZ2hF37D39umNcDPg37w8EwA46G4waO6NPPmwynw7fhIpgNV8KNxnEfbwfcDQ/A
Y0OHvzDMy4Vn4EV4Bd6AMaHvDX2u31C/GCwFy8PKpnCEXwXWhCmwEWwGW8H2z4mfTrAb7AmfgQPh
UDjiuRH9h/tj4Hg4JUP00+BM+DacBxfDpXDFSLNG/kq4Dm6GO+BueGjks8MH+sfhSXgO5sF8eHPk
sH4ZgYLFYDysDKvD1JEjU+oHzWBr2BF2g71gf8PUYCgcBcfBKXA6nGXYIJgHl8BlcCXcALcYNgx2
wf3wCDwBT8PzI1/oOzK4DK/BW8KIC+NgdOQLGSMj8TABJsFqsDZMHWVmMtIYNoetYRrsDB+Dcjfu
mtwT/x/81mafV1SJ/1eSwxeH/p/pm4zhmywaUXH/3155vLKyY7JeUZb8mdQmzxXnO5f/XyTHZO//
mqV/Nl1WxDVe5RVPe+T6IHeJP5t3/WxW+t9Y6mcziZ5qfjs/oYzgp7rov6U2V6qyqvx/KJVDcs31
Kfk/+v1LVeU/+l1VVfsPfjvmSvrv+e/nxDFX8H/PO38W65u7jVHmqj9LLVEr1RZ1QJ1W+Y7nxDtV
nIZOa6eb098Z5UxxZjlLnJXOFueAc9rJdz23stvRHetOc+e62e46d6d7zD3v3tTFdIKuqZvqNN1T
D9Zj9TQ9V2ebPShtxdmY1Z2KvO5b5PX0Iq9n/OS1V6Q8MNv8iIo4P3ldrOHtr0ssvr1+9Nrt/uN7
3v66jLrdf5n4Iq+rFbFvX+R1ryKvi4ynzLHbX5etXuR15yKvx9ze/8RFt5dX2nD766q1i7yu+5PX
Zv9VTSlSPpnXrskPpe0I7+1sf1e3I/dMzJU1uapaqN0b/j4W/j4d/r78X1nXbBj+bh7+bh/+7nZ7
L2pOu32UtRrd/rpu7Hb7ej1uf12/yCqkphZ53bDI671FXu8v8vpikdd5t79uUPonUWaERvFFXje6
3b5R4yKvi5anFXndscjrTrevYpM0w6iZmX7ObDXQmUe27Wv+KbNTZynHL+XfxbWitApKdIhuK9E+
uiX6RXSz0QTOd853xu6yc1k5zhXninKdH5wflI62jLZUXvSh6EPmuinx4Oo2WtbLdUu7ZYxG/oIo
Kv3RJU3NuuZ1WXMaGaHmqW0qV9104k0f4kyv4kt0UW6J9iW6GnYo8aihjK6UyclJ5rSQYs48zaLn
lHZLmT79k9/bouak5ZYxry/8L/a+A8qKYlt776ruU2e6++wZGOKQo2RmCCNJkBwlS1JQchAEYQD1
iiiSDaAEyUmiIiISBAUJkhQEJUmWnHMGgX/3pkG4ct+7/73vvvWvf7lqTe0+3X369P5q1/6+qu7p
FruGtoPiT79yvYZ2cb2OffUjNA6y0m98rst56wGxa+gg25X8+ZDYNQ/teTjY80iw59Fgz2PBnvfP
t7qcbw0532fkfO9vqSlbasmW2g9voR/kDDfIGf4kZ3h/y2bZ8ots2SpbFBjFhbuZq/w7t2NUDKOa
klHVXiWvMqO+nJZDiM9pJSOlwWd81DLDxH+5+Pt92Ks+/DEao6E3xmEGeEveZ9kXm+Dz0A87YicY
KO+wHIyvYBK8i4NxMAzBUTgahuIFvAAf4VW8CsPwFt6C4X5owAgVUiEYqTzlwccqmUoGo1QqlQpG
q3QqHYxR2VQ2GKtyq9wwTsWr2jBeJanusEz1VD1hOWf/12GF6qXehJWqr+oL36sBagCsVsPVcFij
PlYfw1o1Ve2AdTrCUfO7LqKLwB1dTleAu7qqropKj9fjUVtJ1mS07JZ2Syxkt7ZbY2G7rd0Wi9jt
7fZY1O5md8NEu7vdHZ+0e9o9sZi9JTQQizv1nOZ4zhngIt7xYryK6jXvOW+C+iLSKtJBXYr0jryn
bpKisA5TFsqioykbZdMxlINy6GT0BD2hk1Nuyq1jKS/l1SkoP+XXKakgFdSpKIESdGoqQkV0Gkqk
RJ2WilExHUclqIROR6WolE5Ppam0zkBP09M6I5WjcjoTVaAKOjNVoSo6CzWjZjqr/0phnY3aUBud
ndpRO52DOlEnnZM6U2f9BL1Cr+hc1J2669zUk3rqPPQavabzUm/qrfPR2/S2zk/9qJ8uQANpoC5I
g2mwjqf36X2dQENoiC5EH9FHujANp+G6CI2kkboojaJROpHG0Bj9JI2jcboYTaAJujhNokm6BE2h
KbokTaWpuhRNp+n6KZpJM3Vp+pQ+1WVoNs3WT9McmqPL0pf0pS5HX9FXujwtoAW6Ai2iRboiLabF
uhJ9Q9/oyrSMlukqtIJW6Kq0ilbparSaVuvqtJbW6hq0ntbrZ+hH+lHXpI20UdeiTbRJ16af6Wdd
h7bQFl2XttE2XY920A5dn3bSTv0s7abdugHtp/26IZ2hM7oRnafzujFdpIu6CV2my/o5ukrX9PMc
vM0lf4FkLsSbeJOz2F28y9nDVjwOkH5mSz8LST8zKk7FQVhlVVkhSuVSucDRVTi7uXYLuwV4diu7
FUTsNnYbILud3Q6i7a52V4ixk+wkSGb3sHtAcspMmSGWslJW7uPZKTukpJyUE1JRLsoFqSkP5YE0
lI/yQVoqQAUgjuIpXp5TXxjSU1EqChnoSXoSMlJxKg6ZqCSVhMz0FD0FWagMleFs5effbJJ/s1Nl
qgw5qCk1hZzUklrCE9SaWkMuakttITd1pI6Qh16mlyEvdaEukI+SKAnyUw/qAQXoVXoVCtKb9CbE
01v0FiRQX+oLhWgADYDCNIgGQRF6j96DovQBfQCJ9CF9CE/SMBoGxWgEjYDi9DF9DCVoNI2GkjSW
xnK+Hk/j4SmaSBOhNE2myVCGPqFP4GmaRtOgLM2gGVCOZtEsKE+f0WdQgT6nz6EizaW5UInm0Tyo
TPNpPlShhbQQqtLX9DVUoyW0BKrTUloKNST/PSP5rybnzu+hFufONVCb1nH2rEM/cLatSxs429aj
nzjb1qfNnGWfpV84yzagrZxlG9J25oxG9CtzRmPaxZzRhPbRPnhOnhH/PJ2jc9CULtAFaEaX6BK8
QFfoisx73RtfIRSRXJubY8vGptiUV7fG1oDWImsRqNDt0G3Q4dLh0pyH/2eij3PgX9H3V/QF0Rcn
0ZfHV1vYPrT7rxj7K8b+h2IM7Q6s52MwqyqiK1mNID2UgHJQDepCEx4vdGD9/jory8HwEYyBKfAp
zIMlsBJ+gF9gFxyEk3CRlT1gCL2oV0FHdYtKinpNbPeo18X2iPqb2J5Rvdgm8dKbYpOieovtHvWW
2B5Rb4vtGfUO2+68X1+xSVH9xHaP6i+2R9QAsT2jBrHtwfsNFpsU9a7Y7lHvie0R9b7YnlFD2Pbk
/YaKTYr6UGz3qI/E9ogaJrZn1BugeGsfrrtHDeS6R9QHXPf8NxAZIZ53ixoZIPNxgMyoAJnRATJj
AmTGBoiMCxAZHyAyMUBkUoDI5ACRKQEinwSITAsQmR4gMiNAZGaAyKwAkc8CRGYHiHweIDInQOSL
AJHh7H+3qAmCyFRB5NN/E5EvA0TmBYh8FSAyP0BkQYDIogCRr4NYWRwgsyRA5psAmW8DZJYGyCwL
EPkuQGRFgMjKAJFVASLfB4isDhBZGyCyLkBkfYDIDwEiPwaIzBVEFkqkLBdE1vybiGwMEPkpQGRT
gMjmAJGfA0S2BIhsDRDZFiCyPUBkR4DIzgCRXQEiu4NY2RMgszdAZl+AzP4Amd8CZA4EiBwKEDkc
IHIkQORogMixAJENgsgvgsivEikH/01ETgSInAwQORUgcjpA5EyAyLkAkfMBIhcCRC4GiFwKELkS
IHI1QORagMj1AJEbASK3AkR+DxC5HSByJ4iVu/eQceAeMg7eQ8ZR95BxdIDMcUHkrCByWRC56UeK
/55G/7xlNq0R5MZf1ERdQ9fSbXRb3UG/pLvp7rqnfk330gP1ID1Yv6vf0+/zKPigPqQP6yP6qD6m
j+sT+qQ+pU/rM/qsPqfP6wv6or6kL+srkUT/PUq4GTfzD0zw/ztXV9fVQemauiZo3Uq3Bku30+0h
pLvqrhDWSToJonQP3YOVwKv6VXD1G/oN8PSb+h2I6LF6LMTqJXojpIgUjRSVWYY4cKyMViYrs5XF
ympls7JbOayc1hO+Z3xGV2R2/Z5eSR/MTeT1t/F37s1do+74YI9cwR75/Lkp3ZG3gJXC8p8AlsvK
Be5D37v3uymslFYqK7WVxkprxfnPvuN9//hdBdkh2kpuxVq2FbKMFbaiLMdyLc+KWGRFWzGWP99l
sW+9+ST97yjrKas0eFZZqywQb0uENHq6nqln6y/093q1XqPX6nV6vf5B/6g36I2PQ9yfLdPT9DQ+
4gz//5r1Z/ozxnuO5jzKyK3i3zuoTz04+jTe6zPeukR/o7/VS/Uy/Z1erlfolXrV49pYjj5dT+ej
z9Qz/Tsy9Ww++heaszOf4UY+uu+Hf/QCkOKxR32MH4LZwQAz/3v/ZHTJ9/xo4O/ZL6v58A70hX7Q
HwbAQBjE/fpdeE/eLjoEhsKH3MuHwXAYASPhYxgFo7nPj4VxMB4mwESYBJM5A3wCU2EaTIcZMBNm
cT74DGbD5zAHvoC58CVnh69gPiyAhbAIvobFnCu+gW9hKSyD72A5rODMsQq+h9WwBtbCOljPeeRH
2AAb4SfYBJvhZ84qW2ArbIPtsAN+hZ2cY3bDHtgL+2A//AYHOOMcgsNwBI7CMTgOJzj/nILTcAbO
wjk4Dxc4G12Cy3AFrsI1uA434Cbcgt/hNtyBuxzGqOqouqqeqq+eVQ1UQ9VINVZN1HPqedVUNVMv
qBdVc9VCtVStVGvVRrVV7VR71UG9pDqqTupl1Vl1Ua+oSepXtVPtUrvVHrVX7VP71W/qgDqoDqnD
6og6qo6p4+qEOqlOqdPaUWfUWe2qc+q8uqAuqkvqsrqirqpr6rq6oW6qW+p3dVvdUXc5Bfl322tt
aVuHtNFhHaXr6Lq6nq6vn9dN9Yu6ue6kX9F9dT/dXw/Qw/RoPU7P1V/qr/R8/bVerH/Sm/Rm/bP+
RW/RW/U2vV3v0L/qnXqX3q336L16n96vf9MHrJJWKf+9rdZWa5u13dph/WrttHZZu6091l5rn7Xf
+s06YB20DlmHrSPWUeuYddw6YZ20TlmnrTPWWeucdd66YF20LlmXrSvWVeuadd26Yd20blm/W7et
O9ZdO2InN2VNOVPeVDAVTSVT2VQxVU01U93UMM+YmqaWqW3qmLqmnqlvnjUNTEPTyDQ2Tcxz5nnT
1DQzL5gXTXPTwrTk0ppLWy7tTQfzkuloOpmXTWfTxbxiuppuJsl0Nz1MT/Oqec28zuUN08u8aXqb
t8zbpo95x/Q1/Ux/M8AMNIPMYPOuec+8bz4wQ8xQ86H5yAwzw80IM9J8bEaZ0WaMGWvGmfFmgplo
JpnJZor5xEw1n5nZ5nMzx3xh5povzTzzlZlvFpiF/rtfzWKzxHxjvjVLzTLznVluVpiVZpX53qw2
a8xas86sNz+YH80Gs9H8ZDaZzeZn84vZYraabWa72WF+NTvNLrPb7DF7zT6z3/xmDpiD5pA5bI6Y
o+aYOW5OmJPmlDltzpiz5pw5by6Yi+a6uWFumlvmd3Pb3DF3wxBGM81MNzPMTDPLfGoumcvmirlq
rjmvOq85rzt/c95wejlvOr2dt5y3nT7OO05fp5/T3/2b+4bby33T7e2+5b7t9nHfcfu6/d0B7kB3
kDvYfdd9z33f/cAd4g51x7hj3XHueHeCO9Gd5E52p7ifuFPdae50d4Y7053lfup+5n7uznG/cOe6
X7rz3K/c+e4C9zt3ubvCXemucr93V7tr3B/cH92N7k/uJnez+7P7i7vF3epuc7e7v7oH3EPuEfeY
e8I95Z5zL7iX3MvuFfeqe8297t5wb7q33N/dO+5dDzz0lKc9y7O9kHfIO+wd8Y56x7zj3gnvpHfK
O+2d8c5657zz3gXvonfJu+xd8a5617zr3g3vpnfL+9277d3x7kYgghEV0RErYkdCERMJR6IiTsSN
eJFIhCLRkZhIskjySGwkRSRlJFUkdSRNJG0kLpIukj6SIZIxkimSOZIlkjWSLZI9kiOSMzI2Mi4y
PjIhMjEyKTI5MiXySWRqZFpkemRGZKZcfZa5fZlj760mKs6gMnM+WVdjft+mn2F+36Gb6Odgp26m
X4DdwqZ7dRfdBfYx470N+/VH+iM4pEfpUXBYmP2I8NZR4a1jwlvHhbdO6IV6EZwUhjhtFbdKIMgM
vLId28F4O8aOwQSZYy8UOhA6isdNvCmCZ2W+/ZIzwBmrlDPN+U6ldtY711UhmXVvIfPt05ntL0IU
pIGszPk1WQGNYQZYxtmZf8LtB4rWy9JsWfKv0cRAKkjvruXPO9x1XO9013O9293wYN8dvLQCwqwn
0kBGVgB57l09cnf6693dXP/o7uV6o7uf603uGf+blNI/IqXyj0ip/SPKsW7LUe9fo4niT6vJ4Xot
uY9siZYtMbIl2SNb0siWtLIlTrYoiOJWi+e2K6b8tyWVVCVBqUqqEmhVVVUFS9VStcB2hjnDIOQs
chaBcc475/l4yp6pfv4PceyjDPv/N7/+7zCsz6H/LG/+JzkzuWll2ph25m/MQD5zVmTOrCFsVoeZ
6QPhyUbMkT473uPG1v8kK77x3/Dhn9lwNPPgHwz4MLv8v8aGD9iOeXEU8/fDrFiW1YevPe4pD193
1GblcSPQHbdYdTRmxTFBNMdEVhw3OWobcKS+4Mflfe5UnR7lTS/GS+Yl92K9FF5KL5WX2kvjpfXi
vHReei+Dl9HL5GX2snhZvWxedi+Hl9N7wsvl5fbyPJZt+z2ebymKHHL/Kdad/WfepWiKoWR/Yt+1
7jp3vXDwhsey8A7m4Z3ubnevu/8+H1MqSi2cfOYfsvLtP/MypaG0FPcvsfMj3Ozd/l9g55qoMCUP
ZeMwF6TA2lgfssk191zYDFtDXmyLbaEwtsf2UARfwk5QFDvj61AM38ARUAHH4HhohgtwE7RQXVUS
9FI9VC94S/VWb8NA9Y4aAO+qQep9GKqGqI9ghFw9H61GKs72MsafoD2dHCbqFDoFTNepdB6YofPp
gvCtTtAVYLkw/lZh/G0yettuTbE2wUk7mZ0M09hX7auY1r5uX8c4+6Z9E9OFGC5MHxoUeh8zhIaE
hmHW0IjQKHwiNCY0HvOGJoY+xYKh2aH5WDK0MLQGK4TWhTbjs6Htoe3YLLQztBtfCO0N7ccWrA1u
Y+vQXdYGfUyiKYlfm6dMGVwWzh3OgyvC+cIFcVU4IZyAa8OJ4URcFy4eLo7r/etn+EP46fDT+GO4
XLgcbghXClfCjeGq4ar4U7hGuAZuCtcP18fN4YbhhvhzuEm4Cf4SfiHcEreE24fb469RPOzHnU4L
pyXuclo77XCP08FJwt+cHk4PPMU8OxZPM89+h1eYZ6/jHVe5zynjNnVfV829id5B1TvyfmSMWnXv
/hYejc6RKy5NsU2wZuFDaxBKQCjQHjlZ0xTh7dO4+PUcVgXTxPqflgaflvKnvVz8u2zyYl6OmgJY
gOmuGBbjY1bGykwu1bE6WDgKR8ldNuuguR1np7PT2xnsjHYmO7Odxc5qZ7Oz2znsnPYTdi47t53H
zmvns/PbBeyCdrydYBeyC+MW3IrbcDvuwF9xJ+7C3bgH9+I+3I+/4QE8iIfwMB7Bo3gMj+MJPImn
8LSlLUtf1df0dX1D39S39O/6tr6j7/476yx2xVIy02DJfyskk7mfNFw0pOdiMXJPsKf5wL8vrSCX
MKNagnViKS4OlObiQgWoCB5U50LQkEs0NIYmrA+bcUkOrbjEQjsuKaAbJEFKeA1eh9TQm0ta7p0K
4jAaYyAd99E4yIAZMSNklLtjMnF/rQ2Zub82gSxyVTer9NRs2BE7Qna5XyYHdscekBN7YS/u04Nw
EOTGd/E9yINDcSjk4x48BvJzD14ABXA5roCCuAbXQgJuwA1QWOabikjPSxRNXU1mnZrJrNOLD+bC
vg/mwvIzUhlUgkpgxZioEv3/DVMVWDFWU9VYMdZVdVkxNlQNwWbd0xpCrHheYsU40BkMYec9Zyi4
znRnBsQ4s5zZkNzZ7uyAVM5OZw+kcfY7h1hLv+G+CVmYPfpCdp8ZIDczw2TI6+dxKMh5fDskcPbe
C0U5g++HRM7hh+BJzuNHoBiPrY5Bcc7lJ6AE5/NTUJJz+hluI//+r5Lq+Qe+/BD4UoB9yfiIL8VV
cd7X90ir2jyWscQjWzwKsb5rAkb8CrN6ewWixC9H/IqIX8nFrxTOHGcuezTPWQjpxMfM4mNW55hz
AnI6p5xz7JfvaQHxNEE8TRRPizH/TePxwQweZZQRryuK15WZl65CdWal2zwy8T2qqjoEV1/9/3Js
JR4V9H3EutLv4cEakLlMhe3w6QfrFNbHfPwpxYP9uAc8BotSqhRj4SNiSRvbgktIcDGCS1hwiWLd
2xQcQceVVvcEo4jT2GkMxCPzNyGaR18fcdsPd8ZCeh6DLYTsztfOd5DII7FzUNq54FyH1qwhBkAn
VgtD4XVWB7OhD3P/AhjBXL8Txkvbfy1tv5gZ/AAskQj4RiLgW4mApRIByyQCvpMIWM7Mfg5WMLtf
gJXM8LdhFfN5CH5ijZMGtrOuyQL7WMvkgaOsSlw4y+oiGVxgjo/jEQBnQh4hvQLgjyChnD/LAHX8
+7agnvs3ryL8xN/JgKPlLkf9R4tAC8E1XqKu9kMtEv9Hi0B9KP1gnYKn5ep5igf7KdDOOGcq//Jy
Zx1H2w3Xj19eK+Pse+eTRc4kPvh1xb8S969kVv5mSslDIHkIJQ9pyUOW5CFb8lBI8pCRPBSWPBQl
eciRPORKHvIkD5HkoWjJQzGSh5JLHoqVPJRC8lBKyUOpJQ/5/1e8kj3wVBW9hJH4767DKHQwOZ9l
VsyDhbAElsNqWJfPrgV2wC7Yg7VLHxyIH+Bw/tVJOB1n4zz8Gpfh9/gDbmZs9jAOx/EsXsabnPxD
ylPJVRqVUWVXeRjdRMzD3udiLPKLbcLs59umWFxsMywh9gUsKfZFLCW2OT4ltgWWFtsSy4htxT3P
t62xrNg2WEFse6wktiMzqm87Yy2xY+zUvrUW2mnELrLT+pZuhV3f2rFhz7ehqeGI2KVhErssHC32
djhG7J1wMrF3w8l9y+olVmyZaJTf6YC5ORNEM88r/pSP6ybM9r524HzAXnIMso8JXL+IhbhujoW5
boGsI9i3oly3wkSuW+OTXLfBcv69H1ie65ewItcdWS8o9qoK112wKtevYDWuu2INrsfgM1yPw5pc
j7VTgGJ/U3K9yPZnPm6FuWHYU45q9tPiemmY9Qb7GPLvZgobru+Ew1zfDUeBYt9Y/YTLQG7uVc8z
33Zknn0D+sJ7MBzGwVSYDfPhW+axDbAV9vDI/zT37eB6HkdSGo717BxL8ZiIpTiaqmBNzpBN2O82
7MWnjNYYRugzsU1xtthm+LnYF3CO2BfxC7EtcK7Ylvil2OY4T2wr/Epsa5wvtk04g2/Zx4y+ZS8z
iV0azix2WTiL2NvhrGLvhLOJvRvO7lv2OIfYMjhB2m+itNwkabnJ0nJTpOU+kTabKm02TVpxurTc
DGm5mdJys/z2CKcQxFMK4qkE8dSCeBpBPK0gHieIpxPE0wviCFY0yF3dWnIFSE/HaP9fNPwn+daU
e+pzQSHm4mAmClNJrKWWGEnj/7Z/FEz7YKmdH0l+7uV8MlJiRWr/ChnGcIYCTMljGpRMpCS/+JyW
Bgbhs9gQG2MjbIDtnEbMPk3uzQur7upNNVCN0GP0LD2PfqfbdIfucn4d70xwJjqTnMnOFOcTZyrn
2hXOSmeV872z2lnjrHXW0TVSpMkim0JkKOzccG46t5zfndvOHeeuy2nP/dD9yB3mDndHuCPdj91R
7mh3obvI/dpd7C5xv3G/dZe6y9xd7h53n/ube9A97B51j7sn3dPuWfe8e9EzXtiL8hzP9Twv4pEX
7eX18nn5vQJeQS/eS/AKeYW9Il5RL9F70ivmFfdKeCW9Ut5TXmmvjPe0V9Yr55X3KngVyaMIESWn
WEpB1+kG3aR0lJ78a5A5ZdQHMtKzWTlUZ07roDoyayfxiM5TvXhEF5G7n0nGb9EyKouRuddk+kv9
JSQPfRGaC7GhRaFFkDJ0LXSNdRuPVSC1P1ZhfbPPOQK5/RELq5mBzN0leMy+AMrzaHsn1OAR9254
Rri7pnB3LeHu2sLddYS76wp31xPuri/c/axwdwPh7obC3Y3cO8zajb0YZuoWwtS9hKnfopTM1O+w
n0ugyT/Tov9aC/5H2ul+CzmCJgiaUYJjcsExneCYXTzPL54niud1xPP6olEa3hv52fKmP16uBv68
bjnI+HD8/30U/+N4vBc7fIRkEikgkaKlhUPSniTtGS3tGSPtmUzaM7m0Z6y0Zwppz5TSnqmkPVNL
e6aR9kwr7RnH7ZYa0gVn79r00NkT682gx/p9XuIUJE5R4lRJnOrgu54d/dB307AqeZAF7vd0yRzS
CySSbYlkI5EcvjeKxQt4FW8FaiCZSqXSqWwqt65qt7Rb223t9nY3u7vdk7JQNspBT1Buykv5qSAl
UBFKpGJUgkpRaXqaylEFqkLNqBW1oXbUiTrTK9SdetJr1Jvepn40kAbT+zSEPqLhNJJG0RgaRxNo
Ek2hqTSdZtKnNJvm0Jf0FS2gRbSYvqFltIJW0WpaS+vpR9pIm+hn2kLbaAftpN20n87QebpIl+nq
X3eV/3XP5f/QPZcKYljzt7Fj6RZzfpl/6p5y7onYIbTnoTuAw/69MsFdNf/lPTIP7qPhY6inVLMH
Y/Z7a6pzBro/5lV4Ga6xRi+qivEe5XldLVVHNVCN1fOqFeeqLpz1evnXtB5X/OtYDxc+yqOl2J+L
f9Xr4eJfI3tsKf93pZJ/Be2RUuvPxb+a9nBhX/5BYT54pLDPj5bGjyvMH48URunR0kzKH59b/V1p
y6XDPyhdHlfcO48WZq1HS9q/K1kfLYF/985XjvDX3MQ/mJtA2Mf8WYq5vgqr7PryHJT7Tz/xn4Qy
GIbCSB79TIGZMIfHP0tgOazhEdAv8CvjFy/Xev9v62L/Ul3rX6kfO/9xb3bEYzPSH/dAWX8swFyX
SkYP/jUOxNw8jlbM9iN4eSR+zMuj0H979wQeeSlcgOf8J8DiBR6vXJR3YFzBq7x8DW8IZ97i5d/x
Di/fVf4bSJSyOOZsFeJlo/ynprqKx98qIu/ziFE8xlbJVQpeTqlS8XJq//0czKvpeDm9ysLLWRWP
3FR2/80fzLG5eTmPysPLeVVeXs6n8oH/RpP8vFxA+W/iGavG8vI4NY6Xx6vxvDxBV5anuFYFravZ
sf5z4mz2146zK/pPNrQrg7ar2M3953Tb7Xm5g/9WYObqnrz8qv/EKLuf3Y+X+9vLwX/D8QpeXhnm
zBxWPIpU4ZxRLwFGdYxipRfVKTILMPJphEe9kc8iK3h5ZWQ1L69hpYqUkXWGZjV5V0Z4nJWjVXSO
e//jLC2joEXwn7l/aBAUDYKiQfCh/yBF0SAoGgRFg6BoEJT/+0DRICgaBEWDoGgQFA2CokFQNMi9
M1SiRFCUCIoSQVEiKEoERYmgKBEUJYKiRFCUCIoSQVEiKEoERYmgKBEUJYKiRFCUCIoSQVEiKEoE
RYmgKBEUJYKiRFCUCIoSQVEiKEoERYmgKBEUJYKiRFCUCIoSQVEiKEoERYmgKBEUJYKiRFCUCIoS
QVEiKEoERYmgKBEUJYKiRFCUCIoSQVEiKEoERYmgKBEUJYKiRFCUCIoSQVEiKEoERYmgKBEUJYKi
RFCUCIoSQVEiKEoERYmgKBEUJYKiRFCUCIoSQVEiKEoERYncfz7Ig6eFxDVjm0LWQlyD+D5xdUNR
efpX6X8tgkZN6hNXnleVUYgJbnxUyM5LWsXZEN885OQNoYV9nlRoTaoXXyc+30Nr0k/J+FZ6uZxT
CmpBC+gGnTmJtoYk/vMv75SOz/LQwawUue7GVp5QvdyYIRnaHnbf6FxkZqTN1kl9UuaP72NNiu+j
B07SCpVymqfdMExOu0185MFJos2n85qcnX7WCsWqZ+slxMYn8z+EY52Gzbu1a/9y26TOLyfExJO/
0sSauq1bder8cquEjPHp/TVObMpn2rfs2rlb5zZJmct37tqlc9fmSe35G9nis/jbdWzcw9tbtc5c
r33bl/momWuXLxufMXUkISEhPiG+UHzhQoWKNuGPheMTHnyMf/ud/8i5ReJdf7sbaz1Tq3bd+7vr
f7B7fB/M+jBm/tuj+nC64fWO6oMIZ59b1itZ9kP9Q7+1uVtlQeql6vB8r9D5rqV7FRiwo+bkL2eU
L3it9YSEA4USKs7ZsSJ73yw7Cizo++bNolvqpd+xsE7GWj+1WXxqkadu537+85kDrv6Qdf6278Ld
rwzuMqTljnODM54YUj57qyZbBvQa2qnk7B4bGyb2Ov5tTIPZo84Palqg1ZovckY1y9gy5YWnvks1
ZPRAtSp+0Qr3xUzRXTdsXzSzaPL+Yye7ztFhz31ws/64FZfSvlDu/eQTM5QZuuiJ2HfSFuqT4dLO
AVuzzCs1ZaGptSP7p2ffv/LVzps3iteaceLiF43rXt5TdmzBZF1a7j2579MLnbJYMfUKfzOv1uoD
9eaVbV355SevfntibKqyH75U4Ln4VUpzh/ikD2ZgRNLGxzKWGXJYXrwTCnNQ27bROj6Dv5JYbKdI
V5cuJcuzaPmgVcnefmrryEaLP6n3sjRghmj/hWsWs9pb8Zn8z9msNPGp3krxY7LjP/wyP1UjXP9k
gcKpUi2uMcbJFN/A3yGTVSv+mfjqk6pOqty/YrukpC4lChZs2bVjgU73W7FAy86dCnZ5qb2/tmCX
rp1bdW+Z1K0gNzIHIochR+AL8cXyF07IX4hDsADvFN/k/jkjWjXja8RXu/85XvUvHfxEz549H/cT
rbv+l8dO+rtup/3ImfZcYsfPa45tn/xQ58FqbPueqzq26ppr4M6nKnbKl+ZvW3MVjD3YuEO6lW6R
RYNvn1w8/LRJONrhcndry4xdzUqEJsTcnhVZOq5O+c532w4fd2DTG+ezzy264Z2mZ3ct75xYdXkT
p+HVbgcmXDoUrlGydMENv2w8Wytrl2tWJjW9+tivhzw/kBKHdyxsvp71eZ1Jm1fu+SBr8qWr9vfZ
0WDytb3np2VuGBMz/uzs/kkdXxm74vzFlV2azdjd6ZknG41+5rWnNxdp2iTHnLan0tWsFJr7Xu5M
n8QMmVZ4YrZt1xdU6vXb2ZajhlYvbc8sODfNV42nflG23gdhOyZ/nvUlQjXSF5iVUKdBq9ljNsz+
eFTuwR8PHXBy/ELOUUs4R025n6PstCP/T3X3GdbUsi4AOKETBJHQayjSJLASQEBBekdEggEBRXqR
GjqKQBRUBGHTm5hQlF4EFAVko3KldwFFpEsvUqTDCbhV9Hrv3ufHuT73VzIzWbOezHzzrm8mP7Jv
KdvPRnn/Rxzg3g80wsJn/t5uYO9kDUd5mDu5fhcKkEJKIgEJJEJmTygkwaevRSCo5P9CKAHg6Jci
p7OyvaudNQamglKFqaJ0T8ioSknDpY9LKMEBcRkVxFGA98s3Yv/lN0JZY7zsLa3/VrTOxpOotPsq
6X65p9FuqFDvHKnoa+BT27lE6ajs3fZinlpQ5Lin8xzzRBANtLbXHPScC+d1koSapJYEl7WljCLD
k5A8pYpKILKQnu8Sp1s9JndlPl/VMDgWdr/HUiLFQu3u84LBt6kyn7PPbbeOe3+UhM6bTlRrRJ9h
VSY3kg4NCKZ3nKpv0/bDOjd2MlyioL8dk2Uif6JeHubvJGbE6t8QKl358oWMXS/ciJV3VpiWwhgW
hs2cbY9XjQpueil1fYA64Wpt5+PBRFSvD8XKGC83uUWIsYM9y7brOkoiaPUogiXk5p0/zyVt5+hI
MmybTMbW56IShMxEMoeOHraqXSwS8PwqGiVhREgP4OXLO46nfn5OxI5ZyAJr2700dFza+AeseCXW
3uqruUJmFTa9NkuOFb2ULDkMGHzBikAVQKAKpxqi/G9h9aV5bxb3J5EQlftUGR2gigAVoHGAKtl/
RtUve/b4leAUv9JL/YVXkAmi36VTNnHRz/FaPFRPhJSJjbZcBV8WtoxurSriLrVyMmfvnZuYXoma
U05jVnm5sTGf/9g0IN5Ju0x5U8Dch8LgavF6YQKk1ONVzgRc75X/jr8uPrFbQPBJQe9AccR1nrst
S75b5vRO1dNNN4oG0itMSJ9MGaxYcDgKPLDU3hjBb1QMBMdZ26OKHrslWPHbVNV+MrWo/GNZLkVb
CUTdKk1Kz2/8XphUO8AhUbq33z0xrSVMjy81Y3pFPtSnySDxwlGbDEUywULNV6X6MTMfiK5b7Zzu
2tVO2xIK7JuTz5WdFb/VUM1zqc30JEkRpDTBSfbhiTNJ7WDGIxahil6E7Iq0kqBXxle9xPlZ9/VC
/KyX2T4LEMoo/tvRiyJWYBZGYsJcIFgAph8qKb9NFQIOHPuyjvm+r2N9FxcCEoS5s7extzT3sIYp
enrYuWDsPXz3lQIAaXEEkoCSOJKgFPKvInKv+DtTvL+j5hHmvCkLYFXNkXQJBlNK9EI5nmLrdmlq
/DR1eSeekXZw4ITHddYnYjjkzO6HF0q6vG8woD5JQ8jthgKY5vKCXd5p7fDMKl9tt2R18nfbRwfu
ed5qzXFXCegJ6luqWjyeUW+q+r4wX25Q0C6e9WEmxh39iSlmdFsyBoPr9jLj9Fa9HizN2OZuQvrM
Vj8885G92DsWqp0oD6FhLzGDfnrg/FpHuMV2Y72ZGkLvqQB0VAFoxQjRCvK8ltKVwyHlIpvx0mTB
prporKAwKfKJds8Zy/EOuMUnVbnxPArQZzV8artJGD9qwi9Ha1GtVUpWOrXU2zSTKTW88UgEWrYm
j9KMuPMrNRcJI2IMHN5betC9RIgUICa8HLDnl3kQ1X7itJc1gUMAOjLKv3YRDGAS0v2OCY+Db3VE
e71styN0O/lDY4cSLp3MQrg8kK3shQMs3z5ET0RyiBMCQoE8CTsPZZDiD7jR5GEvKaAF4seOQreE
hyCo2POjGYDeF9w0AXVAFaeMUwyR/+e4fWvGEEJ7T6V92AwOwKYBqAEqB2CT/ndg21swyl96/e/Z
FxEYdF7mVAC/WuG0i0IxssxhmkbMOUtzddrMc1bnJLxHOZ9qp3ESjkjnbbqqlxDIfSFPTkznWVoW
OmXEtaK8dM23TBOzempKMaBh6BCTfWNmCgy+QaX3Ct0MH9HqqHQdz6JOI85ED5aHahsuxiqlfFqa
nxsJ4ZKQLUcnLaB4g4UzsOzRwzHkHIvDumth+IYJaOYfunVsHRGYWGE3p2TWNfYFVLdtE8+uKUdz
WliVwCNfS7RK2tnm9cl0I3R/MpGqipjZ8ruCLizSeSsjFjo6bT+enSbyvO4YLY313cS+lbQNOn5K
a+mYT35cWhXtQ+iJNp84ZtN6SUaz/mgOzbvw5/kSKuxztAysoAv9kibcLQmvKeeCacLOONFAdeWu
CmmkYNqXHBtqZlzTDaMM/WPCcWwaxMarrem2EI/M47NwMaa6jxgpumWXYllb7Lr+o3BxRmtOmtB+
2g9Wyy4tal2dTJO+r0hKOzdFBrhCU/Mgm1ABhfzR9aHsALUK8kvq1pcUdIuUZnRnS7x8eyESlE7s
gQiuYRqD/jH85pg6bb5Vwq4eo+jValJuv+FYRQH7l9ERsfXhvcncBdSmKQtpBSF21w85wCu8LoM4
4vIXGa98ZrzO9/RWq0OWOkIs6f2Im1wP6JqFenvLrfpy5g0aTHhNulwhkYLDrn1y3DBtFm2plB5F
90s5AEtGTvB7/qvfjHYS+36z/w6/ASlAAiCILSkO7GWZhCRzrygO7BV/X/r7d3rfxzsWD/RpRAlf
vSzKMlQ1PFKbeJZXL7+ln1mX7/Bc+8N2nXwPAHZkmvyNQSyDZgybUlRBginA/w50eeJK1cxt8sOr
NCSErWwTV6M43817i8u27CJbV8ZvcUyN66bja3hRDeEbqq2UbRcL24qUSNLWHzhG2/YIvldDFYW0
jQmqiQrkhZw5p39olFhk0yEyEnC+uXQeuLdxrTu+ZII7/tpaB3SJ4gnKSb9UNfK+BkhL3eaIgJBN
VvxoJ1mQVtr6jYdH1OkpsfdvzJ7z2QEncehRBINoAbXZJx941SpewQ3uF3L6KCK8m5IHTl6PxpsT
lXFQF2+tJj8Ct/BoG+yuk758AaP6qncuYUQe/m96/zIx/EFv2oN67/0PNRCU8AXfoEggKPzX/OIt
M8z/4+GJpfXNZ8Rr4TLzddyNlsmhotb/b9T/R6ksYaxp40NfmhKrHO+fLM337mvxPXsaXCzq4Wbi
dAia2/L8SkS5aBddWpiTRbkhUaMuDKqX2O+nMGxYUWiUxD7EAQ7Jq/BZvNM2cxI8N/w8AkJaF64x
vIBi6D+TGzU6Hu7wJrDmY8wimVgw8eQfwnw8rpuft0Z9EkWpV8mHXSuZde/dvQzBxJbjZVJs4bVn
aaYsTOUZE+7A5IfJWZHrTQgtL4TcMQxV3ZSr3G4wBDrwAmJ+d6GnnGla905AreSxi+nV05X+VEpX
ulAY7jmgocLH2tQEzAShp+l4R5+wIvvUxqgELja+HhzSdBY9cc81xjFPRqfrs291DrOfhdB8WrKQ
BJk3q0W9HKcTF3aB6rVIRatyydj6jH/ZSEaWh2S5bq0bLx2/F5WsfpibsZoyfWVJSdFp27r7SruB
vtyBqQyAzYQS3UXWulQe7jblyWOTFcsaTSJdvchAHX5hDT4z4yn0/IMPifcaTrhUBQl4kB2Z8+Ku
TsbWCBg8LnaQu433Mi91xkMfVOeoL9C5bIciHR/tDJytC+Ott6m6x3GTzopIDl54PqJ8lHusrKjB
stTHgLRLUVQvL6Yo0ye3BBfnyfo26ibUk0cMmUXhjDMJO1qNm7/RwN09zXmmPmlOc3AVbO1ym8q/
zr7uo/PUw/gWhNAuTa2Jae9pNnzvhliqvOg5xsv10PRtBJYkHsCSRBOBwUDQzd+YL/9wUPv9mBcX
9GovS/srbCmJEYcOniET7vu9RIWgAQ62MuzlgF8vJEEQLAJ3rcLRWpDPCh3BtbVHUtlNEpIrAasD
lxxCoAEDnHCgIOg0yB5kCcKAXPaPoW1AHiAYyADkC3IllGwJ9eaEd3YgXzx/IN//uEY9fF1dbDHm
rna+sJ+eJSRYMAi6OqoqYvm4pLSUtN+CZ6MvkJLKzBsaf0XdvMAxgPwGWbN7n9jGiPPgfPDjpw/m
VaSfMd+CrGxmm4UvGTR72yULSovT5abkzFJ/5hq7bQWZYQksUugQlBN/xLw03BwdUpCvkps97Cz5
CFpFnRf/tMPQmzvqnrzIk+cv6kErnMWVb/vmaiRILBXDbF4vcNVsKt0YLTTVPzz5p/Gr9uA/8MOc
ddKJc2+A/kgDH9uSQqJzH0/l7rhvKCaauExb0vg5T0FXGRiMVk67dp5lnWLM2qlVwCZSe85PuH2I
Y95gaFwj+nQnJOyB4WOdpBWbi/IX/ySCzy0Y4iwlRiPeSDm7rnbV6tw4jscScQBYogOTS4bAEkEI
VWT7wRj82x7+P5zHkf8VirgLAPPBOKT6/oMHmHDHby2kiMN7R2WAJEKKsCc9Lk5IYn4Ow1UEh3jm
zRjYn1zZEpPkhk6zUtWtP9m8FyCqZe9t3q7PevVysNk4KF3WqXkNo6nvvfHh8tpD4odTr+VFnr6o
gEZdeP++sJHtVHq8pPZMZLjPhW7JkekegcoqYWNgMBiSs7NpU17o84nCCHdLMSSUB/kMVUZVV1LQ
EVGnXcnrmtqfTqxR9IZT+Srs4zuGuGeaFP2+NsJsqI+jWrbuNxNaHlRbXCp5d2qM8n3BjkcKMXVW
9BUv0jXt0YLPb1cG43Y9p5biSnFVfGbgkYIGv1bf5sL/StjlC23mzQYB2kDCTL1HtapahyErOfoY
27S+nP8dKpl098wzmtmhzr1Kwf4AfCtKecaBxoLl2UrYOf76tzKYvjlxRORhcquLPe6NINC/AOk9
jNsNCmVuZHN0cmVhbQ0KZW5kb2JqDQoxMDEgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9M
ZW5ndGggMjM0Pj4NCnN0cmVhbQ0KeJxdkE1qxDAMhfc+hZbTxeDEXbSLYGinFLLoD017AMdWUkNj
G8VZ5PaVPcMUKrDhofeJJ8lT/9QHn0G+U7QDZph8cIRr3MgijDj7INoGnLf5oupvF5OEZHjY14xL
H6Youg7kBzfXTDscHlwc8UbIN3JIPsxw+DoNrIctpR9cMGRohNbgcOJBLya9mgVBVuzYO+77vB+Z
+XN87glBVd2ew9jocE3GIpkwo+gaLg3dM5cWGNy/vjpT42S/DRX3/R27VaOULuqxraq9rezFVaaU
Za8R7UbE6epFaqwSyAe8Hi3FVKjyfgGKUHHfDQplbmRzdHJlYW0NCmVuZG9iag0KMTAyIDAgb2Jq
DQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDQwNDg1L0xlbmd0aDEgMTc2MzA4Pj4NCnN0
cmVhbQ0KeJzsnQlgFEW+/39V3XMfmQm5EzI9GTJKBgjkgBBiMjkBI3IkYKIEEiASkCMQQFSQuIpg
PFCfsoCueKyKJ5NDHIIurLCuIpeKeKxCBLwXQZ8HcqTfr3oCkrfJkpGdl79/6lPUt+7uX1dX11Ql
mQYIAISjiFCdVzR8qBClCwO6Og0zFw3Nyy+445e7hwPZ9SgAfW3oqJFFN417bi2Qt6cAPB81tGhs
zv6c8tFAF9cCRK+6vKi4YGbCNDW2j8Cjxl5RXDSsd4j5NoD4FgBT2ciixCRL0uLVAOQ4lpePyr2i
+PRNmbl4/CpMDxyXN6Jk1P3TfwRIdgNYH5g8s6L6mYGXHwWydBG2eW3ygnnSYzHvfwNkdTWAuvja
6qkzd9xQugbIMqyvnjW1oqYaIkCHxyvB41mmzrjh2r3qh2cBWbsNQPdw1ZSZC78+9fZ2gLy9QNzr
qiorpuyfU3wMj72Inb8KM4KTTSmYbsJ0r6qZ8xbmRFIso3g8x/IZsydXrHnz4V+APFMOENU0s2Jh
dfAsownrf4D1pVkVMysLb3QsBLItBEDfq3p2zTw5AVaiPWmsvHpuZXX8vhGbgdztATD8BVjfqyLX
uD+eFT8xKONHbbQWGI8fuiSBhW8+/+amE+tPT7WA1ohJnVKfgaEms/VKyLXAifUnbrTA2ZI2xOtY
jqkUYoEqGRQskAjjsOR5PC9DEJaTe0EFWtUaVTIeINoXCm/DtTRYq6IGtUgZYgskyFtgYa5iAVI8
IlcCN9ilONW7raNJsiaTNLiByLKMR3eqNrErBVHdZhIdDGdCD30fJsDvBPWzsCpQxxZroOC3tKPP
wtL/tC3dAd0JM7vbhq4g1sinutsGDofD4XA4nP8ryDq5ubtt6Cqq6N+PrRwOh9OdEJCbtegtwOdN
DofD4XA4HA6Hw+FwOJzfP6ZSDSHwnLrrLeZ3nO1ol/LjeH638P/YHM5ZyPmr/IaqnPNACO9NDofD
4XA4FwcCCIShEgRCcQ0UofqnYQsc18qgBa3cCjrQyadBD3pUAxhQjWBENYEJ1axoEJhRLRCEakU9
BcFgRe0Bwagh0AM1FPUkhEEIajiEokagnoBICMd4FERiPBqiUGMU7QnRqLEQI/8CNkUl6IlqBxtq
HEioDtTj0AvsqPEQh+pE/RkuAQfqpdALtTc4URMUdcEl8k/QBy5F7atoP0hATQQXan/oizoA9UdI
gn6oyZCImgL95R8gVdGBMAB1ECSjpkGK/N8wWNF0SEUdomgGDES9DAahZkIaahYMlr8HN6SjZsMQ
1BzIQM1F/Q7y4DLUfMhELYAs+RgMBTfqMMhGHQ45qJcrWgi5qFdAHuoIKJCPwpWKjoShqKNgGOpo
GC5/C2MULYLLUYuhUD4CY2EE6jhFr4IrUUtgpPxPKIVRqFejHoFrYDTGx0MRahkUo05QdCKMlb+B
chiHWgFXoU5C/RomQynqFLgatRKuQb0WxstfwVRFq6AMdRpMkL+E6VCO8esUnQEVqDNhEubPgsmo
sxWthinyFzAHKlHnwlTUGkXnQZX8OW7rp6EugOmo16N+BgvhOtQbYCbqjTAL9SZFF8Fs1MVQjXoz
zJEPwxJFa6EG9RaYh/oHmC8fglthAeptii6F6+WDcDssRF0GN6AuhxtR74Cb5E+hDhah3gmLMecu
1E/hbrgZ9R5YgroCbkG9F7UF7oM/oN4Pt6L+F9wmH4AHFH0QlqKuhGWof4TlWLoK9QCshjtQ10Cd
vB8egjtRH4a7UP+k6CNwD+paWIH6KNyL+hjqJ/A43If6BNyP+mf4L9Qn4QH5Y3gKHpT/AU/DStR1
8EfUZxR9FlahPgerUZ+Hh1BfUPRFeBh1PfwJ1QOPoNajfgQNsBa1ER5FbYLH5Q/hJXhC/gA2KPoy
/BnVC0+iboSnUJsV3QTrUF+BZ+T34VV4FvUvim6G51C3wPOof4UXUF+DF1G3wnp5H2wDD+rfoF5+
D15X9O/QgPoGNMp74U1oQt0OL6G+BRtQd8DLqDvBi7oLNqLuVnQPNKO+Da+gvgOvyu/Cu6jvwF74
C+p7sBl1H2yR34b3Ff0AXkP9ELaifgTbUP+h6MfwN9RP4HXU/fB3eQ8cULQF3pR3w6ewHfUgvIV6
SNHDsAP1M9iJ+jnsQv0C9si74EtFv4K3Ub+Gd+Sd8A28i/pPRY/AXtRvYZ+8A47C+6jHFP0OPkD9
Hj5E/W/4CPUHRX+Ej+W34Cf4BPVn2I96HHU7/AIHUE9AC+pJ+BT1lKKn4ZD8JrTCYVQZPkPlc3rg
5/Tvfudz+jddntO/6mRO/+pf5vQvO5nTv/iXOf3zLszph8/O6XPbzemHOpnTDylz+qF/mdMPKnP6
wXPm9IPKnH5QmdMPnjOnf/ovc3qLMqe3KHN6y+9wTv+wm+b0vXxO53P6725O/72v03+/c3pn63Q+
p/M5veM5/Y3/D+Z0wBkXTOMNYVoQgIpd/1GOtuPs9r+P9uN4frfgv/nmXAC061U1gbPiooMYwrrb
BA6Hw+FwOJxAY4zQsV98+7EX0nWc3X4dGsi9FV/xci4AP/ZWnfwYgfMboMaI7jaBw+FwOBwOJ9CY
ovS4rRFUXW9h6Dj7QvdWXbeA7604F4DQ9ap8b/Wfg5qiutsEDofD4XA4nEATFGvAjZDqwvdW7deh
fhzP7xZ8xcu5APzYW+kDZ8VFBw2K7W4TOBwOh8PhcAKNRTKyvZUf32EydZzd/k8F/d9bdd2CTv4o
kcPpCnxv1S1Qi9TdJnA4HA6Hw+EEGmucCTdC//G9VSD/Fwe+t+JcAH78uWonv6Ll/AaoNa67TeBw
OBwOh8MJND2cZtxbqf34DlNQx9nt16H+7626bgFf8XIuAD/2VsbAWXHRQXs4u9sEDofD4XA4nEAT
mmDBjZA/eytrx9ntdzz+v2+i6y34ipdzAfixt+rkV7Sc34AQmtDdJnA4HA6Hw+EEmoj+wbit0frx
d3Y9Os42t0v5/76JrrfgK17OBeDHVwE7+RUt5zcgRPTvbhM4HA6Hw+FwAk30wBD238L78a398I6z
269D/f9OVNdb8BUv5wLw489VO/kVLec3IEQP7G4TOBwOh8PhcAJNz/Qw3FvpLnxvZWmX8v8Na11v
YTlvDQ6nU/zYW3XyK1rOb0Dsmd7dJnA4HA6Hw+EEGskdATow+PF+iOiOs9v/jN//9010vUWw38fm
cM7ix1cBQwJnxUWHKLm72wQOh8PhcDicQGPPiWR7Kz/eD9HJ3qr9jsf/vVXXLeB7K84F4MfeKjRw
Vlx0iPac7jaBw+FwOBwOJ9DEXx4DejD48X4IW8fZ7deh/r/Lr+sW8BUv5wLw4zUrEYGz4qJDFX95
d5vA4XA4HA6HE2gSiiXcCJn9eD+Eo+Ps9l/DMndc6d/QdQs6+cIXh9MV/HjNSie/ouX8BlQJxd1t
AofD4XA4HE6g6TfeASYwW7reIr7j7Kh2Kf/f5dd1C6LOX4XD6Qw/XrPSM3BWXHSo+43vbhM4HA6H
w+FwAk3SFCeYweLHd5h6d5wd0y7l/9uru25BzPmrcDid4cfeSgqYERcf6qQp3W0Ch8PhcDgcTqAZ
OKM3BIHVj7dN9+04O7Zdyv/3TXTdgtjzV+FwOsOP16zEBc6Kiw7NwBndbQKHw+FwOBxOoEmf1wcs
0MOP90MkdpwttUv5/z8Ddf1919J5a3A4neLHa1Y6+fNXzm9Akz6vu03gcDgcDofDCTS5tyfhRijM
jzeiDeo4u/06NMxvQ7r+hgq+4uVcAH68ZsUVOCsuOrS5t3e3CRwOh8PhcDiBpnBlGoRCuB9vRLus
4+yEdqlIvw3p+hsqEs5fhcPpDEvXq/YPlA0XIbrCld1tAofD4XA4HE6gKXoqE8Ih0o83ouV3nN2v
Xcr/90103YJ+56/C4XSGH69ZSQ2cFRcd+qKnutsEDofD4XA4nEAz3psPURBl73qLwo6zk9ulOvkP
hv8NUpdrJp+/CofTGX58FXBI4Ky46DCO93a3CRwOh8PhcDiBZsobhRADMb263qKo4+y0dik/9mpt
dPJfEp/3TByOX/jx2hZ3wIy4+DBNeaO7TeBwOBwOh8P5P0Bo8zFAlPQMTGGMzAURRgH7gopFKY+D
ETAF5qrdUg8pTpaB7aDa5ciHfO6Up+WRlsq2o7WDqOFsNqEUgP7vCuhFVddt799x9tB2qbFdP94Z
lnW9ar2/x/6P96o7d2xxtjsr87KMIemD0walpiQnDeif2K9vH1dC70svccb3csTZJVtsz5joqMiI
8LDQkB7BVkuQ2WQ06HVajVolCpRAn3xHQbnkcZZ7RKdj2LC+LO2owIyKczLKPRJmFbSv45HKlWpS
+5purHnt/6rp9tV0n61JLFIGZPTtI+U7JM/OPIfkJVePLsH43XmOUslzRImPUOL3KnETxu12bCDl
R1TlSR5SLuV7ChZU1eWX5+Hh6g36XEdupb5vH6jXGzBqwJgn3FFdT8IziRKh4fnp9RS0JjTKE+XI
y/dEOvKYBR4hPr9iimfU6JL8vGi7vbRvHw/JneyY5AFHjifIpVSBXOU0HnWuR6OcRprGrgbulOr7
bKm7y2uBSeUu4xTHlIrxJR6hopSdw+rC8+Z5wm88HPFrEg8enFuy7NzSaKEuP2KaxJJ1dcskz6Oj
S84ttTMtLcVjYFsaX1BeV4Cnvgs7sbBIwrPRpaUlHrIUTymxK2FX5bu+Skc+yymfLnl0jhxHVd30
crw1UXUeGHODvSEqyr1RboGofKmuuMRh92RFO0or8mLqQ6BuzA2NkW4psn1J3z71FquvY+vNQW0R
o+ncSOXZMiWmVGexwjFne5YwixzDcUB4pMkSWlLiwGtKY1KZBnWT07AaUkqwlWcK3pFpHl1ueZ0l
neWz9h5VvMUh1f0IOAIcR/7ZPqeiLUcdb/kRWJSNk7NDDcvPxD0ulychgQ0RTS7eU7QxU0mn9u2z
wEsdjmqLhAF2H4zCvq0oTU/E7rfb2Q2+0+uGSZjw1I4u8aUlmBTdAO5EV6mHlrOSLWdKQseyktoz
JWeblztwJDcpj3SoR+s8+y/IEtYjvyrdQ8L+TXGlr7ywyFE4+uoSKb+uvK1vC4vbpXzlaWfL2mKe
HrklQjRti9FoQSnFQTn+bGWWKDF6xHj8p1YG9RSvRoujUskhUoHHUj7Mp6V6u72LjbzyMdZKCX5t
1mamJ93VPj2kXbqdecY6AQ0WnbSw+Oq6On27MhxqvhMObwtwxENxiV3K9cBYfDLj8Z9X3pLGfGm0
x41dlssq4PjzZbUl21WMbouXImx09u1TgBNdXV2BQyqoK6+r8Mq1kxySxVG3kb5GX6urzi8/M3C8
cvOd0Z6Cu0qxr6pIOj4UFHLqHWT56Ho3WV50dclGC4C0vLikgRKaW55TWt8Ly0o2Sji5K7mU5bJM
lpBYAgoJXmQD1Sr1oze6AWqVUlHJUNKTvQSUPO2ZPAKTvdSXZzmTRzFP9OW5lTwGm2Nyi0vOHT3K
I1naF2AjFAuXNjojbHteEXpDC3oq9G5w9bRtFC4RejYMsbm9gqMxODQpKLuvIOE5ExWVUGejX49+
M3oRJgqxmG9BXYK+Fv169JvR70GPawVUViqhn41+LfoWViL0FGIaJJsl+xIhEttG4jUECeFwFL2M
XgAbaiL6kegnol+Bfi16tVKP5cxGvwT9ZvTHlBK3EN5wfzLaHt5wpxI0Tp+RpCQrfMnxZUqy8apS
XzhitC/MG+6rlu6rNiDFl90vxxde0scXBscn1bJQb0rakh0mhOFFhqHh1aiEboMgQsAGjwqh4EFP
BXVbjlsIbuzlTFq7WRCBCFQguDiwyVsE0mCyJmXrqUyPQjDY6Lf0iK+EHmk0W5PWZl9OD8J69JvR
C/Qguk/pp7CEtrA+R81Cvxb9ZvS70R9Fr6Yt6A6g20/3QxD9BBLRZ6GfiH4t+s3oj6LX0E9QLfRj
Nj8pyuJZ6Cn9GNVC/4GX9Q/UIPoRxj6iH6Fp7zYMGpy0UYm4Etsitvi2SHh0WyQ4LMlL32n4pTeO
KCfeaRxRm4Q4yIRkIa4hfoDNK0Q0ZEyzeemhRsllezS7P90LHvRsQbkXz7wXJPSj0Jejr0avxtg+
jO2DWvT3on8UvQc9jjJUC3qJbke/A/0+6I/ejX4Uei3d04Cn8dLdDc4cW3YY3UX/DuHY4zvpG0q4
g76uhG/RvynhmxjGYridvt4Qa4NsA5YDtrFgaMEwEctV9K+NvYJtcraVbsa+s6Emos9CPxL9RPQr
0KvpZhrXMMUWjAfZBNu1gDUb4CslfAoe14J7us3tzMUBKDFxpl+GMZS10londTtXrsYkE+c992OM
ifO2uzDGxHnjLRhj4pyxAGNMnFOmY4yJ8+qJGGPiHFmMMRQvfeTlXpfYBo28jkjZQfR67KXrsZeu
x166HkR6PXPwi8hse6ghIQF7bI3b1TvBVttMal8htWNI7eOktpLU3kxqbyG1GaR2Aql1kdoYUhtL
at2kdhNJw66oJe6mdsnB7ghSu53UvkBqa0itk9TGk9pepFYig9xeam8YnqwE+UrQmM0eOgwvy8TZ
J4jasUftOObtOCdsRt2NXlZSbqwkxfkqR8ayMK4xIcuX7peeNDt7GN2KDbfibdgKB9CLeIO24jDa
igfZigcIQs1CPxH9FvRH0cvo1Vg7Dg1foWgQaiL6LPQT0S9BfxS9WjHnKHoKs9tMXK8Ylthm9EiW
olvRxaGzU7u7pyXG4rIME1bEkKBYMjJWjqWDIIy9NjDYqrV6iWnDz6bjP5tAl62j99AV0BNvxL1t
4YqGX3ravGRVg3OTLTuU/BFiRRx1ZDA4STyGaVCjpFMhRsvCFIihz2GY1BAzDpsFNTj72JqJmbXa
YPsl5rDtqxgvxeiXMZts70tekTTY3sOc5zbY9sbcYXsz0avFnFecXoJBs6RU3RiTZnthu1L1FixY
02C7mQUbbItjhtqui1EKKn0FE2ow5Q6yjXFebRuGx8uLmWRz1+AxN9iyYibYMny1UlmbDbb+aILL
F01AY3vHKCd1xCoHHDvIS6rcfTQrNSWakZqBmiRNH41dY9P01ERrQrTBWovWrDVq9VqtVq0VtVQL
2hCv3OJ2sZ1oiNrCArXIVFTiFsqUbVrZpEe0FC4HTw+hkBYW5ZBCz5bJUDhJ8vxU5PASPa5WVI4c
4gkuhMLiHE+aq9Crkcd4BrkKPZpR15TUE3JPKeZ66HL8lC4u8RKZZS2NZvuCjUCIdend0Sy8dOnd
paUQEbYgKyIrONM6uCCvAylvU9evRLSL9/SsLCwq8Tzbs9STxCJyz9JCz3+xjcNG8j05lp+3kXzH
gtKSjUIm+T5/DMsXMvNKSwu9ZJxSDyTyHdbDEfOdUk+LH8ysHkjaWF+9Nb568dge6/ViAdbT6SBe
qRev0yn1RMLq1df0ys+r79VLqRMuQY1SpyZcOrfO9nisEx+v1Amrhe1Kne1htayOJ1OpEhODVWJj
lCokCmKUKjEkSqky7tcqiW1V7jhb5Q7lTAL5tU6Mr46p5UwdUwvWcXWVyhyXizQOKZ08nm26yh35
lejLPXcuqIrw1E6SpPrJpW27MWf5pMlVLKyo9JQ6KvM8kx15Uv2Q8R0Uj2fFQxx59TA+v7ikfry7
Mq9hiHtIvqMir7Rx6KiUQe3OdcfZc6WM6uBgo9jBUti5hg7qoHgQKx7KzjWInWsQO9dQ91DlXKCM
8VEl9VrIKcU1vhI2UoMex2t5tL00J8xSnakM3iH2iJujm3G1sg4MuOUx4vbZhJ4V9c3um82K8Jli
RWa2s24rirh5iD26maxrK7JgttWRA65582vmQ0T+tDzfvxoEs+bNZx3uU1dNZ2BZPm6S82rmARR6
EooKPVm4mq3XaDC3nF2SJ/1MnsGQj2t7X2Y/zExnmYJwtiLLy2B5Ol1bxX+9//Pbwlz2FNTSTY3E
HUvmQU2p4IktLKY4FRS3bWGacS3FPh5qSvECa4iL1Jw5RpvZLhf40sCu+YyfN78t1tYX89pCX0ts
UnOmS87COst1tsfm4QFB1QyR6KNUT0Ok6IQIAPkL9F+ysHWa/CUrZyH9Gic6b5sHWAcvkGnwAmyG
18gxbLUeNwJNwJZAefAwLIIHYBl+rF2NOXfAGHQqzH+ARMpNkAiP4QfbY7AT614FN0MzhJEI+StY
AkuFd7HVUjBBHGTDKJgNd5Mr5PkwHg6It8IguAJmQTWplUvke+T75T/Dk7BReEM+DQaIgsnodsrf
qj6QP4a+2OJBWA0HyP26l8CNZ6nFmn+CubBGKBOJPFU+gRbY4Xq0QYQRsJNsoS48eiV8QSLIIiEX
j/KE7JG3Ya0YKIMqWAPNJJUMpXbVeHmEvBPC8BwL8airoQE2oPPCq/ARMaqOyX+Wj0Ek9IHheD1N
sItsEVpP39KahT2mwl7qDYOxZDb8Bf4Oe4iD/JXOVhlVSSq36kZ5L4TAABiL1j6NLT8nP9Ob0S0R
XhcL5BwwY7/cx3ob/gafkiiSSEaScbQ3nU0fEeaCFs84AN0UmIb9vQqPvh+H0QZqpLuFJ8TnxJPq
nq0tshnviBMegj/BX4kJr1QiNeQPZB85RHPpRPoQPSg8ID4jvqOpwKueADPhbngOfibBJI2MJteQ
KrKILCP3kdVkJ9lDvqTZtJheR48KVcIc4VUxB12RWCPeqrpddaf6y9aS1m2tb7f+LCfJt8NoHA+3
oPUPwiN4ZRthN3yI7gAcJCpiIGZ0ErGTseQmdDeTu8njZB15hjThWfaQg+Qr/Ej6kZyk+ElL1TQa
Fz9sCeSgc3GF+QB9mO5Gt4f+k/4ihAtxgktIFTKEUmE2WrVMuBfdS8KnYpS4W5Sxn5NUK1VrVetU
z6leUx1TGzV/wM/4HaeeOJ1wen8rtC5vXdna0NokfwqheA/x0wM3XBlofQW66Xi/V+KIWw/vEiP2
XRRJIJnkCuyZiWQ6mUMWYk/eRtaQJxXbXySvYC+9T46izSYao9jcj6bSHDoS3QRaSefgYux+2kT3
0ROCRjAIQUKokCAMFcqESmGecIOwUvAIO4RPhIPCT8IpdLKoF21inOgUXeJQcaI4X3xE/EL8QjVe
9ZbqM7VePVN9u9qr/g5XNZmaUZrRmjLNCs0GzV5tOY7OrfASvHzuz4hJi3CLkC+8BPfQZDEStzC7
cDxPhCnCCIojla4jy+li0kR7qRaqh9Ah5Eo4Jjqxr1+na+lPdIgwghSSIphOB/iOpg4Rn8UgQ9wK
R8RX8Np24ZEXqo3kZnpUbYQGXCMNxnP+TegvuoS34CPhANGIj8E/RD0JJ0fo08IoHAWvipmqErAL
D8OLwhyyGF6i+QD6k9q7cBxfSZ7FeaGYJJHjgozL4CtxFA0SDsGtcB39AI7gc7wc/kimiFPhHkgm
i+ALeAqfit6qWeoEdSh5k04T62gP0gRUfAavbjDpRQRVCNxGyoQ16qP0Q5gPu0U97BeeR+t30xeF
EeIx1RhShU/AYrgd5si3wA2qEvEdMhUEMg7ixRac3RYJSaIdwyU4q4zHOW0DPt3NOA9kCyMwJwJH
zhU4LsbiDLEG3SqcJ0QcQdPwGb8KZ7Fd0KQupl6YqjITnHUAxLdax8DV8lOwWp4Ks+T7oS/OB8vk
RXjEdfAZrIB1ZGnrTVCNW8kP8dm+QlVAd6sK5L60jn5Ii+jK9vcXezueRMDX6F7ERKZqE9SJ70MR
ZMl3ye/h6L4UZ9jVMAkXrIfxKr/FMwwTtkBy65W0Xi4QqvF6D8Bo+WnZRvRQJc+AkfAKPKlRQYXG
hffYQ97B670JKukYeZ5Q2ToN+2EF9oIbe2s+zj934GpYmfBU7HdJGgC71W6NR8GVM5yShC2n3Co4
CZK4hf3Ox4PWrsBPGRXoYHG9mv2gqYGCykvXuw3aDLVely5mqNMJSTx8+jBknf48K7o+Ril1YikF
td7wlqBLV6WJGZCG9YQMSiVCyFt6veEW+2OrcOV7peWHsowRliOWw3iIw5ZvIStrhOX057jybVTh
woRYMiwZpaUD+vcQrMlWQUhNDv1i0IGUJ3aTGYKO5LduOvVz6wM7dzJbJwiN9HrFVgPM34gfkccb
4+JTVF75uDvO2TvFoNZjJ+HeSaVSG77VabWCQEGjzdAH6Wp1VIcrBXeoKShFt58IYgYlbpM1hUQa
5zwdwUx0ZYw4nWE57SrLOJ0BWRnMqNMZKMQaPHgw8wP6E5erBzNPSFb03qSdfT8ZsLO/0EjCjx1r
/cqnbDuyCp/KILTTIoS7jdoEgylnLFW0nrL+3Qha+Se3wWikY7Vmk5WOpV752yYWwUv51n0pixmD
WbEqyCjogFCtzmAGrY7qDWqLhY41WEwmVK98YgOrZbCAV/68iZVg5HhTUJASOdXEakEiLjV2KoId
v2WLZc+eLdbg8MEul3JBLoj23XS3TSMZDOqxakUFRUVFVYpqvfL3bgeLUaNSQ200YtzMVGdkqldU
wywwmZQGx902FnOqiFHSB6cEKaIyCkDMBtBqCdWzC2dHUyLKQTbRcRCMm7txbhMoJwLlRHDmsEDY
tfyQ+AOanpWRlZHhu5gy39Wcs1qLdi8BGqQNodFacYHxduMb2JXG4cbhQUJvMd7Ux1wiXCMuMC00
LzNpDVSlHWwaaB5JC4U8jVs7wpRj1q+iq4WVmpXadcLTGnUwDTKb+6toiEpFtUaTqb9Ki1GtcUzQ
GOImlGq1Or3BYDKZzRZ2n8qDa4NpcDNdByYyoEElab1kgDvMqMOHwpAzVo89hSq5jUsMxNCMF2wm
BqxFvRgEEbzUn5pYPRZhwwRjUlC1hVi8dNzLkqpcVasS8BFc12gdUhrhisTHCx+wiNMuV4blSFSk
5Qimos5JHi6DiKysDGVIn3FRliNHlqn6uZYt3rasXwQLBvTHhbUBF9axuLB+FYzySRyl+4DK+9LS
0kpxQ23EskuxbCOY5OP1Zj3LVRbXJnnvBvtgcx/7YJMXo4MGm5MGKdGX+mJu38G+m1I6d04ZzCkj
ZbiBdrmScTYKCx84iNitDiuuxKyr8GPhmv5hkan4ga7a1DpufWuJqvnk9/cNG/WQcOpEgfjWyVSx
5aTEZoEC+UvhAD5dVuhJNrsX6aloijelmPJMqtSQ1JiraLF+TEhRzFQ6RVWpmxxSHrPFtlf1Xo9P
Ij/r8VnI0fBvIj/r2WKTbWE2mysqIywjqjCq2navTdOP9jL1C0unqaZCmm8qCBkec5V+nGmq6TP1
F2EnyA9mCwkVzAZLEETHGDRW0IfGCIYI36DMGcsiL7MbFZHMbt/3Lyu3L94adKYCRn5oYhWC2GN0
CSsOirdY9liJxeq2lltrraLNbTDQsTY3e2itwexhtmIjt5U9zVa12YwaoZSxIxjYk2E1WyxqlvY9
OtYzjwiLuMvZ2azzgrXs9DiZYCrYzM4b3EtjYSmNhZVs1uzWHNDIGtGmydKM1AiaWGaFJoLNK5pY
dj6N8hRqjOzImijlEY+MTRnlmzQVyua4XCOOYOT0OXudsjk4/DDEKTXjMHtWj+DTit7KJlMcbGWE
jQd7qtoR53SmpgQPTE4KC8cPABISlpw0MDXF6YhTC2mV25a8N3/63lvLVyY2npaen7/gyXU3LXzs
9kfuOvnEWiLUjc6m5hMFNHjH9r++/tGObWzuXYpD5HUxE0fHfveIxB7EIhKHmCLm4vL4WnGeqNZZ
tTqtztTDqjOBoCWGGLWGqEGvu/ReLdHGST1IDxpnVTrKqnSdVek6azy7r1vcluSBKcfYD5wk2AMt
+HnK+vzMxOu2srsEIus7ULN+VGZhdpOA3cqwoKCz05lWmcuuDB66LcJl+enXTnNlsE48bCn7YS5+
3GZlHbHip8/gwcqnEFjeXGZWntSyuaQs2ZocOhB7LVzDukqjDrUufTxzWtY1EzJzcoZMCIkVnY/N
GZb+9CVDs8rnnt6LNs8ke2gVrgANYNuIS6kit1mn3iFBf3yk5huveprZUXYEEo/gJ3EKuxuhIeze
zHywatqDD06repDumvbAA9Mwjr0snyLbxdn0GlxfxLqDSCrQKBX7tVKk2HgjGxiHyyyfQ+IIPJSQ
ag8VxRqy/b77WLtmXBmtI+9iu4hXgdKj+Nn2Dd6wY/UqkmjBC8YWxJ5qJ+tag8m3JP7Ftjaq6PO3
UUWfWKuq+LUNgc7afPbreaC1mRT82kbbhTZa+LlZe04bSxfaWOBos8XXhv1Buc9dh/vJADg6yx8n
LO7c4Z4n8K5/ANwV3HHHHXfd4q4NiKvljrv/B90asUncxR133HHHHXfccccdd9xxxx133HHH3e/Z
AUA6/Qv4vpkOMF1RFiegV1IsTsEMX8OZb7BPgB1tcfGcOuxvME+0xdVgJgltcQ1MOltHC/2V/+Ke
xXVQR9La4ib6LHnt7DeuU8UZbXECKvGxtjgFzf/w9jXgUV3V2uucM+dkwpwEmiJQys8UYxoopCFQ
SiMfUoyICGmaxjEzzZfmP5MQksnkzE9mhmQm5iJyA8WIWBERuTHSXETMjRgxUooUAWulpEVaEAtF
/kRKKaWUInPfvc+ZMK2t3/f43edjnnfv9+y99tprr7X2Pud0ktR0yuASPWg6YnBTnIxMqumCwRVK
kAWDJ9D0IRkzjTE1GTyRviCbDZ4kfEVewn4j3yRhLlXZwrkMPkLp5Vzh7Xs5T+DtL3Fu5vwk54mG
D3Wu+1Dnug91rvtQ56Y4Gd2HOtd9qHPdhzrXfahz3Yc6133I+LA4+y3ctsucq3HtyZzf5nwEsy1B
13k3eErCOM5Hxsl/iuvR+ai49nv42AzO7+Uyus7xcTIT43gql5/D+RTOF3E+jfNCxs1x9pvj5lLj
2tXYWp4lK2XBI+wndK1UQE6qRL2EGqge0KiZXLzl87hyg7OyFO01XCIDPY9SHT5WykdbNcZr1MSv
KlFXQtqLsgKSj4LXYCyTreEypYDG9VVAZhlqNy1FWwNV/Uu2fFQy+0NzMouqyQPO5skmG7euyRht
pYegYTo8YaV0aKqhcvQ2oJ9Zo9HkOF1LYNs/WlUwxHK4XT5I12NGKz0GDVVcI+udxm1pQEbW8Hlz
eY8TLcyyJpqKtjy+LjfvqeF+egKlB/IVhtVW2PoIzUbs7BjpwTXzXzNqD/c786zT8HMVt1XjbQ0o
K3i7i8/XzOPA9FrR4uY2MclyY0ylcV3KNbn47MsgpfE+NqqM69CMaNUZ66wfskIfEbPDHSfr4h6u
gMXlfA7dHz5uN/PIx69Bv2ay5ZjNwz1SwTPxo55gI+o4S4f8ZNQsy8oMuz9ed/3/w9rvaK8Yir2b
74NYLGO5+nEriM3+j3Z9Ni5GbCX6WjQ+X2wXMP36WivQ4uMrb+A7659lQumHol7Jo9NglPqqdO7B
lYuXVm6tdyibdT1Msg4S/yyHMp61ZmVOn24tcFZalzTUN2jNrkrr5xvcrgZ3qVbTUJ9hfbSuzppf
U+3Umqz5lU2Vbm9lRcaj7prSOmtNk7XUqrlLKyqXlbqXWhuqPllLrDFbH5lfWe2pK3Vn2yrdTei2
PpQxPdOavqSm3N3Q1FClTeZSSwqGVBWwIsdd6qupr7Y+VlVVU15pnWbNbyirqbfm1pQ7G+pKm6Za
80o1d015Tan1iVJPfQVUW6c/MjvL3uCxLitttnqaKq2aEzZXNdRrVq3BWlHT5KpDR2l9hdXlrkFj
OXoqUZc2WV2V7mU1mlZZYS1rxrBKax3mrGcq0MF0uHmry91Q4SnXrLDD54QhcTOgrqkvr/NUwF/W
mBEN9XXN1vSaydbKZWXQHSdd/09n5+IVbPXuyia2SubVOxOw4UO6PstXlF6DWbTKZSwE7hrMWtHg
q69rKK34sBNK9aVXuq1YUQOmQunRXB7NWlHpZW6GjLOyzvVhD2XgfGzg+46dvPXIcHZyNgtJyKpa
XF/gp3Cs/wnkmb5T2I6okDZIP5N+LT0H/FLaJW2L01XKT6rY9Smuu/JDc1V+SBvXZ5pgmm76sumL
pv+F8hFIl2InsD2m3wmcwg7hh3gcYzuf3S3c/MRmOvRnQ4reT5/0/3KWiD0F3UVCNKr/VaMl4nOT
xEdMaUTzXpd34dqqJ3TsXxT/6HPR24/mL87PzDT+vCZ7ElNRXRFuQFseHvo6SBBXi98lSdwgbgD/
nvg98I3iRvDvi5vAfyBeAX9bvAH+vgQLpBQphSTpbmkB+BelL4MvllrAW6VWEqWwdA38XekW+N+l
2+BR9psPJmJPhSbNpIF7TM3gAVMAPGj6Jnin6Vvg60zrwL9t+jb4ejmLBHmGPJMk+SH5YfDZ8mfB
5yg5JChfUDCvslhZAp6rPAFewH68WbEpXwUvVArB7cqT4EWKBu5RPOBexQfuV/6NRGWF8nXwlco3
wFcldJGQ8KOEH5GU0J3wc/Cd5kdJNM83h0gyLzdjdeZW80bw75svg79lvgb+biJmSbQn+khK9Fvw
NGoZZkkiyZJsSQefbJkBPtPyY/Ctlp+C77A8D77Xsg/8BcvvwF+0/J5Ey0sWPFNbLlr+hvbLlnfA
r1mug79neQ/8hgWet7xvuQn+AYInqYL6Gzyh7VN/C35AvQr+jnqNRPXdpBEkJN2VdA9JSWOTCtkv
+xoxF+k+7nnd57q3DT9jjflYUYEZfjMXmjHK7DAXg5eay1FWmV0oveZmlAF4g/khgrLN3IaWr5m/
Bt5uXgH+dfM3wFeZ/x18LXzFvHTV8IkIbzwAPtXyINaSacnk6/0r+CXLJb6WF1DuV/djRb/Futgq
RqEcnTQaaxmTNAb8HrYuYz3DaL0wQHKpu7SMrOXN7jqaW+2uXEq5zsoyNxXXlWr12P3DSPhKfo6V
RmJnReEDE1kMhvcY7hviu4m9yyTFXQt4H0geuhaw86BpccFCK40yJES8GQw3uITeEXTX0kp3PTl5
Wc9LjZcBdkOiMC9X8nItL9fzsoeXL/Hy9LKly5bSdV7eZqWg8DKZl6N4OYFo6M3to6Vo/EJ3rBbY
X4SA7TJ7U4O9w7B6lb8dwlpKobvhl09hRaPxTsR+Y+xeGkfj2Z974P/nnY8b93FtItZv+lA9HPo/
qZ6Mp+AinId1OPVC1E4dtI42Uhdtoz4aoH14Z3uFTtAZukTX6JZgElRhrJAuzBJyhMVCgVAkuIVO
YYOwRegReoVdwl7hkHAEmvGGKazA7HgbTcmEjajHO2Epaivp9X1n9L0wqV2vZ93W64cP6/UjGXqd
reeF8MXrer3wpF5/aa9eP24lE/vV+cd7SGF/Wu6pEClIIKH0jD5/+SZmDQkV7G/OJaDepLdX9Ot1
ZYZeV4/icqaajJr5NbaaWuPqWM2lWqodqV/VHq29WHt7aYp+tTS8dN3SrUsH9PF1LXq9rFav63O4
lLlhQkNWw8KG4gatYVXD5oadvDXJtdG1w7XPdcx1qZEaRzamN85pzGusaPQ3dujWutnfp2B1sa7N
XaXXTfP0WuvTa89FXc5XbNRVPNsE3xoShru4h2rohKAgblnCPKFYcAltwouiKM4U3WJIXCWuAzaJ
XWKveEC8iK2TLFmBRZJL8koHpCO4R4w1FZrcppWmLaZtcpa8WTogH1KsSq3iUrqVE1JygpIwEiPw
SZifUJhQnFCR0JNwxpxt3mbebz5svpk4LjErcV5iVeK6xOvDZg7rtSy21Fs6LOstmy09ljNqipqj
2tR16tEkShqWlJk0P8mVtCGpK6k36ZWk68nm5KxkLbkzuT/5UPKx5NPDTcMnDZ86fBGyPTX6ND0c
PU5zoseFt6NPC+8DH0SfFgUgMXpcHAYMR79AI6NO7A+JyzvpESA72odxTrKj3wEUATtxLdHw6Hi6
C2DaEzCmL26Mk48pQttO9JrQe5yG375BdwGp6DFxex4BsnW7sKO5DPSNwAimdzwwget3Uhb6csAX
AAuBxdCcj/orqG2oC1E7MK4ISIKWHENLDrT0QUsf15IDLET7YmjLR81Gs5HMThWjnsao4xj1NEYd
x6jjGNWHUX0YxUYcx4jjGMG8cBknQmxVIzAPW9l4jJwQDcbNlWNYmkNP4LoAdSFk7IBIX2KepM9w
Tz7NZ91Ji9lJA8m7AHGoXaCfQ1biPrZx/x8nWZwWLRFnAYuBx6MDYkF0APtheHQixkzEE1IX4pyD
OOcgzjni2OhW8X4qJBmtx9F6HK0s8rsR+d0kofWFoSuTkBV9UxwXfU1MjR4UO6Jv0jAhI/qm8CAw
HZiB3hHAaMAKTALSgAcgmShMjb4qTIM2OfoqsssJrU5odYqjMB98Cp3sLxJhLhoJ2dWQXQ3tC6B5
ATQvgOU9sMYJG52w0Qk9q8Wk6CYxBfzuaJ84BvVY1PeiHg9YowuwsjJxcnQBidD7MmZ7GSc8y2Jk
6v+VPQqTZpKG1DdiUjQcrc9j/NOw8Rw8cA52noOd5yD5PLxwDl44J94DTASsQBowGXggeu4f9A7N
PhSHVz8UB8XIqZvIp5vxXiARMdmEWGyi+4ydwuOMnJuInJuIOY7DyuOwcqKQCUwHZvA8GPiIN4/D
m8dh+UQR48WR0Vx4IhdereVeHY96As4FK/o+Hc2Dd54WP4O2+2lATIfcZLRPiebifhuzdAT8DmuN
7H/6E2L6USs+HNNR4B8f12YeV5Z/vfB+LzT2QmMv7O+F11+DVC883gupXni8F88EsOt/PK9SoMmH
+fugzYdI9ECjDzb4MPo4rO/B6OOwZxM0HIcGllk90OCDbT5o8ME2H6LXg8zHvqKkf8imj8ukSR/J
JjbqFEadwqhTGMWieArSpyB9CtIvI2J/wIhTGHEKUfoDRp3ivjuIUQcx6iBGHcSog5jrIEYexMiD
GHkQIw7iFIjte7bnLZ84LjYmTR+HWQ7iuWV4VEFGKvRs1Ec9QG90ECfXzmgJL314atsJj8+lHPHR
6AXxCzRNXBgdFL8E/mXU7BRbEu0Wc3GSPQ7+VbQ5aLRYh3oZZOrBfTSNksVstDANC/nICxjZhZEv
Y+QF8TH0PY5rnIXQcEG0A5XAMtjyKYwcEOdCYh7XMCB+gWsZgJYBaPFBywCf/zHYoWtZDQ0DYjHk
qoA6cGZLA9AI3hy9gKfOj1k3ZvJhJh9mGcQsq8UFsG8h6i9DK9PoAC8CiiHzFFAGXglUAdWAE221
qJeh9qD2An6gGfoVcQl8kctXuksshT+duF4G34h8vqWwapjhoUHdQ+hfAn8XAMynTyGfnNwrF8hs
eCHmy0F44QL35ePg8B/uNPHe1ufexf4WAK6e5DOPpkRjxAVdP8BsWqr3wlcXELvRZOGxi0WAzbsE
9WPwiT7XIPwxyOMFD+O5fvjt5ThZluNkGcTJMgjvrh7y7DxI3fFu3Fp5Ngwa2dDFtTp4DEuw7m6s
u1v0oa0Zd8vhQ/bwjIRUTNNi8CU8E1Yb99ZdPJ/Y6krgRawIbxqxJ6Bno92wrduIPMuxAXEeJHWt
g9DYxfNKt6ULke+GLasR9W6xAqhEWxW3rUSsQc0iv5RHfzU80S02AR7AC/iB5uhqSoN3rsA7V4a8
o1vRBSsuGF7qMjw0wLM8l+8J3c9PAiz//jdkdM/4xBL0l3KrusRy8ArUlWivQl0NsJysQV0LLAVv
QO0C3EAT4AdYfpoNrw7wmRdD45KhCO+CxgFK4HbFdp5u1y4jIweRxQv53mf57IhlNjtB2M7BWxtO
lLg8GjC8vAuxGzSygMVvhpFXJcY50IXs43FB7sei/RhG6Vk3gKiOZrbxfc72tWpEstvI1a64PbLa
0M2yqsuI3gW8WZXyM0I/rxqxkuGI9stc5im0lAClPL+ZPN+nbL1iPc/3AX6iaICPWzBIIzAaOwxg
588dDexEe5nbyTy2dGhOXVMjtGvG2TQsdjZB06Bhx6ChYRCjmQ2DXFLEmEG+RxONGQfj7B2IO/kG
mZ1Y65Nxe1tDhCxD454asvKOhfwEN05NzITzCfGFjmn8rChlvo87M+oM3cwekbcyb0p8BqaZnTjm
OBv19cQ832B4n0m8bPTu+mgvX7WJR90Zd0INi+1p7nuWF9zvOGN1jxmrgeQISM6A5AzqwXiHcRbe
GTGaj9CjdA57Rh/JfOAzMixhyGPx1sdsSxyKfsyfd6Id8+UgVvCRXnjpKeNqGfdeHXZAI9+VPDbM
27H4G3fXhiF7Yh6NWR7rZTOJQ+tNGLrj3Tl5SnDylPA7fiJ/U/g/vSWI9BD/b09EI/ERKJXYN7+T
8ZHoQXxMNAMfGVIP4Zn4YXwS6BHKxvvNHHyG0ZfwsdBX8FHJTg688xXhM5x+jneoEbQPnxThAWEa
3S08KDxIo/A+P4NGC28Lb9M9wrvCezRWeF94n8YLHwgf0ASR/dGUiaIsynSfmCAOo0miKiZRmjhc
HE7p4mhxNE0W7xHvoSniveI4ekCcKN6HzE0VUylTTBPTaLo4WZxMWeID4gM0Q8wQM2imOFOE7WK2
+Cg9LOaIC+hz4kJxIc0XF4l59HnxCdyLF4k2sZAWiw7k/2NihVhFXxWdiIpDrBVd9KTYJDbh6dMr
+qlcXCGuoCpxpbiSqsUOsYOcJCgVSg/7lptO0kwi10ZgCwnuE6i3AtvBT6PuA3YBewzsB140cISo
0Yn6GHASOIMx51FfBK4A14FbkBEBM5AMjATGAlYgDZiKMZdRZwGzeZ/gvsb7BfdN1HOBHGARkAfY
SGhC2BuLgDIiTzewDeglwdOPejewTyh1bXFnu01NLa497vyqYneF66LbxXHL7W00uzeDb2ssalJ5
XdakNl5yh4CVrq3uea7tQJ97XnWme17jS00FLsW9wLXLvWBI5pi7EG3z0DZP11+9trHLXdzY4y52
7Xfn8/4XUZ9EfWfeUBwvdl1BDTSKGJcM2evALfdmXG9utLq7uV2sPubehjl24/rwUH3dfZTjlvsE
x0X3aeB8Y5r7RONUYLb7NHAe40835jUpHDnumzEeW3tVcdMEhsZA0xSOFU2z4Lf8xg73BraGxh2w
cwvs29lEjQNNc5gvYj5ovNTkAErY2g0fQx76GazumzH/xQB/LWY+jPmN63rljj7XEaz/TJzf9rgL
edz2w4Zj1euH2j/aH+dH+MTFgPgWx/m6LT72nyDjbRyJdSe71wDrwNexeIBv4O0xjNXjw+IUDx4z
sx432NRr1P1G/Pph676Pxq8xC3Fi8ZqLGM01YsWwo6mdwwqf56FmQHvTqiaFwZBZyxHfzuK7CJiK
fNli5DViDN16ftv0Gu0n0J4Sy3teO3l9E9djUK9BnRJrb6xHfoSRGwzxXLvDkUOpyJ9Mjg7485i7
trETvnsG4NfV6xs3IafuxGol3y9FLAZN82PgOREDy43XDf4GcDY+92L7EPuO9V1qqsK1F3Ud4G68
6r7ceKPJ33jbqPU49ML/h/i67uyTy8A1lvfw50L4LZf1c2x0z+R7kuWBaMT4AGKyF/vAqF17mlp4
/vOc5PsglrOFmI/Vk5iNejvq2NkQn7NGDrJ8RIxcLOd4Thl7X7vBdABXsMevuM9rt7HfjwHX9WuP
CevIu3Ot54dnEkdcrsTWxXPBrMedX5vZNfTHrsWmFAbEdJYnHWvnZ0JTS2OHJ4OtxTMT9mGferJR
n2TrYueHexKHGHd+wXbcXSz8m1Pi35ma+belifw7zWT+beYI/j3mSP4N5r38u8v7+LeWn+bfGKbx
7/syoOU34lsi7ifSRGkiidJ90n0kSfdLk8kkPSA9QAnSNGkatD8oPUiJ0nRpOg2TZkgzyCI9JM0i
VYpI/0bJ0telf6e7pdXS0zRG+qb0TbpX+pb0bRonfUf6Dk2Uvit9l6zS96Tv0X3S96Uf0CTph9J/
0GekH0k/pnTpWelZekD6T+k/aar0E+knNE36qfRTypB+Jv2MHpT+S/ovypR+Lv2cpku/kH5BWdIv
pV/SDOlX0q9opvRr6df0kPSc9BzNkp6XnqeHpRekF2i2dFB6mR6RBqVXab70R+k1+oJ0XDpOC6U/
SafoS9Kb0puUK/1F+gs9Jp2TzlGedEH6Gz0uvSW9QzY5XZ5KT8pz5BwqkRfIC6hGXigvolp5sbyY
lsm5ci7Vy3lyHjXI+XI+ueQCuYAaZZtsI7dcKBdSk+yQHaTJRXIReeRiuZi8colcQj65TC4jv1wh
V1CzXCU7KSDXynW0XK6XXRSW3bJGX5O9sp9WyAE5RN+QW+QW6pDDcphWy21yG62R2+V2elpeIa+g
tfJKeSV9U14lr6JOuUPuoG/Ja+Q1tE5eK6+lb8udcietl9fJ6+g78np5PT0j40PflTfIG2iDvFHe
SN+TN8mbaKO8Wd5M35e3yFtok9wld9EP5G65mzbLW+Wt9EO5R+6hLfI2eRv9h7xd3k5d8g55B/1I
7pV7qVvuk/vox/JO+Ve0Vf61/Bxtl5+Xf0M/k1+Qf0t98kH5d/QL+ffyH2iX/LL8Mv1aHpQHabf8
qvwqPSf/Uf4j7ZFfk1+j5+Xj8nHaK/9J/hP9Rv6z/GfaJ5+ST9EL8pvym7Rf/ov8F/qtfE4+Rwfk
C/IFOij/Vf4rHZL/Jv+Nfie/Jb9FL8pvy2/T7+V35HfoJfld+V36g/ye/B4dlt+X36eX5Q/kD+iI
/Hc5SoOKoEh0VJGVBHpNSVQsdEJJUpLoz8pwZTi9odyl3EWnlLuVu+m08inlU/SmMloZTWeUe5R7
6S/KeGUSnVdSlVS6rKQpafSWkq6k0xVlijKF3lamKlPpqpKhZNA7SqaSSdeULGUWvavMVmbTTSVb
+Sx9oMxVPk9/V4qUIkFSipViwaSUKCWCrJQpZYKCp8ZqIUGpUWoEi7JUqRNUxa00CcmWREuiMMLy
M0u/cJeKx1/hHtWkmoSxqqIqwr2qWTUL49Rh6jBhvIp/wgQ1WU0WJqoj1BGCVU1RU4T71JHqSGGS
OkodJXxaHaOOEVLVsepY4TPqOHWckKZOUK3C/eokNVWYoqapacI0NV1NFzLUKeoU4UF1qjpVyFQz
1AxhupqpzhGy1LnqPOFz6nw1T5iv5qv5wuNqgVog5Ks21SY8oRaqhUKB6lAdwlfUIrVIsKnFarHw
VbVELREK1TK1TLCrFWqF4FCrVKfwpFqr1grFap1aJzyl1qv1QgkJ4myx5c7zcyWeRyvLSKjGc3Ql
nokr68G3oNaAABA2sALoMNBJVJWO+hlgE9CFMXj2ruwBdgA7gQFgL3AAeAl4BXgdeAM4C1zCmO2o
rwI3eJ9Q3cf7hWo8t1fexhwmYBgwAhiFdjzHV40DJhHVVgF1gJuEWj/qFqCd7qXZtIDy8GbEfnrH
T23UQetpM95V+2g3HaAjdILO0hW6KZiEZGGMMEmYKSwQ8khy7HxykmPgyXTH3idxcjtWOU46NjrO
gIUdbzg6HWfBvI5DjjbHYbA6x4sOv+MIWJljp8PpeAms0NHvKHYcAst1bHEUOLaC5Ti6HIsceFtx
ZDvWOBY41oFlOtY65jjWg6U5NjmmOjrBxjlCjkmONWApjirHGEcdmBl6kx31YKMc+Q6ToxBMdRTY
bzocYKJjrv2KI4dE+w3HPPtZxwKwy44p9hOOTLAzjqn2I44ssL3oPeAYB9bvmGPf7ZhAJvtJxyJI
5EHCZj8GHSaUi9Cah1ab/aKjCNKr7Cfta+1Yv3OH/Q37CufO/7F7osx/3oj4TxrpP9OTyH+eZjT/
aZh7SEBU2vBmrCJeU4nKkEdlyKMy5FEZ8qgMeVSGPCp7wwByqeySAeRS+UrUsLIM+VOO/ClH/pQj
f8pHAcidcuROOXK3PANA/pdnA/OABcBiIB8ojGsvBiqAWsAFeIEQ0EZUjXfKarxPVuN9shrvkdVn
aKo93Z4BzASyq5PtC+yL7aPs4+yT7IfsFfZ59lp7vr3Q7rJ77cX2EMo2+0p81tjX2TfYN6Ol274N
n157P/hu+77qRdV51TbG2E+Rwf9YoXhNfJdE8T3EwsRjofBYJPBYqIjFI4jIZ4cichci8jiNUZ5A
XMbxuIxXHIqDJiIu28hq2Y7ofMbygeXvdL8lihhN+f84k0DzSOOxziDzP48TzgtzoVYYKAwXrijs
KOwsfKaK/XSKWXxHfAfkunidBDlbziZRyVfySULu2cmkPIkMlC0/sfyEFMtty21K+JfGCCmX70Y/
qcJuwpnjhK3OZGAkMJbEMHLNaQXSAOSsM8u4ng3MBXKM60UG8gwZG1A0BMGpkRgxkYhzUYwM4zU5
y8BHgO+Pwy60jQLG6WBtSFExMkkfz5FuIMOQnwlgpZF5wIIh+Ts24ex31gM4950BroPZzMcY85IT
9wHnCi4nRhYbbR3/AnD/cD4TB9xDnF3cH2JZmMSnVgyBnD16Wxmbewe3jdvHr3d+IvT+AVaLf7Kt
8u1p3awt9ARau23rm/tbt2m5nuTWXq2geXdrv5bbvA+9DrTs1kpQ7tOqmg+1HtLqNH/rYd7Sr7mb
D7ce1fzNR1tPaCXNJyDD5E9j7O7W81oL+GWu7ZpWgFnOawvBb0LyNCQLms+HybbVvymsaO2e5LDK
W1K0Vc2XW7u1tc3XwmO09c2HUW70OFFu8QTCE2z7m2+GU7Wt3svhKdrGAIUzte2QmaD1+arCs7Rd
KOdoe3jLfv+l8HztxYASXqgdCahoOYZyjG1/IAWjNgbGhHO1k4EJ4Vm2M4HUcIF2JjAl7EB7CiQv
BjLDJdoVjK0CTwG/GJgVrrMdC8wJu7XrgflhQrkQ9sNvYb92K5Db2u8RAwWt+zzmgKP1NHgJ1rg+
sJ2tIq7cHujjHKUnj7ew1W1E+y6s6x9Kjy2wJ+zwFAX2Y71VgRfDW1AeaT1kux44Fp7gKQuchJ5P
KLU9gTPhrbxkkii1LbzcjrGpnuRAVbhFcwTqYK0zcDG83VOP9j7NHxpWutszMuAOk2dswI/SHGiB
TCBwPfyiJxy4FT7i0SC5y9YeFFvPLy0JtEPGyj2gj0oL5IbbjZapgVXhVZ4slGs9swNrUc4NrA+v
9+RwnfHlosBGeG9RYAsvGV/hv4p82+7bEz6m7dK2hk96OoLmsOrpDCaHSzzPYJY+rGhX+AzPt16+
rj2IxdZwim6hlhu4gqxj7fs9m4IjW0/YrgfHhi96soJW+HBV8+7wFdsx+P+6pyuYFr5lOxKcCu/1
MO7ZwbjtSPPuiKjdCmYhP1nsjnl2BmdHzJ6BwKxIsmcvLO/1HECed/O90+95KTg3MtIzEMxB7yvB
Ra39iNSZiOh5PZiHsW8EbeH5nrPBIqyoz7aKceTqMW2/pxN8Efy5D/K7wmOWrmfccylYBnuuBp3Y
U9uD9YjpraAI22xBLTLWM5LzG4EXI1Z4PjeSZrsVDITPeG4390emek3BcCTLOwxR6AZfEZntHcF0
ekcFO8KpOtf2BDuRCWzsXO+44DMYq/NJjNvWBze19nrTg12lh70ZwZ7W8ywfImnemWxF3mxo2Aar
ysDnBXcM8QXBnTgZmK9SsSJw5B64dzHj3nzOC7GiE95i6MnxVkAPj0skR3MEByKLvLXBDrS7uLXe
4N7wBG8oOABrtwcPgLc1jwuv8q4MvtR6yDM7+ErrIe/KwIucv845dod3jaezdDfOhPZInndd8I2I
zbsheDZS5N0M/WXadltfxOntxkkygZ1gkWQuWc9miWjakeClSA729XmcWkcCmZEcjxmWnPbO5LHI
MfjV8BjvNk9ypMzb6/OXTsIuQLbbbgW2RwKam+UDfH4j7PD2G36+Cst365ztQd3/fJ9O8O5j89r2
BFKw6kPB2+Ej3sMhE9Z+FDKbEdOrpSs9Nv/I8HzvoeV1YcV7Yrk7XAXu57yF8zvtR0MhREoLZJau
1ByhEcicY6FRyJyS0Das6FiwJ5zqO+Lb09btO9Z8rW3b0hJ2F/CdXN7e1uu9HOpu62dnbNtujzXU
3drvO7N8FeLIue06O3t9F5evbdvnu7J8fXi+77qvve0QvNfSdpid/G1HcbqqbSc8OeCnMXZjeI/v
VvPptvNon9V22duPk/8a2rcgB7YFB9qu+cXlW8MbvUfh7c1+M9oNDvtnhTcuLWkRkdVHAn2Rs76L
LWbMu7ElGZmf0zISJ0YZO8e8I1rGYl17GLetD43DLsZc7PwMTUI2nkDm7Paexr2p19MZSm896j0d
ykBWnw/NhOcvh7LD7d5roXmt27w3QwvgpdxQdiQNfluMnNweysepshCSqeyuEQnbVoUKeUtxZC4k
KyIrfBSqRSafDrkiHT4l5I10spMq8oxP9Ze1HvKlhEJh1VscamN3KG86LO/0KZFNvjGhlZAsCQ6E
b/kmBCjShRnXIFL+0LrW077U0Abc6daHNmNPLQy1ISu2hbojPVo7u6viHpQaLvFNwdml+jI9Z5HJ
Jm1jZAcy+QROoa1aSWQn45EBzL4Y3ljbfD6y1zcr1Bs54CkLbYu8BG/0R16BnlmR13Fy9kfewImB
k1Dbw+z0tbRY28divdRu9Xe0pLWn+TtbprZP9T/TktWe5d/UMrt9tr+rZW77XH+P5m/L9u9oyWnP
8e9sWdS+yD/QkteeZ9sfuhxO9e9tsbXb/AcCF9uLsK834QkB92uspbClCHwL2+/+ZMSu3/9SS9nX
HJrDtz2yiOVP5Abi64wsYvEF39tS316m7WnRcD7sbwm0O/2vtIRh1euwqt7/BqzS/GdbRsbOENv2
lhXhW+yO0B7A2LHhdpyouNtirg7kVSf4HuQVOMur8B7IdIbb9fzxHuWc3x99F3G32uJd2ZIcXhXj
gT1t+7z9LPe8xS3PsNOAcW07eCr0bGq95r/U0tUe9lgZ17a2dIVneRe39MTyE2OHuOZu6Wxf4TV5
b7Z3aFt8eyJO/9XlE9o7/WnBHe3P+G+07EAObMcJM9J/G08+fb6tuA+msti1b2Kxa+9iu0NfReSs
93Jz/9fWsp3LvafvjpPh1GZTy07kzC2sdKNvQrAnclbbGOqPXPLNQSwuaQvxBJXqm49MuIrzZ1ZE
9OFpMHIDeyfEcj60m5f7IJMbOhS57ZsfOtRmYvIoC1AO86wIHS4dAflsROdY6CgrsfvG+BwBahth
uxI60XqT5RLa+VysbBul9WkXcXqU+FqGyiptYds4vdR2eTrbJiHzT0e6fHWh823pvMzg5Uy+X5zc
fud/k/c1UFGlV4LfexT1w59lQZBGJEWJNKFpmrBQASTIoV6MvKoixIWqghjaJsQQYghtkL8FpAsw
rmtcYojpGKeXsR1jeoxxGOISxhjadljC8RhC265LjEHbsBxjPMRhGA8xsPfe917xqhrbTmYmZ8+Z
8517v1v33e9+97vf/e73vUcVT4o06JFBj3va5vfdbGpuW8T8jJHZ1NHOvAVN3Q3FgDuaEl+Ka7jV
rvVuJWxB3GltOujWv+KCyLTiSME/rQ332sO8DrCk1Lu9qbdhZ1Ve01FY0bCm2k0vLTYdb+r1ehru
NvW+tAievN4Z79a3x4A/wRuvtDaVtseDhrn2xM5dTdtgpbc2ngI7W3G+OhcQeysbjv+XN7zVmIe9
1U29IONqrMSZBTsrwJJJ6L1WOpWBthTZnvqmE+3pMFI4nXobm067jkLvwH/pQFNxu9Xb5lpoa3tF
aOp2nX7FtbcKdsnEprPteV7v3oj2Qu+BpsH2bd7DTdr29FeONA23F4P3RtpLvX2AK7zHGirad0KW
ONq+a988ZEhv592m0Tavt5/2iEXXlZb5LtYcAaf3RcgSE7Cuo/a2ek81x7ZMdGlhp2vtCsMTeJfp
S3hH0N9YCVf78TzfFYN0VzzRiXurkMYdsyvFtQAytch/JaphBOhqzGxd6Q03Wha7GNLAJ3rvJbwH
aTbjaX+v0NbWZYW1w7zVjUboa37vFNqDa6Qrr+k02FDYnIT85lQffxvxi4kuRdpb23i4ZfwlC94v
eLfuNYP8bHMGyFQ0PoA9ax7HAvsU0F07iYYMjBoaBpvveyeas4He1ZzvOti1m/i7kN+1h+hmktna
LLQd6OpoFtvPdp5tFtoHiR4GWmwf6epuLmkfBZwEe/Q87acjsMu0dR1smIQ99ybReURfJLqX6Nq9
Ue1XYE+fgdx4Uk03XgcfJjW7MJIb+8Hmo8072rVdx4neRvQJkJ+EHFu1t6brtOtg+2RXYnMN0GeR
3zXYXNek7Tr9HnqY5EeaI9pvwLxnuCa7RiH+b3RdadjlutI1qaJvEH0Laa8FbM7tugtRmu6NJroU
aczJCt11D88ncIa0tIe9MgX7WhucARraw7rmGsfxThDOMLc6d7kGm1/rWoB1dKvrMZwHbqL83k6Y
I3+azgl7OzuPQ5xcxDPP3k7a0S5288383s5uPdJdV4iOcC00aeFUk9F+tzuqubX9Xueu5s72OciK
t9oXXplp3t/+uNPa09jT1uNtadtn7Cxsadxn7CmAleWFaISMBDGDd5FzmLE7K5quwGoSJdwS0nGh
+40WY8el7nMt0a17us+3xHWMdV9osXRc7b4k3SO3JLcWd4/hnWb3VbyL7L7WktZxDU4F0h0u3dvK
d7WqO1b5XpXuUlsyO6b871Wlu9GW3I7p7qmWgo6Z7umWrR33u2daHB0Pu++3bO941P2wxdPxCFqR
npbKjqXOmJbqfZruR9hv9xL1m4799mjku2m8d07He+eeELSkx0iWpK9Y0hMtjULKkHin3BOH98g9
cdK48M4dNNP9NeYlbAtxPoo7SI8Fd5CeZOT0pOEa7Iluqd1b05MpaztOdtbvC+nJbfHui/a2SU8n
pCcGLQeaRnq2NpTCOWeo5fC+uB6H/CyC7vpb+vZZera3HNuX3OORnzmQ3+SnCnT/3jKwb2tPrfzU
Qno+INHS8wpo1bWtpX9fmvdiy6l9mV0nWmr35fZUtpzZV9BTjf+tgn51yFS/OuTpV4cafaHew4Lp
l4Zx9EvDBPqlYaK+Ud/GXtDv0/83ZqVfEdroV4QloR8JTWelofdC77Md9MvHF+l3jp+DPjJYIvs4
Y0xgn2WxrIq9wjLpPU6lrJd9g5WxfvbXzM1OQSlnZ9g5VsF+zIbZi2yUvcNeYtPsN+xl9n/ZfdbE
Ftgya+d4LoV9jTvIHWLnuKPcO+zvuV9xd9k/aWo1X2Z/0JzUfI8tay5o3uSCNFc0b3MGzazmt9xa
zUJwEPeh4MTgTdxG7UHtBW6TdkT7JufRvqV9i6vQjml/wX1G+791Wu7zOoNuHfct3QZdPHdSl6Db
x50y7DPs54MN/9VwhA83fNtwjF9n+CvDGX694YeGcf45w9uGKf6Thl8ZFvhPGf4QEsV/Ef/SxHeF
RoSu4btDTaHr+P2hvw6d5Q+F1Ye9xh8N++dwnv/H8PXh6/m3wzeEb+SvhaeEp/C/DH8+/Hl6u3Up
q6UnpfH4ey3bUYDjACcATrNY23HbCdtp21nboG3YNgLUqO2KbdJ2w3bLdtd2zzYH9YLtscALeiFC
iBJiBbOQhL/9o7llepvexni9qBfpN5ImPpVPZYzP5rMZx+fyuYznt/BbWBBfyNuYhr7PpeWdvJPp
+DK+jOl5N1/BDPyL/IssnK/iP8ci6PtcRv7L/JfZWn4vvxd0NvGtLJK+z7UO/J3IYrS/0P4Cn/ez
G+wWjcyEv4i0VbMqW7Wt1lZva7S12by2A7bDtj7bMVu/7ZTtjG3ANmS7aLtsG7dN2K7bbtru2Gah
fmCbty0KTNAKYYJJiBHihUQhRUgXrEKeUChsA55JKBZKhQphp7BL2C3sEZoFOMzbFlcKyWCZExao
mHzlsVwOCr3C0U/wwnEAJpwQTsO1s0ANCsPCiHBPGBWuwKdJ4YZwS7iLv6/T/Q14M9ovzvF/KGSy
eojaXNYCMV9IcW6H+D7HnBDhP2bFEN/vsE/Rm9RKyEef1m3UbWLbdc/qnmVluud0zzGX7nldGnPr
0nXprFxn1VlZhS5Xl8s+o8vT5bEduk/qtrHP6j6j28Fe1FXqKmG9cOw4rCT0sgVfkQYxw2xnAQYB
hgFGWJ5t2jZju297aHtkWxI0tkdCiGAUooU4wWJ7KCQLaUKmkCsUCFsFB+DtAB6hUqgWaoV6KI1C
m+AVDgiHhT7Ax4R+4RTwzgBvQBgS2mxTtqvCRdtVKGNAXwN81XbOdt52wXYJf4uof1m/l35tGuLn
rRYomeznULLYu1CssOp/wz7GZqFk60p0JSxHV6YrY7m6al0128y4sPlw+m84LAXfAVcaARDFONcc
1LEAZqAXAB4HZZTqXXcJIlz3CJCOcs2VxroW6LPZ9bg0yc0TP9WtL81wRxAfryNPkVPaKXS2O8qn
G/nYFgF1KTTqVuh8dywBXsca+1GuKSC4zXRdaYc09oe1AiL0J8rjwb5LoHaBjVgH6lvNJrVtanhS
20DAse5wJ5FfatypvrErdqEteB39o/hVXAWqoE81YDsFcCwKKLahz7Ad6qyDPhXfKH2r5xB1yGMs
CHFn+PmxRK7xuiKv1HitwZ3t862iG+tW2QakO935VO93Cz6/K7XSN37G+VRqxUb0F44Jx3DILb6n
vTI2pT7iLil91e0qfc29w89O9VgCbRUD/KDUsSrbcDyK/wJjoUpFq2NWL49B8R/yFB0n3VV+fSh1
xBPGr4w3ImD8ymeMH6SVdtCXSyvxAmufzBvumtJz7rrSR+5zpUvu80/0y2p16we8/jS5P6WfKtm/
ip9jA+br/erWlc+uMGncT6p9fgnwtcsk+elptW/exVVq9TjUsY/1eXeDL29ccLeWXnJ3Eq3USk5W
1ueYe7/v2lX3IeoX417J19fcR0qn3K/6fKZfiQ2qp92v+caI8jPuk6X3Qeah+w3fOpfblGncF8pC
3JdIjxKTUJcZ3WOooyzafdUXr0ot57qyZPd0WZz7GvkwxTPkSvdcdFk9l115nnHM665CzwTxtnmu
u4o9N0muFHIi5svAOQYfumJAfyAf1n9Zv2c7xX3FSh++Od/puYNj8Pn6abFXFbC2A2MqMF8F5iXZ
R2iTa5dnVskhrt2eB649nnlXs2fR5yulz8B8rMTNavtTAL/M4p4iPyOkuWfKMt331ftUWa77YVmB
+1HZVveSny5lnwUoc3g0Zds9IUR7PEbacxVQ9FR6oqmu9sSV1XosZfWeZBr/E6Cs0ZOGoMRdWZsn
k2qvJ1e9l5Yd8BSUHfZsVe89ZX0eB9XHQAf4keZXvbcnSXFQdsrjwfHSGM94KssGPNXUbshTq/ZX
2UVPfdllT2PZuKetbMLjLbvuOVB203O47I6nr2zWc6zsgae/bN5zqmzRc+Y9uXC1vU/ZU9R5+El1
YHwF6lP4uI9VqeJttbzfuop+JScq5wNlnShrXq+KJZTDWIyX9+f8ldqVKM23UvvgaeN8Qq71i2V1
raybiIB1FLj/qXIpjUdV+/b9gJzkVz/J3pIAfwb059srA/fVwLpOle/UtTInSr5Olfz9lYavtCrr
zdVRznAduLrLta6D5WEu5hkg6C03IfjO4Yo+RTfad7Q8xreGsR/1+VhZf8rZWG5P+Rv2Cdfx8njf
ukc+rDtcf2p9rhPliauevWW9rtPlKX7rMCBHKbnIdbY83e9MhNcwJw6WW0v15XmlEeWFruHybUSn
lheXJpWXluaXV7hGynfSZ7heKpTvoutwzXWlvJn4IEO1rINoc/lukhkt34N38fqv6/87Y6Efpf9c
9bvQ3zH8j6xJf9nnK8FBbJmeo7xIz1Fe0o5o3+L66AnKq/QE5QQ9QZmkJyi36QnKu4Z9IVF8IT0X
uUHPRf4PPRf5JT0XuU3PRX6Lz0WCYvG5SFAyPhcJ+gg+FwlKx+ciQR+FO9qT7I2VpwdWnm2z5lsF
q2gtsbqsO6yp1iprjbXO2gC4FWje2mndbz1kPWJ91aq3ZlhfgysnrW9YI6icAzhvNQO+AOWSdcx6
1XrNGpHptU5Zp60z1vvWKCgPrY+sSx/TWGOpmK1J0AuWDNKIn2IJskE2w4qvCOX05fj9yYB721aY
kXa2D+5qz0LJofvcXPYLNgl3stegfJz7GTfO8jUTmrdZAT6vgpYc87BK1XjNzCJbkAH9SSPPkMeu
jLxVNeZDMGIc7zkY5xtQzoNUlfUC2YhP/tbRLxIZRE8S8JKh8HAvjf9vNxWKhqWxF1gw+yjLgPvr
LJbNDGCTwMLZVigRbBuUNUyEYmQOKGtZMfsUWPpptp1FQcx5WDT9l81Y1ghlPeuAEsc6oWxgV6DE
w9jfZh/mIrgIlkDfDu1YGWvR1aCMoqt5c0XXiqaKpvMPF80U3c8a3zJSdL/oYdGjoqWia6Km6KEY
IhqzPKIx764YLcbl14oW4CXnO6yJeffyHotpYmZWv5iL2Kq1snyHWCBuzerPr80btTLRUTST3/ZC
tbi96GrRVdFTNE1ajaDfV8R60ENlS2ne46xxsRG1KMXKpJI1K1ZCy7Z8hz0GdQF9QDz8QnV+LdDT
BNNitVgL7TUwnmvYC5W+oodgnxHtBiumthzNr4VWh0Vv0YyYBtLHxP6ia/kOhKxZ0PNQPCWeKZqy
JhZNiQPiUNF03j3U4IMlKyMAeTEENIeIF0n7ZXE8y5M3Khph1AjQmwwT4nXUq/RCGhUAGxDEm1Df
B60AYp/YiAU9Id4RZ7eMiLmbwUYxE+QeiPNg4aKdKdrEELsW+/frG8AeZjeJ0eB9GC1YCZQCyKGW
IEV2/SkwbT/uZ78f2I9njWf120/YT9vP2gd941XBanzk2YdXLPcbBfDtIzjLEqAN2IfP/mt598Rk
e3x+G+BEiMo20jpVdM2ekjVrT7db8+vteUUz9kL7Nntx1njRfYpTZi8tWrJXgNRO+678PtFr301z
uGjfY29GT9o77N0QO5kQuTCH9oP2XogOj/2oWOCsdzY625xe5wHnYWef85izP6vAWSC2Fc04T9Fs
Qg/OM84BBPtB5ykxV2qB15xDL1RS7Pi8KXlO7MubxBlfmVNRA7HVB+tuFmAeY8t50XmZdI87J/Lr
8+ay6ilWj4n12AJ9k3fPmphVAMXjeMNxTqGpFDjOQ+ykQX0B4BKMn2X1YdlydstZx5jjquOaY8ox
bU10zIB/Chz3HQ8dj7aMbhl1LIle8U5W/8frHHy+w6nZnOwMcRodNc5oZxz1UG9NdFpgdV50JkOs
Qx/OtI/z+QX2PbSeoGdnpjPX3gu+q/h4Xd4VZ4Fzq9MhLjq3Fy05PThLzkoxE0eSNwczOGq/Yp+0
3xA9MCpYgfZbAHftN+wwMvHYZq/PX8fsc/YF+2Mcff7hvMeK34vuO3ipFjMdekeEI8oRi6tI4W3u
B92LDjOCIym9w5HqyCh6ZNX6gNa2vduRDX0WruQF37xoILch0Lp35AMIDjG9A2PHUeJwUQzJNEXR
DUhgOxxV9j2OGnuho87R4Gh1dDr2K9ENGdUBsoeklek4Atm1DQFnU8odDt7xquM1x8m80aIZiP6H
WX0vTmC2dV6HebjuvOmsdtY674hbMR+CjQ9h7lPthfnHxGTIzo9hTEwsyOqXsjHOj3NWPOa04MyL
BdB7svOBc965KKYVs2JtcVixSSx4odJ+sDimOL44UfQUpxSnF1uL84oLi7dlFRQXF5cWVxSnFD3M
74PZMmLOhZwN2al4Z/Eu9AnaXdwsZUqMYJjV0eLdxXtoL/z8f6ATVA2rp2fm+D/lWVoj4wCi0vZA
aYbSAWUnlG4oB9OupPVCOQolBcpxKAehnIByGgryzkIZhDIMpRTKCJTRtFH875b6F/U76b94foJ9
EvxaBAs7iDnhdKBl/xm8Fwp+/iyLZFzYbNhDsoj+1pUzyLi8PKiHoS4Mysg5m/OYYFAGpIcBRuTP
owBXZP4kwA2ZPyLzRgLaKfQtuVb4kzJcUdGjKvquDFfk+obqmgL35OujKl2Dcq2AejxKrdgYqG81
m9S2qeFJbQMBxzon97mgGrti14h8/VaAvYEQ2P+ICgZVoNh2V253Re5T8c2kiq/M4YhqjI8D/KjU
kyp5pYZrubzKt+prig1Q5+rlOkJlw2BA34PyfCq12vZRqc6NWqX9cI7fGHNjAcwASf52+o0l0NZA
PwTWgX0GzoUa1DGrjEHx390VHbmp79PXauMPtCGwvqWaB6V/hRdYyzK5GQDZAJ0A+9/HL/+/1Ip/
lfpJ8/WU2jfup9SBPlb89LTab30F1pOr2K/oz8/xrZ1cAUCUaVElp4rl3BKVjEvST3Ev5+vcHQBV
Kp+pYwPnvybHbx3m1gE0ALSq/K7EyiGAIzm+tehbk6/KtryW459rhnN8uS73HMBJid58GKAP4BhA
fw7l9c2nZN4ZgAG5b8yJC6vMoTKGQD70tTlZGpu6D+X65iFpDH458GmxFphv3y9frZaXRiWbNl9c
4W++DDAOMKHy1ZPykDLW1fanAH7uG7KfEc4DXMjx26dyLwGMAVwN0HV3BXKvAUzJ9LQ0Nz5Q9MzI
9X2AhwCP5PE/AXKXJFDibrNGrkNy/PbSzUaA6By/PL05Tq4tsh+TVWNXAHy1OU0aL45xcyZArtyu
wN9fm7cCOAC2A3gAKgGqAWoB6gEaAdoAvB8gPtR7yvvl5Q8ab0qtrK0n7T1PqtW5Ub3WA2tlzp9U
33gCPK3/p+Xe1fwXuH5W2/+fVqty0ar1nzI/ar1P2DNX7X+1elLVv8rvbmWecA1cl9bB5psAdwAO
yDArge+8qrRXdGMsP8hZWcOjOf7nY2X9KWdjuT3mb9wnNs+v2EBrL1paf2p9mxdzVj97y3rzWI7/
OgzIUUouytPm+J+JJqV1nBe2Mr48kyouZLm8mIA4kf2dl7jiS9+8qdcAysTnPMbvPdFbFth/nHtN
rhf/Cz8L4yLwxSYpIwCjAFcAJgFuANwCuAtwT/48B7AA8Fj6/Bwvg16SeS4CIEoFsSoZM0ASQCpA
htw+GyBf5gt/BogAJSpwAeyQ7agCqJH6Iqh7H2hgBSnNKR0p3SkHU3qfaU05+kwDlpReVTmuUM8c
STmRcvqZQ/L1EwBnnylJGUwZfDYRMdYyNSx9AskTJIdtR1JOp4ymjILEFVXBdzCY3vtNX3qziIbe
KfIhendINL075Bl6a0gcvS9kA33H10zf8X2e3hHyUXo7SCa9FySL3gtipTeCZNMbQXLoXSBb/uL9
cZyJk741O8yeY+xZiKVnFwLgsQyFUp0McZMMsZUcoQKIq2SIq2SzDLwMSXKduqKLZGHuk7MlIH7h
CuA1y9hT4blne589GlCOv4fz/vxVCr5NkL7JzejNMdI7Y4Lpm9wh9E3ucHpnTAy9JyaO3hCzgd4N
Y6Z3wFjo7S9J9MaXZHrLy0fo/S4p/256OXaWDa78DWhDH3NumtowhGXT9AbPpplN9zc93HSfPj/C
mmBpw1CSJilElhpKMiIfS1I08pIsUIxS2TSFRdGYFAcaffoIL0maFD0bPKQhBGROYTvkSz1vGMIn
hzz6WMv38z+BtP4m/48snv9f/AzbqG3SNjEbZk8mhP44dIR9gt5YEwNgkt8Fk+Brr4H2J6H9KX6Y
BfMXQFcstYkDiWjCsj/WpzEOAd/6hBjfZsSyWb5KIoaZYiZjJtfHW+osDevj1yeuT1lfDCVmfXrM
rfVWgLz1heu3kY5X8Ru4/Pf470HfP+B/AJwf8j9kPD/AD7Ag/kf8j8CyfwBrgmFMY0xPowkBy37C
QkN/CvYZYcUd4Mbo2d12thYiuZOxD7sksOxfodVgObQ6H4CzPGROi8MyZL5ruWhOt1zG+plqy0CC
3jL+4WTLBNLK59gUy3WUsWy33ESexWO5g3zzLcssyURYbloqLQ+wRlkES7VlntqArKXWsmip38gU
oLbpGwsRUCeBZ6MWoNQHYJsCYBv0vzFRtnHecnhjikRvtFpyN+ZBf5eprz7SEybbNSTb9EBlz3XS
XbuxwnJsY3psysZ4S//GbZZTG4uV8T/jADsaN4ZZ2jaaaFxeGK9CH9gYQ/OI7wRj9AYtzlBh+Czj
DS8adjKtodpQzfSGXYYvMIPhi4YvslDDVwxfYWGGPYavsnBDo6GJrfnAMcxxZ+idZGGsEc4tLAGy
YcJ5GS4AXJIBslrCVYBrAFMSbNgF9YxUqyHh/godP7UC8JmzRBPtNGebs+MnYqLj4xIG1gG1rmRd
Sfw8lIsbooBaXFdips8JjpjoD++Kj1t3HkpJwpBZMFclHIAr4/HjKANSizHR685Di/MxcTHRMdEJ
FxMOA3c2JtosxN8xu9bVxE+Yd/iAdJoPIcQPxC8imIV12WYhYcIH2StFsjH+gWSjuQTatSb0I50w
lHDKnJTggKtxkn1om2xXNvQugmYRLQLtsj2gG+2ZN+8HOy+DFeNod/yENH6Qq0noM1eZa6A3aBs/
C5qATjgGnxrM+F6VMP7rPORo/tv8t5mB/w7/HRZiKDeUQwRUGiohAj5n+BxEQK2hjkUYXja8zCLp
rWdRofOh82xd6ELoAouh95o98yflOHyjWQlAHWU5C/3GpIK+y5AnZz4LybXSNw44tlUll8F24dt5
fHIcZKPvQkTzkI+of+otnnrD9+nqKdIZRbqGIl1Lka6jSDdQpIdQpIdCpDeycNKEY2A0hmAawyay
56hs9xnqeyPxvGQ1x0ZUvKuy3Wq5YbKaY/UyD/971r/G9+j1mCeOWkuaGGniSBNPmoJIk5504JuW
g99rA/USSvojnugLnt75hd6Q5iGRxtgs+6Lex+PZDnkW1XK7ZF9sk3l/ziw9bd6fZPdRNqSyW+IN
s5Oq2JN4dfIsqnlH5FlUeP9Wc/hBZuFfM8ur+YJj59kVOhXE4n8fj9ruA2eUCCU2qiTKFbUDcBV8
2kG8GsISLcJVMaoOSlVUA31GWpRLJxQxar8MokqjHopIoOhTNKn11FGNV1qp/xrpM47F8JLhJRhz
vQGizLDXgBHwgfcmNkAzKP9lM7IS4BRzRp6AUkj4tK8+4SunI8/66EEogE0DpsOmeiwqyRHTAIHy
WdJ0luoVDWd9miQ9jZFhEsfkAbhsqjZdjhyOHEZsuoxRbvi8oebPHaHpAcA8c5rmTAumx5F8pD4y
IjIKMNaxkebIJKJTIzMA85HZkfnAM0cKkSLQJZEuKlUgGRtZAyVbLthG79NYF9lAODayFWRQm17W
1CnrqTItwDXk6Kk1gkBXdtAIqwwNf8L+wcP5/zplV2kdJuH/z+cyuGx2CT6/6sdN5tIoC3v9uPFc
IuXy3X7cKC6WdcJnlx83hDPS7ywL/LiM07JS+Jyi4vJsgc7ZUT7eytievsJN/An+dZD4G/4UZLbv
89+Hk/UZ/gy0PMefA98M8UNMB755k+n5y+AhA/9zfgLyzyT/Ngvn3+HfYWv4G/wNZuSn+Cm2lp/m
p0Hnu/y7kHOGQ4ch5/wETuUfglP5TyE28Gz/DcJfJ/yd99DfUNFHVHSfiv6WTMPYOTMH4+WU95Q+
S7wYLh4+zfnxjBz2ftOPp+ci4NOYHw89zMFMq3jsEVuCT/1+vDnwOgd7kZo3yx7QbqTmTbMZ+FTt
x5N+Z1rix5ug2Mrz44357QUSb4SNqub6WbpHw3lllJM5ysmYjXfTjufnVUPte7x6RMX/JtFVKrpS
5fmvqzz/jRValvmWqu23VDol+kt+sybROBYLfasT7yOl0SSvSIP90j0o4gHAISwYTnshPq5fvglb
Yixcw5zhLFwbHgZgCo8JjweMdSJ8TglPhxITbgWcF14I/G1QTMAvDi8FCSy75TqR2qlLPMiZoK02
fA/oaIYaZcLkq3kAHeEVdE1qjVBBJT18J+Cd4btU54YPej8TwZXSCPfAuJkpBMCoArj/MIHfTBYA
iBBTmsxHuf4AOCXXZ2R6ACATIBegQPpsPMqcId1rp9eWAJ5Ze3/tw7WPoNxfu2TShHRjMYWsXcLa
uG3ttMm4dsZkNEWbjCD9EIspxGQxWUjOKBWplaLRlIwaAZM+UxrqQk0rekyZoFezdjpUBDouNDVk
d8hxUxzg7pDd/2Ynng+6m92hbBFG3yVmoekAVoA8uUYoBNgm18XyNZQrlaEC/NkRmgTjOBiaEZod
mh8qQBFDS0IOhnRgAVqkWgCpDChJoa7QHfQZCtQlIIvXd0hFbrWisU6tD3XJmhQ92aFJIJmEukKa
Q3pDekOrQmug7gjp/TPvT/6syF0Da9MI+dkIkWmECDVC5Bohco0QuUaIXCNErjFTlnMAwGnQ6AGA
U5IR8qaxFqBevtYIAFFrLJABPmd0MKdufE1SxFHAqWuyoeRDyV4zvUbUjWNZU7JGoDp/TdIaF8i4
1uxY46LPWOrW1Kypoesuqcit/DVmgxTpQ12kaUVPNnwSAfKBrtLv0Q3o7qypAjyuG/iLRy6+j3dR
dQLA+x3tUv0f7yrlKTsGynM0e5iDx5azlZwc1K3tBXpGi3M7oztI2IN83QXGaTqCb0JmfqDFXWwx
6Brjgm9q4S5ZE4t8Q1rQLON0cRoHcO5o90OMVAYzbLuMO9wMYpCA/M+JtAvMLNUjjTioGzlB3X+c
QhnEmg7k8BdIchEx9AFY83niP0Cs2710AvjNy7CbB21HzKUu1+JJQXsPse404QTilBLuJYz239Ti
dy/ntOWIdRMk2YM7lHYa8FEt3sll6PTE300yiPsJs2C8P2V4FeTLiUPPEYIHiYNtmeYO0RHEv0ny
rxEmDXJf1wmjtxep1SKOiC3iKIC+hleX8glnEqa73yWYt+VI1Lz0K9Jv0PyUejwPnvmBTgD8OuE+
Lcw0/ybhB4SnkB+0HumgEeJMEP1zwinEeU7zFmCBcJGEkc8tET2BmLtH9JuEGwnnSjKkJ4z0bEH+
8u/53wPHHAyj0xzWwHk5OFUDu7rmd0hrfkr8JsTBn9G8AfQS0lwr4qBiuvpd4jiD/wGObSaS5Ah/
mTRcIp0ewuHEaSU9f00yIYQjEetE0vYuYUn/iaATOHbC/yMIoj3oneAB9Axy+O3B40Df1WwE/D+R
w6Vq8Bz6AuIgK9FJKK81yRr+FvBbyOf3aTYA/dkgsIf7Z00W0D+hVt9EHPxVoncRPk747xBrK0nP
Y8TaaeqxDvkaLfHvkeR2omOoLzPR3SS5WZNMFuJK+T3ioEnEGuLwLxPdGXQD34JOkpUkM074DGK2
nnNhFBE2ENZzsBKXH/A/ov/Mko5rlsP7oJtB69FyvM/hpnn0wxLioPWwLjk+HWn+NaJ7grZhPBD9
gPCvkcO/TngCOdwG4j9CDFkFf8G0iHTQLsIpdHVCE4vjlfQgzZ8m+guEp0hynOjXCXsIP8dBtuSL
yZ7nCOeStRqi8Z1iMCLNOcRE35Y4aAP0jjJbCHuIP0dt54nza8TLc5oM8KojuA7wOVz7QV+iGdlL
1u4i+ptEn0AMMnUU8yCpuYqYf51apRAnFq8GzZJMg8wZpEgeRC+RZBhxuhAHf5XobJI/QthFGkaI
rsWrunUkc4TwR0jDN0nbEmWqZbItDDG7TTrfIptbpbgiP39B85+A1lGMRQa/CDIfo1Y50hgJb0O8
fAdP+PxrlOejl39P2RvzvxlpbgNdfR2v8h6i3yF6gPBBkt8t81F+njjphAXCpqUdyt0dXMU9ZZLk
k0hDErW6R7iJZJYIf4KwdO/4FmF8WwOsI3yiCDP9RcCHSc+DpfM4dpK5SXtKPdLB1AvIo2Q35me4
l4Z5h5VAuxtizYeJ3ku4lSRrNN8Fyc/gLsC5+Byk+e3gpR/xnYR/RPgueeM24LsUV+E8ZCGeo9W0
nfCrFHV2zW9xv9e8C5y/Qs1BZtLvIXoWMTdPnAvE6Sa8HbEmlvhJxDlP+OeEv4Q4OJlkvk10FNHn
iG4mnZeI4yD5VwnXI2aLGnyqOUb4a4i5GKL7EYNVSN8mfJE4caStlyzRyxqQQ5r5dKJTCV8hPET8
PsK7CXcSv5LaMrl3pMlOdpPwG4TnZBnERwkfIlyHeHkn0dWE81BPUCZppvniTlJfEzTSa+SHrZK2
ZdrBIcbxPPNj9MbyORwX4QeIgY+ZZBAxnEOQc56uXiAsEL+X8DRijYNkthM2Ew4jPEvyr5PMHdI5
Rq3mCccQbiOZgyRfTzKPNZCruQzNL4D+p+BaopcAm4ONGPkYP1ww0lxUcDzg0OAwpDV4jrytxWcp
N4LxTHJPG0beEwE/jzsOW695ATDtd2wL0Qbc3ZZ/QzImTSfJJxFG/r8gBtpBOIpwNp1z0gl/iE5E
LxG2EL4MrYYwtoHGd3Ksoz3UExyEHsMzJLtNZ61+wrelkxjazCcFUwYIHkOMpzs+Cc+rXKU2lfA8
YuJcQknuEvEvEX+eOPPEmSfOpeBqxHjW5eYRgw2STC/JjxFf0jZGenpJBnv3kEyqpJ9keonuJc29
yGGLNJYxwot00l6UrEX/8FtoLFs0/4IYWwFGDanUV6+kn+w5SbhUpvFqKUrCbkI5lux5nWx7HUcE
dCrlfBoL9gVnhnqij6M9kMMgftincfbpLy/3GP4SljErYbTWwP6W8F7MY8s/hLbfp7waCdkUNCzR
7kC4lziLiLlUicbzPJxmz+NVpLlUCUsndmqVSvcCvXR678VzL2DMtEnI5z0kM086K0mmEu9ZgukJ
WXAU6gFcS7m0AluR5Dz1conoY4QvUY/HCM+TzkqycI6uNkmYWjXR1V9SX78k+2+T5G1JJ57AuUrJ
TvLPosSRr+IZfoxajSEfruYTnU8jDcP1/sfTyJF6Jz2pOONsjloxega2lTBb/hngqOVJwPHEiSJO
/PIf4Pw/ghxoj/g8Yp6es/F6soqeesIYkZNOdKq0e9JVel7J9xGekHZqutomjUjaW4n+IWLwOKzl
ZRti6AvpWMSgDfttJPwy4TrEkK9+hjOClsO8hBBNuz9azleTzBDhXpmWbMaMcYjwDOFJwv2Eb1OP
NUTfZHSXgTsm+xpH9626Kso25EPKhEzKKvStnueRs/wAOZAZcDXF6PBbK5PkeYarBrITZSRtDHk+
lmaHopoyQy/OHb8F1yyszV7M1dL9snxXK60U9NVx8p4g+/AonleJDie8hfBd8vY9og9KJxDCHpSH
88b/Y+/Lo6o4tvXrdJ3qc4QGB1ARUREnVMSDogIqoiAijkE0RolBQBRFQEQkhiigoFHUOMSoQUQc
4nWOc+KsibM4RJzHOMQRxxiHCL+qr9pzvffm3nffH79311vrJStff2fX7l3Vu/bep6q7ORGtPfTZ
nEP0e92GJZDgLR5Db6nPbfC+BBqeA78USF6D/wW4Fzr1gcsh8QC3A7YD3oT8Hvh24GRgiUAahtYD
wHRgD/TyGDp+kIQClwAXAkvRWgyMhyQcIw/HjIeLCDF0Be8B3kPEBr9qGfnie60JvFpdj0BxvesR
q39g3dUB1jYAA/Q7zHOQ70LTD/KjwAPAhXKFCc3K+GbvALQFdgL6YJ0wHlwFYgVFagEr6KsX8S0c
Cs1NAt92KUPNLJsEzAMOBXoCNwHFqpXp8hSgqLqk9CH4j8CxwhrWuuTtS7RyXnqW8W/ztxfFt3Pp
I9WW40OBPMJXAI8gbmuCy7sBL4DjMEKpI96JiNM5xkOfgf+A+H8Avg/yu+BFwEVAUakIdn/EiPEL
D5Q9EPaJI3p5Ak6MkUBci5FfY+kvJj4jb2+a/MTIxXc3l+AeiBoAfATcAUwGitUdEfp8VFg/sNeQ
DwemAwOBmfj+LQDu4d8CfczeHA8INN4QqPoKVIBGAhwJ+QqBpqkCDdBXIDFDx1TDjPst0L+P1t7A
VQIp5Ow6OCwYiyE5BMuXwNuBM2BFSALAx0A/BViKvjSgK1qfQvND8HJAabk/9NFKbSF5g1ZPSG5B
chd8Jbgd9MsD04AK8BGuIh+YAMksYDys9QJi5MZYoLxqR+ARSHKBkUB3YDgwAohrNA7DSOTYWuPq
tgDRapbj34DWRPDd6NcFPBSIkdNfYM0HknECbTBH5TBf5hgg5DQP9qfBTmPIgyEfi3OXwc4ZYA4k
8D/DXCiPca4TWpfCQme0boQFyJk3eAF4X+BtoAVyREhZfxGHHHkcKuOA6YjMgeIekeFbtbyITxH5
7IBA4w2Bqq9ABWjEvUHjSMhXCDRNFWiAvgIJj/C5iPC5iO25ImKlBcFNNaRlwY33pTXBld7QWSWQ
Qp9hFU1h31gMySH0ewm8HTgDVoQkAHwM9FOApRihBnRF61NofgheDigt94c+WqktJG/Q6gnJLUju
gq8Et4N+eWAaUAGieij5wARIZgHjYa0XECM3xgLlVTsCj0CSC4wEugPDgRFAXKNxGEYix9YaV7cF
iFazHP8GtCaC70a/LuChQIycosoZfSAZJ2cTs3YJWIw5IgINcjZXCLQBlsOMm2OAOJfmwcI09NUY
ciL1wYOhMxZ9LUO/Z4A5kGC+GOZOwX1skxNal8JaZ7RuhAXImTc47nWzvsDbQAvkiKuy/mIvXNa7
jMd5WVd8q64s7cbxBnCEQOoi0ABUCNAX8t7A/QIJ9A2QGKFDp0Eu9UehtRGwDzAD8sfgsKAMBd7E
uQngC8EVoBmSAvC24H7AcZDkAL8Efgo0AqXN1UDIDdngb9FaFZKnkDwHLwaHNcUEbAM0AEdDpwew
FSSdgS1hrSGwFiTNgfJ6bYCDIAkGWoCOQE+gK7AFNL8GLoC1i0BctZFB5zxat4BfQ6s9+FLgRLQ+
AZfztUsgk/OCOTI2A7aDZhEsHABWhrwO5DhL+Rk4DBgI/AG4AzppOCsXkjDwuuAX0Crl88FPiJUP
j6sIxJXAVUBfINZFRMqfCeRRFIF4E5K54L9Bx73shbjvinXjZsTqS6we8TaOUQVixU7x3g9bAckk
rBJvQ4JdMI0AT0DrMqAzrO0HbseTrFictbR0jNhZQJKEve01WPAHeguJCXs0gxtQ7gv6QtMevcg3
TE6J8Zuwp2Ny/e8k92vYFwcJZG0EGlXgOshf4jnRRnk/tjRErNgFKtliVPS4vG+JvoYAA2S/sHAO
rXfkfhA+DBdIV+FaTkNzjdgTUbln9IYfUAF4xonWGxj5RsxCCUbYDxLIVYyf+4S3soMCjV2BeWIX
rExGj0tg3xv9FkJfQ+8abKZKC+IuLv8S2o2d9W5ctcBKwO3ADGAq0KLLT8PPAmdDshw8A36LB5bg
zgOeLVK88WXU72yXTsCuvxD9FmJ2xLn79ZEnYbcoLZwWuwNguEDuSdmLkBzV9U+jmp2GTRnVSdAs
BC/EFQm5GT65JjSNbeX+BRZigAuAB2U06vFfiNiIwCzLGUzCtcPniKWNmJc0zHgF8Cmw8KPcXULf
T96TgQUnXHUyInAIPJ+Ms4JltMio0HOkHOc54iwV9xlYrmhVz8BylLBjfAD7F9DjVIwqV2A5xJ75
qUAT7kuoW3ULYzAjHE3YNasDBGcE8uXw22FpE33ly10z7vPcE2icIOMHI9yNawkQb34zeQ8k0XCJ
y2tAZy6uxQk8AnP6Gld6CZJCSOagr5uQhMGHY4FDgc7ArmjdDM3leF5wBpaNsACfsGOI/AxZzTA2
ZDqtg1GNwFPUycDFeK7qCl6MJ61u4G+AqWgNA5ogWQ4codbgWBvPZ2tDUh+8Eix8CUmQQHIfeF3q
gF+CtVj5bBdowZPfJUAHWHgO+VXgbP25s1hjFOMps6tA5gibs/WVm9DZrq/HgsRdCKxv3XQMEt7G
GsNVtyOwM57dD0GPRlizYGwT0G880Cwkxq6Qb8YIPSBfDsvPpTdg2R/YCIh1mlIVrfOBrXDWZMgD
2CPxjQP5TnFnScFaiGD9o/SFvAV6bIhekiGJh/fKwDOgeQFoJ65CkU/GKa7lpJxfvFPRGHawyqVN
ob8dvtoP3h2tIeAu4Fiv8pkSNp+Bfya9CssNMB4nyeUTeYz8FHq8CayEK10PnXTwElgoQb8X5FsB
kNyF/nrwq/K65PN9VibGqUfdFDEesVunvoLTCbDsAc2X0JkF3hd9LZZ+VsWbRAFoHYPW7pi7o2i1
g4VrkkP+Cncn7oMPkDEvOB0GNEG+VyJm4TH4RfA5wNsy5lmWGL/gbAVwhoxncd+P3oGOC3y7Hb3n
Q+KovwuRjqzhaMBui9sE19+yiBbRqMek0EyF37LR2gu9rIHkBBC7FSUIOALxfx+5gz0UjZBzjavI
xLmZ4I/AH0mOcyl6vIuRPAd+iX0Bot2E8auhAk2IT3YQ41kt0PwdWr+CvA0QOyaaJH0COxiJCd5Q
h8Db2CMY0mUlQe/1MZIoaRkWcjH+XFkf1DT4Jw1xMgXVSfAw1YdbmAcdXyYqdrZ4MsVrTonYxwkd
ckNwPu94uwAYDMTdKsUTrZcQG9fhk63CjrJQr2/iOdEzdbSwr1fCmqhgQj6XiTd8fkNfv6CGrAOO
xXWNxvgPwz/2kKPeMgJsAsnX0CmET44LNDoLZK8huQKJLdAHkurAUTJK2TPOH0JyB/gEml3FnTEe
hwEYTxr6DUAtDUDvHE34dmBp6P0OdLoK5DqCO8O3k4HbhT6vFWk4V2AMsIlAWoicvQM8zvBdw2R2
I56B2wUa60LnCritQHUJQ7QING1BhFTFtffGGIpgfxST48SomMwy0XswWjfD5ivwV/AnqqJRgR9W
Q34YV+Ei9XG9fzCZs2l4q0GM8ATszALvC69WF2j0wWj7oPU0ziqQ32vy+0IfbQBmPw1cyDuhrz9k
tZT2dU+KHseD+8HmH5i1h9BpLHo0TYedS+g3BZFzBjbHo6+d6P0KEHlnzAM2xGy2gv5RcHcZRZJD
57K0A5wJTXiMZYEj2rlXHTH7QtISEuSgugZ8JGzGgNsA96H1I5zVBz5vDvwF17UA+eICSUPgZWAn
1IEAcAO4PSwjB5XBwLewsFvakZkF7oqzXoDPxVnB8rtAoCkb1lDnTfFyPLJKQ3MGJA/AUY25t0Ur
vhFM+FZiO2G5kDVAPDfAt1UvzFcDRG8DRHsD5N1McZ8KPeJbUg0H7wjuhL6KMPJdwAewX4DR7pdc
2gHuRl+DoemDjJsMjNfjPwCzI/J6nLBg00/wcjMFN3sDFfSLVUQ5T2QT3qljWImZFsNCT8SqM/gK
vT4INOiRz9FmJPTxXp9xkB7bAlUmYywA2SF4F8g7oZdmgquo3moUPByNaD8onjjQy+w0x2T4ZKTR
n3Nb43IR4cbJXBOrTcMBwXlGTBb32YARAg0DMCNtxFnGkcJLPGJ9xP09o9gLJAuJoVj0YkQ9N8rv
F1T7t9315ymZHMuDl9efpODZdBmedJSNB8YDe+Le0X3wXPFUQuiXvSg7DclM8W0u7CgjBNIq4JOB
2yHxBS8WaHADHoWkL1rDgK6QzAbXwEuAqcDlkB8HXwycB7QA6wODYLmclLw9L77dcHVp4NdhIRat
7YSE72KE/gBgKeRXwa+JVkWOoVhwY3PwE2j1ADrB8mvIzXhC3QDcHb1EgMdD8zms+ckRwlpX6GyG
BNdOLklNSOygPxk2r+HdXZMcs7x2IVHCgNvxXPs2LOxD63o5C+I5uGEA8EtIBus+EdZcYbmjfKqO
c7vAWgmwHWyuBS8G2kk/Q98NkgzYmYBzz0oPyNlE63rsyBygnw75S8j34KqTpLelHbRSYHdIOksu
Z0H3mLBzUUSj4aRAPuOCv4K+C1o/gn44RhWCXkLApZcaQycUo70vrwjXOAdyL/RSqayuQLT66T0K
eWNY3iqQzRBofCNaOa8r6gMkznIkMubF2whKfWALGf/gFrylUAPWauC9hesCaRW0NgZ3LZshfI69
LYU8H7hcekYiJBlAP9kKdAHOBq6H5hF4wF/GrRwPsAQYBbwKzUoyciCJx9jOAu/Luzew86GMaujs
B57AuRdwXaHAAcBHuMZb0NkCy9MhvwYcIjMaPBpx0hKaqdIakML/r+CT43KcwME4qxTcDJ6Mvs5g
Zm+Ls8zegpuQp2o4MABz11u0mlCj1AZ4E/4B5rEmrmsMRtULUREDTVQtVdo3Qv5YjvxtKjJL4F45
ZpnpuF9EcVcqFzZzkcX5Ik54PayLuK2LalZXVB5ZYYC+qEXZsOOH+oAaRW5AEqxnn9ApJ+uYQBor
6xvkpcCLwJOwGVTaiCMB94RmGka7UOYUfPgMdy99gXjCrszF9f4mrxrvlkQab/LxpBq7C45o34P9
SCTuTu/B073GhOjvCNiQfMMKwgYmD4wirtGfJseT8MHJg4aRAUMGRSWTofEDUxJImrDbOyzIldTk
3xxl4v/xR8oRW1KROBA78YnLzET81ZpGypNKxJHY88/iTVPRQqzMIP4aQ+cKUQkVdruGh7iK32JB
u1FvY6QCqRwdPTyJZABzgLnAOcB84PKY+LjBZH1sXMJAshW4My4hLoX8CDwcNzIxnpwAnuGKA8kl
4C/xidHx5A6wZPigmDjyHPg6mTcbCBD3wonRihRM3JwSo1P/RvJXZiC4Zy3ffdHR9j00v4d276EJ
KO3YvIeajhVJXeJBvEkbEkS6knASQWJIPEkh6fiFgNkkjywhqngtgUySYzZUkkdVvr9mMIvfdBa/
sF1XP84m4i8/DTbdCf4CxmYjxmuwKdKPl+SxQk15dFjPz+PHqsHy6DRE2nHazfvi9p1O6J9v6lch
3ifCG0T4VROFj7qbeJPB5IdP/8O/R8WGiogyuCneNNjYl7gQP9KBhJIw0o9EkaEkmYwhWdxzX5K5
pIAsJ+vIZrKT7CdF5Ay5Qm6SB+Q5+YN/dWimzYSaVplWm7bguMa0Fce1pu9xXGf6gR9Xc7YNx9Wm
7TiuMe3Aca1pJ47rTLuIwo+7+ac1XHsPjqtNe3FcY9qH41rTjziuM/3EtdeY9vNPa7n2ARxXmw7i
uMZ0CMe1psM4rjMd4dprTUf5p3Vc+xiOq01FOK4xHcdxrekEjutMJ7n2ur/ziPhl8jSS8W955BSu
fJXpZ90zp3XPFOueOaN75izvZ5XpnO6f87pfLuh+uaj75ZLukcu6R67oHrmqe+Sa7pHr8Mgvukdu
6B65qXvklu6R27pHfoVH7ugeuat75J7ukfu6Rx7oHnn4X3hkDskny8iaf+qREt0jj3SPPNY98kT3
yFPdI8/gkee6R37TI+aF7pnfdc+81D3zChHzWvfPG90/f+h+eav7pVT3SJn0CC808IjZID1iVqRH
zFR4xGyUHjEz6RGzKj1iNkmPmM3SI+Zy/w2P/EiOktPkEvfIPfKUvDYoBhuzjfSI2VZ6xKxJj5jt
pEfM9tIj5vLCI+YK0iPmitIj5krSI2YH6RGzo/SIubLwiLmK9Ii5qvSI2UlGjLma9IzZWXrGXF1E
jNlF+sdcQ/dPTd0/tXS/1BNXanbV/VJb94ub7pc6ul/qSr/8tz3ywOqR+rpHGugecdc90lD3SCPd
I43hEQ/dI010j3jqHmmqe8Sie8QLHmmme6S57hFv3SMtdI+01D3SCh7x0T3iq3vET/dIaz1i2uie
aYuI8dc90073TIDumfbSM+K3NcW48Q00k38TaCRBvDzGvw1cSH1i4f4KIt1JX+1nXukDzR8YZ2qn
dTZLKwYL47IzOpulneWsI/TO6WyWdh5M6F3Q2Sz8vkpd4kl8+Hx0JX1IJK/qKWQsmaRdtPZ0ydrT
ZWtPV6w9XbX2dM3a03VrT7+860m7z1kncyCXPdDZLO0hWEcuK9HZvxrRDeuIblpHdMs6otvWEf1q
HdEd64juWkd0zzqiR9YRPbaO6Il1RE+tI+K5b/A0ePIFjLPizNeDdZQ6+C7mKzc7b6wCUoj4tSj1
b2aLr35oJ6Iov4OFWFlnKwu1si5gDL+B58TXinVx5lOc9QxnPIf2b9B8IaJFecrPENEym1T7R1+R
+Xxds4ZsJad4/rzkmaMZqhhcDY0M3gZ/Q4hBvO9stN3Lbc0D22dlP75jyjHO5oIVWdlxKzthZSfB
xKpUU04JrtzgOAdtP1u1TltZMRjl3rMnjsoZnCFGMlURo/gKOmff06miiDHNUX4ilGvOUc5ZLZ23
sgtWdtHKLlnZZSu7YmVXrewamImvm52IK589T9KStFH42kBZwPs7hF4XKAe41gKFrxSUfP75MKT5
ykEuzVeuW239ovvCpExTvuTxUqAs45rLlVXERlmjrCHllXXKd6SCskHZSCopm5Uf+IqfYmXsyKNG
/IqLWPdV0H9RcRFvWKms5DY3cn2q7FB28LUijzxlNv5SXPxenohD/q0j/h/pfOXL66wyX5lPaih5
Sh6pyW3sIrXwl9/t8JffAfjlO6pOVHMUsVugFN1TG2oj7kNRDfa4Br2r1qAi8g1qLbW2GKEhgqyk
92gt6k4bU0/ajLakWXQCzaaT6GQ6jU6ns+lXdB7Np4V0Gf0LXUlX07X0O7qJfk930D30J3qYFtGT
tJiep5fpdXqL23pAH9LH9ClzZx6sLWvH2rNAFsSCWWcWyrqzMNaH9WMDWBQbzIaxRDaSjWafsbEs
g2WxCSyHTWKTWS6bxr5kM9lsNofNZfNZHstnBWwJW85WsXVsI9vCfmDb2C62jx1gR9hxdpKdZufY
RXaV3WB32AP2mD1nL9kbVqZS1aTaquXViqqDWlV1Vmvy63ZVa6tual21vuquNlI9VE/VojZXW6g+
amu1ndpeDVQj1Eh1kDrSdr3tRtvNmqKpmo1mr1XSqmjOWi2tjlZfc9caaR6al9ZC89XaaAFaR62z
1k3rqYVrfbUILVKL0cSvVnxLzVQsOWrRWnweGtAGROFebsznoQltwuuDF/UijLagLYhKM2kmMdHx
dDwxc+9nk3J0Ip1IbOgX9AtiS6fSqUTjszGd2NFZfAbt+ax8RcrzmZlHKtAFdAGpSBfRRaQSXUqX
Egc+U38hjny2VpLKfMZWkyp81taSqnzmviNOfPY2kWp8Br8nznwWd5DqfCb3EBc+mz+RGvQQPURq
0mP0GKnFZ/YkceWzW0xq8xk+T9z4LF8mdfhMX+fV7Ba9RerRu/QuqU/v0/ukAZ/5h8SdPqKPSEP6
hD4hjXgUuJPGPBI8iAdrw9qQJsyf+RNPFsACSFPWgXUgFh4dQcSLR0gwacZCWAhpziMllHjzaOlO
WvCICSMtedT0Ia145PQjPjx6BhBfHkFRxI/FsljSmg3lO5o2LIElkLYsmSUTf5bKUkk7NoaNIQE8
usaS9jzCMkgHHmVZJJBH2gQSxKMth3TkETeJBPOom0w68cjLJSE8+qaRzjwCvyShPApnki48EmeT
rjwa55BuPCLnku48KueTHjwy80hPHp355AMeoQUkjEfpEtKLR+pyEs6jdRXpzSN2HenDo3Yj+ZBt
ZptJXxG95CMev7tIfx7D+0gEj+MD5GMey0fIAB7Px8knPKZPkkj2M/uZDGRn2VkSxeP7IonmMX6V
xPA4v0EGsV/ZrySW3Wf3yWD2iD0iQ9gz9ozEsd/Z72Qoj/83ZBgrY2UknucBJcN5LphIAs8HW5LI
c6I8SeJ5UZGM4LnhQJJ5flQlI9VqajWSotZQa5BRPFfcSCrPlLpkDM+W+uQznjHuJJ1nTSPyuSr+
om0szx5PMo5nkIVkqM3UZiRT9Va9SRbPJh8yXvVT/cgE1V/1J9lqgBpActQOagcykWdYBJnEsyyS
fKHGqDFkspqsJpMptt/ZfkdybTfYbiBTbTfZbiLTePYpZDrPQJV8ybPQhszgmWhPZvJsrERm8Yys
QmbzrHQmX2k1tZpkjuamuZGveYbWJ3N5lrqTeTxTG5H5PFs9yDeaRbOQPM1b8yYLNB/Nh+Tz7G1D
FvIMDiAFWpAWRBZpIVoIKdS6al3JYp7RPckSntXhZCnP7L5kGc/uCPItz/BIspxneQz5ixbPc30F
z/YHZCStTRtSC/Wmz+gUOoN+Tb+hC+li+i3dQLfQbXQXKuZReoKepufoRXqN3qC/8nr5gDWkz1hD
1phOYV1ZTxbO+rIIFsli2BAWz5JYCktj6ayQLWMr2Bq2nsfS96wx28n2sv3sMCuip/nxDLvALrPr
7Ba7x0rYU/aCvWalqqKqqo1qR39lXdXK1E2trsarLVk4ZwPUKHUwu267VTNqZk3TKmiOmpPmorlq
dTVPrbnWSmuttdMCtU5aF62HFqb10fppA7QoLVZL4NeajJpGUNMMqGYKqhlFNTOiajHUKxWVyoRK
ZUalKodKZYNKZYuKpKEi2aEi2aMilUdFqoCKVBEVqRIqkgMqkiMqUmVUpCqoSFVRkZxQkaqhIjmj
IlVHLXJBLaqBWlQTtagW6owr6kxt1Bk31Jk6qDN1UWfqoc7UR51pgDrjjjrTEHWmEepMY9QZD9SZ
JqgAnqgATVEBLKgAXqgAzVABmqMCeKMCtEAFaIUK4IMK4IsK4IcK0BoVoA0qQFtUAH9UgHaoAAGo
AO1RATqgAgSiAgShAnREBQhGBeiEChCCCtAZFSAUFaALKkBXVIBuqADdUQF6oAL05Llfi3yAXA5D
FvdCFocjc3sjc/sgcz9E5vZFtn6EbO2HbO2PbI1Atn6MbB2AbP0E2RqJbB2IbI1CbkYjN2OQm4OQ
m7HIzcHIzSHIzTjk5lDk5jDkZjxyczhyMwG5mYjcTEJujkBuJr+Xm01p83+Zm0focfozPctz8ypy
k8eQnpuN/u3c3MoasR1sD/uJHWLH6M/8WMzO67l5lz1kT9hv7BV7qxpUppaz5mZtnpvDkJu1kZux
PDe3/GluNtNaan6av9ZBC9ZCte7/l5v/l5v/i3PTYBD/R2oXMoAU8G/RjWQnOYjd7W3yGPdJsG8m
jfg+iu/f6G88lrPo7xwn0FccJ9E3HKepk4jC2qppHNupYzi2V9M5Bv6JhRew8BIWXsPCH7DwBSx8
CgufwcLnsMD3f+pYoQE2zsoyrCzTyrKsbLyVTbCybDDsqLVngmvP30l4tblGCHvLSonC6wLfJ/La
oBKV1wcbYuZ5HYu/ew3FHaT6xBtWKtge5dnMz6T33jEeF2K3f4x/esZ3b5ehZ0/H8dznbfJI72GH
KHYUBHsDAz/zqtgT4hmFGTveX/ludJW4B6IUyJ0jKbYtb2v/D08uxJjEsyk34sG9G6DfLziCvexR
677/pvj1Q7BbVnb7HVNHC+1/uTfGExs8kdPwpIm7SnlMqxsHG4cY4/QndwapRUhV8XcWjpCSqgMs
WVX7qeUa5YTk/G5nMCkFWVW7cFEnxWDwsrWUU1lje6o4M2IZqNo0Vg1GQ1YrxWAs6GX5wOLxnsSl
sGaGC2mDf3uQKDKSJJJ4Moik8P/8xb+W2u8ZMzp6Zqu5l1YW/TjHMub+mhptXTwrfzGtIKuSlyXL
GGnJol0LqGJQFBvPlRUv9SyLWHBk97uza/ChJHk1tjRUaW+jrYNbYGLSp8lxg4ekuLpHN3T18vVt
5dotLjo5cWRibIprYGJykqdXTYuLVK78ty2JyQNT4hITvGpbaol26uD01/awxMQU1/ajUoYkJsel
fGqpWdXO0sri04z/09zL0qxfVTuvZvxjCy7k//SzfApfcSOqg9K7l5eDpaL4YHaw+XDgyCFxCYNT
eDcVLPZCaHIwhQ2KGZ6YEPNuYDb/bGB1LLXlwJzfb48Z5NorbnACt+raM7C9JcvgZrGzTqDBwAjN
MpQnXG6jZBkMZMunn5/5eENH3+Xeq7wuvKrXovPo3W9q5R/oOOLRyeA7p3P3DesaFvV8nrKv27nO
8U3r+g/aVVRni23IlnGjLnfcsWK6fc+f6jV+WvCrXZ1aJ9vXfR0173i1jktnhdaad2xDU7d9oU3S
E89Xrtk617eC7+UdDZ/Htm5iaFZW2iBk2aZ4w8S8Nz+sjx6X9SqiIHNC9rR1T7fOXnzcZ1nP7KoN
Jna/bHlB2j7f/6pt5s6ch/G+33p6v9joudbm86gZabF5c0fa5ax9+uMz1+97VJoafcTjfLOO1Uq2
hc5p3bOXU1HsB5+uWD3xYB//hVk9JyWw71rs+azujrDYtvO6H208tnnChE7qyfwToTlKQg5Zsnvi
1V6K+FXgxZmvLZm/Wxy4O2vUM2oWG9XMQ5cxE6WWzEIhNRgz51syv86o0P9E0qO45Pw6H4x1XN9t
WtmRRcn/8/GWVZ7sIVPatJlU8aT/i+gHVwMs5cUYHQyGMiOzUH6w1BACe2MVo+PRGkWpJKn/2icX
fuw+/4Mgz8VB0Y8ttqK5vNHI0yjnvdShIiI+W7lmbGj9p0Xbu6cU9m2Q0mjUhpy3K7vOTiPd7h6+
73Qp7if7wvRnSuD+wxOPvux1dO/CHX0SH0cH/SWIlMw5OL/YZavtwmp2s89eqLm64eePHi4buWr6
Fd9pbecO3e4z/NSktXXeXr17Jq7cjEk7Sq+Tbd7Pfk9/VaGSJ7vfcM6sDsPcR2zxmX7NZHfo4yHH
dmS0Hxa7fNuWbdO8Dz+lFdLH/HbqWoern5Vev76q9MXVYrsNSWdm3uix2acwvcnpthe9baNaKQsz
h9b54kVE9PR1/bb5no3M7T3BuflvrecWZGmFn0zZ4LFl0dIjKy+4bt5lqZbt6mjXaHvY8/bXBlhu
zHSPm7gn6Zdn364syuiQnGrPa8wYXmOi9Boz0LD+G9TCyu/nEeN15j+Y1bzgePFC04yXmRbNvfSC
08L60ZI5/v/L2OwQODx0jd169Ax7p07/ifp/WXuWjkhxOnIxr+nrJ9HVMhZPKzuYNF5b1KnR69f9
1hV1K7+j9YXax1jx5+ntNs1Lred3qaCH663knwNH3C6Ld3y1cML6ehN3OG76eGerLzx/WpkdOSI7
s8H3zemr1WdmKSWbe1dUjozPfrEnO3pgtQLHvAUL84KjW52r2ObDAyGuvar8frRv6Yvdzoc3B8fb
3fFjRctcbkx6fHnF3qTx/U8+fdpu6/klCxaThBWZx0r8jKt3h870cLh2t31quQxD/GDXjV7r/Ied
CjCPL06yTLX8ujP3RNOS0zntnPst3T0k+84X6TNoaMJHga4heZNKD3Xccqer0WAbVVT4wGVWvbcn
vrPf/3JzXefP3qSfieh+cvBdvfa8tGT+9ue1569ZfD759BEt6pPLi1MWfmI/t/3y/g6B9TF9NcqL
rOeJbMpA3ahRx+hkqZLx52kfJBRqGdtaWlt8C1oVtMhpPiQlJcmvadPo5HjP4e/m0DM6cXjTpGFx
Qto0KTkxZlR0ysimgb144HlykSXk3QgNBmMbi5/F591ni5LjoRscPXr0nxkclPyepZS/SyhUn8jI
BufSLZ0rdWrfqs2AURtvFpKWFUPWefT9Zm76w8WVFs0tcdrw9Yvh085ZnF1W145uHzzr7Fpn9y5f
t/w8IDzyaNT2u3/EffvJuJ8mLsvR0v/yy0efX5xUPDqNLat7OOZl9w+2BLlPc/YIN7sn/1TLqa3H
cdIg0eHk0oFPz0T57SDdWdN5gz+/FR3YrrW2c4ppzPW0gF1X04omuhZWW7Q98vHCVWERqY5vq6ex
s9GjhmW+nRi8evVHYbs+27W22pKZ65/aeoy1VLjo1WXnhH7jfv+mUtrdK2MjV9rt96r5Inm+/+Dj
PiU+Rb7VR15sfd776vhTeceuT7niXBpj/mTtC8+tzeqlxtV7Vjy1RZ19F+sF8eqzgFefbFl9Kgy1
nddjN6m3suLFjrX6jhlc+Pc16D+z1mlp8fVqafGyeHu3EqXHl3/8D6x1wuOGDxqZMnB40r+71rnU
KuHN2oMdQkc4HSwK8e+1+/VKxx88mm2r1CPs4PiH/s3Pd/aa6b55Rsy1Wj0n/LC3y8lx7OWjUTun
HFhevCYuKTatQeydzVseZX9/rGTF20pLbD9ya9j0eMD5PsbqqZuGxwwPDb94+cmVXQvHH8i4Oq6r
0mr2b7vzzX1qDul07Pzu1Iimn2+uZ9zYp/9Ql+iyjPQ2JcXGet18R6eYPt4bcS6nlceoQ/b3avqW
S08tXRCfMObaA//pX+ePsP+kUQ+nqMhm+afGd2/sFjGk45QrTSdU6Ln+1SbnqfEl9b5xeHmkwtls
++dZqSNb7v9qTOHRSPUBW5fTfMvL2f0ntJ/QN3t2wrpaHiFHE/MCrw29M67+tGGy3mQZ3LlH6v5Z
xTH/71jtVFDL6TuLygaxhCHvFcrEO93bff2998ouOdO3591b1bp94P4TlmrWExwVo1bThvQio/gu
JJC0/9uV0D8so/6kQM3uVtFrb3rPbRWnLRpoMtjnJnWc+mhk+I525ViTsq0f9Mp2eeg7Y8viPrZX
cje3rn7yzapvD2357oPa1RPNcWOH0UK34IfxG4enu20N/nnCs6nld5omt9xzf+zdpI87Lpx56mjR
5Wm7r+9qdCz9waE1zYonfn8k+seWJ51q70q90nr+huoj82tPOrdxY6Xw3Od5eweFznevnxc5uXzr
Aw6D0kK2HV893q/Huqi+Vyx37/rWuPHF0wu+ma8caufGZESrxjlP5yuBTT8LnvRDmXJ+0KvQKxdo
yqwNLEE7uuCS+8D0kCdV8yrW9lFcJv6/rWE7Os1ox1OHY8G2e1d23nuRZt77RWnanDMbykMCra4V
uWxS/gYsoFYBC6hJsOYR6yIDcPOIY+CaRxgFAaiMsjAwNzIFFk2GhqagMsoYwjUEcQ0aN9OjeaRu
oArhyuU5ZxZkpBYpuAS7KrgG+1lZmLoY6xobmDrrmjo5uxmqGihD/CSD6ifdYJCnFIJTi8oyk1MJ
Fm8fWHQ3TTsg1ZiuulEtabOw9zmDXQeELP40ppqwHzHbpJLxjZ3lAPv0L9s/Vssl6bjd9F4SaLL9
cs7bKOstzQvdbQU59EyzXZ8dsulhSmNaKZH52uutus47m/LoJVcKZnqHtwhcWK/7o1P22SvNLc/P
z2NLWl4Ucsj62Hn7HQ83RAjkPF16/fChUvO9X1ofNr7QuCH98dO6j02Lr11nXjRftOW37a/VD7cZ
nVjAlPL52X8ptUKO4C5Rpk/N6mWeTYXL3681qjh2PUfMXyl1epKvm/5/5fWtb5YV7GU+feuGEetR
7QkO2+Zd1WnL2X5a2Ki291jdOnF9oz9pu2U3uIb+WPtLN705XXNyy6WohcrIzSlEgfBi+rfv73s+
Pst8HJnh931GV9Xd2XooLSWsJQYlLaWS4oLkRKq0lGAmlWAvrFHaf2wHsJVWvPbl8RNt9i01XXKb
lbVFPuzT+5nLjnP06m8+a194ta2mXP7ua/FNe2se/5z5icvVY63I7kydT3bpSSGf3tWrC06yfHPu
Zrtfx/cEd+VqdVEHjvn7eQ1Zmm6YbuOZw3C5e1VF4tGtHY5z7czuRCxRn211ay9brMiyTfw+B/ts
uj8lzfyR9vbqZxmNDUa3Txly7vmtlOHm8+tysdJzzT4lht9h+9nWNS4Q3WXyU6NP3iuJdWHn10b3
l7wTOa5HWPfLZXNmrjzgURPaZB/PYOE8h+2M/Q39/f7FnLZ/d8V9Of7G/FBK4gLfK7YFZ6I3CDce
vLLYUGpvyrVpl6rstaLdgjltzjL/tI9kONMZnGjYxDIbWGJNZ2JkNGhsH8AuG0pHEjHUtaDxGKh2
gkYbJ7MhD/I4GtBeBI/bkM8AWVYUWGrANbIYApP6icvbnR+abus6f+zDjq4PRxY+qN/oZZCGpIXH
MMIgbIFOgxaDL0MmQzJDEUM+eCgujaGEQQFYHeYDRQrAZCJQJBPIyluo1qCCM6WWVBbkpxclFmRU
KqCVTCxNjAy9vim/+h3PtwpUlz07zTttgefv545T9xtwv/oU4zrzVbR7d17lh4sTRK807eAzm2aZ
frCd95eLw/KcOWsLZFIjJ969tLHm+ZydJmsYfx1c6/PRUujfgp23bkhMClLU0opPzE/NeJucOf1j
+F7Gr5dvKr/Y03T1yA/t//8ygm/12X47Zrqt89qc5asPfVAUqb3HtffIusMvatd4FiyYvOylofQu
0SXHw2a0XfG61juloTdHgSf1Jtf+GmmuylrnoFnKEZfzpTMX3GcuCLRm/HloudbPKT631/Ep9SX9
Dut6JVJpdOC30oTaH5M44kXmXWZVWRWj4Xdi3do0Dv2LqVNXp+3sPr7x8q2M6q8burpDFzYxyRs0
MUkjYonNsImJByjEQffkiF5FolTc7NDkuCDWQAI5LXIjBn4ZgXbCZVgN+cHjD8ZGhobmRmYGxlEY
SVE0a+JJ3aUTal5/KK04LLYv98zp5z/RyidQEjkjmH1CWH1foaNZhFzc+hPpl+fw72F1Z058/mNB
wF5G3z96hrzcjKYzH14qfR3xImLznKaQ1WVRFpMC97y/eq5g8e3Z5YW3Hj6t2Px7ZsnCHrn4TRNv
vVzKts+12HGPaZmTiY20oOXL8OcfVPfYMc7mY5qkrGx29KLy+6V+R0L7n9XYeH5e0PX14gJR5rOz
PvU4aOneDL3efWBCKUfumaMblJc8KhP/+PQ8+7IS3ZyaaIaLU48fCnv7dGm6bvvyS0LBOn1/bCPK
k4NtZbZritb9Fi67xvp0zYd4q2sPzScoXDzBdLntwVaj5uQTL//d13AQbf7C9zh2d8xCjzMnr622
MLQusAhzNlpzcYnOL2sGBgDj8YDpDQplbmRzdHJlYW0NCmVuZG9iag0KMTAzIDAgb2JqDQpbIDBb
IDc1MF0gIDRbIDI3OF0gIDEzNVsgMzUwXSAgMTc3WyA1NTZdIF0gDQplbmRvYmoNCjEwNCAwIG9i
ag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAyMzk+Pg0Kc3RyZWFtDQp4nF2QzWrFIBCF
9z7FLG8XF01CuwpCSW8hi/7QtA9gdJIKjYoxi7x9R3O5hQ4ofMycw5nhXf/UO5uAv0evB0wwWWci
rn6LGmHE2TpWCTBWpyuVXy8qME7iYV8TLr2bPGtb4B/UXFPc4fRo/Ih3jL9Fg9G6GU5f3UA8bCH8
4IIugWBSgsGJjF5UeFULAi+yc2+ob9N+Js3fxOceEOrC1RFGe4NrUBqjcjOyVlBJaJ+pJENn/vWb
QzVO+lvFMt3QtBC1kETN/YWoFlVX6KE56FKcrprsmVe/BdZbjJS13KeEzPGsw9sJgw9Zld8vODV0
rA0KZW5kc3RyZWFtDQplbmRvYmoNCjEwNSAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xl
bmd0aCA3NzQzOS9MZW5ndGgxIDE2OTQxMj4+DQpzdHJlYW0NCnic7H0JfJTVuf45880+mWQSsg8w
XxgSlpAECEtYJANZ2NcwkABCJskkGcnmZEIAAaOg0IiKu6hV1LriMgwucceltu5LbW1dsdrWtmK1
rVZRyP853zsnhFS93t+9/3p775wvz/c85z3v2Zec6JAwzhhLwUvPlpRWzJ390ua8lUx3xhLGMkNl
s0qXv//FsmWMXTyHMd3YslkLSp74eP5hxi78EPHq2aVl5X948u+QndWMKR/PXrK4IlA37WzGLt3I
+DVxsyu8sxRl1JfIuoOx8jcWVxSM//Kt1z9njP8atVbXNvva1mWtPYexET0o5LXaDSE1fPVTrzK2
EnHD4Pq2hubPP18Yx9jo3YxZMht87W1sMHOjfpHf0dC0qf7L8U+/y9ia1xgzjW30++o+emc82sfX
IH1SIwz2O41vIH4p4sMbm0Mb1QnKEdRVxFj2tvX+YIvyqQkdOHu5SG9qrfWtqqq6kbE6PWNDFzX7
NrZljRu+B/nRHqa2+Jr9Gbeffgb8NzJmn9HW2h7qdbJz0R4tvS3ob1t/t+44Y4W3ojgHE2Nr6FmW
13jnM+sSpn/GMsxMhIf+vOV5wc+9cXD7V0ePnWf5yHQfohamYxSQz8iOM/6Udd9XR4/us3ykldQv
KHuFJSGHLWYGzaBjDlbA/Iwl7kG9mos+l+9Bqtmw11CIIocSKy+zc3XMzHQJBp1Op1d0+sNM1+th
d/RSvYwtrFBV5kF3hlIbTNfqclTGr9MKvd8QL3qK0uNPtIa/xP7PB+Pr7I4fug2xEAv/24J+Aqv+
odsQC//1oHuW7f2h2xALsRALsRALsfCvCrqrufW/szyliu36Blvuf2cdP3RQJrLzfug2xEIsxEIs
xEIsxEIsxEIsxEIsxEIsxEIsxEIsxEIsxEIs/EBBiWJw9NNhZyMGpWthelaPeDJzwKKHsrNhbCGr
Y0G2Tx2sDu3t1fztTB1g5b2fMdb7D3Yfz+ytfX/W+2XRkh0Da1bmKVcwI/9Ii3068NNpiOuin2XT
se8OvF95/z9C6X/GmWd+R9ru/2pT/sVBGRBd+x9mqP2OxH/JivLMrlu39tQ1q1dVVXqXVyxbumTx
ooUL5s+bO2d2eVlpyayZnuIZp0yfNnVK0eRJEwvy88aMzMke7h7mSk9OdCTYbVaL2WQ06BUdZ2PK
3OXVajinOqzPcc+Zkyfibh8Mvn6G6rAKU/nJPmG1WnNTT/b0wLN+gKeHPD19ntyhTmfT88aoZW41
/EKpW+3hq5ZWQp9f6q5Sw0c0vVDT+hwtYkckKws51LL0xlI1zKvVsnD5hsbusupSlHfAZi1xl/it
eWPYAasN0gYVHuluO8BHzuCa0I0sm3pAx8x2UW1YyS7z1YWXLK0sK3VmZVVpNlailRU2loRNWllq
QLSZnaceGHOoe3ePg9VU58bVuet8ayrDig+ZupWy7u6d4cTc8Ch3aXjU5g/S0WV/eIy7tCyc60Zh
85f1VcDDhmyHW+3+jKHx7iMfnWzxRS3GbMdnTEjRxb5hQrrUDG1DC9G/rCzRlvN6PKwGkXDX0kqK
q6zGGWGegtyqsK5apBySKSlekdIlU/qyV7uzxFSVVUe/NjSmh7tq1LwxGH3tKxtfSFfDSk51TW2j
YJ+/211aSuO2vDLsKYXw+KJ9LTswtgD+vmp0IiCGYWlluMDdFk52zyIHGFQxB4GKSi1LNFs4uSTM
qmujucIFZaWiXWpZd3UpNVCU5V5a+QAr7D18YILqPFjIJrAq0Y5wagkmJaesu7KuPuyqdtZhfdar
lc6ssKcKw1flrvRXiVlyO8KjDqO6LK1GLRf6NsBbOouem7LNaqXOqVSJ2YJBLcfLPWs6EhyYLi0q
ZnTWdLWSO5l0Qy1RD6FOKgcRJbtkjkhSRNaSOc6sqiwK39EkZ7RNhuywuV9ZDhj62kT1fGvTyFs0
aJRa5i/t18CTCjVEGxgt7ZvbqRNjEa0YOcxiOufIJCUbOxc2HYrRTGIW09UwW6JWuv3uKjfWkGdJ
peibGGttfudXuOcvXVWpzXZ0lSw/KUbpRRQLsywky4iuBGuwPNcpp1WLz9bifdE5A5LnymS12+ye
X9EtCndHC2QqdhA6bcyZ6zuvKGkCtmY5Tjd3uc+tOtTybl9Pb1dN9wGPp7utrLpxqijDPbeu211R
Od2ptXVZ5VbnZlFVEpvP5y+flTcGZ8+sA26+a+kBD99VsaryARzs6q7llREd15VUz6o6MBxplQ+o
jHk0q05YhVFEVBERJS1DxKz5Ox/wMNalpeo1gxav7eFMs5mljbPaHh3ZHNKmg01PNo9mEwGTlN6I
IcZxW6bWienZUtXYXV0lNhdLxVTii4e5ewYL69wzDnCdMS5sdftnhW3uWcJeLOzFZDcKuwkLg6dy
DI44k7qr3TinsKAqmZPTUlREkWpPb+/yyqwXnEeqsrDU1gCrKsOWXJz9hux58JstUA3z7HBXrU+0
g3krRV5T9tzaKixbWSBc5oYtKMESLQEe5VoesRyRqRZzgwnU8nchEu6qClflikorA1XacnaE2Rz3
VEw7lWnIERUVVHUnucdrexNbwZq9U5AFbWMVlWRxIorKqmiQTHFoea0bSbXVKkZbz2orsNTpLLU6
yeLHkajP8WuwOqOJTHRLybbZrWFLPgrEl9C2fLElDdmmqipqvBbbGXVA3Y6wDS3K6TeU0QwYHSTN
FW3B1040Vbg+LopZ2sOWuTfiZBGN1koyITlsz57rw+FP+W2wuItkZrM4I2zRMp4iq0n0PA7jrmQv
7+m9xb0pq1/IG+MW3xzEwmTOB7CwWVX3QEN4dW7eGPNAq10zd3eb7d+cgcbLbO9jYVTL8F2DsYhF
UXt0O+6xpPN5ENulOFuKs6TokuJMKbZJsVWKLVKcIcVmKTZJsVGKTik2SNEhRUiKdilOl6JNilYp
WqRolqJJivVSnCZFQIpGKRqkqJfCL0WdFLVS1Ejhk6JainVSrJXiVCnWSLFailVSVElRKcVKKVZI
4ZViuRQVUiyTYqkUS6RYLMUiKRZKsUCK+VLMk2KuFHOkmC1FuRRlUpRKUSLFLClmSuGRoliKGVKc
IsV0KaZJMVWKKVIUSTFZiklSTJRighSFUoyXYpwUY6UokCJfijwpxkiRK8VoKUZJMVKKEVLkSJEt
xXAp3FIMkyJLClUKlxRDpRgixWApnFJkSpEhRboUaVKkSpEiRbIUg6RIkiJRCocUCVLES2GXIk4K
mxRWKSxSmKUwSWGUwiCFXgpFCp0UXAoWFbxXiuNSHJPiaym+kuKoFF9K8YUU/5Dicyk+k+LvUvxN
ir9K8akUn0jxFyk+luKIFB9J8Wcp/iTFH6X4UIo/SPF7KX4nxQdSvC/Fb6V4T4rDUrwrxTtSvC3F
W1K8KcUbUvxGil9L8boUv5Lil1K8JsUvpHhVilekeFmKl6R4UYoXpHheiuekeFaKZ6T4uRQ/k+Jp
KX4qxVNSPCnFE1I8LsUhKR6T4lEpHpHiYSkekuJBKR6QokeK+6W4T4p7pbhHioNSRKQ4IEVYirul
uEuKO6W4Q4r9UtwuxW1S3CrFLVLcLMVNUvxEihuluEGK66XYJ8V1UlwrxY+luEaKq6W4Soq9Ulwp
xRVSXC7FZVJcKsUlUlwsxUVS7JHiQikukOJ8KXZLcZ4U3VL8SIpdUuyU4lwpzpFCXnu4vPZwee3h
8trD5bWHy2sPl9ceLq89XF57uLz2cHnt4fLaw+W1h8trD5fXHi6vPVxee7i89vCgFPL+w+X9h8v7
D5f3Hy7vP1zef7i8/3B5/+Hy/sPl/YfL+w+X9x8u7z9c3n+4vP9wef/h8v7D5f2Hy/sPl/cfLu8/
XN5/uLz/cHn/4fL+w+X9h8v7D5f3Hy7vP1zef7i8/3B5/+Hy2sPltYfLaw+Xtx0ubztc3na4vO1w
edvh8rbD5W2Hy9sOl7cdXnJQCNyaI0NnuHBnjgxNAZ1NsbMiQ6eCuih2JtG2yNA40FaKbSE6g2gz
0abIkJmgjZEhJaBOog1EHZQWolg7UZCMp0eGzAK1EbUStZBLM1ET0frI4DLQaUQBokaiBqL6yOBS
kJ9idUS1RDVEPqJqonVEaynfqRRbQ7SaaBVRFVEl0UqiFUReouVEFUTLiJYSLSFaTLSIaCHRAqL5
RPMizrmguURzIs55oNlE5RHnfFBZxLkAVEpUQjSL0mZSPg9RMeWbQXQK0XTynEY0lbJPISoimkw0
iWgiFTaBqJBKGU80jmgsFVZAlE/58ojGEOUSjSYaRTSSaAQVnUOUTWUOJ3ITDaOis4hUyuciGko0
hGgwkZMoM5K5CJRBlB7JXAxKI0olYwpRMhkHESURJVKagyiBjPFEdqI4SrMRWYkslGYmMhEZIxlL
QIZIxlKQnkgho45inIhpxHuJjmsu/BjFvib6iugopX1JsS+I/kH0OdFnkfTloL9H0itAf6PYX4k+
JfqE0v5CsY+JjhB9RGl/JvoTGf9I9CHRH4h+Ty6/o9gHFHufYr8leo/oMKW9S/QOGd8meovoTaI3
yOU3FPs10euRtJWgX0XSVoB+SfQaGX9B9CrRK0Qvk8tLRC+S8QWi54meI3qWXJ4h+jkZf0b0NNFP
iZ4iepI8n6DY40SHiB6jtEeJHiHjw0QPET1I9ABRD3neT7H7iO4luofoYCS1GBSJpK4GHSAKE91N
dBfRnUR3EO0nuj2SivOa30al3Ep0C6XdTHQT0U+IbiS6geh6on1E11Fh11IpPya6htKuJrqKaC/R
lZThCopdTnQZ0aWUdgmVcjHRRZS2h+hCoguIzifaTZ7nUayb6EdEu4h2Ep0bSfGBzomk1IB2EG2P
pNSDziY6K5LiBXVFUnAY8zMjKZNA24i2UvYtlO8Mos2RlDrQJsq+kaiTaANRB1GIqJ2KDlL204na
Iim1oFYqrIU8m4maiNYTnUYUoHyNRA3UsnrK7ieqI89aohoiH1E10TqitdTpU6lla4hWU6dXUdFV
VFEl0Upq7gqqyEulLCeqIFpGtDSS7AEtiSSLGhZHksXyXhRJ3g5aGEnOAy0gl/lE8yLJuBfwuRSb
QzSbjOWR5G2gskjyTlBpJPlMUEkkuQs0K5JUDppJ5CEqJpoRScL3d34KxaZHEqtA04imRhLF0phC
VBRJnA2aHEmsBE2KJK4CTaS0CUSFkcQxoPHkOS6SKDo2NpIo9mYBUT5lz6MaxhDlUmGjiUZRYSOJ
RhDlEGVHEsUoDSdyU5nDqMwsKkylUlxEQynfEKLBRE6iTKKMiONUUHrEsRaUFnGsA6USpRAlEw0i
SqIMiZTBQcYEongiO1EcedrI00pGC5GZyERkJE8DeerJqBDpiDgR8/Qm1LgEjifUuo4l1Lm+hv4K
OAp8CdsXsP0D+Bz4DPg77H8D/oq0TxH/BPgL8DFwBPaPgD8j7U+I/xH4EPgD8Pv4Btfv4htdHwDv
A78F3oPtMPhd4B3gbcTfAr8JvAH8Bvi1fb3rdfs416/Av7Q3uV6z57h+AbwK/Yo91/Uy8BLwItJf
gO15e7PrOehnoZ+B/rn9NNfP7AHX0/ZG10/tDa6nkPdJlPcE8Djg6T2E92PAo8Ajcae7Ho4Luh6K
a3c9GBdyPQD0APfDfh9wL9LuQdpB2CLAASAM3G3b5LrLttl1p22L6w7bVtd+2zbX7cBtwK3ALcDN
wE22PNdPwDcCNyDP9eB9tvWu66Cvhf4xcA301SjrKpS1F2VdCdsVwOXAZcClwCXAxch3EcrbY13k
utC62HWBtcF1vvUm127rLa5zlGzXDqXItZ0Xuc72dnnP2t/lPdO71btt/1avbSu3bXVunb/1jK37
t7651ZNktG7xbvaesX+zd5O307txf6f3Qd25rF53jme6d8P+Dq++I7kj1KH8vYPv7+ClHXxsB9ex
DkeH2qHEhbxBb/v+oJcFlwS7guGgflo4eDioY0Fu7ek9dDDoHFoO9mwJ2h3lp3tbvW37W70t9c3e
09DAQFGDt3F/g7e+qM7r31/nrS2q8fqKqr3rik71rt1/qndN0Srv6v2rvFVFld6V8F9RtNzr3b/c
W1G01Lts/1Lv4qJF3kWwLyya712wf753XtEc79z9c7yzi8q9Zeg8G+wYrA5WHKIBiwajJczJZ411
epyHnZ849cwZdh5yKkkJma5M3aiEDF6yOIO3ZpyZcWGGkpD+UrrOkz5qTHlC2ktp76b9JU0/yJM2
Kr+cpTpS1VQlRfQtdeHyco2LS4nHTdT6ujDVnVOekMITUlwpujJXCmeJhxM/SVRSHnO85NAlJPCE
hN4EnScB7gnxrnidePXGK574cZPLE+wuu068eu1KqscOiyhxRNyS5eUJNpdN5y22LbbpPLbiknKP
LW9sOVO4yjnjDpBiFq3gKa5y7OuDqdzA8f38wPKK3Nz5PWa2bH7YvGR1mO8KZ1eIt2fpqrBxV5h5
V62uPMD5BVUHuK5keThZ/B9bLX7O+eezWUPmh4dUVIb3DamaH+6C8AjRC8GGHEhls6py17Z3tOfm
htbitbY9lKt9IcY7RCxXGMVXewhx8XRocZb7nYHcQOvaEULSGPruXP/TA/+hG/DvHw4w8SGDmb26
HaxOtx04GzgL6ALOBLYBW4EtwBnAZmATsBHoBDYAHUAIaAdOB9qAVqAFaAaagPXAaUAAaAQagHrA
D9QBtUAN4AOqgXXAWuBUYA2wGlgFVAGVwEpgBeAFlgMVwDJgKbAEWAwsAhYCC4D5wDxgLjAHmA2U
A2VAKVACzAJmAh6gGJgBnAJMB6YBU4EpQBEwGZgETAQmAIXAeGAcMBYoAPKBPGAMkAuMBkYBI4ER
QA6QDQwH3MAwIAtQARcwFBgCDAacQCaQAaQDaUAqkAIkA4OAJCARcAAJQDxgB+IAG2AFLIAZMAFG
wADoZ/birQA6gAOM1XHY+HHgGPA18BVwFPgS+AL4B/A58Bnwd+BvwF+BT4FPgL8AHwNHgI+APwN/
Av4IfAj8Afg98DvgA+B94LfAe8Bh4F3gHeBt4C3gTeAN4DfAr4HXgV8BvwReA34BvAq8ArwMvAS8
CLwAPA88BzwLPAP8HPgZ8DTwU+Ap4EngCeBx4BDwGPAo8AjwMPAQ8CDwANAD3A/cB9wL3AMcBCLA
ASAM3A3cBdwJ3AHsB24HbgNuBW4BbgZuAn4C3AjcAFwP7AOuA64FfgxcA1wNXAXsBa4ErgAuBy4D
LgUuAS4GLgL2ABcCFwDnA7uB84Bu4EfALmAncC5wDqub2cWx/zn2P8f+59j/HPufY/9z7H+O/c+x
/zn2P8f+59j/HPufY/9z7H+O/c+x/zn2Pw8COAM4zgCOM4DjDOA4AzjOAI4zgOMM4DgDOM4AjjOA
4wzgOAM4zgCOM4DjDOA4AzjOAI4zgOMM4DgDOM4AjjOA4wzgOAM4zgCOM4DjDOA4AzjOAI4zgOMM
4Nj/HPufY/9z7H2Ovc+x9zn2Psfe59j7HHufY+9z7H2Ovf9Dn8P/5qHqh27Av3lIX7eWMdO1jB2/
5KRPUS9hp7F21oXnXHY+u4Q9xt5kNWw71F62j93MbmNh9jh7hr3+H30W/D8Tjm8yNLM45X5mZIMY
6z3ae+T4zUCPIb6f5RLEBunVE5ZeR+/HA2wfH7+k13G8x5jErFpeu+5VWP/Gj/UexfdXxHsnibhu
J3SCluNT07XH7z5+y4AxWMpWsdVsDTuVVTMf+l/HGlkAI7OeNbFm1qLFWpDWgHc9YuvghbNE0ye8
WlkbEGQh1sE24GmDbo/GRNrpWryDdeLZyDaxzewMtoVtjb47NcsWpGzW4huBbexMzMxZ7GxNSSbL
draDnYNZ28l2sR99Z+xHfaqbncd2Y54vYBd+qz7/pNgePBexi7EeLmWXscvZlVgXV7NrBliv0OxX
sWvZdVgzIu0yWK7TlEh9mD3N7mV3sbvZfdpY1mLUaETkuNRrY9iGMdiCHm7v12Iav86+0dqGvou+
dUd7uhH2s/vl2BAdR+G5HZ5UCs2DKGXrgJHYgz6QPtEjil2m9f+Etf+ofJdVjsc1/Ubmai0m1EDr
t+nL2Y+xA6/HW4yqUDdAk7pO0/3t1/b57tPiN7KfsJswF7doSjJZboa+hd2KvX0728/uwHNC91fE
d7E7tZkLswMswg6yezCT97H7WY9m/660b7IfjNojfZYH2IPsIayQR9khnDRP4JGWR2B7LGp9SrNR
/An2JOLCi2JPs5/hhHqWPceeZy+xnyL2ovb+OWIvs1fZL9jr3A71Cvsj3sfYy4YPWDybyZjhQYzz
NWwtHgNOpXblVZwiCjOxKWwhW8RWP8zs+Hafyqbye+9NKS0155kexbdyHVNxGTAzzks8CXqd/f7M
zGL3/RON5yuJc3t43j3FpvNxzS0+9s6xFwuOvXMkaUrBEV7w9nvvvOf49MXEKQWF77323rixPDEr
UUNyvM5kSja6h+XrJo7ImVRYOH6GbuKEHPeweJ1mmzBp8gylcPxQnZIsLTN0Is6VV79epSw+ZtRt
cxevKDQMzUxIthsNusHpSXnTsx0Vq7On5w8xKSajYjCbRk6eNWx+U9mwN0yJQ1JShySZzUlDUlOG
JJqOvWmIP/pXQ/xXJfqmry5VjNPWFA9XrrSadXqjsWdoesboaVlzVyQMcuhtgxyJqWZTUmLcyNI1
x85NGSzKGJySQmUdW8g4u6P3qDEXIzid3eFxVM9om6Gzjx2bVlBgzU9Pz+zp/fCggy8Ef3IwIcp2
jT8/GKfxhwdtgnWJnqHDx8XFWdPhbnUkiBccrVZ4WdPhYn0QP4Ow3kOeDETY8ElLbelp9oL0cflG
18ilLm+S1+BlxQhJaVMSC4t5wWu572nfAscnFjr6VOKUUwoKCxMLx409NVsObKKbxytCjeDuxD7j
BDEnQ3VpvJBjIoRMMeaak10ZaVmDzLrjhYotZUhyytBkm+74bG5OVjPS1UGmMc5GdezwdAvvNPBz
bZmunIzmBOeguExznMlgMMWZ9Q1fXWqymhS9yWrEwO/ts988enhc5kjn1yuVm4eOzrBZBg1JwYKr
7j2iXIPvmTlYmed5XMXTuM05RYzKFDEqUxwO8cJITRHjM+Uh/ATFWEHvYTHABdGBL4gOvMZxUbtN
sM7qsQ7KKrdNGeHUx48W/wk6fd6EHq4/GL/QsAAjeaT4CIYSA0mD91p0DKf0H7qJRuOJtZmalhhd
oylKjraSU5KH6sTCnqxcY0ocnCwWz+y9q2t3rxw5vuaidYu3e0zJrvQMNclyc8nW0uLKyRkpE1bM
zDrFUz4iAyOj12NkOheuWLj9QE3ooR2zy0p0NpNdDJjddKysYuX0mi2e0rP9pySNLhkn/n3gXnz3
v0V5lhWy2nvaJvKchOgaS4h2GfzJPQkOviAhuggTevgXniTmGYT15EnES4WRZVp7eLbHkjsvJyFF
nZsihiJpypRibOan0H9tFMQY8OgYiH6a+i2b6AikaLvXqLtFZ7SYzWlDhqdkjJ041W1OooViTBqc
ljrEYcqeOXXKEHvW8CFxeoUrNalDEy0Wizk5f8HkY2GzzazX46XsMNssimKxmbdPKh2RoJitVku8
kzEdt/Z+zt8yrGUpbBSLv9eQ7VzoKEdz334RB41skZITbdGggQfJIyaxkQcnmRK5OcU92OlOMcdb
Mka6XKPSLZb0US7XyAwL7zDHiVbEmZUH45LiDMa4xLivpmTlOm02Z25WVl6GzZaRh5W6S+lU8g0b
mZNNZvZ7jMNSx89mxYUvjEdDUvrVOzl6qJm+wZqammzS3WxLc6enD0u1Ge1pjp2GuKSMJEeqlRuO
p31DQopNr5+9LVNNMhqT1Myhhfl5GS+YrSa9gnVz/Mi3JIh/aZp7/F3dK+xdrbXx99hGpBUWMcdr
40Vzs7WDWZwHOTkTJg+Sg2XoM+frTlh1r4jW7NLbk9JFa5Qd1jR3Rpo71Xb8qn4JaL9eSxHNv8Al
WvO8bA1POjNTTTQaE9XMb0tAe89T6nVXGTrkPDtzZjswvMXa8PbNc7RNpgGW1BTddqMjLSkpPcGY
Zk3OSkvPSrbw4ztPso3NUc6VE81fkur4uJNtDgfOl+v/Zzx8Uez5t3l+97//0a2NPbEn9vwgz43f
8zkqH2XZv+i5MvbEntgTe2JP7Ik9sSf2xJ7YE3tiT+yJPbEn9sSe2BN7Yk/s+b/2aJ/CFL/lV8Vb
YXF4G/luntn7Ad+trGWDlbXQNyI9TzeMyd9TXKe9FS1nvBYTWsfiFT2Tv+l6uJIU1fp+PgaWrkyK
amM/u4ltUBZFtZmNRgppC1OVp6LaqtvX529jK5QPojqOjdZPjWq77kq99IlnTcav+37b9XhTY1Rz
ZjJdFdU6ZjL/Sf5ea5Zklr8dW9/Px8DiLEpUG/vZTWyaJSGqzSzF1BrVFuawzItqK1/S529juZZV
UR3HUiznRLWdL7BIn3g2yfp78ZvB9ZboOJOmcSZN40yaxpm0vp8PjTNpYz87jTNpGmfSNM6kaZxJ
0ziTpnEmTeNMmsb5Nqyg8WwsG4e3+L3S4pOmQdbK2oF6FoKtRPuELn1O1wdLAKqF5SNlJmvCo7Jl
sDWwRqS1azE/2A/vDXjXwbME+ZrgUwNbAB4Bzc8HNKOsOs23BbF22Fq0NMofQAtUwAe/AErYhFgn
VAh1qdrngmugm+Cram3uQO467XPHDVoprdFSQ/BojtYpPFT0sVWr0699vlj0Za7W13pYfNrnXoNa
L1SNfVovRb3Uj1qkjNFKbtYsTVqJPowR2WUtzSinSRuxtmgrW2Bp1mqlMkU/Q/1aIGps0/oiPxdN
o01tFzW1YgRU7RPBDdooBLTPAIvPVoe0mOhxqG8+aMyoFlVre0u0X63a2NZonida3L9HYtQ2avmo
1+sRz9fWQ//ZHKGV1qyVsEkbh47ozPcfbzFj1H+/1n7Rf5qXoLYaBFONYq5VlNHW1xtqY0PUpx2x
zdHSQ+gFzdCGvlnyaWvEB2vzSf2Sq7kWLfFp9ddG68/XVmyDNlci5Z/3wNR/6vWK6MoJRNfYRJQy
GTvo21d6SKuzTluJopb1fXMgx+ab9l5DdF239XmLlUsz3gJ/v7Z2FsCjlo3UxnQUfOq08mZreVu1
8kN42tCPAjyd2pOv7amT68uPll4AvUlbgQ1aq9tQwiZYxYjVaz0WK/XkUqW9XvvXAEFtvcjyqrQ+
0CrZpM1uu9bCkLaO27V9R7lVrQ9iD/i1GQxodfi1OazR8srRKmNe9HtmNG+wXwrtnzptTE7sic7o
p+gbv6VeigvfWsxghzaGdX1rrE5Lb9NWyKZ+66pN62lLdGVRWX7tLXbKwH6LdNqRI5FLzJRYDTV9
NX1Tq1r+qeTvP0YnSpenoho910Jau2tPOl/+ue/yNBnYrmn9RkD0hPpCp6z8PhHsO7HrtDOrRTu7
fN/aUxpn30ljSju+NfqmXpHu0FZeh5azTtv/ojf+vnKEZ5O2a75rhv679sWJPVGgtUbsATr587W5
amMbb1PHjx03Xl0YqA22trfWh9SS1mBba9AXCrS25Kszm5rUZYGGxlC7uszf7g9u8Nfll/iaAjXB
gBpoV31qc2udP9iitvta2lWkB+rVel9zoGmT2hkINartHTWhJr8abO1oqQu0NLSrrXAN+ZuRs6VO
rW0NtviD7fnq3JBa7/eFOoL+djXo9zWpgRDqqG0fo7Y3+9CCWl8btMjS3NEUCrShyJaOZn8Qnu3+
kFZAu9oWbEW7RbNRelNTa6faiIargeY2X21IDbSoIdEPtAxZ1KZAC+pqrVdrAg1awVRRyL8xhMyB
9f58NdrNEe1qs69lk1rbgc5Tu0ONqN/fqQZ96EswgG4jo69Z7WgT1aDEBljaA5vhHmpFhzaILvnU
Tl+wmeoSw1zb6AuiYf5g/jJ/Q0eTL9g3A1Nl1SswOOiOOjF/8viTBj0U9NX5m33B9aIHojUnZq8B
Y90mzLWt6HhLwN+ev6CjdqSvfZRa51dnB1tbQ42hUNvUgoLOzs78ZpkvH+4FoU1trQ1BX1vjpoLa
UH1rS6g96ip0vQ/Vrxd+Va0dGJJNake7H5WjQSJZ9WEG/MHmQCjkr1NrNmnNKvMumInUoBbB/NR1
0Ex0NgZqG/vlBQdaaps66pAVI1YXaG9rQgVirNqCATjUwsvfEspXZd2tLZjIkYFRqr+5RmQ6UVSL
dP7GFmnuYiliWtpDwUAtrZe+2sUykWVN0xowMoBasGTFngiKhV3X2tnS1OrrXyna7KOWYuLRXYyx
EB2hto4Qhn1DoNYvfBr9TW0DOvR95kKbiYI6f70Piz/f1962se/nJtabzs79xn+WJ372ws2bDWKm
3l6WEP1LPEYkjARPYKzv55hvDqXKFXFxHD58zff1t9s1/z3f1z8hQfN/6vv6Oxya/xff1z8xUfjr
xnxf/0GD4F+q/SUiM372Ef7ip0+T+CtCPBM/Ve1mmco8lo2fYscrtWwqPGchfd6APIv65UlBHjfy
5CPPdOQRnguQvnxAnhv65UlDnhzkGY88M5FH/G2kCqSvGZDneL88GcgzCnkmIk8Z8iyC50qkV5+c
h6/tl8eJPGOQZwryzEOeCniKufYPyPNkvzxDkKcAeU5BnsXIUwVP8XeDmsX6Mpu52frkkzch7N1r
NnCzyWzeuAtho1HhRv3hLhHMnJv1mupiXYqemw1L9u3DT5/csGTJPkVBfN++fWYLN9se73q86wY8
l+LZhcdi4BaUKIvUc6MhfEiUY+HcEi2SyrQMKNMiyrRYuSXuEML1nus9F2vPbjxWI7ea9Xp9aPeO
HTt2h0x6booW22XlOquhr9wuvYFbjXP27Nnz/4g7E/Coqvvvn7kzmZlkZgKEAAmgMGyyCQgoFmRR
UdkMEYVSbHWKKA4iZSeAQCSIu6Ii4lJFpEjRoiWtrdZOI0QIYTFgJqQZSkhgmDDehCTkTsbI3/P/
3JshhKVP7fs87/t6ns/cucs5c37f7+8sN7WtJU4o1jFjxqyzWLjChXUJDlOCK8eT4+F3Nr3S+ZXO
z1HWUBxWk/7f97hq8w6T4rjQfKx9h+1C+7ZY+w6jfYfL5GiRk5KTsqnnpp7rxqwbo0vwlP0p+2q7
02Zyxiv8M/TO1fxz51A7mlpjP5HpNClOa+alP+K84kecNv1HnIkmZ8sTHU90rL6loG/x7OLZeRMO
HMh9Ye8Lu527nS67yZVg5p9hM3fr/8wcZthRfCKn8R+XorisOU3/iJycOJvJZe/yyIEDB+KsJsU+
e/bs4nV8c9kP6P8YGZwgNitThfmhpfNni+SZ8x9+TAyd/euFcxghCcJ076TbOosUZjhpjEKrcInk
2JmJfEwUbYzrjVcUsrWFaEsxj01PHyO6TZp4d2cx4L5J4zuLEbFn9PmwpWhnnJn5hVZNrVuEQySJ
1NhZnHAyazI+Hpq7YK7YYnxuNz4/NT4/Mz6/ND53PcbmR+QZn4eMz0Ljs8T4PGF8njY+VX25FrX6
p8lqfLY3PvsZn7cZn1OMz1mPP/b4Y6aVxuda4/Ml43OD8fmu8bnV+NzRNKv9p0/TT/y0o6T+//Bl
RWG70P9a8//vmoIPrv/6mCiuNd6b9Te91eJVZtadYpc4IspFrUkR8Uak9li0qtD/ZqX/jTLZ+H/R
Yw4zDW08PrO28fjbaLM65FvV5kvOTc7zl54n9rj0vFXSpeet37r0vPuPl573vOx+7/aXng8eIOKV
5ud1ze5bhemuWy49n/AcxwRyuqdI1//OR53VSDVASRerlC3KUbHJ/Fvzb0WhZaHlfeGP+9b6jMmc
cG/Cr02fJzztMJnynC2ddyi3O+93vqssdc1wzVL+7lrlekHJTVQS7cqRxPrEeuWfwpQZ0bWxFrk+
u2opoJS4TjUr4VgpuEqpS+zSVHpShlJGU2YZZePlxVWQuDnxTy03xMqmZmW7XlqJq5aEVulN5blW
65tKpLEkdbxK6UcZnPxWs7KlsRh3LivJO5PzmsqhNicop/XS1nK1ktSvbVLbnu2ea1bWG2XXVUtB
u4YLJSU5pX1TGR0r465a0o0yJXa8tGTGPvXn9hilsKk01j6eUp3aO3VG6rup2/RyeeupO65WGltP
/WtqeazUXSz6r6Q2GL+VqXPNhK5Dm8qErpOayoxYmUXJ7Dqr20DKqO79uo/uOovPft139ci7rsgo
dT2nUeb26kHp26u8VxTKe/3YO6/Pu3rpVd7nyz7hPuG+lr6JfZP7fkEp7DeCkt5vWv93YsV3Q+ag
HoMqBr9602DKiCEpQ6YNybh5Z6x8efOemwuH9qbcPHTtsGPDrUZZN3yXUc6PuGnEx7Hy2fDznH88
oto4qx6pjFRGfDyy76iXRn15a787plKO3/Xo8HWNT3Osbnxq7Aj9ubETxnUZN2DciHHbxvcwSvr4
WUbJGL92/Dt8ZozPp5yYsGxC5oTjd8+lbEjz8FR62qG0Q+Pz+Tymf6OUp6lpDRMzjbJ14gGjHJ+o
wvGJkXTLxAj31fRp6cfSy+9ZSHl1Umee2zox0nhn0rKJkUmnJlVNTp+yZ+rUXyX9quOvesy0zJw2
s3hmw4Xjo30pO+e0nNNlbsbc1XNz5pbPVedG5lnmDZw3et4j8+bOWzbvmXkb5n0877N5ufOOzJ87
/9X52+bXLhALkhaMWTB9wZcLihYOXjh94TuLpix6ZpFvUd1i6+K+i+9c/PHi00tGL2nI6JhxZ4Yn
Y37GOxk7MoqXdln6y6WfLS1e2rDMuaztspuX3bZsxrKty4qX914+evkDyzcu37782PLIE6OeWPbE
lyusK0atmL/i0xV7Vpxf2X7loyu3rlRXDV2VsWpHZvq/mas+u3w+unS2yVx8sejzSOami6VxBvk3
Y2/c5SPu0nHSmOlXnXUuzDzNyqVzR+aei0WfHTILL5bGeUGfQ1tuT9nTbj3zcMmIamZNYw42jsy3
rdKZXzcmbm65wVXQNGfybKtI1xl6XddniRsvzp2NKjE7jzbm38anuiRuvqCeflWfi41nS/T7xvMx
BWn3M9cpZvLN1CgxWiugdxs4lhjl4uoQvmxVGN1sHbi4EmzW+33F7L/9itk/ITbnP2fM98Ysb7RD
7cTRfN94YSbEj20xv5ibGuefxvkt5iNzIjOg7tqMptnxgqPMcSnjMsv1Ghc97jopszyznNb0p+q4
l55a3nXSlTnBPFjYbEa9yjzbfF69ck6Nzdx7jGxqnEUnXJg/9XmdK/xqppq6jSuTUtJvGpx2qK2l
cR0zjqxZ7RranCCrki6sPhdWlaSObS0XV6DGrNTXNuNpi/4EdXe1TdLv6Ff0p/TrSR1dBRcyNaV9
UkdWwCS9vv698erFdbT5Sqr3xVg1Y+tms5UziRYuXyfXX7I6FsRWxuQLved+Q+Ov678/Pr3NiZTR
9OcS9XXVdI1xqtmIvaBx40jU1WzMlK4z0Huc7qauREp68luG39t0b5qN6qGpO4j1wgpb2NhqppqS
mak2Fv0X9GPXSbor+rfGTNOPmWr3ft0GNtK4wnUbaKxKzYq+wjWubsb6+H9YjDW1WbnyCWOlbVZi
K25TubKGvtL+d8VYi39yaVqx/025XCm9NK3j/6YYK/tPLsZu4yeWy9Ux9ijNypX6GXuXZkXP+0an
/7tyZcv/uXc/rTTqrO9dEjcPt47rMvy8q0Tf9RhlnXHFqu90jLN147roe6DYPQo7qJv1XVPjVX3u
17/pxdgdTTV2VvoeqnpEtbE/YnfEt13D1xm7k8ymXYxetk7MTDs2MVPfwRhnW2P7nMbvW9kFletX
9B2NXi8tVowdz0Jjb8Szxt2t+mfqDp7equ+mmC16pB0z9l0ZsZJuXOmh77qMs/S0Y/q8FLtHYec2
gL2avkPT6601vlGMfdpcYz/Hs8ZOrWm/Nj59pGIocl7X4p6FjUoMtxrx0OPGno7PN9rWf2mt0ZbR
7qUj8UpHm+fBdUWNZ8JqypEl5rvll+bJooV5qnCa58sas08MEQp3CjgLGt9U82R5Spj4rBcKn/vM
U2UBb+gfyfMiV543eURr06/FJNN0kWp6SLhNM0Qr02OiFU8O5smR5tnyH8JEOyeFhWedPNuKZ508
m2C0F+SpKhFvekB05H5X7k/m/jXc70pb3WnLTe236c9x4eDbTvrbyvwE/Vgh/0J/h5pPyjfMp8QA
c1AMNIdEH/MZedgc1v8/6Gm9gNbLhYVvinnqjz/Qm/W0tFtkiBZinGgJQ0UvMQxmyMPiYXgEFsiQ
WCjrxCJYDEsgA5YKp1gmj4jl8ASsgJWQRf018BSshafhGXgWnoPn4QX4XNwmvoAo338EKXqZBJgg
XQwz3QOT4F64D7xiommP6ETEXvMUcYv5fmE3PwizxTPmVeJa85OiszlLXGt5Tx6xbIL34YjoZfkW
CsEPRXAUiuGfUAIBOAb/Er3iWsrDcSfkkbjvhDNO5XslVMsj1jgxztqL4yDRy3oTx9nysPVxmAO/
gUUyZF0MaGNFGyvaWJcB2lg/EcOsn8JfoF4Ms/UWnWx94EHRy+aB6TAP5sNSyIQnAY1s6+AVeA/e
F7fZPuJYCVVQDTVQC/WAhvaHYAY8DItEp3ghhsUni05G7p4mrxOMb2dwvV60IWuzydpssq0H2XYr
2baabLuXbJtOto0l20bx9BbypZ95inzJ/HO5jAy6kbx5nRY8Zp/caj5JngWF2XyaHDwj7jfy7BRP
HWObeWFUPCD6N2t/DO0vpv07aH8IT0+j7fW0/RdqDaLtDbT9Nu19SXtTRCKtnKWVs7TSklauo5U5
tNKfVvrTSh9auY5eHqelnrQ0g1YG0sI2I9J9fPtEpNDGP2jjH7TR0/Sg/IJ2+tPOg7QzmHbupZ2R
Jq/8hrb6mzbKv1Lzb7Rnob3F9OwR2mxNz7Jo7Xlzuayjd/nmCkbrGXG9ORwbsa1otTeteml1CK3e
QavdaLEnrX1LzW8ZeXcT5WThiM0w/8NMos8sb4osqYo18BSshafhGXgWnoPn4QXIl1GxHw7AQTgE
30ABHIYj8C0Ugh+K4V9SiuNQCiegDMrhpNwvTkEQamVAnGOc14EGEaiHKLPb99xvgB/gPPwP/Ehf
pFRNAkzGrHjSPI0M+6U8a36Ao0eetRyRquVbKAQ/FMFRKIZ/QgkE4Bj8Cypk1HIGwvAdqFAJVXAW
qqEGauEc1AF9sfwIUu6PS5L7baNk1HYHjIPxkCZDtvs4ToZp3L8fHoAHpWrzwHR4jHvzOM6HhXxf
AhmwlPMnOGZyfBLW8v1pwAfbyxzXcXwFXuP7engdNsAbtP8e1zfzfQvfP+L7J3z/G+CRDY9seGTD
I1tAStsxwCMbHtnwyHaCOmVQDnhkOyMDtjB8RywqVMoCWxWc5V41bddALdRxjne2CMd6zvHI/hDM
gIfxSxEviWRj5TKLl8jdyeSwvnrFcfYHzsZxNpYszzV/I/oIE1cjYjSZGSAzA2RmgMwMkJkBMjNA
ZgbIzACZGSAzAzwdItOiZFqUTIuSaVEyLUqmRckilYyJkDERMiZCxkT4vRx+L2D+lYgz/xqmk0EP
yZNkTYCsCZA1AbImQNYEyJoAWRMgawJkTYCsCZA1AbImgJMRnIzgZAQXA7gYwLkIrgVwLYBbEZyK
4FQAVwK4EUD1KKpHUT2K6lFUj6KqiqoqikZQNIKiEVQMoGIEFQOoGEDFgDFiS4QNLW9lJNtZe//O
2vtncwFr7WFWIVYbQ98wER4mwjJD3yc4S+GsI/qupoWjYirrpJt10s066WaddLNOulkn3ayTbtZJ
N+ukm3XSzS/dxFrZjbWyG2O2kDFbyJgtZMyWMWY1xqzGmNUYsxpjVmM9TWLMBhmzQcZskDEbZMzi
txjPujmYcVrGOC1lnJYxTkvN00UP80MwW6xhHe3EOtqJdbQDa6ebtdPN2ulm7XSzdrpZO92snW7W
Tjdrp5u1083a6WbtdDMWg4zFIGMxyFgsZOxpjLlCxlwhYy7IGudmjXOzvrlZ39ysa27GSpC1zc3a
1o2xEmR9c5P/heR/IflfSP4Xkv9l5H8Z+a+R/xrrXxLrXxL5HyTnC8l5jZwPsga6Wf/crH9u1j+3
nu+yFq1r2Z+9JJ/CgTHM52XM54twYgxO/I67L5Dtd5iPsJMqlD+a/WK64V6Ap0t4qpgV8yW5krPp
1D1C3W+5Ooq6L1F3L3XHUbeQer8Q1tg4+jlP+nmykCfHGfsrPWc+NFp6mPsjuX+I+0XcH0ZLz3L3
U1q6jZbyaWmA8fw/jX3iceMzIhJMLUQn0zSYDY/Db2AuzIP5sBCeY6VvZcoRLn5lNa1n0M4+Y2+0
SbQz/03caP4K/8tFV1bte9klJrFyt2eX2NVcwcxwhh6EufaduJH1fL78ihpt2VN20dd06s8WY1nB
ppHz94ux5geM3ddYkUjPOtCzDvSsAz3rQM860LMO9KwDPetAzzrQsw7UTKbmHGomU3OOUdNFTRc1
XdR0UdNFTRc1XdR0UdNFTRc1e1DzBmr2oOYNRk0nNZ3UdFLTSU0nNZ3UdFLTSU0nNZ2xmoNjNQcT
yf2iN996GxpnG3uEetQK6P8uOdwDk+BeuE8ksHdLYO+WwN4tgb1bQrz+n9NaULg1ddJjO41cw6My
UWjqKctNvaA39IG+cD30g/4wAG6AgTAIBsONcBMMgZvhZzAUhsEtMBxGwEgYBbfCbXA7jIY74E64
C8bAWBgH42EC3A1pMBHegrfhHXgX3oNN8D5shg9gC/wOtsKHsA1+D9vhI/gY/gA74BP4FP4IOyEb
/gR/ZreWw/ErWWLaBbshF76GPVzfK/2mPNgH+bAfDsjTpoNwCL5hBzGNt5UHZIHla3YSe2Av5ME+
yIf9cAAOSr/lEHwj/XGtZHlcMrSBttAOUiBVlltfhjcBDazvytPWrfKs9UPYBr+H7fAnru/myG7T
+jXfC6Tf+i3PF/M9Istt18C10Ak6g1uetXWBrtANukMP6bddBz1lia0XkAs2csGG77aBnA/i3jB5
2nYLx0nyrF2R5XYzWCAOrGADO8RDAjjACS5IhBbQEojXngStgbjtxG0nbjtx24nbTtz29tABOgL9
t9N/O/2303+7G7pAV+gG3aEHfRooT9sHwc+k3z4UhnFtFNwJd8GDPDed4yPcm8lzj4IXZsEi7q2A
lbAKMuFlrn/A8x/y/DZZYv8959uhlmuaLI83AbHGt5b+eOKIbyNPx3cmh5abUMeEOibUMaGOCXVM
qGNCHRM1TKhjQh0TyphaypCpFSRBa0iGNtAW2kEKpEJ79qzXQifoDG7oAl2hG3SHHnAd9OQtuxf0
hj7QF66HftAfBsANMBAGwWC4EW6CIXAz/AyGwjC4BYbDCBgJo+BWuA1uh9FwB9wJd8EYGAvjYDxM
EPr/NLDDlAYTIV2eMt0Dk+BeuA8m0+8p8HOYCr+AFbLStBJWQSY8CashC9bAU7AWnoZngPcN0zpZ
b3oFXoXXYD28DhvgDXiLOfJteAfehfdgE7wPm+ED2AK/g63ACmjaBr+H7fARfAx/gB3AXGtirjX9
EXZCNvwJcpjLv4JdsBty4WvYC3mwD/JhP1w+i0yWv2aWnso60IKZ/xbWgRbM/rcwax+2MONZmPEs
zHgWZjwLM56FGc/CjGdhxrMw41mY8SzMeBZmPMsO3lE+gU/hj7ATsuFP8Gf4q6y0fA5fwN/gS/g7
+OAfkANfwS7YDblwUDgth+Ab4YxrJRLikoUjrg20hXaQAqnCYX1BVlpflKr1Zb5v4PtGGbK+yZqE
B8Zstol7xGL9Hffos5U+W+mzlVna+ok8Zf0UdnIvG/RZ7jOe/wvXPuf+F/A3zr8E+mmln8bst5fz
fO7t53iAawfhEHwDBcJp/Zbf5t3OyrudtYhrR2W9MVOW0Dfe56wh6vLOYlX5zu7ayu7aehZ4Z7Hy
zmLlncV6DupAgwix1ctTtkRZaWsBLaEVpMh6Wyq0hw7QEa4RCbZroRN0hh7CabsOekIvuIFrAzkO
AlZZG6tr46wrnHZFOOxmsEAcWMEGdoiHBHCAE1yQCC2gJbSCJGgNySLB3gbaQjtIgVRoDx2gI9BP
O/200087/bS7oQt0hW7QHa6TlfY+vKP1heuhH+fsFOw38P3CTDyY7zfBELgZfkYcQ2EC3+8G3nPt
E6mXLnPt98Ak+IWstz9IPx/huctnad537bzv2pfACvqwElZBJs8/y28z/o1ZewPHjbT7JrwFb8OH
tLcNLsziH3END+0adX+Q9fFCnoo3sVeySzUePeMTOLbiemvhNGZ2Vqj4dlxLgVRgPo7vqP9dUh/p
sX3VCkao39ij7Wq6PofrS42/o+j7rSoRp4yRvzTfLXezO03Q/7bFvUrRVxkgw8pgGAIjYYw8rIyV
+5XxcDe78snyOLuLY+wujiVMlfsTpsHTMpzwDDwLz8Hz8AK8CLzLJbwM6+AVeBVeg/XwOmyAN2Aj
vAlvwdvwDvwW3oX3YBO8D5vhA9giw84+MizM9DSiTOWdeD7v0MPov0b/NWWoDNJ/Tbmd47OyTHmO
d5f7xfXMX9fz5P6Ee2Uw4T6YAr+Eh2RZwiyYDXNgLiyEp6VGbBqxacSmEZtGbBqxacSmEZtGbBqx
acSmEZtGbBqxacSmEZtGbBqxacSmEZtGbBqxacSmEZtGbBqxacSmEZtGbJpjnCxzjIcJcDekwURI
h3tkGbFreDhEHsWhA4rho8wz/nLYidi3Efc25X65Q5kBj8OzMgcNcvT3b2LfRuzbiH0bsW8j9hxi
zyH2HGLPIfYcYs9JyJA7EpbCcngSnpI76FcO/cqhXzn0K4d+5dCvHPqVQ79yxK044MUBL307iQNe
+ldPBtWRQXX0s5SeFNOTYvPkH+vMU3/UWF1cONOf1cWFO/1j7/i5ZFcd2VVH74rpXTG9K6Z3xfSu
mN4V44wXZ7w448UZL854ccaLM16c8eKMF2e8OOPFGS/OeHHGizNenPHijBdnvDjjxRkvznhxxosz
Xpzx4owXZ7w448UZL854ccaLAsUoUIwCxShQjALFKFCMAsUoUIwzXnE7KnhQwYMX+1DBgx/7lDHi
GqJPI/q02N9bn4+9T/dGhbaoMAgV2qLCoNhfiX+BV/vwah9e7cOrfaiRhhppqJGGGmmokYYaaajh
QQ0PanhQw4MaHtTwoIYHNTyo4UEND2p4UMODGh7U8KCGBzU8qOFBDQ9qeFDDgxoe1PCghgc1PKjh
QQ0PanhQw4MaHtTwoEYaaqShRhpqpKFGGmqkoUYaaqShhkfYyIU6InYS8StEvJiIk4hwJREuEalo
lIs+uWhThDZF6JCEBkncfY34c4k/l/hziT+X+IuIv4j4i4i/iPiLiL+IfhTRjyL6UUQ/iuhHEf0o
oh9F9KOIseKVH14239WJ65V7mOOmgpd5bhZz3GMwG2ibHp9omutWMGeskvsdy2XY8QSsgJWwCjLh
SVgNWbAGnoK1wNzoYG50MDc6mBsdzI0O5kYHc6ODudHB3OhgbnQwLzqYFx3Miw7mRQfzooN50cG8
6GBeTIyHBHAw5+kze9jou8YYDzLGg4zxILrp7+k9uHuEsRtk7AYZu0HGbpCxG6TvGn3X6LtG3zX6
rtF3jb5r9F2j7xp91+i7Rt81+q7Rd42+a/Rdo+8afdfou0bfNfqu0XeNvmv0XaPvGn3X6LtG3zX6
rtF3jb5r9F2j7/qcNVX+E7UPoPBXTXOWHlGpGEhE2dwv5349bpzHjfO4cZ5nS3nWzrMORkoCker/
PYgEou0X+xvQHhw6j0PniTKbKLOJMpsos4kymyiziTKbKLOJMpsos4kymyiziTKbKLOJMpsos4ky
myiziTKbKLOJMpsos4kymyiziTKbKLOJMpsos4kymyiziTKbKLOJMlvcSCRZeJOHN3mKV3TEnzwi
eIgR8D0jIEIka4ikXewvM+30v8wQyRv6X7PwLg/v8vAuD+/y8C6PqLKIKouosogqi6iyiCqLqLKI
Kouosogqi6iyiCqLqLKIKouosogqi6iyiCqLqLKIKouosogqi6iyiCqLqLKIKouosogqi6iyiCqL
qLKIKouoshjHU41xfDNRfBP7z5zupNev0eudwkG8B4n3ILEeJK42xNSGO68Tz0HiOUg8B4nnIPEc
FFZlEb4ult8rS+RpZQ158aKsUl7X/9LO1QZljYwIE5/fi148EVEyyIilsEb6lbXCrjxN7RdkhbJB
/+/7yx+UN+UPDva3Dva3jmvgWugEncENXWAGzzwMj8BMeBS8MAseg9nwOMyB38BcmAfzYQEshEWw
GJZABiyFZfIHI54GenpSWSFDxHJKWS/PKrzpiWnKfLJ9ASziagZRLoVVskDJhCdhNawRbZS18hPl
ZZ5bJ08or8Cr8BpslJ8T3+cORR5wmMECcWAFG9ghHhLAAU5wQSK0gJbQCpKgNSRDG2gL7SAFUqE9
dJBVaFiFhlVoWIWGVWhYhYZVaFjlGCoLHMPgFhgOI2AkjIJb4Ta4HUbDHXAn3AVjYCzMII6H4RGY
CY+CF2bBYzAbHoc58BuYC/NgPiyAhbAIFsMSyIClsEx+LixkznFU/BYVy5QNsoZcWiNryZN6kY4L
UVyI4kADDugZVsaKE2HFifBEBJWjqBxlhYmwwkRYYSKsMBFWmAgrTAT1o6gfRf0o6kdRP4r6UdSP
on4U9aOoH0X9KOpHUT+K+lHUj6J+FPWjqB9F/SjqR1E/ivpR1I+ifhT1o6jfgPoNqN+A+g2o34D6
DajfgPoNrHIRVrkIq1yEVS7CKhdhlYuwykVY5SKoG0XdKOpGUTeKulHUjaJuFHWjqBtF3SjqRlE3
irpR1I2ibhR1o6gbRd0o6kZRN4q6UdSNom6UMbeY7NbH4go0XUl2rxGJqH0StctR+6yYi8Y+NPaR
6RU8mYfWJ9H6pLKM8xXyDLVqyXyVzFfJfJXMV/Hhf/DBhw8+fKhRXpJ7GQFHGQFHGQFHGQFHGUsH
mBv24JEfj/x45MMjHx758MiHRz488uGRD498eOTDIx8e+fDIh0c+PPLhkQ+PfHjkwyMfHvnwyIdH
Pjzy4ZEPj3x45MMjHx758MiHRz488uGRD49O4tFJPDqJRyfx6CQencSjk3h0khGiMkJURojKCFEZ
ISojRGWEqIwQlRGiMkJURojKCFEZISojRGWEqIwQFY99eOzDYx8e+/DYh8c+PPbhsQ+P/Xjsx2M/
Hvvx2I/Hfjz247Efj/147MdjPx778diPx3489uOxH4/9eOzHYz8e+/HYj8d+PPYLLw4GcTCIg+fw
excunsW5Epz7DueqcK4K56pwrgr/nfi/E/dU3FOV57n2Ik6/LP+AgxU4WIGDFThYgYOVOFhDnvwd
F0txsRQXVVxUcVHFRRUXVVxUcTGIi0FcDOJiEBeDuBjExSAuBnExiItBXAziYhAXg7gYxMUgLgZx
MYiLQVwM4mIQF4O4GMTFIC4GcTGIS1W4VIVLVbhUhUtVuFSFS1W4VIVLVbhUhUtVuFSFS1W4VIVL
VbhUhUsqLqm4pOKSiksqLqm4pOKSikuluFSKS6W4VIpLpbhUikuluFSKS6W4VIpLpbhUikuluFSK
S6W4VIpLpbhUikuluFSKS6W4VIpLpWIALkVwKWKMxkYX6nChBhdqcCCCA/p7Uw3q1qBuDerWoG4N
6tagbgR1I6gbQd0I6kZQN4K6EdSNoG4EdSOoG0HdCOpGUDeCuhHUjaBuBHUjqBtB3QjqRlA3groR
1I2gbgR1alCnBnVqUKcGdWpQpwZ1alCnRvRmZjjPzHCe0a+ynicozxPFC0Rh9J7vG2Aj6/2brNsd
2NV1hGvgWugEncENXWAGzzwMj8BMeBTYQaJ1PVrXo3U9WtejdT1a16N1PVrXo3U9WtejdT1a16N1
PVrXo3U9Wtejdb14FK0r0LqCHqv0WGUUhBkFYUZBmFEQNvS/MALQ/YrMZwev6H/Z+PfZXoEfFfhR
gR8V+FGBHxX4UYEfFfhRgR8V+FGBHxX4UYEfFfhRgR8V+FGBHxX4UYEfFfhRgR8V+FGBHxX4UYGC
KgqqKKiioIqCKgqqKKiioMpoCDMawoyGMKMhzGgIMxrCjIYwoyHMaAgzGsKMhjCjIcxoCDMawoyG
MKMh/BNGQxiHwjgUxqEwDoVxKIxDYRwK41AYh8I4FMahMA6FcSiMQ2EcCuNQGIfCOBTGoTAOhXEo
jENhY42vNv5TyJvwSsUrldlGZbYJor2K9rrGKhqraKyisYrGKhqraKyisYrGKhqraKyisYrGKhqr
aKyisYrGKhqraKyisYrGKhqraKyisYrGeowqMarEqBKjSowqMarEqBKjSowqMarEqBKjSowqMarE
qBKj6tBzYREshiVAvhGjSoyqaMlcrF06Zsi0542RHmFOjfynMcLefTF7VN5MGW1ORpuV0VbGSGvD
SEsQaU0zyiJW4xWwkvfyNfzWs7KazK7m6Shjs5rVuY5a/VA4gsJ1zXZN1WR3NdldTXZXk93VZHf1
/6PZpprsqyb7qsm+arKvmuyrJvuqyb7q/6u7Iv1tJYpSe5veW+qEOXYtiks/iMlom4+2+fhXiX+V
aKu/2ZTgRBz6htA3ZMx/L3O+nneE19kpbeTamzKEriF0DaFrCF1D6BpC1xC65qNrPrrmo2s+uuaj
az665qNrPrrmo2s+uuajaz665qNrPrrmo2s+uuajaz665qNrPrrmo2s+uuajaz665pNTleRUJTlV
SU5VklOV5FQlOVVJTlWiewjdQ+geQvcQuofQPYTuIXQPoXsI3UPoHkL3ELqH0D2E7iF0D6F7CN1D
6B5C9xC6h9A9hO4hdA859DgXwWJYAhmwFJbJkKHx97GREBWtlT+LtspX7Dh3kZe7ZaayV25TzrHP
0OTLyveywMzMab6et9f+8hPzYBls+reVp4iW5p8LZ+zfKaxwBuQhHNtCuztgFyNgtyxUcsn0r2Ev
v5nHcb8MKId40y3k1/wci6BCxCtnGKkae9wIO6F6aJA1ZiFPmG1gh1Te/vvLk+Yb5DnzQBgEN8qI
eZgsd3qk6nxYHnQ+BswRzt9wnCsDznnAnOBcznEFx5XAHtqZBayYzheBUel8mfuvcY25z/kG5xvh
HdrYIr93/p72P4FP5TnnH2En17I5/5wjMTkLuHYYjsBRzoshwPdjcILnKuUJ5zmolydcybLK1Qba
Am+HLt4OXd24PksedLGnd9Ev19OyzvWiPOd6Hd6ED2SVGBdTtQSfoqh6FFUrUbUSVc+j6ilULUbV
o6h6DlWPoupR1IygZi1q1qJkLUrWomQtKn6PihoqaqiooWAlCpag4FEUPIqCJSh4FAWLUbAYBUtQ
sPgyBUtQsBIFK1GwEgWLUbAEBUtQsBIFK1HwKOpVol4l6mmop6FcJYppKKahmIZSGkppKFWJUrUo
VYtStShVi1K1KFWLUrUoVYtStSh1NKZUCUpVopSGUhpKaShVK7oo2+Vy5c/yU5TykYM/oNBWVPlO
OS5nkmeLlDPyPbJ7ilLHTvt7OYI822M2y1yzVb5kdso5ZLvfnCzd5k7iEXN3uZDM72LuJ29DtQ/I
/jvJubfNI+RK863y/ti/nVVq/rncZJ4qZ5m98u/6v79EVF8wJ33FKrEb9sp/8Yun8eM4vxjkF87Q
ajUtltPiWcbSMMbScN4It+PYV/IwtfTxcsAYIxXiWmofoeY+ap6ib0H65qCFQmM8DJaF1PxK7qPW
aWp9Ro3W1Cjj90qN8ctbtTGGOzFOr+e8vzxOrRP0MldcQ2adM2rmkllfQx4Zs5/ah8iqQnaRfo5F
8hTZcYrsOEVmnCIzysiMMrKijKw4R1acIyvOkRFRMiJKRkTJiDIyIUomRMmEUzh3CufO4Zo+81eI
RPpjpedb+L3t/O5fifV/ibvzKKnrM9/jv66qruqurhZFBLe4xF2zqDEm0RgmCWPMJDExiRmj0SQT
jQOBRBRUQASyaBIX3EERl0gQNSyxQ1wAd6PGNHTTBRTVDWnZu2l+0NDQQEN/76sqnblm7twz5557
z7l/vM+vftt3eb7P93k+Tx2ofgFvh73s2sKe63M3hl3a36797drfnnvQ+SNhl3a2RylvdRn5td5Y
U/J7SvhpsWS+ubweGlxtTjSKIyUbrg7t7Nao3RXaXRFdotfJnp5oT60te8vzYbzex3uzkyX2ssRe
LaxlicASXX37qosluhKFMEeLdTypIdHBe7IYEK5KDrQag3AojgvXJY/HCWFz8mTrfAo+bPXYPTnY
/c+W/+3yGUZzhr23lnW7WLfL3lvLwl0sHFg42HtrWWE8SweWmMwSk1lisv23lrX3svZe1t7L2sH+
W2v/rWX1vay+l7XGs3wXi43PzRaJ5mBBuC73huNfUI/FWIkiVrn3V8f3tLEmXFcbhT/VVoY5tWlk
cKzzEzFMhJoUJtuDa63m3toHwpraKZiKhzA9zIlqeOR23rjGSn9M9Nkv+uwXffZb9U/Y6fvt9P12
+n67en90pPUoreUutt/G9tu8lRajOsWoTjGq09y7zL3L3LvMe5t5bzPvbea6zVy3iS+d4kun2NIp
tnSKLZ38u1Ns6TTWLuPcJlZ0ihWdYkVnRVaPk3jAA1b/Fat/j9W/J7HIir6EV8NbiTdkxTfxVniC
F/Qklrqe51uFMDqxMixMFNGMFqzC6nBr4q+Oa7BWm+sc12MjNkWTeEtdot3nzejgeVscY2wN1yW2
odPn7dgRhopNDSJ3QeQu2MHfEqMWJ3rc24f9YVGi1zHIwhVIoBS/Uryt0ue0OJUNE5M1PufCiHI8
6+d4IA5CfwwI5/LWC3jrBbz1Arn1luTh4YbkEe4diaOjbyePdfwgjhPzjscJ4TvJE52fhJOdn4JT
ff4QPhw+L0Z+X2SZbdUmWbVJVm0Sb/+KeHlH8mzPfAKfDD9NfsrxHJwbJiQ/7XgePhMutysuSP6T
z58N19oZ3+r7F7Oz7ZAbkpdGhyavwNCwRHz9XW5oaMgNwzWhxy7psUPusUN6eMkkXjKJl0zKTXL/
p/glfoVf4/ZoYO4O3InJnr/ftQcwxflUPKidac4fcXw0jMg9jicwI9yS+224QTabkHva+TP4HWaH
8+2q82W4CTxwEg+cRB/cIstNyP0h/DQ3H3/03AuuLfDcQp8X4SXX33D+lutva/fPrr2Lv7hWj8Vo
0FYjlqLJ8ys8W8BK94oQvXn3JLv2/NzqsNDOPV8WnWD3XmD3np9b6xofzPHB3Abww9wmtIVXcvww
xw9zHeCDua3Yhk4RYDt2+bw7LMrtwV6f94PP5ficqDCxlt/V8rvaZFhUm3KsDKNFidGixOjaKufV
okcWfLA2F16prcUBPvfDga4fhP442PUBoSDTF2T6Qu0g7R3qmcNwOI7AkfiAZ492/xgcq/8PuibC
ikYTayeEBjt8Uu2t0cBaa11rrWutde1tuB13uHdvuMHOnyRSnS9SnS9SnS8KTBKtzq+dpp3pxv2o
Np/Q/gznv8VMPBmui44VJa4VJX5fzsyvlfP5myLBRjt+sp19uZ09366da9e+I+futGNftmPX2pWN
duOf7cJFdmGTXffPdtYVdtJcO+YOO+ZNO2ajXXK/XdJkF7zE+3/L+7/K+1/h/aX/qXA2j18S/Zt4
9ZSR/E7GWpqYK0vNFxOed+0FvCbPve7eG2G56Llc5npFzNoic82XA7cYbZvsNV/2mi9+zTDyN8Wp
NiNfLBa9YdQF8WaNeLPGyDeK13kj3ypm58XsvHjyhtHPFgtmiwWzjbLHKL9e0jyy19Lc90Xaq8J8
GWy+DLZUBptvb26xN7fIYEvtz6fszy3251P251P251My2NLcz733C9yG28NyUX25qL7c3twimy2V
zZaK8MtF+OX25lOy2Xx78yl7aTa/n83PZ/PpNvkkL5/k+W2bnJLnq2389A1+OYNfzuCXM/hiG19b
w9fW8LU1fKuNb7XxqzX8ag2/ekMuyvOpN2S4+XzqKRluqcyxnH/M4B9t/GMNBbmIH7yEVym0t8Lz
LL1OdmjkC58TzVtE8xb+8C6rtrJqA6s28InnRO7VLPu2SN3Csm+z7Nt8YzPf2CAaN4nGTaJxEx/5
EB/pFmWLomyRr6zkJ+tF1nqRtV5kreczy0TTlaJoQeRsEhEbRcRGVl/H6utYe50I2CgCNoqAjSJg
owjYyLLrRL1GUa9RpGsU0QqiWFEUK4piBVGsXhSrF8EKIthKEWylaLVStCqKTkXRqSg6FUWnetGp
XnSqF51WikpFUanYF5XqRaOiaFQQjZqsztsiS4vI0mKV3rZCb4suq0WX1SLIatGiRbRoERlaRIYW
kaHFSjVYqQYr1SAqrBYBWqxUg5VqsPNbrNTbdn6jHd9oxzfa8Y12fKMd32jH19vt9XZ70W4v2u1F
u73ebi/a7S1WscEub7HLW+zyFru8RU28iTou6eqzwr7o43ZZqc76kR011Y6aake9Zp0n2jV7rOtM
61pnXevslnbruta6zrGmc6zpHDtit12w21pMtBYT7YDd1mMij9/Ny6fy8qm8fKq1mMjLd/Py3bx8
Ki+fypv3sNccdprDm/ew1Ry2WstWa3n1HvZay5P3sE8d+9SxTx37rOXNe3jzHjaqY6M69pnDe3fz
3qk8d48515nj6+EOHtttBouc7TD2neFpvrk6OtzMdjhbb2ZtZtZmZtvMql4caDezejOrN7odRldv
dPVGt8Po6o1qhxHtMKI2I2ozojaj2WE0O4ymzWjajKbeKEq1bFt0tJ526mmlntbrab2eNrFhqUZt
0FuX3hr01qC3nXpr0FuD3nbqrYEttrPFdr3uZIvtet6p5/V6Xq/n9WyxXe879b5T7+v1vl7vDXov
1Yfr1QirxcsdYYlZL9Fzlx5bxLIXRNwVIm6pPniuHHHTnurqq6Ha+/4P00eTl0Rnli3X6k6LO63l
s1Jt11O2Y2XfW9uddWh/ufY7qeECTdvBwnvNM8sSESpp0jQyONb5iZgetmljdXllGj3dLIuUxtgV
naiNN915nv22a+tFT2z4e31fzjeR+JJBFbLhRbO6yGx+wI7b2XE1O65mx1J9vZr9thvDi8bwpjG8
aQxvsuU/1t1H4Mj31d/Hev54e/FEx+mef9S1Us1dYc5xNMj4Oo2p05g2G9Pmvm9wthp9m3FtNa6t
xrHVOLYaw1Z9d+q7U9+d+t2s38363ay/zfrbrK+t+unUx+boeK0vMPs/mfnb74uyeXaeradd5aia
Lf9LkV/0reVKsx9a+hc9f48+Zvy2XhfodYFeF/yXkacUaY71XCnKnOhYihjTPfufI0Z1OYvuoAP2
qK3T1vXicE3fv+5Youdvl//F6JnGvdqTz1m1enXBcuN/mZXmvi+ClDJDgaWmW+tS3t3AWtNZa7r5
vKzV27Q2xyrW027LWXA6C063kvWsON2OKNgRBStab34v2xUFc1xtjqvNcbVVrafBltNgy+mt5f8p
chSscr1Vrv+PyHGsNo4P0839ZfNebZXry9HjCFZvZvXm8rcRO0WRPeF1o97C8s1GvMWIS9/hbGHt
ZtZuNsotRriFlZtZuZmVm1m5mZWbWbmZhZv1tIWFm1m3mXWbWbeZdZvtqp2i7l7Zj/fwsJ3h5Sgh
C+6llPZESWrkLWedzjZGxzqL1TC76ZOYPollym6Zslum7O77jrCdZtlGx++W8dplunaZrlum66bX
d8t27TT6broipsl3y27dslu37NZNd++mu3fLbN0yWzfdEcts7bRHLNN0yzTdskt3VC2X7zGSh+Xu
WM4u6boNeo2t4BNW8IlyVKmW7buSA0SSD4cOM2jzVEfy41E/EUbNE52hn0KU0s467ZS+c91dmoEZ
58rfILSXnmeJAfbTx8Nu10vfynrCe2uiQ5yVZt9l9l1m31We+aW0whVh2ftm3mXmXeVZNzg2Yima
0QKzM7MuM+sys67oGL0tZt+d7LuCfVe8vzLXd4de1rPtTj2s18P6/6jGny1/47eebXey7Qq23fkP
FfoK54Xyt4DlSp1tV+h9PduueH+1HlWY+c7o+GStTwPCo9RSTC3F1FJsTH80pj+y1k6KqY1iKn27
toWdNlNGsRXYZwWesQLPqCP7qyNL/zqypHraqJ424/ojddNG3bRRN23UTRs100bNtBnPHymZNiom
NqY/UhRtFEUbRdFGTbRFGaP5vZ536HG3HnfobY/e3tXbu9Fx7r7HbhuNcaUxrvTkrr7vsP/nCn2c
sjuXX3+WHWaEjWy4lw33/scqPetanfMXHBdQWm85vn/VVjgv4O+rt8ozrZ5fE1b+wyoOZLVWVmtl
tVaWamWpVuP+a993Uq0s0soirazRyhqtrNHKGq2s0coarSzRyhKtrNDKCq2s0MoKrdHh5rnKHFeZ
4ypz3GqOeXNsMscmc2yiVEte12Q+TVRlO1XZbi6rKMuSBzaZS5O5NFGS7ebRZB5N5rHKHFaZQ5M5
NJlDU/l/UR6X/G50XDQ1ujI8GF2FH+K68Fg0NtwdjcNNGI+bsTZMjdZhPbZ7Zk+4K9qLHuzD/nBX
xcmhoeIUnIrT8CF8GB/BR3E6zsCZ+BjOwsdxNj6BT+JTOAfn4tM4D5/BYPwTPovP4fMYgn/G+fgC
LsAX8S/4Er6Mr+BCfBVDo0EVr4SXK14Nz1W8htfxBt7EW2FRxdt4B3/Gu2FR6tFwd+oxPI5654ux
BOaa6kUId1UeGB6s7B+mVlLZlVR2JZVdOQiH4jC0hrsrOzyzBdvC3elTcDaGhwfTI/Bj/ASjw2Pp
68Hu6cmhId0QFqVVPJkTw6LMSTg5PJc5BWfiY84/jUvD1MxluCLclZmCGWh1/h7WwJpl2sJjmXZs
da/L+a5wV1UiNFQlkUIl0qAUqyjFqmpkUYMcanEA+uFAHIT+OBifCouqzsF3ff6h40THJx1nheeq
doaGam1VH0wfXx71D4ujgyH6RYdgIAbhJJyMU3AqTsOX8GV8BRfiq/gaLsLX8Q18C9/GleFhnvsw
z32Y594cjQrTo9G4HjfgRowNs3jzLN48izfP4s2zUr8Oi1O34XbcgTsxGXfhbtyDe3Ef7scDeNR7
j+HxMMuqP1y5IiyubMEq/BWtrm9w3IgO97dgm2v7w+J0GhlUI4tDcRhOwIlghzQ78I5Z6bMcz3Y8
1/ELuBxX4Lv4HoaHh3nOwzznYZ7zMM+5mefcnDbftPnyoFlVPynZJro7NET34F7ch/vxAGbiSczC
U3gaf8a7+AvqsRhL0IBGLEUT8liGAtaGZ8WEZ8WEZ8WEd6Id6MJO7EI39oS54sRccWKuODFXnJib
2hQaUm1ox2Z0QHWSirEV29CJ7VCxpLpQeq8XIcy1357NiAUZez9jr2fs9Yx9nrkwvJP5puPFuNQz
l+GKMDfzI+ejMBo34EbchFtwK+y3DBtl2CjDRhk2sp/mZn7jOMNxruMCsEOGHTLskGEHe+1Ze+1Z
e+1Ze+1Ze+0de+2dzGZ0YKt3u1xnD/tubsVHolR0UFSJNDKoQjVKv95dg1zpJyZxAM6JBkbn4sow
jo+P4+Pj+PhoPj6Mjw/j48P4+DA+Piwao4WxYQQ/H8HPR/DzEfx8RPSzqF/0c/wCt+BW/BK/wq9x
G27HC9FR0YtYG8Za0bFWdKwVvc+KzrKis6zoLCs6y4rOikq/IL0njLeq463qeKs63qqOr3goLKuY
hofxCB7FY3gcv8ETmIHfYiaexCw8hafxDH6H2ZiDuZiH3+NZ1OEPYVni9Khf4oxoYOIsx8G4IIxL
fDFcl/gSLnI+NExKDAvDEz/C8DCcZvtS8rIwim77UvK7jqPCn5OjQ2OyIapMNkYDkk1U7zJV+fIo
m1wbZiXX0SLro5OTGxw3ln4byHFz1D81KjooNRrX4wbciDEYi3G4CeNxMybg0TBCvBghXoxILY36
pZqQxzIsxwoUsBJFNKMFq8CevH08bx8v1oyrPCgs4/VjxZgRlZujrPgyTnwZJ76MqOyJDkonwbfS
/XEwjsMpYUT6VMcz8LFooJgyIv0Jn4eHceLHOPFjnPgxTvwYLX6MFj+GiR/D0nwpPRZ8Kf1gWJZ+
qPw/6JdlPoCjcDSOwRm4MMyy08baaWPttPGZkVG/zLWYiEm4G1Ncf9Tx8egou2l85hmfWz3/HtaA
z9k599k599k5s+ycWZktUXUmxlbPd7nP/+yg8ZnuqF/VgLCs6hAMxCAcisNwOI7AkTDWKmOtMtYq
Y606Fh/EcTgeJ+AH2roSV2G885sxISyrrgjLspeE67KXYnwYnp0A+yZr32Ttm6x9k7VvsvZN9g7c
icm4C+abvQf34j7cjwcwBVPxIB7CNDyM6XgE7JN9DI/jN3gCM6J+NeNwE8bjZkwA29awbc1PYX/X
2N819neN/V1jnDXGWWOcNcZZY5w1xlljnDXGWWOcNcZZY4w1xlhjjDXGWGOMNcZYY4w1xpg7Lep3
QDWyqCn9tZXkEjtlrWhU+lT67ZFBiRtEs1z5rwukkUEVSn8FMYsa5Mq/YJ8TzXIUQJECKFIARQqg
SAEUKYAiBVCkAIoUQJECKFIARZHvYJHvYEqgnRJopwTaKYF2SqCdEminBNopgXZKoJ0SaKcE2kXJ
q0XJq0XJq6N/D3E0FMPwIwzHCPwYP8E1GIlrcV0YKqJeI6JeI6JeI6JeI6JeI5oOEU2HiKZDRNMh
oukQ0TQrmmZF06xomhVNs6JpVjTNiqZZ0TQrmmbl3RZ5t0XebZF3W+TdFnm3Rd5tiUrfd8zCU3ga
L0SHibyHyb+x/BvLv7H8G8u/sfwby7+x/BvLv7H8G8u/sfwby7+xaD1StB4pWo+MNqplN6EN7diM
DmxBjK3Yhk5sD1NE9pki+0yRfabIPlNknymqjxHVx4jqY0T1MaL6GJq+QNMXaPoCTV+g6Qs0fYGm
L9D0BZq+QNMXaPoCTV+g6Qs0fYGmL9D0BZq+QNMXaPoCTV+g6Qs0fYGmL9D0BZq+QNMXaPoCTV+g
6Qs0fYGmL9D0BZq+QNMXaPoCTV+g6Qs0fYGmL9D0hYqvRQMrLsLX8Q18Ew+FvEyUl4nyMlFeJsrL
RHmZKC8T5WWivEyUl4nyMlFeJsrLRHmZKC8T5WWivEyUl4nyMlFeJsrLRHmZKC8T5WWivEyUV0vU
qSUWqiUWqiUWqiUWqiUWqiXq1BJ1aok6tUSdWqKu4i9RtqIei7EkyspiOVksJ4vlEueU/o+q4+cd
LwgTZLMLZbMLy9nsstCRuBJDZbf3ZbXEiNAhs50nsw2T2c6T2YapxScnrwuzkwvCa8mXogOSr8p+
S9Tzjer0pmiQLNcuyyWTK9T3f8t0lTLd8eXfmGx3fbPMMyrKyXI5WS4ny+VkuZwsl5PlcrJcTpbL
yXI5WS4ny+Uo6XZKup2Sbqek2ynpdkq6nZJup6TbKel2Srqdkm6npNsp6fbUlBCnpuJBPIRpeBjT
8QgeDUNkziEy5xB1V526q07dVSeLZmXRrCyalUWzsmhWFs3KollZNCuLZmXRrCyalUWzdGZMZ8Z0
ZkxnxnRmTGfGdGZMZ8Z0ZkxnxnRmTGfGdGac2hk6UrvQjd3Yg73owT7YEzLzGJl5jMx8tcycl5lH
qv8K6r+C+q+g/iuo/wrqv4IqoahKKKoS2lUJRRl8SOW6EKsUiiqFokx+tUx+daUxVRqTjD5ERs+p
GoqVvc5DiNMRKpBAMsrJ9DkVRVFFUVRRFFUURZk/J/PnVBZFlUUxfaRnP4DjXDvB+YkQa1UZRcpg
CGWQS5/uPh+kDg5WdRQphCEUQk7lUVR5FFUeRZVHUeVRVHkUKYerKYerKYerKYer0+JoWhxNi6Pp
6zAKo8NQamIoNXENNXENFTFEPVugJPKURD79SPkXmQam5+EP5V9lGph+07Eh1FEZ+bS1VPcW0t3R
QIojT3HkKY48xZFXC9ephevUwgvVwgspkLx6eKF6uC5zbpRVE9epC2J1QawuiNUFsbqghUqZqS6I
1QUxtTKSWhmZ+U7oyFyOK8IY9UGcGe6zPZX5MX6CazBSm9fCvNQOLWqHWO0Qqx1iCidL4WTVELEa
Is782vO3lX9VMKZ6suqJWD0Rqydi9URMBY2hgrJU0GHqipgSGkMJZdUWsdoiVlvEaotYbRGrLWIK
aSSFNJJCGkkhjcys0/Z6bIBYnxHrqaYpVNMUqmkm1TSTWhpDLY2klmZSS2Oopaxav6DWL6j1C2r9
glq/oNYvqPULav2CWr+g1i+o9Qtq/YJav6DWL6j1C2r9glq/oNYvUF15qitPdeWprjzVlae68lRX
nurKU115qitPdeWprjzVlae68lRXnurKU115qitfdaYxfQyfCnVV5+C72v6B8ytxFX7o2tWO/46h
GIafhHYKLU+h5Sm0fNVE70x2/UnPzgoLq57y+WnsDIXqKBpIweWrza364FBXfUiUzX4jrM1+E9/C
JeFCyu7C7Hd8vjF0ZMdgHP6u9Cb5/AvcGuUovhzFl6P4chRfjuLLUXw5ii9H8eUovhzFl6P4chRf
juLLUXw5ii9H8eUovhzFl6P4chRfjuLLUXw5ii9H8eUovhzFl6P4chRfjuLL/X9UfLl/UHyHRHeG
T1dcEX2l4nvRNyq+H91Y8W/RP1f8IPp0xZXRvyYuiC5JDI2+lbw4fC55Sfhs8sUwM/lS+EpyTXiH
NhyQFOGSG8LdyU3hrWRbdESyXb21OeyKjo7u7H09eiYsjd4IS7X+mb5fgz1b66dp/TSt/1PF0LBL
bl2vF9WcquzicI5eztPL6OTCsCC5CC/1diRfCfPluBXJ18KbydfDnXr/uZ53J9eHjXo/R++T9Z7U
+yN6fz2qSi4OM5INxqSSTy4NP0g2hReSeW8tD82y4io69ZnwJ2P7kye/LXcu9vQUT49LLu3t9fTj
nv6iPDrfGzd446Hybzt+1GjHy+YfkL2/mPiKTD40DE38OEomnqaTXw//lngrTE2sjj6e2CkjD4j6
JT8afptcGOVk6Y+awe/19JZ6NJlcqtZcFv4gS1dqvdeM8jL1uL5MneyrSZNmtjHZZlbtrm8OWyr+
NUqFF6JKpJFBFaqRRQ1yqMUB6BcWRAfinNAcnYufhXnRz/EL3IJb8Uv8Cr/Gbbgdd7LhC6ExejE0
ViRCc0USKVQijQyqUI0salCLA3EQ+uNgDMAhGIhBOBSH4SgcjWNwLD6I43A8TsCJOAlfC6sqLsLX
8Q18E+NxMyZgIibhp/gZfo5f4Bbcil/irrCy4m7cg3txH+7HA5gSViZOD/MSZ2EwLgrPJ34Violf
hyIvv9iqdPCzfXxsnpXo4GNf5WP7krt6NyW77YjdIZPc09ud3NvbnOwJ6eS+3o3J/WFwstf1EA5L
VfZuSqXD51KZkElV9XanqnubU9mQTtX0bkzlwuBUresHeG5UeCE1GtfjBtyIMRiLcbgJ43EzJuA3
oTn1BGbgt5iJJzELT+FpPIPfYTbmYC7m4fd4FnX4A+bj+bAq9QJexAIsxCK8hJfxCl7Fa3gdb2Bp
mJdqQh7LsBwrUMBKFNGMFqwK8yp7wgvpJPhvujIsSPd3PBjH4VScgY+F5vQnHG8Pq9IPYKpz80z/
1mfzSZtP2nzS5pOe69o8PIs6PIcXXH8RC7AQxp429vSffX4Xf/G5HouxBMuxIqxMF93biM3oxHbs
QBd2ojusyhyAfjgQB+HQsDJzGA7HETgSZ4XmzCcwMszLXIuJmIS78SgeD42ZZxy7w7yqk8KqqtNC
c9VHHE93vBBf9fnbYWXVD9y/ElfhV65Pdf1BPIRpeAY9YWV1FFZVH+Rof1XbV9WH48jQnP1BKGaH
YTh+jGswCvZ71n7P2u9Z+z1rv2ft9+wduBOTcReMN3sP7sV9uB8PYAqm4kE8hGl4GNPxCMwx+xge
x2/wBGaEeTX/Eoo1X8KX8RVciK/ia7gI48LzNTdhPG7GBEzEJPwUP8PP8QvcglvxS/wKv8ZtuB13
4E5Mxl24B/fiPtyPBzAFU/FgeD53Wph3QHV4/oAsasLzUUqumCfytyeXRR8Rl/dF90djw7RoHG7C
eNyMPaGofi6qn4vq56L6uah+jtXPsfo5Vj/H6udY/Ryrn2P1c6x+jtXPsfo5Vj/H6udY/Ryrn2P1
c6x+jtXPsfo5Vj/H6udY/Ryrn2P1c6x+jtXPsfo5Vj/H6udY/Ryrn2P1c6x+jtXPsfo5Vj/H6udY
/Ryrn2P1c1z6Fa6KPxnnW6FDzdqhZu1Qs3aoWTvUoVPVoVPVnU3qziZ1Z1NiRthU/veRf/tXR+8l
usN7sllBFpuWXBIdLV+2ymC3q+GmqeGmqeGmqeE61HAdarhS/VRUPxXVT0U1U6xmitVMsZopVjPF
aqZYjTRNHTRNnTJNTTJNDTFNDRGrETrUBrE6oEMd0JE5NRQzp5V/j7OD9i9p+SKdXaSti7RwkQYu
0r8x/RvTvzH9G9O/Mf0b078x/RvTvzH9G9O/Mf0b078x/RvTvzH9G9O/Mf0b06sd9GoHvRrTqB1V
o7U90ecnS7+aFmJ6M6Y3O6oH2E+XhKk05lSasommbMqND5tyN2NC2FQ7ILxXewgG4mgcg0muPxHe
ixKyyu/kdTou+WL0qeSC6PLky9FZyVeiQ9n3ueRrlNTr0UnJxdGFbH2hur6SYviM2r5/Mh+dye5/
pRyOonPWuLo2OpVeuJBeODG5KTpfu6/1fZd9mp5eDc94/t5yn/PcG0ZVLIgOcO0dZ0tKv0v5v/6W
bsXQaPB//Xu6xnOG3fFpvX5ZPvyiMfztyhmyZbern5MtF8iW7eXfKN5c+muUrh7p7DPl7xQHefYE
Yyj9LYIN0Yc98RFnS6LBZjjAvaPMtfSrb5eE+uSo6Bzjfy11Hr2WcOVtZ+96Wm6iCbc6W+VseFTr
bK+zt6OTolQ0OKpEGhlUoRpZ1CCHWhygx4ujQ5KX0nhXYLg5LaADX6EzXw2NqVHR4NRoXI8bcCPG
YCzG4SaMx82YEA1Wyw9Wsw9Wsw9Wow9Wow9Wkw9Wfw9Wew9Wbw8u//2LWuq2S0+rzGJD8mUrWfpr
Jq+GP1K3m819FJu8aFyLPGW25l4b9a9oiI6raIxOZ5kr2OHzyUs9dVl0WfKK8m/MXZYcHl4t/SpR
8vqwJvlAdHZySvQJ/cRW+gRKZk7qU9GZqXOi01nrsugobxyln7Os5qjoGD1tKfVf7qm27++avJX8
jrcv9/z3HL/vOIqHNYSVNHIHfbyn7D/LoypvJaN06S+heHqgJwd6stqTsSe2RgOjtaIoDRWtp5uu
1VNpTa8PTXR3h1XvJ+I2ltvLW8Fl3tJmSRFX9g/71PD71PD71Mj71Mj71Mj71Mj71L779Hlx2FT6
H09aPNVOyZRbWxa6okH/0Od3xKzvYYS5jaLEl4ROo9tqHjGPO0TfO731pn5r9Lv7v+23Rr9rSn+b
RWv99VupxZ1a7NBilxartdbZN4t99tnFrpZ+L/A7lPz3cK07o6LDvFltxGlv7vLmPm/WGktvyWre
7LEr1kZfiNZhPfbw7L3owT7sFx0uVrlcEk5Pfke0uDz6bvJ7jt93HKH2udZ4rg9PJG/iFw9En+QP
n2bxBj2eU16bpWF6ubd8WG7PDVDl7O3zkTNT2k71IkQnVfaPvpC5FJfhiuikzBTMQKvz97AGxpnZ
6lqX4y5jK/3+41Yj22POe4zsVPPeY2Snmvfh5l2KGFXmmzXXjckV0YFlr1vojde8sc4bh3tjnTcO
98YnPX2gMW8oe97S0GPcu725rvxWvvx3CS7V32U8+QrH7zqOFhXXRB8U8baKMVmR8TCR8SDxbmH5
L+qU1q/oqaQrW63DxT5dUt4bpV/DG5i8jlfdIN9tMO5NemwLcdnfWr23zntZrVdpOeFOMTosujJ0
Rlfhh7jO6l9sPS81riswmmeWnl7LSzaw9EZjalNftmtlszx5XjSo8sDQWdmBLaEzPRwj8GP8BKNx
vXYP6PubQAUtF7VcTF5nVqPF/DXWcS0vWmcHlWcrDm9io7bwl3ItPsj4eoyvx/h6+mZf+k55tVZW
ayWhlVON8UCtdGulVyulX5qv0sJ7pb9HZHw9xtdjfD3G12N8PcbXY3w90YejK6MvR1fhhxgbDYnG
4SaMx83RED320+OHxKxKFr5IzKpk5YvErCdZ+lmWXsRP3+KnXyz9lfnk0+Fuc3pXhjjxb6ORt0qj
2URNfCo6h4+ekzovFFKPRkNSj+HxaEjlgdGXK1sdOxy3YFs0JH0Kzsbw6MvpEfgxfoLS+KqMalef
3yT6/CZRXquSBdvCxvK3EXOMe2bfUwP7nhpo3LEnzyx/A9EWmnjG8N7X1YJb1H6tar0tarvW1Mm9
6/na8N7Y1a2ubE2dHD6j1eG9q5O72LnH2/vEhv1hcaoydKsLd6dqQpcnF3vy/PK7r7rb6EqjK9ny
u3Fyr/56WGV/WKbG7E1VR2nv9npqmVqy15ODxaXhvRv00qtK7TKyjuQexx697uOZf3tzn157Vadd
RtyRqnLMGkWN639raZ8Z7OR1w9W13VGFVrZqpVcrQQubyn2nowpvb/V2r7eDNzf1jeGUkp167zKG
Nd4+ztvN3t6V3GvHlka/jx/v53G9dEII+41ljdaO01qz1nalqkO+PKsa65yLDlQpt2t5vzHNLmXR
kNDibuNYleyNEt7are9VqVqfTw7Hlp7oXeKJjforWaroiY3aLFmpqI1trPuf1svq962Tt/+b9Sk/
W14Xz/4362GO/5frIJ7+H9pflPl/bHdz/N/Yu3znv7RzdEBqQFSdOsT4Do2yqcO1doR3jqQZPuDz
Ue4d7d4H3Tve+QnunejeSfJBKjVQD0e4e4zjCdYklxrgTA2RGqT/w/VwhJ5KbR3l+tGuH+v68a6f
4Lp2rELp6VLPR/Q9Ueqp1FZ/40q4uz410JVBODQ6yvj6e3K9No8yvoTxJby1PnWM+8fig64f75kT
XDvR55NKf5VcK6uMtTTDROowYz08quxrpfT2KuMvzTCROs69493729sJ8x2AQ/jeQGM+9H9Q9x1w
VtTa/yfJTDL33tzdZXeB3YWFpYOgAiIoRcGuyEOfHURQUGyoDxERKYIFRJSiAgpSBCs+7KCgWBGx
K1JEOtIRkF43/29y76677sIWePr7Zz6Tm0lOymROvjknmTkX5WbgXirg6VdEXZn2vpBeGelZSK+K
9OqIq4H0mkivhfvDXeDZlEW55RBbHmeaWYg2ZKN3VnsV8Swzcc+VQFMZNFlIr4KzKmiqgaY6aGqC
phZmNvuctOvXNEpFO2yP7UM7UtGOCNqhXd9WxXV114P70IZUtCFinwoJd+8Z8X6Otd72nnD3Hcux
Ld5qToml5QmM2q3ov7/wBUb7yRQtKW8gV31SR+IPpNaglOPFIyitHu66lHyC3LWpzLHyCko53d7R
8eEXPImv3HMsFc+4uSFaUr5xqF5b7MneCCTtBMSpCFRrIw5kbwOqnSsOZW8C+nQBqmUB1Zp6fvZG
IGonoFFFoFobL5S9Dah2rhfJ3gRk6gJUywKqNfVSs/egR05Ej9RBj9Tx0nCdbuqhRxLQqgbolZro
lRpeJcRXBl0WaKrgrIrraqCrDroaoKsJulrgmhA0Nw2d60xh/9fnM0qBtJsKSbc6pIrTICvMgbSX
6P5baCa7jpqxTnQeu54eYzfgtzM09yvMOHEldJGrzExIHuPcP9XVOQrVHEdl/wNpkYvNuXoj94pD
k5/NPjZvuJD9d7vVCCVCSz6RiJpCJz2BWuGoT63pMmpAV9JViL0GslxzupmG0kX0BL1Kd9JMmo2r
j3GMoK9oIY2kxTgm0DJoJxNpPUp8hVVgFegnVomdSPPZxawNrWFt2eW0lrVj19Jm1pF1pK3setaF
trHb2R20k93DxtAe9iyODDYORwU2HkdF9gp7lWWyj9n3rDKvzxuyk3kj3oQ15E15U9aYn8HPZE34
2fwcdjo/j5/HmvELeGvWnLfhbVhLfim/jLXiV/Kr2Tm8PW/PzucdeUd2Ae/Cb2QX8q68K2vNb+F3
sIt5d96T/Zv34oPYVfxR/jjryofxUex2PoY/w3rwKfxN1pO/zeewh/hcvpCN5ov5GvYS38g3s7f5
Nr6dTec7+F72Ht/PD7LZ3AhinwguBPtMKBFlc0SiSGbfiFSRyn4Q5UQG+1FUEVXZQlFd1GCLRS1R
hy0R9cSJbJk4WZzMVogGoiFbKRqJxmy1aCqasbWihTiDrRctRUu2UZwlzmKbxDniHLZZtBFt2RZx
ubiabRPtRGe2S9wuurFs0V3cy0n0EX24FP1EP67EKDGaB2KamMbD4h3xDo+IGWIG1+J98RmPiu/E
Ip4mVovNvKrYIwyv5/leAm/spXq1eUuvhdeCX+H18AbxK70h3rv8Vu89bzYf5X3rfc+f837y1vKJ
3gbP8Hf8sB/m3/ja1/xbP8lP5t/58/1f+I/+Un8lX+yv8dfwZf46fx1f7m/wN/IV/mZ/O1/l7/B3
8PX+bn8v3+Dv9/fzzf5B/yDf4h+WPv9dKpnA98gkmcSzZbIsy41Mk5WEkFXkKSIsT5WnikzZRJ4v
Ksm28gpxsuwgB4rG8iH5iLhWPiofEx3lMDlM3CBHyJGis3xaPi1ulKPlOHGTnCgnitvlZDlZdJMv
yBfEHXKqfFvcKafLD0Qv+ZH8VPSXX8i54kE5Ty4QD8tFcrEYKZfIJeIpuVyuEE/L9XKTGC3/kIfE
WEWKi5eUUlniVVVTNRKfq9NVCzFftVQtxWJ1tjpf/KIuUv8Sy9Wl6lKxRl2uLhe/qSvVlWKtaqc6
inWqs+oitqhb1C1iq7pN9RLbVG/VTxxWD6gBHlePqEGep4aoxzyphqkxXqCeVc96yWqcGuelqPFq
gpeqpqgpXjk1Vc3yyqvP1DyvtvpRLfROVr+qHd6papc64LVRh5TxLg9qBjW9q4PawQneNcFJwcne
tUGjoJF3XXB60NTrGDQPWnjXBy2Dll7n4ILgIq9LcHFwsdc1+FfQ1rs5uCy4wrs1uCa4xusWdA66
encEdwb/8e4Oege9vZ5B36Cvd2/wQDDQ6xUMCh717g8eC4Z6/YJhwTDvgWBkMNIbEIwKxnoDg5eC
l73BwdRgqjckmBZM8x4LdgQ7vaHB7mC390SwL9jnDQsB+LzhIS/keSNDKhT2ngzpUHlvdCg9lO5N
DlUIVfKmhLJCWd7L4cvC7bxXwp3Cnbw3w13CXby3wjeHb/HeDt8Wvs17N9wtfIc3PXxX+C7vvXDP
cE/v/XDvcG9vZrhPuL83Kzwo/Jr3Ufjj8Jfe2vCC8FJva3h5eK23J7w/kuFlR6pFhvtZkZGRSf4T
kemR2f74yPeRHf5LWuk0/2tdV5/rL9NX65v9ffo2fZcM6e66h0zUPXUvmax7696yrO6jH5bl9GD9
hMzSw/VwWUuP1E/J2nqUnijr6uf187KxnqJfk0306/od2VLP0LPkefpD/aFsrT/SH8mL9Sf6S9lG
f6N/klfon/XP8lq9UC+WHfQSvUJ20qv0dnmT3qn3yZ76gD4k++jsKMn+UR7lcmDUi0r5YDSIRuUj
0aRoOTk0mhZNk09GM6IV5VPRStHqcnS0ZrSmHB/tH+0vJ0QHRB+WE6ODo4/LF6Ijok/KqdGno6Pk
tOgz0WfkG9Gx0bHyzehz0Unyrejk6EtyRgJPSJAfJCQnlJfzEiokZMrvE/YmHJA/EQ9DfifSZ5W5
hGpTFh0nZ2aaNWYd1TcbEP61UIpsM9a8jmObGYKrS0x75JmD0IZ4+gazCf6q+NWeAvlt6iazC8ef
aaqQenbifKrI9t6P88N8MctRQzlbyxEdNC/Q/WIOIqwxk19LUVyvyd/GnLsppM5vzEqz1XyLElbj
btcX1cZiuACljoqX/pvZYuaYtfGrHQVq34xzmVlh5pt95iIKoe9OoCp50rOLqszsxrPbhRL+bDn6
HxJLLPUF8wJpnLnP8C+5f8e51ixBGctx6UPOqklnIFTZpX5uvjMLwT/gHejthdf/qnnejMfvYJxn
mpPMPaYHQnn6MefuEdpSIHe2+cKsBwd9Yb5GO/AcbO/lz5VL+00RXUHQU4kSXOiJeMxWlP1tDm/m
5Yp4zC7c+Q70/a9mJ+T9REQ1wlPIrd1sdk9ocw51gfxbzEaMsa05PW5XRt3v0rw0RbU7Trck39V/
8l19Wbwy4Bo4+jinmUV4foFZVETNe/OM7QZ0WhHUr5mX7Yg2XxS7Tfnzr7PcYXm2QMqCYuTGnZlH
XGj6X8ezuaEY+cEj5h2HW8vtcyupM684NH0F/VrQBcUqYZuZ6VCzmHxRSAk7is9VheSOI6z5qVS5
33D+Ioscx92dUoz618XmMnMQfLSzxDXoo6bWwvlvV0vOjLcqdsTTKxeSpw6Oyjjq5Gvli/Hf72PH
UfI3KDR/vHfBJbuBTruP1GDg5+/mDyDYSjemLFfvc/FPuuRK5mMz2/xsZ/Qj5D+UJ/wYpQP/r6K2
doTE45ZhbphVEItz8xzMEx6OmSeRLqROCE+Lx61B7/145Fk1p37H0c8gfwjo0z2O5Db+LfM6CTPj
iPn/yoU+pKeuiH88nv6lmYv+/yp+VRC/D+QJD0HudGpDVhI6Mx73oXkfJfz3iPX/Vnh8Np6YxUdz
qfmX6WLaxqknFMg/ECj2gvmv+cH8nCeaUwd6kIYi9AQNs9/M0Gvg3Gk0A9LhLJpNDd2qQmP6jBZS
E/qF1lJrWs8YXc06sU50NzT6f1MPq8tTT6vF0738Vt6N7oM+vpj68l/5GurHN/ANNIhv4ptpsNXN
aQjfw/fSUH6QH6QnrG5Ow6xuTiOgm0foSVFZVKYx4lrRgZ4RncT1NNab7k0nq9UaGu8n+8n0jXxX
vkvfyg/lbPpO/iqX0g/SSEM/WZ2O5ludjharS9SltMzqdLQCOt1VtNLqdLTa6nS0wep0tMnqdLTZ
6nS03+p0lA2d7jFG0OZGMKmeVGNYyOp0LNHqdCzJ6nSsjJqsprAUq9OxslanYzWh0+1gJ0KbM6xt
IAKftQ+CIMyuC3SQwK4PygQprEtQNijPugYZQUV2a1ApyGLdgmpBDXZXcEZwJrsbWtuN7B5oZ4NZ
L2hnj7HeVv9i91udiPWxOhHrG7k/MpwNsJoOG62TdBqbpV/Tr7HP9Rq9nc2xugabb3UN9ovVNdhS
q2uwFVbXYCutrsHWWF2DbbS6BttudQ32h9U12C6ra7CDVo9gh6wewQ5bPYLzhFBChKuEsgnleThh
X8IBbvcUFjmOYY5jODhmFDSK0fQseHosTUHMCzgUvUivYpaaCn6Sjp8k+OkDjLoPwVVhx1VhcNU8
xH9FP1OEFuDg4LKFkKp/oaWQrpbRaoyxNeC5KrSe/sCI34GjKu2kvVSN9uGoTvvpMNWgbHBkGceR
mY4jheNI7ThSgyNvpyTeDXypHV8mgy+XUTm+nC+nFL6Cr6LyfDVfTWl8Dfi1ouPXCo5f0xy/lnX8
muH4NYUbbihFQPynVHAthw9HZcG7CmE8fEoXIfBxquPjCuDja6mm6ABurgVu7oTw9eDpWo6nM8HT
y4h5y721xL113nqS3gZvK0W8bd4uquTt9vZQorfXO0SVvcPg/hqO+6s47s903J/puD/TcX8muP9s
SlXnqHMoos5V55KnzsN48DEeLkJMa9UaMReri0mpNqoNBepfGCfVME4uQd5LMVpCbrRE7AoIRdVV
GDMJGDPtqYq6VnWgRHWduo5qqI4YRWXcKCrjRhHDKLoNuW5Xd4HmP6o7Yu5WdxNXPdQ9qKWn6omS
78VIi2Ck3Y9cfVQfxPdVfUHfD2Mv6sYes+spoBmsHkW9Q9RjSB2mhiFmuBqOXCPUCNA8qUYhZrQa
jZaMUWMQg/FJYTs+Uc54NR65JqgJiJ+sJqOcKWoKKKeqqYh5TU1D3tfV6+iHN9Q76Jl31fto50w1
E30yS81Cqz5Tc9DaL9Q8lPmjAmeqBQo8qRapJSjtV7WCstRKtQZ98pvagLo2qk1UVW1WW9CTv6ut
VF1tU9tQ43a1A23epXaBcrfajdQ9ag/i96q9aMk+tR/lH1AHUPJBdRAlH1KHKEUdVodRe7bKRl6j
jP1/1cCnTIsm8IEm8IEm8IEm8IEm8IEm8IEm8IEm8IEmxIAmg+APDgYTt5hCnsUUYhZTSANT+sDv
G+5PSRZZSABZFpKOLIospmjkl8gOSrIoQ8KiDKUDZdZQiv5N/0apeq1eS1G9Tq+jcnq9Xo/UDXoD
pemNeiNV1Jv07whv1VtBv01vA812vR00O/VOhHfp3ZSh9+g9oNmr94HmgD6A1IP6EEV0tjaUFrWq
dYrFL/he1IPvRyUlA8UCKh8NRcNUNhqJRkCpo1GqCFxLQUxqtBxlWHSjckC3DPgVohVBUylamVKj
WdEslFMlWhXhatFqoK8erY4wsA/xwD7EPBcdj1omRCci16ToJJQ8OToFZb4QfYnKWjQkYdGQkiwa
UhIQ6804Gg7HIRwa+kDDMQiPBQ4Kh4MSKPgawtPoPfjvE7gNaPgxwp8CAwXNAQ4K4OACIOZC4Ktw
6/eBw0HhcLCsw8FyDgfDDgfLOxxMcziY7nAww+GgZokskaKsHWsH/3bWDf6drDv8HqwH/CFsCEWB
kpcSdygZAkp2gW9RMuJQMuRQMsFhYirfwrdQGYeDyQ4HU/hhfpgSHQImCU94lAzsCxAOizCVEe1E
O6oo2rs32Sz2ZTrsqyyuE9chvqN7u83iYKbDwcriBtGZKuTi4HoSQMBdFAD7DlHYoV6GQ71ydtUW
47OVaoXRe5Y6i4TDuECdD4zzgHGtEbboJhy6SYduaaqtaosYi25CXaYug3+5ugKUFuM8h27lHLqF
HbplAN06kVY3qBvgd1adQX+juhF+V9UVvkW6wCFdOI50PVQPxNwDpJMO4wJ1n7oPeXur3qDPQbr+
CMcwbqB6EGGLdIFDOuGQLqyGqqHI9bh6AjEW9QKHejqOeiPVSMRb7Asc9mU41BMO9Tz1HFBPxFFv
opqI8CQ1CYj2vHoe9BYHhcPBjDw4KBwOBsDBmQjHsO8D9QnCn6kf4FvsC4B9SxC2qFfWoV45h3ph
h3rlHeqlOdRLd6iX4VBPq51qJ3JZ7CvnsC/NYV9GHPsOAeOEwzgdsICRiKFVuFf4PgqF7w/fD79v
uC9Fwv2BTZHwgPAAxDwcfphCDqd4ZGTkGeIOcVL178CaJP2H3kHJDl+SHLKkAln2IrxP76dEYEo2
xrnFlDJRERWUCDRRlOBwJNnhSCoQJBlhiyAp0fLR8qCx2JEazYxmIr5yHDuqoASLHckOO5IcdpRx
2JEM7HgOZU6ITkCuydHJoJ8C1Eh2qMGJN9xuV16brDu7MV1EVx9Jzv//w5kNZqM941crC9O77DqP
W+sradm/2RUup3l/7K5/zanT+T/Etc8tVv90uugSs9qsz7+iU3S9OSt05q6St/D4OtMamqf9PaLu
XSDHBmjac0u/LpNbzpa/Xpk/nB+Ph664Cz272mzFmbuyl0cTTc2TewmoFpNd9yiPUHyFMUe7/ptc
OLc1eevVdI2L21zY6oLZVHBtzuwwq8wvSCmwC1Fal7NKnv/Kjp84V+dZL0DbRW54y5GesllRcFXz
eLnCd3CKzDXFTHK/h9xq+Jf2tOtD5hWE5sVpcjjLjuDd5vuc+BLV85vj0dV/XttVMLMsD8Xjbj3I
rpWvcKHf0Jq8CBXv3+I+X7dqvbpoupI7cFqecs0ecwjnAbvWZQ7nozvavtT/Mfc3j/liODPuGDJf
Ukh5q6k2eLDSMZR6dFebHLZaPHWYWqgDNhR7D/HY54q/lJevVXnHXjHzv2Vmmzfi+wOpZoKZ7WLX
2Nk97+xdKvlhMbBxpZMf1jvZxKGZnZPMSvxOjVNtdfttX+Gcg2N9/pVrh2TplLM2+znmgnnmR5zj
EHuRmW++dvE/x6QIt6N9TclbWqDlG/NduTnUvJkn5lYz2XQzj9pVftM9N7YZ4t6z467griPZPdeC
e6GbzMe4lyXHb6Tm8IOdx4BgOXLhPIrvz+ZtA3A5d2/E7rEUUfK3x6uNpXXopaj7HWH3mwuk9jCf
56ON/S7D7LbGckgp6ltgud7JW66fbAjz28p4r8E3t5jv3PPeS6KQOSxK9QuUuRXj4Pf47pIAcuTs
Ou2NpR77/PbnPnT+/cocKcXKXm7e/g3H1gKy5wonexYy2jGajzN2Feb+gmfzC6Qf+mtMPP4/hcdT
SfbRS+zMTSXMEHvHYrB52P1ucwjwtj0RetlMj4VcWo585vY78aTeL0Xr3jLvATHfjV99bl4l+37Q
DBvGCeQEin0OlMiRgrcBfb+O40Rs/yyhQJlzzbvmo3iZqfYqHp8PHYwpeWtdPoxS80vuVY7ussqG
cvTKmCTuEG2e5Y/YOyLx8bPDIXIHc4m7+ojsbt5dOO9FaLgZg7nu3ngped5tQQ/MMr1L0drrTV/z
vOmG0KcY1c+brg4fHsds9Dz6+SMzztyMuXWb3QN0dzbTTDMTYzXHZ40M8+lfylxvFkKrjI3cU3ND
cbnT7I+dxZeY85W9y4333LeC8s9Sbp7O1Xyd5LvSvfeQ942Lk/K/sfJ3ufy7uO4Npt+Lbom7owLv
X/0dLr8ma3sVPLyzKPx0T+e4abolcXnlD4wGq2Utwu8RdrpzKTcde3vNc6aPeciMduHvwe+T7Jsy
8XkoJi/uNu/gnH1s9biS6sfeZDmmMtaYdZgJ3fyIZ7oOfJgrc8eeutkOmWN7YRJgiesqhcydJ/fX
saeKtlgc/DZ+tSI+fuKt/mfGc2HO3GRuNB+Y6cTdVV/TE2jdKSYRmBlmH66Gmv+Y00014Ggjc6+5
5RjqismPWcfU3jgmxXTa3PcNJ+VPPZ7OTDkOZVjuXRhDdci3BZ6+S19tfvpzFv5nHVrzK8acW/ME
D1tNMVdTiUm6SJ2L8wjvqv7dDu19Iu/IhXw1859sz5EdRlsPKzvF3nQ1d0M6+hmjL5b2kfN/Ne+b
9uZRhIaZpbG4UtY199jbW8Iad+V9z+v/rsuVcXcc+9uVhb3rfjxdTDqE/L0Ws95xWLEo6h3lo+Yt
JkeZ193a/ubS15THpR+XUorlIAsds+RqRhyPlhRRRxzpIN0e87r8cXpKRdWyBpLt/3ikHD8HqWfX
ceuZ5GNox/EY73/jfkRpuBFyz+pYzviXHTnrIt+5fYbvjpr5jjjtGyWv9+92pfkGokAZR9wNOUoe
t1pvV4pimnBsRSd3Lzh8NP3Yre2mUzeSJa/X5S/FV15mvZs7/vyWLGdNrri6XYTOL3mt/6grV9qM
Jd95IvtWg92XztXszSzn/w58LnI34v+ag9y/+8jfTOSh2/e/b0vxXPEQsrSzeqHfShVZl3uD4M9v
B92ORS5nhQvNlENr16oqUnuMuX/A5ZfdY6gB7akInHU7Mf/Aep/54ziWtYriK8qFfnFUx33lZHfQ
vy8ktaiy7XdUq3Jy5oTcCv+qeExOnc1cXX9pV56rQX+WmdMW+71WgVbZr7Ia2F2a0mjtZpx50czM
/Q4sHrISQXxN8/vcdjQo0N4XS15fvvyleFPI/OR2Jb7KvXbvAEHelMXe6SvG13tHqLvQb5OLyLPO
rVrZmdxhgbv6HGMvhgzho8mXbkZJpDOK971mIflL8/7DfPu9pTv3xK6dH181Pzo6xO+lYv73jcBf
f5gf3TmOykMm3RjfTVoZG9OO124teUuLuI/YDlsebd10Mveal8x4Zzcg950e09q8VcKSP/97JGbb
xiPXY7IL21WO7Sj+Je6PondxSuvcOzJxZDY7IE/sgHy02Cz5E4nMFsTZPePTzJXu+m1wwELTwcyx
1+Yj85T5wq6Yu7Qn85W9LCe+RC1qa7qZAeai+JULgQO7uvCLZrLpDj4YB2ltJmZeSzHdvGveic/a
dnW+HNV3e869zO0uLvY+4njI1c/Z52GtJOS+BZRvLcjsz/mav0Ttfca8Al3t2fjVd67ucQ7nv3N9
YHdf3zC7zCeOIPbVfvwNgzgXn1ryWv8p9z/5GrtgLatyECu27/xPudLsU+FJ/055Vh1yLSQUZ+5J
Ifv+zmUuXJEaQffMcnnXQupY62aTCnSKWYARao9lZrk5HeOlK2kTm9fjeipGZ0ynKh+/fiu+U8Ep
94tpF//aUe7DvVthemOei69AmlamI87W5iZKMbE5OMeGRl+c55pm5goT/7LBfGmWurcl7IjdhDlp
VVx/rUu13cxZ11EdfXWj8HZNMpPhv5J7PdPqcvnerLg8HmhP/6bTqKGzE1PDpeS993D2TyaSvdfN
lB+Y28zbdg4z/cyDNoRSh+SrNvYO2G2laO/t5k7c/53uIkDodoebD7qZ+kc8y/XZsS/pZzirIDnO
9ay5O15GMXS8QuveWDRNgTxb3BsBVk5w3OS4+XNcey5ZH1XesbkSqTlaz2l+EXbs2sXt2A2kCxln
ZamLs07Xy1mnG+ys0w1h7VgHGs5uYbfQU84u3dPsHjaExrChbDRNs9bpaKa1TkezrHU6+sBap6MP
2Sfse/qI1+cN6DveiDemH6x1OprPz+Rn0s/WOh0t4Bfy1rSId+d30xLei99HS/lw/iQt51P4FFrN
X+LTaA2fzmfQZv4+f59+5x/w2bSVf87n0B98Hp9HO/m3/DvaxX/gP9IePp/Pp318IV9I+4UWUTog
kkQyHbIW5sg4C3PkLMz5orqozpSzMBc4q3IR0Vg0ZlFnVS7BWZVLclblkp09uRTRTrRnqeI60ZGV
s9/KsTRr9Y1lWKtv7CRvhjebtbNW39gN1tIbu9FaemM3+Ul+GdbVT/XT2S3W3hu701/qr2I9rb03
1sfae2N9rb031s/ae2MPWHtv7BF/t3+QDbI23tgT1sYbG21tvLEJ1sYbm2htvLEp1sYbm2ptvLHZ
1sYb+8jaeGM/yA7yEbbIWnfjzFp345617sZ9a92NK2vdjQdyopzME6xdN55s7brxFGvXjVe0dt14
NWvXjdeS8+RiXsdadOOnW4tuvKlcLzfz5taiG29lLbrxNtaiG7/EWnTjt1qLbvw++30c7xfwgPP+
gQwUfyCIBBE+MEgMkviDQWqQyh8O0oJ0/kiQGWTywUGVoCp/1Fpc449Zi2t8qLW4xocFDYIGfIS1
u8ZHWrtr/Elrd40/HbQMWvHR1u4af8baXePjrN01/py1u8YnWLtr/PngpqArn2ztrvEXgh5BD/6y
tb7GX7HW1/ir1voanxo8GjzKpwVDg6H89WBYMJy/Ya2v8bes9TX+trW+xt+31tf4rODtYDb/IPg4
mM+/DBYGi/jS4JfgV748WBas56uCjcFOvsVaZeN7rVU2vi8wIcb3W6ts/JC1ysYPW6tsgoXSQ5VE
1NpjEymhqqHaIjVUN3SSqBBqGGooKodODZ0qskJNQs1ElVCL0FmiZuic0DmiXui80AXixNBFodai
fqhNqK1oGLoqdLU4NXRHqLtoEs4KVxfNrXU30cpadxMXWmtt4iJrrU3cZa21ifustTYxwFprE49G
Lo90FlPtV3tilrXWJj7TSieKb6ydNrFAt9c3i+3WTpvItnbaPM/aafOUtdPmha2dNi9i7bR5Za2d
Nq+itdPmZVo7bV6WtdPm1dVT9FSvnrXT5jWydtq8ptZOm3emtdPmtbR22rxW1k6bd6G10+ZdYu20
eZdaO23e5XqVXu21s1bWvGutlTWvg7Wy5t1grax5N1sra95t1sqa1y2BJwTeHQk6IcG7JyE5IdXr
ZS2refcn7E3Y6/VLpETm9SfOVgP1EqDxJVISMSqDQ1Ay5mGP0jB3+5jVayC+Jg5FtTALBlQPKBkC
HjYjDTy0//NwhvsHDIuYCQ4xE4GYVyLXVTjKADc7oMTrqDO1pC7A0FbA0O6QHO7GcRb1oF5Ulu7D
UY56Uz/U3B8ImwaE1ZTOoiyBMtwXwhVYEjD3RGBuLcTUZrWpPqvDTkB8XVYX4XrA4nSHxQ2AxW3h
XwJEPtfZC01nHYDLDR0uN3S4fApwuQ/i+7JB1IgNZoNR5qNA6gpA6mHUmA1nT1MTNgqo3cChdgOH
2g0catcHar+C8KvA7vrA7jmYD75gX1AzNpd9Tc3ZN0DzFg7NOdC8EfxTgenSYXqSw3TuMD3JYXqq
w/SzHaaf7DD9NIfpFYHpr1Bl/ip/lTL5VP5fqsKnAeWrOpSv6lA+Cyj/AfwPgfWVHNZXd1ifCaz/
Fv53QPwsIP4P8H8E7ldyuF/J4X414L6mGiIK9K/p0L+2Q/9aQP80OkGki3SqKzJEBp1jZwKEMRNQ
HcwEteDXFnWQC/MB1bPzAXI1FU3hNxPNkNpCtIB/hjgDNJgb4GNuQIz91vp89631Be776vPd99UX
uG+qz8M80Z/O8B7wBhHDbDGcEr0R3ig63RvtjaEU7xlvPDX1JniTqLz3vPdfSvemee9SBmaUGdTQ
WhOlRnZeoeZ2XiFt5xX4SX4StfLL+GWogZ1dqCFml59J+Av8BZTlL/QXUqK/yF9Enr/Y/4V8zDpL
EbPMX4aY5f5yUv4KfwUF/kp/JZX1V/mrKGLnJIraOQmUG/wNVMbf6G+kZMxMm4n5W/zfUeNWfxul
+Nv97VTezlWocbe/m9L8Pf4eauHv9feibfv8fWjPfn8/wgf8Awgf9A/SGf5h/zBKzpacUqSQHp0h
fekTwwynCJOFDCgqQzJMiTIiIySklprSZFRGqYVMkAmgwSxo/9VdpiBvqiyLvGkyHfQZsgIly4oy
EyVXkpXIWkCtAr+qrIoSqslqoK8uq4O+hqwN+jqyDpWXJ8gTEF9X1iVP1pP1KEGeKE9C+SfLk5G3
vqyP0hrIBqBpKBsi7ynyFNJ2xkVdTWQTxJ8mm4KymWyGEprLluTLVvJcUJ4nzyMlz5fno81t5aW4
r3/LK1B+B9kJtV8vb0AtneVNKKervI1aytvlndRK3iV7oMZ7ZE86S94rgR7yPtmbysn75f1obR/Z
D/fSXz6AcgbIAShhoByIEh6UD1JEPiQfQi0Py4dB84h8BLVAAqAKVgKg+pAARlAjOVKOpFOsHEDp
kANGI3WMHEMZ8hkJHJBj5VhqLsfJcejtiXIi/EnyeWpobcCCHrICSpgqp8J/TYJL5TQ5DXlfl2/Q
ufJN+SZKfku+jdTpcjryzpAzEP+enAnKWfIDUH4kP0bqJ/JTagwJ4wvEz5Vz6STIGfNA/5X8CjFf
y69B+Y38HpQ/yB/Qnh/lT6CZL+ejhT/LBWjzQrmQTpSL5CJqIhfLxcgLGQW5lsvlKHmFXIFc6+V6
lLZBbgL9ZrkZ9H/I3aDZI/egN/bKvWjbPnmI0q0cQ6dAjokinKDKUCOVrFKogkpV5amxSlMVqYnK
VFnUAFJOLWquaqs6dKE6QdWlZqqeqoeYE9XJ1ELVV/VRQgPVAJQNVUPQnKJOQWojBd0RstHpdKpq
qpqirmaqGeibq+ZIbaFaoC5rU4BZmYkaWpkJPmQm+JCZ4ENmgg+ZCT5kJviQmeBDZqIMKzNRBSsz
wYfMRCdamQlhyEzU3MpMlG5t1dJJQaugFXJBckIMJCfQQHKCD8mJGlvJiZpAcoImEHQNulILyE93
UmJwV/Af0ECKQl5IUYiHFAXKB4IHUM6AYADCA4OBiIdEhfZAogL9sGAYNQqGB8ORC3IVnQK5ahRi
RgfgumBMMBbhl4KXUNfLwct0oZW0EANJi8JW0oIPSQs+JC34kLTgbwz+oDODHcEO1LIz2IlyIHVR
fSt1IWwCY/97K0R0boiFGKVbCYwqQAJT8INQQKeG4Kh+KBwKI6xDCfATQ5h/Q0mhJGocKhNKRkxK
KIWah1JDqXRKqGyoLLUIlQuVR3x6KJ0ahTJCGXRiqEKoAsIVQxVRS2YoE6mVQpUQA9kOYch2aAlk
O/iQ7eBDtoMP2Q4+ZDv4kO3gQ7aDD9kOPmQ7+JDt4EO2o7CV7ehMyHaXUVL48vDlJMNXhK9A+Mrw
lQhfFb4K4avD7SjVSn6IGRSeQjz8Qvg1hCH/IQz5DzSQ/0CzP8KIR3gkg862UiCdFrPdYKVA4lYK
hA8pEH573Z4y9bX6WsrSHXQHKqOv09dRZd1Rd6RqupPuRFX19fp6EvoGfSPCN+mbQN9VdwXNzfpm
0Nymb0P4dt2Nqus79B2guVPfBZruujtS79Y9qBIky3sR30v3QjzkS/h9dB/4fXU/qqj76weoih6g
B4LyQf0gKB/SD6PGwfoxxAzVT6BkyKCoZaQeCf9J/RRoRunRaPMYPQblPKOfRXisHgv6cXocws/p
51DmeD0eqRP0BKqlJ+qJVMdKrlQbkusUqqtf0C/QOfpF/QrCr+pXQTNVT0Xq6/p1+G/oN6mefku/
hdS39TtInaHfoxP0+3omYmbpWYiBvAsf8i78T/SnVEN/pj8HzRz9BdXUc/VcUH6pv0Qt3+jvEfOD
/gllQhpG+Qv1QviL9GLQLNG/InWpXopylunlCK/QK6gRpORVKG21Xk21rKxM/4+1r4Fq4zzT/WYk
jSZY/BgTQjAhhBBCCKWEEEIpJoRgQgkhlBDHpS4SQkhCMxL6Rwgx+kV2HMoS13Vcr+u6jtfX6zqu
1+v6ulzXpV7X63U5Loe4vtTXpdRlXa+PL2Vdyvo6XnLf75VMnO693d5z7vnO++jjnR/NjF593/Po
zDxkA1cOkazEcGKE5CYOJcJVAt68hRQlvpMI1ypxOHGYPJ749cSvQ+a9xG3k2cRvJH6D1FE+DRng
06SI8mmSRvk0YSmfBgQ+DQh8mqRRPk1KgdnVIJ+uRz7NIpOO8eb7jJny4yTkx0nkK9CSkBk3IDNu
RGacisy4CZlxOjLjR5AZZyAzfvQB/x4F+vfw6N+jQP8eBfr3JKB/jwL9exTo35OI/j0K9O9RoH+P
Av17ktG/R4H+Pcno36NA/54voX/Pa+jfswb9e15H/55m9O95A/17WtC/JxOY+irgzYlMInL0R8kL
TCaTCRyaMvUKYOpvkErk4m8ybzFfgTzl4l9k9IweGLaLcQG6GS/wZh8w8heBkW8h64CLvwP9d5l3
YX3KyF8ERv4+qQEuvpu8DCz8OOAPmB+QWuYE82NYSln428jCX0EWXocsfD2w8BIiQxYue4B/y4B/
v4L8+0vAv19DFk4dhuToMLQaHYZWo8PQw+gwtBo5+peRo3+BfYfdSqqpsz9pizN1ysufZb/Pfp88
w54EXv4kMvKnkJE/zf6M/Rnwb8rFn2Cn2CnI/wL49xPoWvQY+0v2V8DIf83+GpA6GBWhq1shO8f+
M2R+x/4OkHq7ZaOzUR77P9l56FN/o3z2X9nb0KcuRwXsx+w96FOvo8fZZfYTko2OR7kyRsZCn/oe
5csUMgX0qftRLrof5clWyVZBJhnYfzHy/lLk/WXI+1tla2VZkKfsv1j2JLD/z8vygf0XI/svkRXK
CqFfJCsCfE72PHkelMCL0K+QVZDPyb4AeqAY9cBzsirQA8Wyl2Qvwf6pHihGJfAWKoENqATeQiWw
ATVAPbD/HSQJeP8ekoqMPwMZ/1pk/BXyE8D4vwiM/yxZJ/+pfILUIu+ve8CTSYGeTMnoybQGPZla
UAk0ohJ4Gf2ZXkM9UAl64CPCoQZQKn4JGoBDDaBEDZCE7F+J7D9DMaeYA5Z/XfE7yFDezyHjfwQZ
fyMy/lRk/BnI+B9VLCoWASmnr0dOr0ROn4qcvh45PctxwOmVyOaVyOYfRdZej3xdiUw9FZn6o8jO
65GXK5GXZyAvrwcuDrqXKwZGziEXT0UuXh9n4WVcGaxfzpXD+pSL1yMLj3FuJfJsJXLrBuTWjcit
U5FbNyG3Tkdu/Qhy6wzk1o8ie36UG+aGgVN+nfs6sEnKniuRMVdxO7gdkKeM+QVkzC9ze7g9wCMp
Vy7n9gFXrkKuvBa58jruAHcIePz3gCWvRZb8JvLjddxx7jhsRVlyObLkN4Eln4RtfwhceS1y5Qrk
yuu4f+DOwh5+yv0U1qdcuRxZ8lpkyRXIktchS67jpoAlVyFLfhlZcjmy5HXIkmuQJa9HlvwC9yvu
V7CU8uMYM36Bu8UtQIby4wrkx5XIj9/klrllYKiUGVchM14HzPgR6FNOXIOc+GXlE8qnSC0y4zpk
xm8jM34FefDLyIPfRh5chzx4rfJF5YuAlAGvRwZcp3xJ+RLskzqKJaOXmAK9xJLRRSwZXcQU6CKW
gC5izegipkAXMYWyVdkK7069xBToJZaMLmKvoYvYGnQRa0EXsUx0EctEFzEFuogp0EVMgS5iyegi
tuYBF7FkdBFLQBexZHQRy0QXMQW6iCWji5jiARcxBbqIJaOLmAJdxNagi1gmuogp0EUsGV3EMh9w
EVOgi1gyuoi1oIuYAv3DFA/4hynQPywR/cOS0T9Mgf5hLQ/4hynQPywZ/cMU6B+WjP5hCvQPU6B/
WDL6hynQP+xL6B/2GvqHrUH/sNfRP6wZ/cPeQP+wFvQPy0T/MAX6h72G/mHN6B/W8oB/mAL9wzLR
P0wBGmYNqQTF8hR5GfVJLf80/zRogwK+ALj+s/yzpIIv4j8HeqOYL4Z8CV8S1y3lfCn/PFmP6qWc
L+crAKmGqeO/yH8R9kM1TC1fz78K2MC/Bntr4l+HdZr5ZvIC/wYomXV8C98KCuFt/m1YSvVMDa/m
1XA8Wl4LW8WcGKnCqQOFY4L3ogonibfxdtiPg3fAVi7eRV7h+/g+yAzyfjgLqnMqUdusRefGclQ4
VfwIPwJIdc561DlV/Dd5GCVQ55SjwlnHf4f/DmQ+4D+Ad6dqpw7Vztv83/KHYCuqedbxH/Ifwjrf
548C/j0on1X8DP9bwH8GzbMKNc+rqHlq+UV+EfZMNU8l/zH/MZwd1TyrUPO8iZrnZdQ8Vah2ylHt
VKLaKX8oERROFSic1aQGFU4dKpxXUOGsB4WTDirokYcyYM1HQeFUoLZZi3qmFvTM0/AuhaBnVoGe
KQMsf6gScB1omFWoYVaBhnkDkKqXVaheVqF6eRXUS1tcsVCtshF0SDsqlk0JmyDTldBFqhNMCSZA
MUEEtCRYAK0JVkBnghOQetGtRi+61ehF9zB60T2MXnSr0YtuNSofGWqbL69auyqXfGFV46ovk+pV
ulVe0oZOdXJUO3JQOM+CiqAa5lnUMM+oukHDPKHqUZmAqVPd8gQqlmdBsfRC36qygXJwq9yQoVrl
SdWAagAygyo/qBSqT55CffIs6pNnQJ9shcy7oFKeQZXytOqvVH8F61N98qzqm6odsPR90CdPgz75
FuyN6pOnUJ/ElMmTqEyKVd9VfRfwA9UHgFSZlKEyaVX9LSiT50CZHIb8h6ojpASVyXOoTJ5HZVIG
yuTvIXNc9QPyOdUJ1QlY84eqH0Ke6pPPq06BPilWnVadhqVnQZmUoCYpQ03Sqrqg+hksnVBdhDxV
Js+rPlJ9BGtSTVKm+qXqCuT/B2iS50GT/Ar2NgPKJBuVSYlqVjUL70v1SSnqk8+rfqsCjofugEXo
R1qouqm6BRnqFJirmlctQJ/6BeajX2Au+gUWoV9gLvoFPo5+pNmqf1f9OyD1DixSfaICBogOgnlA
zIEBoo/g4+hNmo1ugo+hN2k2egrmo6dgEXqTFiYmJSZDnvoL5ieuSVwDGeoyWIAug48nZiRmwlLq
NViEXoP56DVYgF6DeYm5ibmwlDoO5qPjYC46DuYlmhJN5AlUYk+BEguiEoN6SNycuBkU2hZQX0+h
+noedVcr6K5vQn9H4k5Sgurr+cRdibugT50L89G58DF0LixC58ICdC7MR+dCOWHW3s4KAPlVybaS
XxOiaYfQQOghRAg7hGfllbEeglcJIgKxFWIUYgfEboh9EAchjkAchxiDGIc4BzEBMQUxDTFD2MAF
DKKZw2ADkxCXoX8TYgFiCeIeIZ0sBA+RBJEGkQmREzuGzvz/y2tRbF+dpfGg21RAVOMy0lkH0Rg7
XtxmX+wcO1sgNkBsiuXjr2zgKgZjPQpxAvrXVnKxuAExH+9fhliM9+/GIkjiwUGoIFIhMiCyY+sG
83B90qmFMMauU6dl5ZrH1i3E9UinE8ILEYCIxs9hOPZ+wZL4uW6D2AmxJ758f3x5eTyqIAefYyc9
n1MQZ1bOJXbOJyBOQZyBOA9xEeISxBWIWYjr8ddbD7zeX/82xJ3465X4dnceWL5MiFYOkQCRApEO
kfXpK/38tLkQBX/xKxus/fSzouemLY5/1v+vkfnZwPreGnsfrKvM2Hr4vg9GGUTlp68r+4jtlw02
QL4Goj5ef7BM2/Tpq7YVYqN8dcesuXFwUhPpJYgcogpwa28q4GhvBuCO3mzA3b15gPt6Cwcn6Vb+
TZqDvSV+bcd1c8vg5Y5b5g2DVzVHessRq1b6x3trB6/SpX5jx23zpsFrmrHehsFrsX4c75i1gzc0
473NiG2A57B/DvsTve2AU70awOlePeBMrzh4g27ltwAaob9stgzOa+Z67YA3ez2AC73S4DzN+51q
udk5uKhZ6o0A3uvd6veqE8zewbudbO8o4g7E3YB8Zx1gUu8+wLTeg4CZvUcAc3qPD96lW/kDnfm9
Y9JudYo5IMGV7R2XiDrdHJU4iv6oOss8LKk6S3vPAVb0TkgqmvEPx/JxzDVvk1LVBeadUkZnde/U
Ctb1TksZNO/fFsdi8x4pu7OxdwZxDrAF+xt6bwJu6l0A1PYuARp7762gxcr6d3Y6rbx/j7rMvF/K
6/Rak6Q83FthPBOwpt1HmvHvV1eaD0klnVFrJmLO/T7N+w+pa8xHpfLOYWu+VE77/qPqGmsR9OvN
J6Sqzm3WUsSKlf5OazXgHmsd4H5rI+AhawvgUesG7G+Squi2/hPqJvMpqVbdaj4jNXSesGpX8JRV
6z/VecZqlBrUG83npWZ1h/kiHoMF0bnSP2/1wpHozJekts6L1sAKXrJGpTa1yXxFau8Z7w8gRhGH
Ac/1bwOc6N8JONW/B3C6fz/gTP8hqZ1uNeTtmes/OhRQW82zkkbtNl+X9D03+08ALvSfQqT9pf4z
kp4uHYqqfeZbEtdzr/+8xJlY862h4RiqQ+bbkmji+y8iXgJMwn4S9tP6rwBm9s8C5vRfB8zvvyWJ
dKuhbYB3oL/FvCzZTUX9twFL++8AVvRDhuaHdqpHLHLJY6r2UqzzJgztUW+3JEiSqdGbQtEUxX46
YIs3C3CDNxdwk7cAUOstBjR6yySJbjW032TxVg4dUu9SX5MiJqe3Roqo91pSpK0Ug3nqA5Z0adTk
9dYDBrxN0ijNDB2N5eN42JIl7VAfs+RKu01Rb+sKDns3wncH8kMn4njSUiDtM23zdiDqVvo7vSbA
PV4r4H6vG/CQ1wd41BsCPOHdMnTKdMo74teqT1uKpYOmM97tQ2dwb0fimfPeXYAXKdLM0Hn1WUuZ
dNx0ybsX8cD9Ps0PXVRfsFRKY6Yr3sPSGO0PXTLNeo8NXVFPWmqkcdN1uPKA3pMr/Vve04C3vWcB
73gvAC57J6VxQe69DJjgvSqN022HZtWXLfXSOfVVS5M0IaR4r/0JpntvSBPqa5ZWaUp9w7JRmhay
vPOIiyv9XO9daVo9b+mQZoSCAbKCxQOcNKNetOikuc4r1mHEbYCz2L9u3Ql4y7oH8LZ1P+Ad6yHA
ZetRaY5u5T+jlVtP+M+r71pM0k0NsVilBW2C9RRgCmI6Ypb1jLRAl/ovajiLW1rScNbzFGlfm2u9
6E/SqCw+6Z62wHoJ8cqf9Iuts4Bl1uuAldZbgDXW29I9upX/kibVEvKzmgzLFj+vrbfeAWyyLgO2
2uSAG20Jfl6TbRnxJ2k7EHW2FP8VTZ5luz9Na7KlI2Yh5vrTNHm2AuhbbcWAblsZoM9WSfOw/qw2
ZKuBzBZbvf+6ptCyy5+pHbE1AW63tfozNSWWvdIURf8t7S7bRv9tTbnlAKy/19YBeyi36ShCZjaW
j2OV5bA/R1NrOQbHdsBmAjyMeMxmhStD83e0J21umD2xr2mwnPTna0/bfIihFTxr2wJ4wTYCOGnb
DnjZtgvwqm0v4DXbAf+y9obtcEAO+zntL9Jk244B1lrOAjZbLsBxzttOAi5SxMysps0y6S/V3rWd
/izSfABkq+2sP7+Ls10IpGjaLZf9FV0q26S/gvYD6Zp2G2Q0GstVPK8YXrvf70q13QDMsM0DZtsW
AfNsdwEL7QSwxM7BudNt72j0lmv+ao1oueGv6yq3q/4Eq+yp/jqN3TLvb9R4LIv+lq5a6zaK9owV
bLBn+1s0kuWuf0NXsz0PsA2x3V4IqLGXBLIoJwnkdunt5cBPgBsECrpEe9XgjS67vRbQY2+IzeCB
YjoPBsq6JHuzlN0VsbdJ2XQmClR2bbW301nJrgGEuSZQ0zVq10vlXTvsIswv8H0J1HftttulOVq3
gaaufXaPdK/roF0CPGKPxGos0Eo/38DGruP2rf58TYN9FBCuQ6Cja8y+g14T+27A2JmO2/cBnrMf
9LfgjHNdKBtQwexDR/5bQuVAqiQKNQMZgPUD2fHx+TYd5YbuCE0DedI+9cmBQkA6ziwLrQMldMwZ
KAeEkSQqFzYOVMHo0TFQK01j5c92TdiPBHRdU/bjAVPXtH0sYO2asY8H3F1z9nODV7tu2icGr3Ut
2KcCPlhnGtZZss8EQl337HOBLTrWfjMwouPtC4HtuiT70uC8usl+T6rVpTnYwC5dpoMP7FVvdCRJ
zbocR1rggLrAkRk4rC525EjZunxHvv+8rshRFDimK3WUBk7G+IauwlEROK2rdlQPTlJGETirq3PU
BS7oGh2N9FNwtNyf2XUtjg2ImwA3wLFN6jY5tIHLOq3DGLiqMzosgWs6i8MZuKFzOryBeZ3XEQgs
xjhtJ+uIAouL8ShkKbqAYxi4K/JGXdSxDXDYsRNYHK2Nu51aB6Bum2N/kOh2Og4FOd0ex9GgSref
rqmWO04MLuoOOU4FU2PMTbPbcWZwUnfUcR6+48hRdSccFwdvdGY6Lg3e1Z1yXIF3Nzpm4TqccVwH
PO+4JeXpLjpuAwc75LgDx3PJsQx4xSkPjGiWnAmw/1lnSjBDd92ZHpikVyCYrbvlzIrVdjBPd9uZ
C/u54yyQynXLzuJgYbfcWRYsiTHM7gRnZbC8O8VZE6yi34tgbXe6sx5YOnD1YEMMu7OcTTEGHmx+
ANsQ2/FdNIj67lxn6+CN7gLnxsH57mJnx+AiZdRBsbvMqYv37Yge+v0KSvErCXw4GEHcSo8qONpd
6TQFR2N9xB3dNU6rlNpd73QDHwZWHNzd3eT0xThwcN8DeBCYqlPK6251hgA3UqSsNXgkht0dzi0x
pho83q1zjkgl3SbndkDIQ8bq3BVjrYGaTzE4Rr/1wXHEczHsdjv3AhcFRhqc6PY5DwDzBF4anOoO
OQ9Lzd1bnMcArc6TwDkvOk8Dt6Sfy3QMu0ecZ4Mz2lznBfh205E5qXu7cxJmz1znZejvcl4Nzmmy
ndfojOC8EbzZvdc577/dfcC5GFzoPuy8G1zqPuYiwXvdJ11ciI2P7Th6a9pdqhDffdqVCqOxx5UR
SoqNhN1nXdmhtO4LrrxQZvekrT6U033ZVRjKj3EArclVAnMBzjLdV+m4HZuju6+5ykNF3TdcVaHS
7nk623Yvumph1oNRK1ShnXQ1hCq671ovhaq1213N/kw9cbWFMuPz8gFXuz9Jz7k0lEu49NKcXuUS
6Zzuskv39Kkujz9Nn+GS4H2vuiJ0/nLBGKjPdo1CPs+1w5/WVeLafX+m0Be69oXq9CWug3BswCWC
qfpy15HAJD27UKO+ynU8NtL6L+lrXWOwnwbXOMwCMOeGWvTNlmOhDXSeCm3St7nOhbT6dtdEyKjX
uKZCFnrdQk7cj1evd02HAnrRNQMaB8bwUDTGdigGOmJ4n9VY3KFhirFMaBviTnoMoT2I+/V215yf
1XtcN/28XqJshDKTQIc+4lqI9WG+A4StYC4IHaKjbuiQfqtrKcYrQkfjCGcRaNWPuu7BfIF9PK9D
+h1u1p+j3+3mgVEArwid0O9zJ8VYBBzVCoZ2ag+40/xF+oPuTMAj7pzYjA/7AQyd0h9358dm+dAZ
/Zi7yF+qH3eXAkIeMufcFbFZPnT+AbxI56nQJcSdiFf0E+5qmLthBg/N6qfcdTBTwzweuq6fdjf6
G/Uz7hbAOfcGmMWa3Zv8G/Ca30K8Hb8yN91af4V+wW301+mX3BZ/i/6e2ynNGVi3N3RH0A00RBME
00BzpFmwDrQBugfapVHBN6CR9EJoQC9xwpYBMZoC69hh6ciAJ5oubB+QYOmugUg0S9g7sDWaKxwY
GAU1tHdgh7RVODywO1qg3j6wT5KEYwMHo8XCyYEj0TLh9MDxaCXMmGPSPuHswHh4i3Bh4Fy0Rpgc
mIjWx9SB+sLAlDQmXB6YjjYJV73Hoq3CtYGZ6EbhxsAc6LgbAzdXePj8wEK0Q1gcWIL+3YF74WMi
8bFRncj5+KhJVPmSolYx1ZcWdYsZvsyoT8z25URDMQVqavTlg+aKKR3UFGKeryi6JabyxELI2MUS
XyloLpjroyOm/b6K6IhQ4KuObhfLfXXRXWKVrzFqMhXRNdUjvhbJI9b6NkT3xnRWz7hv0309G9OY
YgPqykbTdar4fNqVdz/kMwKiVhKbfRZQTDGNswwac1xsG1gIVpmqfU7Yf7vPGz0ganwB0FlwBaKH
Rb0vGucq20TRNyztE+2+bdK06PHtjB4TJd+e6MmYHhQjvv3R0+JW36HoWcpzohfEUd9R0NSgrKOT
iJfFHb4TMGuAgob5AjB6laIfNXX0Gn2X6I0Yirt9p+CM9oHmsosHfWckD9W/0XnxiO98vL+IeJfy
pc0kfiVBvW7m4ghHtVklHvdd3KyK9RFTxTHfJWmHOO67AuoVNOzmDPGcbzamWDdnP4B5pvO+63DF
Jny3AKcoUo0Z2BhDcdp3O6YrNxeKM7470nFxzrcMCHnI3ByUxzTm5pIHsJyyuM1ViLUxFBcGE0A5
gn7c3CAuDaaATgQVublZvDeYLk2Z2cEsQH4wV5o2Jw0WRDvo57K5DbFdPTJYHJ03pw2WSWPmzMFK
acKcM1gDa+YP1kvtBt4dCC2jdsD5CMcu0CyGJHc0LDekuYfDCRrOvS2Yash076Rzh3tPOMWQQxH6
+8Pphnz3oXAW4NEVLHKfCOcaSt2nwgWGCtiKj2k6Q7X7TLjYUOc+Hy4zNLovhisNLe5L4RpDJh0/
Ee8YNrivBBfoaBmuR2zShtyz/jTDJvf1cKtB674V3qgpd9/2zxqM7jvhDoPFvRzWIZroOBm2xrUV
YNhtcPbJw76YzjJ4+xLCIUOgLyW8xRDtSw+PGIb7ssLbDdv6cgF39hWEd9ExM7wX8YBhT19x+DBg
mZ817O+rDB8zHOqrCR+LzSmGo3314ZOGE31N4dOGU32t4bOGM30bwxcM5/s6glU4ivKGi306SW+4
1GcKTxqu9FnDlw2zfe7wVY3Y5/PXGa73hfzVhlt9W6TjsRmKYviaRoLZEPp9IyFvjLl1p/RtD98w
3O7bFZ7XkL694UXDnb4D4buG5b7DoWVDUd+xcK5R3ncyXGxM6DsdIcaUvrMRzpjedyGiMmb1TUqj
xlz3zkjqg3szFvRdjmQYi/uuRrKNZX3XInnGyr4bkUJjTd98pMRY37cYKTc29d2NVBlbPSRSa9zo
4SINxg6PKtJs1HlSAU2ejEhqHK2ebGnO6PbkRdqMPk9hOGQMeUoi7cYtnvKIxjjiqYrojds9tRHR
uMvTELEb93qaIx76+UYk4wGNJxIxHva0RbYaszww5huPeTSR0dhnZzzp0Ud2GE97xMCI8azHHtlt
vODxAE56pMg+42XY9KDxqmdrKE3T4AGFZbzm2QF4w7M7csQ479kXOW5c9BwEvNtXGRnrIZ4jwZke
znNc4npUnrHIeE+qZzxyrifDc04Se7I9E5GJnjzPVGSqp9AzHZnuKbFMBqt6yj0z4cqeKs9cZAbW
vAlr1noWInOxd+lp8CxFbvY0e+4FJnva+tnIgoYzFkhLPe39fGRJU9Wf5M/p0fSnRe716Pszh9ge
sT9niO+xG31DvKatH2bnHk9/0RBwuf5S/4Yeqb9iKK0n0l89lNmztb9uKKdntL9xKN9Q2t8SXKA4
VBRT/T07+jcMlfbs7t80VEHZy1A1ZSlDdfRXlKHG2DcOf8EYjv9S8dlvx+n4bwX4y8BQS8++fm24
gM7vQxuoBh/aRKtxSBv7dQjHhzs9B907Yf/IxHqO9Bv9lwz5/Rb/pfivN/i7Ss9xi3XIaLjd7xyy
xFR/z1i/d8hJP+tAK2HJI8wC86+EMH9klgjL3GU+JnLmE5YhHKtgOfIQu4pVkVVsCruaJLIPs+kk
mc1k15LVbC77JFnDFrDPkIfZb7PfJo/IGmRfIhmKesWrJFNhVzhIluInip+Q7CRo5PGknKTXSU5S
S9Im0pykThoiX016L+nHJJR0PukW+buk+aQlchmO5stEjv/9IIkkk4fIatJGVpENREveIDryLtlE
vk5GSISMko9IlPyC/IZcIL9lEsh/Z1RMIvmESWYeZhiGPuPE0/smmUeYdsbAZDE9TJQpZLYw25kG
ZifzbeYt5gfMz5mvyj6Ufci45U65i+mTB+Qhpl++Rf4u45O/J3+PCcjfl3+LCcq/I/+AiciPyI8y
78hPyH/IDMt/LP8xMyr/qfwfmffweczt8in5R8z78hn5LPMt+XX5vzC75b+X/57ZK/+j/N+Y79K7
6Jj9ijWKNcx/UXykWGYOcgouj7nEPc09zSxyz3DFzB+5F7lK5mP6hAfzCfcKV8fKuXrudZbj3uA2
sUlcJ6djszg9Z2dzOBcnsZ/j3uFG2Be5UW43u477DneAbaRPTrCt3BHuZ+yb3EXuImvjJrlp1s5d
5a6yA9wsN8v6uN9xN9lBej8WG+T+wC2yUW6JW2a3KIkykX1Pmap8mP2O8hHlk+wHynzlC+xR5ctK
kR1XOpTb2FvKbyq/KVMp31fuliUqv6c8IltD/6+q7BHlf1WelGUpx5Q/kWXT+4Fk+cpfKKdlZcor
yuuyCuW/KP9Ntp7P54/J2vg/PPSE7DdJHyd9LKfPy4lkC6CKZNOnjWuPxoOHKCL5orbhjmisa/jS
5boS0SI6RW/DrBgQo3Viy6h4QjwlnqkbE8+LF8VL4hVxVrzelNCUKw43ucVt6xvXG8Wd4h5xv3hI
PNqUu74OqkoONb6ANf5HwjCfMJ8QFio6hchg2WN4Jyphv8d+jzDsh+yHsOwo+3dExv6I/RFR4J2o
HPtz9ueExyfBHmI/Yi+RBLwHVYV3nyayv2F/Q5LwvtNk9vfs7+HbQe8sTZUxMmblvwYrZBxJxyfH
MmTpsnTyqCxDlkEy8U7RtbICWQF5DJ8Ky5ZVyapIDj4D9oSsRvYyycWnYvLwno2n4PhVTCpeOYpE
OEt8wlnhgjApXBauCteEG8K8sCjcFYmwKHKiSkwVMzCyxTyxUJgXS8RysUqsFRvEZrFNbBc1ol4U
RbvoESUxIm4VR8Ud4m5xH8ZB8Yh4XBwTx8Vz4oQ4JU4/2MwbxBlxTrwpLqy0JfGemTXzD7Qkc5o5
05wD2fzPtE3mfFi3yFxqrhDv3W/manOduRGQthazVlwwG2Fdi1lrdpq95oA5ah6Gfeabt5l3mveY
98P5Mw+J8VGDPrO+Gq9JBjQZyYImJ/nkaaIgRdCU5PPQeFIJ7SFSBS2BVENbRerIery7/DUYdehz
l8nkK6SdpJAOaKkw7ujIGmKElkYcxIlPXHrxWUs/3lEeJpkwHr1H1pL3oT1G/hpaNvkbcoA8Tr4H
7QlyBFou+SG0J8l/g5ZHfgTtKfIP5Cwc3wVoBfjfsJ8h0+SXpJD8CloR+S20z5HfQSsmt8kf4Njv
kP9FniPL0J5nWEZJypgEGPsq8f7xL8LYl0Kq8P7xaiabeYK8xDzJPElewec962A0bMEnOttJPfM1
RkNeZbSMlryG95I34dOdrzMiI5JmppfpJW8wLsZNWphBJkRaYeyMko0wer5DvsK8ywyTrzKjzCj5
Gj7d2QEj6UmiZsaYMdLFjDM/ITrmHPOPRM/8E/NPxMj8jJkgPVi/AowCBUTkC/lC0ot351n55/hS
YsM78hx8JV9JnHw1X01c+CSRG++/6+M1fCfp57v4LjIAn+11soS1X06dJUzHIcYgxiHOQUzEYyoe
0xAz5G3TmGncdM40YZoyTZtmTHOmm6YF0xLgPYEVeGhJQpqQKeQI+UKRUCpUCNVCndAotAgbhE2C
VjAKFsEpeIWAEBWGhW3CTmGPsB/aIeGocEI4JZwRzgsXhUvCFWFWuC7cEm4Ld4RlcYsoFxPEFDFd
zBJzxQKxWCwTK8UaaPVik9gqboTWIepEk2gV3aJPDEEbEbeLu+h/EFVoFT0wCX4tqQP9Fdb/f6vv
16ElY5WnYJWvxipfg1WehlX+MFZ5OlZ5BlZ5Jlb5WqzyLKzybKzyx7HKc7DKc7HKn8Qqz8Mqfwqr
PB+r/Gms8mfIBLRCrPVnsdaLsNaLsdY/j7VegrX+HNb681jrL0Cts6Qc6/tFrO8vMI8x2VD3tLKr
sLLXYWVX4/MRL2E112A1v4zVXIvV/ApU8yB8B/yMH74D9CmJV7GaG7CaG5lvMN+A7wOt6SZ8PuJ1
rOZmrOYWZgLquJW5yFwkb/Jv8W+RNr6dbydv8T18D31eOyWQshU+JxVc+1WEsXVA3ZVCVEBUQ9TF
c40QLRAbIDbRnHy1qcxWLkz9+cB1pu2XTJW2KlONrVaY+WzQnKne1iDMQdy0X6FharI1Cwt/Pug6
plZbm2mjrV1Y+jTo36YOm0a4Z9OIrH3WpLPpRf7PB66TZL9uMtlEMc0mmqw2O4bb5hEzIXLsFuzn
22+JRfbbJp9NMoVsEbH008C/K+x3TFtsW8Xq/yTq7Mtio0NuGrGNYmy37TDtsu0WW2JB+/TcxA2f
Bp7rXts+cZNtH33FOGA7KGr/86DrmQ7bjpiO2Y6Lxs+G6aRt7P5+HwzTadu4aPk0TGdt5/6SsHa4
d5ku2CZMk7ap/2Nctk3TsOrce2mYrtpm/qK4Zpsz3bDd/A8xb1ugYTU5RkyLtqW/JKxW9wHTXds9
GgKxsxicnafxv9n7HqiozmvfMzNnRmJ0aixFJWgJNYYgGoPWEmrVWoIw/zTWGK+lOmHOOfMHZhjn
n8Z6iVpiqbUWfcZaY4jPay2lxlprqBI0lmvUcr1ULVFjjZdnrLFKiVe5xPoMeXv/zhkckazYdd9b
663Vrm/t39nus88+37e//e1vf4esSTAW28HX8kC0rtQZKikdEDKXDg4l96bg0tju0qGh1M+i4IrY
XtgYEUoHjQyNKs0KZd9F40I599DEUO5dNCk0+b5pWii/tDBkuYccoZmls0Nz7qF5oeK7iMd9H1QW
CfcvVUKe0rJQoE+ie2VLwoPKloVToBcKRe6LFoeWlFaElt1DbG8l0epwWmllaOX9UNm6cEbpqtDq
HqoOreshvr+RqCacCX5beGxZXXhC6YbQRvS3F5XtCueB3xyq+Swqqw9PLWsMF9xlY2to211UG6q7
h/jZprCtdGdoV9nR8CxcW8Jz++rPp9KeUH1pQ6jxHjoYaio9HDp6Dx0LtSRSWWt4fjy3J+bieK7s
yXFnw1JPDmoL+xLzSE+cJM5rfF7iProUDvb4tj0cS+wTckkV5RRa+8E1ag4IrlfXL9bVplAq9g2K
9+AWou2xA/F4Du6gK72H75ddDy8tuxleUdYdrvKL4TW8v/j7h9eznMfmHxTe5E8Jb+H86k8Lb+c8
6c8I7/BnhnfzHuAfG97LuR1jpnj3TwgfiOdnf174kH9quJnH7S8IH2df+G3hU5w72SZoVvicf274
gn9++LJfCnf4feFOfzB8yx+LCOxf7EHsS/Khfyntk9p+5l9B+4/mZ38V2VkTMbEN3FsfGeDfFBnM
+07PXpswRz02mbQ9Jb4XcJ94b/RviQxF37ZHRsTnGfqc+2nusS/Tnoex7YiMZJl/N+3heSrxfs3+
vYts6r7M+xX2Y3pPfC/mK4jiB2PrtcfiXUT+vQsrmHiPje+rcfIfWFjN1LNH8p6p7Y2Je+Vde6S2
T8bJf4j2QZpj7H20H/qbFzYwIW55nzugUk/OIvIfj2Theioyzn8uMhFyyh/+C5FJ/suRaf6OSKG/
M+KAnNcw7yW8bmkd8Xry34rMDgiReZyLAqaIE+sivg60vIjYIjuc5wIDKDdpawTzRXmLn4/nwHvW
Vq911ZNf4v0nG5w3A4MjCs95YGikrOd51qf1FhgRCQVGRhZzvwNZkYrAuEglcjiPh8YQmBhZFZgU
qcZzn5V/tH4Fpml5PL7GVyboaH3GWHvl457xcB6O06e961PyaaBQuzpCu3hMPdQ7TybmSs6P8RyZ
mBNJF3ZYh++RDwKzw7bg7tih4N5YMxPXNjzfqGsOxI5DRjkrcDJqDh6KnYrXL8Hm2LlAZeQg8hjV
HcHjsQuoKSinBXZGrgQqIg3xmiB4KnYZOY33f64bONedi3XwHh28EOsMXo7dChyM3A52LBKCnYtM
wVuLBiwUFg1eaFo0dOGARSNQk2n5Es9ybabVTah54jUK29Js8L2FgxeN5HzJ/eqp7eJ1WOedHAyK
1zBa7cG2uB5bOHRRFtc7C0csGhd/Hvo0Hvyb/IV1QmNbOHLRRMi4boyTVifeRb1rQa32u4s0v/au
63qIa7E49a7r4jVaH7XZwiyVPrM249orsf7imitedyXUWNxXPMs6mk/uWVu0/gLzIhvuWVfOyOZ4
jRVQIlsDZZFazkVxvUAospPjOrA4sgfxFM8DrMNrjuIP11WRw4HqyDHwGyInA5sjZ5gS11tga+Q8
54hAbeQi4nNP5No9dQxRoCHSBaJ4ZMI65Lx1OKrH9Vg0Kb4GeU0EzkSTA+ejqT3rj3PQxWg6cs2V
6KjAtWh2oCuaw3tPnHi8fMbC+qMxB25Hc8v10cmwTfmjPCmaj3Fq+uXmqKU8OTqzPDU6pzw9Wsy5
qHxUtKQ8O+opz4kGynOjEd7/sAdyfqKaoHxydEl5fnQZ5+NyS3Qlziy0F5bPjK4unxNdV14c3cj+
Ki+J1pR7otv4nFAeie5iP5UvidazfvmyaGP5ymhT+eroUa4BOf/Hc3P5umhL+cZoK4js8T7DsV1e
Ez3Lfi/fFm0rr4te4jgr3xVtRw6jeSyvj17HvcboTdhoinZzLi8/GhPLW2L9y1tjg8rPxlLK22Jp
5ZdiGeXtsczy67Gx7N/ym7EJyGM8/u5YHl+DYmwqx0Owf6wgOChmC6bEZgXTYnN74odqcK4/ghmx
+cHMmBQcG/NBruXc4IRYMJgXi2H+aJ0Ep8aWBgtiK4K2WFVPrMbPAfE9ivjgrNga1gnOja1nmaAX
dOaV5mpB+MdfUP6O/oLSLly/83cAqUsok1PldHmUnC3nyLny5NminC9b5JmEc+RiqUttcjqTXCJ7
pNtqkwNyRF4iL5NXyqvldfJGuUbeJtfJu2avkevlxtkH5Cb5qNwim7W2DtQqn5WTtdYmX5Lb5evy
TblbEZX+yiAlRUlTMpRMZawyQclTpioFsj7eSMOmzFLmKvPlJLUpkuJTgqQXQw+5R6zJ9/h99Ab+
zj+wjmK76P/Kd1A7rY0Z1B7Cd9DB+A76eXwH/QK+g6YIHsEnDBHKqKXia+jD+Bo6HF9Dv4ivoen4
GvoIvoZ+CV9DR+Jr6KP4GvoYvoZm4mvo4/gamoWvoaPxNTSb1twxYazQQu1JfA3NwdfQ8fga+mV8
DZ0ofCD8WfiKcJVaHr6JfhXfRL+Gb6JT8E10Kr6Jfh3fRL+hG6EbIeTjm+jT+CZagG+i0/FNtBDf
RIvwTdSCb6JWfBO16f5Z96Lg0C3XLReewTfRWfgm+k18E30WX0Pn0Er/jfCcbp9unzAP30S/hW+i
38Y30QXiKvEHghO/NFgi7hX3CRKt68OCIl4W/yx4aP12kS91wmKh4k6sumjErlOuc64LrsuuDmqd
rlvkeJM0QBosDZVGoClSmRSSFksV1CqlVVK1tEHaLG2VaqWdaCOlLGmcNFGahDYNWCg5CGdL8yQn
N44b/WiKmzFa3AzG+zli9DRHj1H0cKyI5P8cih6OFRNipR9FytMUQ/zN/AGKjnkUQxwfDyI+BuA7
+UAaVylFEkfDIIqFtRRPHAeDKQq2UzxxBCQLv6L2BURACiJgCM3/IYpb/h4+jOb8XYownvWHMetp
+AY+nGb+ijACc5yuG0Rz/AhmNwPz+iXM6EjdAp1TeBQz+hjNaFDI1MVoRrPwlXu0bjXNYjZmcQxm
cSy+aT+h+41urzBO0CVNTJqUMB9Z4kOurN5NWiItc41zTYw3aZRrktam9W7SSlehy6E2abVrtmu2
tI4kvZq0UapxzaPmpKZwk7bhWuYKxZtU51p8b5N2wcJiV4XWKtUm1btWuVZJjYTV9zapybXBtbmn
bWVdrdVqbWfv5t3p3ePa42qIN+Wa66DWDvdu3gbXsfi7vAddJ6ltJUmvJk9wdbnOUOP3nefmyZTM
dL2IJ9Dkjnutuw57CmDhcNyzritq8x52XXNd89YSdt3bvMdofLd7mkPS97QktfXhqaNSi2SWknta
q5SKdvaOJ+JNapPSpVHxhhm/JGX3au1E16UctFxqNzV5tywSTu4ZkcNVIfeX8u9t8iDJIqdIM6U5
3OQ0qVhtcoYUIEmJVCJnSiUJdnqaPNZ1RfL0tIAUiTfV+67zNCMU33IeYrdQnioXcIzJNvaEPIvj
Q55L3HyMNluWZB965MNYVUscKScxS8e8Z7znEQ0X4f0r8HS7HKS1M478N9E1SY65auWl5GWzvIL6
VyWvoVh2yusp3hfLmyS9vIViubqkSt4u5dJ711CcVJLuDnm3vNd1Wz4gH5Kbqccc/9XycYzSSTN2
1FUpnyINh3xOvkC2eNViRNBU1wrPbqVrtnyZ+t9BY+4k+SrSm0irbpV8i7hx8nxFcE1STMoAZbAy
VBmhjMRanq02JUsZx+tVmahMojZNKaTVWqauWMWhzMbb6E3KPFel4uQ1qZBl0ixTQspipUKpdG1Q
Vmnrj1dgrVKtlFGsmRFvqXR3g2SRcpXNUqqyValVdkrFyh6aX5oteY3SoBxUDpPnsqV86tMGqUU5
ppwk7TPUzks5SgMikEeJuWI9ahQx7CXlItEVKZ/WcLXSRfKIctutV867k9z0bneyO9Wd7h7lziZf
+9w5HO/uXPdkd77b4p7JMU6exZy758iZFG257mKlzF1CzeMOSJO50b2IO8e9hEZgkebQnWVSsXsl
xylhiXu1e517o7tGGene5rrirpM87l0UjwEem7ve3UjvLKEIjfD4vNdce7xdHokyw0HvbZqf8zSe
fIqXap/el0RZoNZnpkxxWNngbvclu4a6Gkqa3TN9qb50XtcUM+Qt3yhfti9HqfXl+iZThHLm6KJs
xt6p9TZ4G1QNV7XnuC+fbHG+QwRDU80yFMFk66TP4trgm+na6ZvjOizpSa+B+nPNV0zcHnexr8R1
UM5z53jyfB5fwBdBFtQymW+JF5nVnes96T3pW+ZbSXnuoprrfKt96/A2epNvo+uKr4azGeE1X41v
m6/Ot8uT4qOM7i5WMxdyV5L3iq/Rt1oq9jVxT9xNNE8cO8Xuo+4Wjh+1yWuo34fdrZyT3Gdpjtuk
mTQ7lyiusikfZLvbydfb3Nelye6b7m6XwyN6KO+4LnoGeVJKmkuaPWk0g9sobq65FnsyPJmesZ4J
njzPVKlEOc9+d+2Rcj0FHpvrmmeWZ65y0TOfVs8qSjA+KUDvP0/74yXPVFrBZspZJXQn6Il5lkqp
nhWeKs8az3pXhZTk2eTZ4tnuOunZ4dnt2SuZPQfIqtlzyNPsOkOWz3uOU5/M1JdTnnOeC57Lng5P
J/XxGNlOcl0jzVtewWtyrfIOoGwzmNaSg+JmKD2TTbGS6x1B8dvuHena6cl0t7vb5TXuNtd55aQ3
yzvOO5L8oPdO9E7yTlOOeQu9Du9s7zyv06t4CyULXcuULm/Iu5i0Kzxr3C3eSu8qKeKt9m7wbvZu
9azx1soSqqkx/zhh/h2dMD1CEP9VQwr/32SctYLueb2Q7NxGrY7aLmr11BqdjfOoOZucTQvOLDjj
PEqtxdkCWSu1s9RY1kbtEjV6bm7H3A5nO7XrTj7D6s0O8wx6xyCcaAScaPQ4yxhQ84o4yxhxijGh
5u2HU0wSTjEP4OTyIE4uA1DzmlHzfg417yCcWR7CaeXzgm6QNCiAMeG/O3ROEHROG13z6DpLfKhw
u7PgfshioesOot2fQntVshSrVHjgPukQUXMfdFwlS4Sup+6PLMvoek6jCxpdVqnovHq1bCSqIb6D
qPNestTR9dZnk6WeqJHsChqZiAbcTRhbLyoa3IuG/g00gmhkH5TVh12mcb1o4v2Rg/xeNIlo2qdQ
oUqOUyoVOe6TZhPN64OcKjlo3oqU+yMHzW1RmUYhjRar5LisXu1tdD1JVEFUeS85KAaKVn02OTo1
G9UabSDa3Iu29kG1vWjn30B7iBr6oINEh/ugY73o5P2R5RJdzzixPvokumdpJ7qu6V28T7pCdK0P
OqPZ7KZr1/2RVaTr7Ttk0d+hHp1B2jWFKI3uJd15VyJZM7T3mz+brJlEY+9+3pLci1L7IH52Al3T
6ZqnXaf23Z9PI8soouw+KIcotw+afDdZCxLyd2K+jedLLY9Zbc6e/GKd5bw7f8TjJHFeNX/3+Ghu
gm/n392nnpySmAPia1hbW7xnxGN+xtBeMd2l3rdKRD6ioJojeH+xLlXlPCbrCqIqNb86eb4oT1rX
E21S9wDrFi2/31Lj3Uo+iednK+1p1t3qeK17NT+QTc6XbBPEdmk+rZQXreQ7K/XBynYva/7V/MnP
Yp+M72EXEvxMdmyCaoPv2Wi/sA3Q+tV7nnrNUc+eEp+nKnVvtA1W+2YbmvD8LXUs+Pdube+jf9tG
aLIdCbS3D+q9Lx/vg04l7K8Je2wPdSRQr/21Z7/87+yTI5x374VZzjt7YMJ+15OziGzTtCvtWzaH
tsYof9hoT7LRHmSj/cemaHJaw7x/YN0WqOvJRvuMLaTmIttibV1o6yCeFzm22A7nOeSn+BqpUvMW
P9+TA3uvrV7rKp5fetZWldb/Sm3OV915Hvq03my0N9k2qP220Z5k4z3ovJaTeAy0B9l2as99Vg7q
ncf70on3uY983HMv6Q59aq77rHyafjfdkycTc2VOQo5MyIfQTdd0clUfcI6eQfEzI0slrm14vrmm
mTFOk1Gs2POJ5zym1S8zqDaydWl5jOZ0BsdWpZrP7Ox79pdWE8wo1HIZ7/8btDzH8Ud79AyyN4Ps
2am/MyhuZpC9GRRnM9gmxdiMCi1/xvPlTq02i9dNoTt5FLY0G+hjpZov0a/eebhXDu6pYeJ5mMfJ
tvgexdSM6oTnV2njmaj6CzUXjW3GBk02KYEK+6DetaCzD9L82ruu66GKBOpd18VrtP9ObbbHeXf9
ddB5p+5KrLGc2rMNCT7pvbZo/dmOOe9ZV7aTzp4ay8br+ryai3ry1UU1rm1XtHiKy1mnS4s/vlJe
sWvrzk5rzG5WKXG92ZPVHGFPVePTPqqPOobInq1RjkrIg2w/V7tOvrMGeU3Yaa+zz0xYf6Rnn6Ou
Nzvt0fYSIo+698QJ+ahO9ROP2R4gimi2aRz2Jdo4NX07nensK4lWE61zIhfZNxLRGc6+jahO3f+Y
kCepJrDvIqpX87G9UY1T3gvtTURHiVo0f7USnVXPCfZLqp/s7aq+nfYO+02ibrUG5Pwfz80O2gMc
/VVie9hnKLYdg1S/O6gGdaSpcebIUP3I8+jI1O6N1WxMUHO5g2pEB9WHDs49VI85qA5zUF3loHrK
Ian+dfi0PEbjdwS1a0yNBwfVQg6qgRy0RzjW3Ikfzt1cDzioFnJQLeTYosm1nOugesCxQ7XP68RB
PnJQDeA4kBCr8XNAfI8i3nFI1XE0qzL+rzEGNg18+x//Ncbf07cyMUs8xH9R1TcLvxSEfulEo4iy
iXKIcokmJ1zziSxEM4nmEBUTlRB5iAJEEaIlRMuIVhKtJlpHtJGohmgbUZ1Gu4jqiRqJmoiOErUQ
tRKdJWojuqS9s/1TrteJbmrE+t2CkCSq8qT+RIO0vrVrVxpDUgpRGlGGKu+5ZhKNVfuaNOHOmJPy
iKYSFRDZVDtJs9T3Jc0lmk8kaXIfUZAoptpNWkq0gqiKaA3ReqJNRFuIthPt0K67E65x/b1EB7Tr
Fu25Awn3DxE1Ex0nOkV0jujCnSv7J+kyUcffcI37olP1499KmINEmqkS28d8tWm6l3vRLfV/Ox+/
xp+P233ARDRAm2+SPzD4zvWBoUQjhF9aC60O62zrPKvTqoDKrCHrYmuFtdK6ylpt3WDdbN1qrbXu
tO6xNlgPWg9bj1lPUjtjPW+9aL1ivWbtst626W1JNrMt2ZYKSreNwr+zqeXYcokm2/JtFttM2xxr
ta3YWmsrsXlsAVDEtsS2zLbSttq2zrbRVmPbZquz7aJ/19sabU22o7YWW6vtrK3NdsnWbrtuu2nr
tov2/vZB9hR7mj3Dnmkfa59gz7NPtRfYbXyf5LPsc+3z7ZLdZw/aY/al9hWgKvsa+/o+aZN9i327
tcy+Q2u7qfXF76V2wH7I3kz8ca2dsp8DXaB2mVqHvdN+yyE4TKABjsG0Jwzr8xcXBO0XF5Lwiwv9
8YsLA/CLC2b84sIg/OLCYPziQjJ+cSEFv7gwBL+1MMycbn5SeNg83pwvjDG7zB5hirnMvFB42hwx
vyBYzRXmF4VnzJXml4Rvmtea3xSeNe83HxCWmY+arwor8OsL2/8/7plON1gXxH+v0sD/N/mMHI0o
s2RM1ihfI0sCz0SrJmOOxrNescaXaOTRiLJuBmXdDMq6GZR1M1Zquqs1fZatS/j3Ru1ao9G2hHfW
af/eJYy2NFM7bjllOWe5QO0y8IKlg1qn5ZZVsJqsA9RmabYOtg61jrCOJGkWyUdYx1knWi5YJ1mn
0ZrEqrR00rp0WJ00V5/DL20I+I0NPX5jw2DOMecIovlpc4FgNBeZ7UI//N7GAPMCcwnNg9dcKgw3
h8xhId28xPzPQoZ5hfm7wihzo7lRyDS/ZX5LeNzcbm4Xsv4fW9d1f0v8BuE8ig5d94Pg+4N/EvyT
4MeLhYQTjBHISyD/MfjVhDnGX4EvBK8++yT4mXj2CcKxkE8QA7DDz+bAfrE4ntH4Lf5vn4xLiE8W
pzEao4S7ofMav/dj8B/vRx9WQF4Kfjz48eAnqL3VcAlwIXTI5sf/SxxN2KaNaDTufgu9wkjFpzAu
L3ruYd5wBnwS7gp46ueQ+PGsFZLPgZ+CZxfB2ufQkylAI3QmQkchHAd+HPgcMQ9yH/iJsAA5cDzu
5uDuV8SvMhpL0ZM8aDI/3nAdOqofVsNaI6zxXDwh1kKuYi5wFnQk2KyHTfKG/hl+o36M0Un4kpFW
tz4GfgrwjDFEWME6Oj3wZeijn3qB0aBA82Wji3A7bD7EEt1p5nU3cHct9J+G/o/AJ8PaDWAb9G+J
/0Zyvfg24Syxld/CvO5DSBTxNOEk1hG6GHUW4F+B+xkNBmgWwc6zrK97HxZqwb+Ou9Oh/wn0s8Bf
AjYB34D+VbGcNG3GfyX+Jset3mR8i/hulutKjM2EF0SKBH0q6whXjcsJ/4tRd0mTEBpyYCcVmIZn
ZeBa4BDxE9x9nvjfM+rPgW8EHge+LBbzHJmuAuuBdcAqYAdjv6H0rgnqDELzJRP/hkoJ+CnAgRrW
AauA/OwQaB7C3V2QnIGkApIt6rwzT1gPrANWATuArF8EzaV4SlDR+BOOCvAvo+fbwTcAt2uSOmAV
sAOYT2M5aKxCFHkY8fbTwBt4dq2G9cA6YBWQLayFN37EOoaNwB+hzzeAbbDTxn3WXTUeI+wEXjW+
CgwCFwARCcZ2sjAE83UTmm3AKxouRww0cWxA0g0L3bDQDQvdiIoLuHsBkguapIHQgLE8YjyEmDkG
DAIXAE8wIhLa1BhjniKNrZ0Af5Vqeu4DSfR5GtJY9Ec4SvVpkKRBkobVncaWCd8GNiAyd9AYl6jx
CcvVwLXas7wuwoj5Ifx/4qZ3vQoMAhcA3wa2A9nmOTx7Dt44DmvHwb8M/jUN2XvN6Ocz/djaQBXV
SAO/XUXjm5jZIOaR794Af9X0NfawitwrARI60zKmQn4cM3sckt1YI6OA6chCTyK/vWTKJHwR8g+Q
izrBr+MdRPcn5LSBaj5kTV1/o5vw88hmlcAh8MZO6GRjLbwD/hlgrZYDaX/Rwb6+H6PpBM++6Qfs
DSNyqehkn5j2Mm/KZt5wGbFdizjJQfQew1N7jbv5WXEnesV3fWo+N3HmHM1Ia7MVa6oV64hXx6Pg
1+Lun7QxhtEfBc/+Avq/gJ+RYYyX2T+MlKsZ1fkaY6L9UR+D/kDwh6BfoWWPOuSBKt4dsAYVyF8G
PgR8FG85DfykXyHPZr8deC/ffZpnmVYu88kass0vazm5hvihiMkTkKQDz5oe5vlFvn0N8fwc8vYe
zqLGk4jJ46xpzETsJbGE5o5jOJnzue6YuorprEw7AublJHuY8kADYqwBq1LFt7FeGoBvYwfhXJ3K
z5I/38JTy7GCliMO+S1R7pWhiO8aitSsIlKtohuONT4NT+01fYT8wPq53FuKZJZc4pVOEf4O7yzo
eY6Wf5ZDk9+yDbgW2GR6jHnTD7FyZ/Aug5V7DncbNVRXKPOzTaNxtx2SdvSfPTzRdIJzHXr7Ku+G
un/HnpiK3n4M+a/g8+Hg0zGWC1wp6WeKbL9FNBNe5upRP4yR5ms5sgrP2iaMsYbXmuFJ7IOPMxrS
RZLofwfLr0DzBiz/B/j/AD8d9o+x5wnZsgV9DjAKu8BfAT5n7C9wXcH2v4qZyoKFFnX/5TqK6oTn
kf04wleherki+jAKjrcv4e4m9PwE3rUf1lJ5pOIf2BtG+ET8CPMb4/3dkMLWDO8wL34VfAHG24FR
fIRc8RFWYir6iWyvb+QeGiZg7A9oveWeZIDPFql21R3BqH8jUjWom4q+HcWziHZ9nljGaxxPzeYa
WD/b8BfC9eLTZHky5nGPKHF86l8hvhXWPtCQrb0GO1+GzRxRJHyfkaJuuMBVGXnA0A9++BmeCgGr
EQOXRfbeTljIBP4Ydhzgoxj7q/DzNIzRh6c+AJ4DetljVGXxKFZw1Ur8AxwV2IP8sFaCfs6GHZNx
A2cALRp5dG+iP7dMIxmNN4DvAPdDngG0cE5Qa07W1I8D5hlPYx9hvkCtQmHnBPAI7ByBnSOw80fo
K9BXWKIPQjIJEodatTIvdHFPCN8B7oc8AzzrD1QrW7xlv4qoo4pgp4if1T8L/lmVZzuE+yHPAA6H
JA3xg3oDNt+HtU5gLfB14A6Rd8DpsDkdNqfD5nTYnA6b0+Gl6WzZkMWahix4oAkWmsC/Af4NHgV5
tQb9Z/y1Ol7mqW81sFODp27AAkty0c+PNGzGyuI+zDI+gdXKs7Nc5GrzoHY64Le8LZ7CmsXpgDUF
tZK/iNp+GE4BhcDfwdow2O8CngLuwLNzgQV4di/kHwCPiRSlpgwel6mOUfSxjthi3EcrHe8yhYy8
TxXDV0F44K/QN7NXTXVY10+itycQJ+8Dq7VzymnMzmHE5GnM2ml4BvHJq4w8MIpnyjiEcDPORHpo
joDmCfCVePskNd4wFz9nicGAmTJAXgT994EfAWuBh1HJ15ou4S0s+YTnheaX+UsaYq7B71UjhyUU
CRbMoAUzTudoodLwBzpXOowPMpro3Prx73klfvx7I82y4RVUSs3sE/Ep3ndEmXnDr4D/A/JarsfE
15AVoU+1MddFX8SzVtRFpdD8LZ83xSOcpQ04Pxqe5fOyOAh3f42nfsrY72HIU2DhNnAH9J2Ikwqe
C8Mb7FvDefDTgeMZxXSeIzEDsVEF/bcQUe8yGrdBZzyiIpU1Dd/HzP4FvA93H8fdoYiWfFhQz6o7
gIV41xRUBa9hByxgjxnexw5Shdx4CLvGYa5PDFtQka7BHrQV9eFSSF5CVdMBOweArcB3gO/CzkVg
C3AR9qZ3sc/uZTT+FnwFcB+yaxf2oO9x/SaORhX3rsbXA+uAVcAOvssnL+MV+L8ImgOAT5n+iVA9
keGEaNinYR2wCsgWfgXNxXjqDZYQsmQmS4zzERXFqHUXAa3AICrDEOrPApxJUcGKoxA/b+Jd0DRU
cS4VISHkUVyG5Uc1rAfWAauAZM34OJ9JTW8hZo4YU+ipB2FtC9AFxPlUTMbYXwBfr2E9sA5Yhbs8
rhfYV+J+5vsNN/0EOJft4ylRQ/YPzgiGHewHwxRUfUs1fBUYBC4AIpa4cjP1x7x/G5oFnBuNjxqP
EP+h8beEP4H8lIZB4ALg28AnON5w9zAkhyH5Pte6hl/yCtX9M2rpEcCvARehtkzHOegp1K7ZqIrX
IKIWIWLXcB2oL4DlX4N/AafXPejbe5C/x3ZEK/p/niXiwxq+CgwCFwB5fT3GvRK/yGdY08/UmOcV
ob8Iaw8Ct6BCWIZ1lIz6YSHifzPuvqvhq8AgcAHwbeiQP8VH+C3G3/J3RULW2Yen9oFPhge64KWz
xjqshRF8V0WcWC/xiVW8zBLjfu6JWA/+Q/Ai4kSE/lLjVcyCinx6/T2fXskbHBUt4jL0jSNWAL8P
Pd+Hu2oWnQx80JhMKPB8GYeZniF+K8uNjyCS3wO+oOVSzjyNyKVrobMK+j/HivsL1tGDyKi5yMCb
wL/JGZjiip4yHsS8HIZNnF4N62DZD2ujwdfz+ZdOuHw3CM1GxqT9HOFJAk5bP4ZlfDPpp2b7f8Pp
pgor9ApW0BtYHV8G4nRseB0WfgZrgvgSPdUIO7/hvon4TiXiRExzwXuojLNwmHmy0AFsxbruALZi
tXYAW9HbXxP/Q7xxL7x0m2sAwyvITkeAIvr2Jp+RxX8BRhgN+HJiaDat5P0Oq3gt+Deg/xqe/SFW
ehVLTB7OBqZSyH8L/Tbgs8Atpi7GfvN4p4POTzly+j0MPgU4HtZuQ389+tyfdwdxMH+nEp8wpiJ+
mNdz34ztPPviYKydpep5E/Gww3iU44Tl4vvamZq/WNbhjPMU1vV03iP6FWLu3sFMfZV5U3/jQLp7
E3vWPj4RU/RyTsjnu/0KsbNs4dVE+aoB+DbyUgOQ91ALviONhvw85Och/xDyi5C/C3kxrL2Ht6gn
r6XYGVuB+/i9xjYekQnfYw27ceLeij1uI+vr/5XP15TlFsDDH6HPnJee4rO2aSBWfQdW9wFG8uQx
5Jkn0BPGFtx9EHXRg1z5UD78GGvhVWQMvlsBrNKyBz91GnnjLT53k84myDeh/8hXpheJr0efnxYf
JvyfjGI6/L8LI/0jZicGnec0TZaMwDnodzxG8SE+IxvwVdmgntrO4NR2FDn5O/BDGuZ9DM5lP0G0
DDVSLjIl4amPUCH8ks/jRp9IJwtxDXJsAM8G8Oxq8LX8Lv1X8MYSzMtrOPVLGNH3cMJtxYoQIfkh
n8rF0ejnt6B/DW9Er4yV4Jfy2dxQDl7V8cPCROC3uV6iupFX5T5xCO8L6OEHiHP1NP11RMJ0jP0J
QyONax7bMUWASxjFLeLryJy8Ir7BvHGxcTF6xf6cDR317x37kc2MfNcQ5l3MqIOdQfD/PvTwp3zu
NpwF/yGf1g1Pgp/Op3XDLzCWz3FPjFhB4nPiMJLUoP/LDB8SvmigSBCv8F95TP+CmvB5Pq3T6Lg/
D/OZ3bAKNsMasg8HAp/jc7pxH/Cf+Bxh+N88dlMKPGDBGfwCnnLyOd3wBfAHcLcT/fkzergb8v/E
3zLS2TOmTLx9MnABxlsGnKjVlryrDsNTx/jkrv8Dn9wN34N/huH7YRt6+DzQgtn5PubRyrNG0Uuo
fx2SNPRzE04xa4FTVB4nlLVYa2tx0lnLpyq6SycR42OoqA9C87vAN4wvIR8ybwZaVYQFKyxYYWE6
NDtw1hvNEnE0JKch2STSjOvwrH4kcCXOy9/EefmbOIU9hfPdT/isRJFA+noPNN/FG1NQf46BtTH8
rJgPfrmKkCxna4T7Ic8ADsfOTp4xnsDofCKdCg2bYfMp2FdHNxn4HT57Uv8xCtgcDZujMdIOjLSD
fSU+x5ZN+caTwO9yFMHCLhXhnxLwhfDDFJMNvmKcgfP7WT6/0yhs/O1LPIH32rCC/ggLN2DNxrsV
94oyD+Mr4qOE88UVJF+MjIrzMp2v+e73gWmQTBYriQ+K3LcxkCDfisMxF38B/iejoZnR2MIojgEu
52eNY/GWL8BmETAPuA3WqlRfwcKHwEx4+AWgnzNevyPsgSQH/HkT575SfKX3M9/PhF3veb5rfAwe
boZmPniZ+X5H2FqSgysTYzfOg09hXGps5GKW8zEvm8Enw8Ik6PyCvw8YnOx/MRWzsAux8QjvYoZL
PDrD6+AHga+AznngGDyVAUzGbKbws8atPOPGbZCPh+bPMMvfZ17/F0ieMk0Erud4g+Ywnk2Kk5eQ
AxmPw+YO8I+iz8nw4XdYTpo30dubWKH4S/0nPxd0guGT34F/nf+WDcz55GfgHwdW8V/Jtbs/B26F
/hLwKg4FroVcfXYn+J2wtgP4HiTvgT8DHZLrn/mEv4iOAb4EjAGnAM8AKxh1ekahE5IcoMBoUMC/
DNwOfEjj+a8Gp/HsDUjWAp/GUz8Cn4y7bcBbkOAt+lmQfAhetT8Jb+8Cvou7fwXuhzUDdIqAz0L+
vsZzH2oheR2S6eA/wVNZ4C8Bm4BvAK9C0wb+JngT+G7gUOCF7iyuDNEf6Av/xRKD6pk0YCpLdBi1
7jng7yE/B74ReBw6qvee6f46WZigzgXz+inAGuAWdRbA5wAF4MvA7d1cnR5U/c8S3S+BN3D332F5
ozo68ENUz0OnGzqPqGOBpA29ugT+hDaWr2NcSfTsEjy7lCUC/KN7EZo53Q6MYhN6vgm93YS+Ma6F
5AbwKiSPMAoqnwZMBV7EG0cB04FPAj/Au9QIXAf+T8DU7mmEs8F/HjNbqcYky/U7wWd38+n7HfB5
kCMq9P0YTYg00yJGcR8sfMweMPmZNzZjrrernvnkFf5rI/R/oMYGrK1DHz6Czl/hq2d4VdKaGor4
Z6xWZ/nj67ziMNKYhnpgOuEQ4BRgBe5WwFoFS8ifLC+APAcoaJjO+wL4lzVkTQe8fVrzfDpmoQbI
/NMsN/wIdzvx1JfRQzXCOzEi+F93Vp0RjPQ1NZ7BS9DZAy+dVLMH+0pshcfU9ZsMPg2eaYJ+U/dU
/ioFPgY7UfCvMhqwig1FiMCb8Nta3MVs6oZDfpV9qLuNPpvgvVSMKAle6makuFJ5HiN8pfsBUI3D
5zVMx7M1sMP6/4e9Lw+PotjePl2neyqZnikiBAREjGwCKgaIiIgoiAqICAEU2ZR9MSJCWEQEZCci
oqIim4BssimIgmyyhn0R2UH2fQkQAmJIJr+qt/veT/L5fNf73d+f9+Hh7dOnTp2qeuvUqZmanskO
+NyF0m+A4JOuYtQXgBOB23LyaczGGIPQLIB8L+Q4zFp9yNvR83MoLWRknTFmac3TKO0OHIfSSWAA
0c7lIXsrvbBhTJSB3lsRm4Dj4bkdPLSD570+S0b2MttWrOt1WK1nMQvIKpYN5p+AHy8Tbgeez6lo
mIS82cuBsEyBZXEvB6KVX6DH6rMHYO1sgPx7zvO6n94+MhXZZo/hyn4C8nPQp8HP75CRCUU08EFg
MW/NwmYDcLGfnR7ViJ3C2gibRd6KBiIDiDFgqRpsdgO9vIG4FdgXNKv6PQVj7Vszgd2AXq4oDfwC
2AP6ZMg1gJ0Rge9A/42/F5h4HujLhgFv72gOe+QQ0drbUzCbAfBfEPgxcAdwORD53FqA+cqBvAyY
ibo7vfmCDCatK5DbA+uBpZuQwyhdAbk2sHHkpukh9CfhczRwHnCuv369tkzkb0Dk38SKaAx8Hvo1
kCvD/n14w75jrUfrEcQGdkYLmZwLwXIFogWydRPZeC/kudA3gezlVcx+YDYiKgY4CBkGr08CReHN
y0iN0dsfciaYz5jgISfyAcar0UoFZiIPJyKTzAO2hGUm8nAIY/H2qVg/r8Yhtk1mqApNVbBXFVnl
JvRh8LDCR5N7GZa1fTQeZqF0no9x2HeSwGEc+mnyUhxKtwJ/QN36OGPMwBl+EZw0Fgl8ry1D/tM1
5umUyngmJxtny2XMU47WDoNiNj7/XY/3njihsk7b5smcVXhHhk9bRM2Aa1Y6PsHZbmSxGnK6vR/v
VfGZl3l9Tk1FKTMv5kSCy9qdTOv21+Y1hpFFmn3NRKNBTrdnkDlf0pZ02KDVEbVqGXRm40wjACxn
9zVrEx5m2fp1LzeHhyxTGmiEWonABDyfcAsYZRc2M87vGsZ4nbExshhgvuEikgxyVz4Cb9qSNhq0
inm1oNll0L5kUI/C4FT+0IwCfmqaUwWR6vlBaRODzkB4uAU8AkwBLmRznlPWoFjO5t19nHlfL25B
k9dpin6ap8hCRkO7jEyHDWp7I2809k5V+IlDrXg2z++V4rFm9nkq+jbXnGmj1kJgFWhKG3tnJWqd
8ntiSptAM4n7mGwDfTUfzXNEtu9tqmEJffvRyNYx9IeFZdDJML96A1kIYTTWSpSaJ5ArWifwxKx5
qq2+SNH4sDl1EcvFRybrimGm52K6WddGFkPFUI39hPl0Wxh762NgokF+AzafCTzrKEZrfIRHaFwA
+SGeCT9atq7DEnXFs6j7EeR88HbdRKl1FK1ninxmLQsTFU1EQfQzxsS/wKf8IqA11UUes5bFA2Yt
G3urHrCBQbphkBkeasFbY1HI5EyxAz6NfFOcNLsG5LmwrAsPEdS9D/IZ4GrLMLwIfbhgFdeW5Sxz
wqnzotZkWeZT5mwrw+wFIt7kVTEAn9qbX5a9aB0z/TFoVRcFjEYsMTuXddrsucAiwHIGtTeNdBLy
aGBe6wgsj5iVDvmw1cfsJvC5w5qmcYx1yOxHpid0Fh5umJ6ILCLzFLp91WAgFvJxyGE8ne5Cfgz6
b6HRfuwpAe3TbgqsCbxkkM8B5xl0QtBnGRQ28ENoSsOmhcHAPliWBdZFaTHIrSE3geUZaKC3UwzK
opAfQOnPwAxo0ApvgdwO8gBgfWgGAnsbtNBbUQ2lmyAfQ38CsPkYOBul6yEvgHwZ+BLwVegxIs5G
Xc/bVuAgYCfgHlgmQMa4+DZafBvyOvRnL/ACNF/DW1vUqgzLzdDfD3k+5IngZAnkXsCvgGVQa4rU
u0/gHm92jGxfAuZ4c2RkJwRNFuSnvTmC5hNvpozMLYCtgV3hraU3X6glvVmDDE4CV7xZg/084BmU
FjMoi0LzM/r2CCxHAjt7/KD1Z9DDVR4nRqP3RCN7jIFneyqwKloE29Y1lIJJsRweEHXOGGAq7CcD
dwFfBGLUthdpE9HPfrAvCQ/g3FHoA+JHlELsRcP+FGzmQH4Kll6M1QAqg1FzTN2o/Ognw+Z5eFgM
jIX+Hoy6NJjZDPvPUIo1Yu9GrRJoC9zyGG/dgcN9qAtu7RTgA/DzPWzi4R98iuqouwh6rDLHi9WO
aMtbiUW92IOfbZBhKUag1kXYfAr0IgTscTcvktHu/eBqvkHrGjTj0ZYXh48CnwA2QN2dkCvCQwXg
WeAf0A9FW20gN4QfjMtB604lWI6Cn7GQwbxAfrCnAXsCG8PGa/FXoBchy1D6BhDzwoXQ4ltAMC+h
sa+jxT7QezkNa9D2VjdWrpMHmrxAZAZGVDC8CS9TIauIq7BHXTsZ+A1wFvReboTMO6DZAPkIWkdc
MdaOSEctRJ3jrSZvRCtgE4T9BGi8eV8JfSKwMBB9ZuTMwHD49HqFqLAPAbGmbMSGhZ4H+qPWu7DP
hIyVaPcF7ocec8rg32kOPXKUjaxlIx4EsrrdHrgU9hmImQGIHy9fzQYiFzlYRzwIGi9zpqGuN6eY
d8ZMBRBL3AyItcajgYheud1gFKLCwf7lINoDYFti7AGU2rBn5Ch+HPiSaZ3IvAexp0TMp0VNgTWB
lwzyOeA8g04I+iyDwgZ+CE1p2LQwGNgHy7LAuigtBrk15CawPAMN9HaKQVkU8gMo/RmYAQ1a4S2Q
20EeAKwPzUBgb4MWeiuqoXQT5GPoTwA2HwNno3Q95AWQLwNfAr4KPUbE2ajredsKHATsBNwDywTI
GBffRotvQ16H/uwFXoDma3hri1qVYbkZ+vshz4c8EZwsgdwL+BWwDOreg7o5sHka8ico7Qq5JfQS
iLEErgAfQelIYGfgM6i1Cu0WQQ+9nmO89lRgVdTFqK1rKMWIxHLUxew7Y4CpsJ8M3AV8Eej10Jtx
b1z9gCXhAWN3FHxiHkUpxEA07E/BZg7kp2DpzXUNIGpFoTQqP/rJsHkeHhYDY1H6GWREpr0bNiXg
Gcww+s/fozQefsCMqA79IugRvY4XAx3hzYtwL1a3QQ8bMQKaiyj9FIjZEeCBuwHHw5s3j48CnwA2
QOlOyBVRqwLwLPAP6IfCZxvIDeEHPXfQilMJlqPgZyxkcCWwsuxpwJ7AxrDxWvwV6M3pMpS+AQST
XAgtvgUEexIa+zpa7AO9lw0Qvba3LhDzTh5o8gKxphjzyPAmvDWO9Siuwh517WTgN8BZ0HtZBTLv
gGYD5CNoHZHAiHCRjlqIE8eLeW9EK2AThP0EaLyZXQl9IrAwEH1mZJvAcPj0eoV5tw8BsQpszL6F
ngf6o9a7sM+EjLVj9wXuhx5zyuDfaQ49VreNSBDIhHZ74FLYIKptL5OkQfZmCrPJ4D+ACOFmQMQ8
jwYi9uR2xD/m2kE+dxCrAXAoMaIASm3YM/IDP26QDokDZE5FtuvSEt45Bo/Smlp4393enDbwVJwk
1EbpJPPdWI4zz6fxWJylCKMR56EfZfTmAQsy37YwmuYGnV0G7XLQZ6BuV5SeMxjoBrk9sBa8pXmW
aLeJf5pRgswZhXlvOAmaIf6JRzl8t86cotTB+UkmzkNicTYyF/pppq7YCU17lH4OWcBDGrAncBbG
HjIoBoCBRuaERKTi1CIBcgIvNnWNDeXgvCKff36ikY4bG6cC/CSiVk2ckFQxGiufPUHrC/hnI3Nx
BjIX5yEaI5/kmHOq+jnbTe6F3MS8txU7jWw9C7kpSmtCXgF5Pyz7Qo6CXAWla1HrAjR5PW/QnIiY
d/oPwSYvasUDW6N0r4coLQw5E6VfwkMJ6KdDXwlyWZQGIHeAPMzrg5GtA14fUNrbyJHEnJs6EkpB
s5AKaTwIeZKROQ/ey+cY5GrAdGgyIY+F5VGDzi6DtgW9AM5FaZRBKwNyGjAe9gSbUcCywMEo7Yk+
jIHcGvIstHgRNn0gb0RpEvwE4X8NcJrfc9OTztAsgWY5MAWIkXItlCpoBkSW4a+wG88rI+YkMA6e
u/h9MPrDZo64mkE6jLrzgaPhDSce4hQ0jYyNXSpinlV7CqXVIzM1Rqiu1sfAprzRiKten+F5qulD
4F5oVhjZGg19YmSBiU9jb69D6V5TqsduZicEz4nQF4TPj9D/e3IydT8Horc30LeDppbTFWM5A/1k
RF0/U8uqhLb6QC4GP/GRLHyCkGX4BKYY1K+mDB6DpghszkDOa5CfQa8SMGupaKs3PLdHD48ZDNjg
trQXITmNTdQZG5HXaMzv7+gMiVVmx5ixBArC/oyRnedgE4KmqReHYLsIWgmBmbyGMWsoRt0kYs5m
k9DDWZCDkVdMjEXMaWc+YD20ngo2noXc2lhaGagVD/kmLFPhYTTkkdDvBRtboS8FzXWUfgzNQXj7
GJqnYHnFoM44mC8vDtH/uhjLcfThGCLBi+QxZtT6XcARsIR5Bw7ATGXAPgIP5dBWFZTGI36OQV/Z
oM7vZl5q+zYGTyEGdsHzTo9/nw3T85oYyzFwVQD6MLAJLJP8drOwLrIQe+mIBM/S8FbUyDq20xHJ
xqYlcDQ0r8CyMNoqDMvtqJUKm3HAJSit56/fCnosAfR5Eca4DfoiwJ/Rn46eJcbbxRu1sdRRhFNr
RFTAZ3UqohpsGGasjvD8OfLASrC3xm/L+KmAmSrgZSrUSkOtNbCMINrjYbkIkRlr5EAxyoNIW4YZ
N/2f4K1of40Yb80xRyWAr6OHl/yMVwh7jWllq79mx+rS77y1bLzpbPk5elUBtby8ajwPxilxGrVF
XLU1e3pOAy2/jKi7ABvkAfbW0UjUrSe2IPKXYTbNGFd5uRGW/aFvBObHGNR5aRlyhckq3ozMAkah
NA6jroHxHgGOAmbBc03M19PAYsA6vo3Jcv38eTSZ7VOTM3U8LMNqmomoyMInuVmI1SzEcxbmwsi3
wNsAfxcrBI0Z9TiMtKq3iyHnpGF2lhuUiCKJXYbPwbItEHscXTVxqF8D/4YcmI4caDJMI/SzCqI0
HjG8E1GNXKQtp8LS2H8LfRIsa0F+Afpp6PleyHOhfy6yG9gVqy/dvCY3rUTG5pzAfCWa1Yo5fRHj
Kubta5G1+Lw+v+ktej4QY4mDZWIEr3lQtwgV1T4L+zOr5ex5xjMRfueNbPM9Hf+k0SAFoQ8aPZHR
RJqZp6wjTc2T8BF8HyQShFwecnnIFc1z2pEE8yy91neFfjbk18zzY+bJfC2vh5wG+ZKRzbd4dN2l
5lduoE8wTwNqP3Pw2yw38Ps2yw2a7xEQme+5R2LNtzkiseb7IJGFgSTzKzfyffMrN0bOXmHkyMDA
R+ZXbuRV4z9wyqC8AvmQ8S/PQb4N2bNpAKwIy1bAtuZ3b0zfso95fQ58AfupkL1aF9DnDOhLQB9j
UD6N0ZUDXsF4B6N0EVBC/xgsa6CtS9Bvhs8K0FQBM54mE6XNYJ+CFjeDpUxgf7ReHZYPoq6xjIcc
D7lCYCP0tyA/CD+evhR68jLkMpBfhZ99BqMkZPyST1QUSptBMwLefjK/gQMPj8FDecjlIVc035fX
9r9ALgDMj1rPos8V0OfWmOWJGOkNlKJvgRnQvAZcD8xA6d0aH5HfQv4OPldCHgmb74GfQr8I8i7I
100Pza9w6N6aOKyIz+U5OwcyeDOfpEfKZ583/cnGXJhP3rUm3ZRmrzBMeppIf2AcELXgoXz2Olii
bjZGnT0R8in4XAt5L+Q0lCKisg9AcxZ+zBM4REFreNQF4jbvdEui2A7d2r1B/ZJaJXehhaTf+TVM
rBFH+p1FTg7lpxAFqAgVp7xUjh6lx+lpqkOvUAvtowG9S+9TG+pEb1EPGubbh0nSvVSC8tEjVEl7
qU4vUBNqqVtNpL40UGeOztSVetJw/I1Br46iKJ0zSlIsxdNj9ATV0Nn5VXqNBDWk92gQtaM36G3q
RSOoAHHt+vVrUZ3El16Mo9aNEl+Io7Hwcjd+M/Q+nZtLaY/lqSo9Q8/Ti9SUXiemstSI+tFgak9J
1I16UwrqRFMcPUBmp3uSalI9epA+gL4gxWge7qfCVFr7rUiVqRo9S7XoJWpGrXS/H6LG1J+GUAd6
k7rTOzTS78Fd5FIxuofKaA8J9BQ9R7WpPjWn1uTQw/QyDaCh1JG6UDL1Mb9l2qZC9zb8MrAlsD2w
C7AnsF+bVknJPBQ4GjgOOA04H7ikTavu7XgNcCNwO3A38CDwWJs2b3blM8AMg7YAxgCLAh8CVmmb
1KmD/RywLjCxbZe33rSbAFsC2wI7A7sCewL7tu/Wqo09EDgS+DlwMnA2cBFwpXbcyt4I3A7cDTyY
1KXHm/Yx4BngJWA68BYwYtCxk95qk+QEgTHAgsCiurCbUwJYFhgPrASsCqwBrPWW8VMP2AjYFPg6
sD0wCdjtrW5tuzi9gf2Ag7safQpwNPBz4ATgVOAs4Pzueo6cRcClwDXAjcDtwL3dO3Vp7xwGngCe
A6YBM4CZ3d9s0zVAwCAwFlgUWBpYoXv3+PKBqsCawLrARsDmwLYaKwSSgMnAvsDBwJHAMRorBiYA
pwHnAhcBlwPXaUwIbAXuAu4HHgGeAl7o3qN198BV4E1glkEpgFFA1b1H1+4yFlgYGAcsBXwIWCFZ
MykrA6sBawLrAOsDXwaaV+NC557Yf+PKep3fQ0X+vyQLPxz6/0ZHZwxHZ1FJUf9rdzbuPNnSWS83
hv8mss5zLn5z+T+RLJ29/xrz/m0UmBGhvZo7nPaY/cG8SvzbeNffxnv/L4z52xiHnjKu1p/QjODP
OvUvkfVOVYAK/pvS3ZCE3p+K/VvX4lTi37qWpFL/xtXSO+m/xn/NiaV38H+Nef4WltevNpL1rj+G
ptEiWke76RRlWLYVa5WwEqyaViOrrZVsDbbGWNOsRdY6a7d1ysoQtigq6oo+IkWME7PFUrFZHBQX
RCYHuTCX5Spch5tyZ+7DKTyOZ+s1aNqK8mKW6+W6b53rfmSu+1F/urdzlQf0Mt9P0vrTfTDhzvvQ
1Dvrq5t3+o9teud9frrTf/7YXPelctnXynXfPNd9rvHkP3jnfYHSue7r57rvfWf/i0y+s/ze5Xfe
l3wo1325P93r9VcyPlf5QNwLnR/yeiN8oL53Le2N3NYxV0DnqlK+dqd/PehfT/nXq39lXTbBv1bz
r7X8a6M7e1E25c5RPljpzvtykTvtH2ly5335XLNQoUKu+4Rc9ztz3e/KdX8p133anfcV8/4pyrRQ
KTbXfaU77StVznWfu7xOrvu6ue7r3TmLj9fRqDQzbazPqL01Adm2tf5HeqWOIcuJce7CXpGXAqHa
KjVUS61Tq9QarQlYl63L2u6qdZUsK91KJ2HdsG4Qq+qqOtnqGfWM3jdNPAh+ls18CZFX5Nca8w0i
ZfrDYV2znL4voN+NdKMJlErHKNOK1X2I0r2KDTUgEaoVStRYO9RQoxldjM7JcfrdQrx+z1NVnSMW
MbpP53FNVfqdlsiv7y/imqr2ktB3+zWmqoMaN+qxmggtTMXUMd3XVbr0OK6p6oS+rtH3J3FN/ZPl
Kd/ytG95xrc861v+o78voL910d8X0d9/lNRDyUsoqf/nErUZPdyKHm5HD/9RshMlu1CyGyWCpND/
9DJzhXlyO0bEaFbza1Y59Fzoec36KrWKArpPazRTTGbHtxgnTPp/aV1/oB7VQH2bx8pD/a3C1r00
AH/PcrDV1GpOQ6wk600ajr9hmWK9bSXTB1aKlUIfWWOtL2m0dc26Rp9YN62b9Kl127pNY0xo0Gci
IAL0uQiJEH0h7hJ30VhRQBSgL8U94h4aJ4qL4jRelBFlaIKIF/VpokgWPWil6CV60Sqd/fvQavGe
6EdrxGAxmNaJYWIYrRdjxBhKFV+IL2iDmCb20UYO66jJ4gROoAjX4JqUw7W5tiV4Ik+02E62p1i2
08ZpY1Vw2jntrIpOB6eDleB0cjpZjzrdne5WJaeH08N6zOnl9LIqO78GhluPBxsGW1lXgsNcy4qE
YkLPindCzUKTxLfhtuHO4nq4f3ikyFRCRXGUul/dz3lUcVWcY1RJVZLvUg+oBzivKqPKcD71oHqQ
Y9XD6mHOrx5Rj3ABVV6V57tVgkrggqqSqsSFVGVVmQurKqoK36OqqqpcRFVT1fhe9bR6mouqGqoG
36dqqpocp2qpWny/aqlacjHzJ4W5uGqv2nMJ1VF15JLqTfUml1Jvqbf4AfW2eptLqx6qB5dRvVQv
LqveUe/wg6q/6s8PqffV+/ywGqKGcDk1XA3nR1SKSuF49aH6kMurj9RHXEF9oj7himqMGsMJ6nP1
OT+qxqqxXEmNU+P4MTVBTeDKapKaxI+ryWoyV1FT1VR+Qk1T07iqmqFm8JNqlprF1dRsNZufUnPV
XH5azVfzubpaoBZwDfW9+p6fUT+oH7imWqwW87PqJ/UTP6eWqWX8vFqpVnIttVqt5tpqrVrLddR6
tZ5fUBvUBq6rNqlN/KLaorZwPbVNbeOX1A61g+urX9Qv3ED9qn7lRLVH7eGGap/ax43UAXWAG6tD
6hC/rI6qo/yKuqwucxN1VV3lV1W6SuemKkNlcDN1U/3OzXXwtkL+ImQuy8q0MnUWy7FydPZwhH4f
gHXmYJ0FsM6kKCwKU5QoJopRtCgtSlOQa+ns5jqtndYUcto6bSnstHfak3I6Oh0pj9PN6UYxTrKT
THc5PZ2elFfFqTjKp4qpYnqNl1AlKL8qpUpRAVValaa7VVlVlgqqh9RDVEiVU+WosIpX8fid+opU
RD2qHqV71WPqMSqqHleP033qCfUExakn1ZN0v3pKPaWzlcm/xZF/S6jn1fNUUrVQLaiUaqPa0AOq
nWpHpVUH1YHKqCSVRGVVF9WFHlRdVVd6SCWrZHpY9VQ9qZzqrXrTI6qf6kfxaoAaQOXVYDWYKqhh
ahhVVCPUCEpQI9VIelSNUqOokvpYfUyPqU/Vp1RZfaY+o8fVF+oLqqK+VF/SE2q8Gq/z9UQ1kZ5U
X6mvqJqaoqbQU+pr9TU9raar6VRdzVQzqYb6Rn1Dz6g5ag7VVPPUPHpWfae+o+fUQrWQnleL1CKq
pX5UP1JttUQtoTpqqVpKL6gVagXVRf57Efmvns6d6+glnTtTqb7aqLNnA7VZZ9tEtVVn24Zqu862
jdROnWUbq106y76sduss+4raq/eMJmq/3jNeVQf1ntFUHVFHqBl+I765uqKuUAt1TV2jluq6uk6v
qRvqBs69vPdXFiUg15bRseVYLawWWt3OakeWvdheTCKQHcgmjqoWVU3n4f+d6NM58L/R99/o86Ov
MKKvrHm1ZXUKHPpvjP03xv6XYsxyOuvX8zFWMZHAz9lNqAhVoRpUhxKpqX6/0Fm/fu+jX1mm0Cc0
jqbSbFpIS2kNbaZddJBO0AVK16/syQpYoejexNHdo5Oj38G1R3QfXHtGv4trr+j39DVZS/1wTY7u
j2uP6AG49ox+H9de0YP0tYe2G4xrcvQQXHtED8W1Z/QwXHtFj9DXntouBdfk6A9w7RE9Etee0R/i
2iv6I33tpe1G45oc/TGuPaI/wbVn9Ke49oruS0KXDtTYI3q4xp7RozT2+g8Y+Qwj7x79uc/MFz4z
Y31mvvSZGeczM95nZILPyESfka98Rib7jEzxGZnqM/K1z8h0n5EZPiMzfUZm+Yx84zMyx2dkrs/I
PJ+R+T4j3/qMjNHj7x49CYxMAyOz/0NGFviMLPQZ+d5nZJHPyA8+I4t9Rpb4sfKTz8xSn5llPjPL
fWZW+Mys9Bn52Wdktc/IGp+RtT4j63xG1vuMbPAZ2egzsslnZLPPyBafke/AyI+IlFVgJPU/ZGSb
z8h2n5EdPiM7fUZ+8Rn51Wdkt8/IHp+RvT4j+3xGDviMHPQZOeTHymGfmd98Zo74zBz1mTnmM3Pc
Z+Skz8gpn5HTPiNnfEbO+oxsBSO7wMh+RMqJ/5CR8z4jF3xGLvqMXPIZuewzcsVn5KrPyDWfkXSf
kes+Izd8Rm76jPzuM3LLZ+QPn5HbPiNZPiPZPiMRP1ZyPGaC5DETtDxmgsJjJsg+M+fASBoYyQAj
mSZSzN9pNP3GaVoTKmPtEl9xXX6J23MH7sxvcHfuwb34HX6Ph/MITuEPeCR/qN8Fn+CTfIpP8xk+
y+f4PF/gi3yJL3MaX+GrfI3T+Tpn8I1wJfN3lKyd1k7dwCTz7Vx+gV8gwfW4HjG35XZkc0fuRAHu
xt0oipM5maK5J/fUrwR6c29yuS/3pRD340EU5vE8nvLxUt5GseFHw4/ilKEwBe2i9n12nH2/Xcwu
bpewS9ql7AfMyHSPbuB03Xu9UsQ/m3jQlOk63tm1xUn/tCjtWzxkzqY4SZeQHWubXwArbZcm90/1
vHZj7fx2Aftuu6BdyC5sfvtO2/6fdgWVoDx2Xjuf7dgBW9pRdrQdtF07ZIdtZeexY2xz3mXrsfXX
nTR1hP2kXY1CdnW7OildVokK8gyexXP5W17H6zmVN/BG3sSbeQtv5W1/xbg5LePpPF17nGm+18xz
eI7mez7rPKqZW6vbO8EX/+l9uraao0uX8jJezit4Jf/Mq3g1r+G1fzXH8D6DZ2jvs3iWeSKT52rv
37LOzrqH27R3Mw7jvRzF/qXXvxgHODvhc2bq/c3oQj0TDbqe00UsokE0mIbQUBpGw2mEXtcf0Ej8
ddGPaDR9rFf5pzSGPqPP6QsaS1/qNT+eJtBEmkRf0WSaojPA1zSNptMMmkmz6BudD+bQXJpH8+lb
+o4W6OzwPS2iH+hHWkxL6CedK5bRclpBK+lnWkWrdeZYS+toPaXSBtpIm3Qe2UJbaRttpx20k37R
WeVX2k17aC/to/10QOeYQ3SYfqMjdJSO0XGdcU7SKTpNZ+gsnaPzOv9cpEt0mdLoCl2lazobXacM
ukE36Xe6RX9QJt2mLMqmCOXoMLZEA5EoGopGorF4WbwimohXRVPRTDQXLURL8Zp4XbQSrUUb0Va0
E+1FB9FRdBKdxRsiSbwpuoi3RFfxtpgs9osD4qA4JA6L38QRcVQcE8fFCXFSnBKnxRlxVpwT58UF
cVFc4qC4LNLYFVfEVXFNpIvrIkPcEDfF7+KW+ENkitsiS2SLiMjRKcg8bc9ss8MBlhzF0dyAE7kh
N+Lm3IJf51b8Jr/Ng3kID+Vh/Cl/yRP4O17A3/MiXsI/8XbewTv5F97Fv/Ju3sN7eR/v5wN8kA/x
Yf6Nj/BRPsbH7Sfsqubvttq77T32Xnufvd8+YB+0D9mH7d/sI/ZR+5h93D5hn7RP2aftM/ZZ+5x9
3r5gX7Qv2ZftNPuKfdW+Zqfb1+0M+4Z90/7dvmX/YWfat+0sO9uO2DlO2Mkrq8sa8hlZUz4rn5PP
y1qytqwjX5B15YuynnxJ1pcNZKJsKBvJxvJl+YpsIl+VTWUz2Vy2kC3la/J12Uq2lm30v3b6Xwf9
r5PsLN+QSfJN2UW+JbvKt2U32V0myx6yp+wle8t3ZB/9r698T/aT/eUA+b4cKAfJwXKIHCqHyeFy
hEyRH8iR8kM5Sn4kR8uP5SfyUzlGfiY/l1/IsfJLOU6OlxPkRDlJfiUnyylyqvxaTpNz5Fw5T86X
38rv5AK5UH4vF8kf5I/mb7/Kn+RSuUwulyvkSvmzXCVXyzVyrVwn18tUuUFulJvkZrlFbpXb5Ha5
Q+6Uv8hd8le5W+6Re+U+uV8ekAflIXlY/iaPyKPymDwuT8iT8pQ8Lc/Is/KcPC8vyIvykrws0+QV
eVVek+nylvxDZsrbMktmy4jMiaIoS06XM+RMOUt+I2fL6zJD3pA35e/B3sF3gn2C7wb7Bt8L9gv2
Dw4Ivh8cGBwUHBwcEhzqvuv2dd9z+7n93QHu++5Ad5A72B3qDnOHuyPcFPcDd6T7oTvK/cgd7Y5z
x7sT3InuJPcrd7I7xZ3qfu1Oc6e7M9yZ7iz3G3e2O8ed5853v3W/cxe4C93v3UXuD+7P7ip3tbvG
Xeuuc9e7qe5md4u7zd3u7nB3ur+4u9xf3d3uHnevu9897p50T7tn3fPuRfeKe8297ma4N9yb7u/u
LfcPN9O97Wa5ETcnRCErJEIcskNOKBA6GToVOh06EzobOhc6H7oQuhi6FLocSgtdCV0NXQulh66H
MkI3QjdDv4duhf4IZYZuh7JC2aFIKCdMYSsswhy2w044EJbhqHB0OBh2w6FwOKzCecIx4bvCecP5
wrHh/OEC4bvDBcOFwoXD94SLhO8NFw3fF44L3x8uFi4eLhEuGS4VHh+eEJ4YnhT+Kjw5PCU8Nfx1
eFp4enhGeGZ4Fj59xtk+ztj7i6+EzqA4OZ/CdfT+vodf1Pv7Pm7KzegAt+TX6BB209+4K3elI3rH
e5+O8if8CZ3ksTyWTmFnP4196wz2rbPYt85h3zrPP/JiuoAd4pL9uF3FIpzACyfoBK14J8aJscrj
jL1C4HjgjHVOxssEKw3n7deDw4LjhQhOD/4s7g5uCt4SFXDq3hrn7TP0bp9O0VSQiuk9v55+BTRO
7wArdXbWTbhDSKhNkOZCMp/RxFABKuJu0Pf73I0aD7ibNB5yt/7Tdp+WVlOUfj1RkIrqVwBlvU+P
3ANG7x7SuMX9TeM296jGHe5lU1PlNx5VAeNR3f0/7X0HXBTJ9m6dnulh6GmaMOQkyQASekAQAwYQ
DCioIChiIIuKIGJcXRUFlTWtEUURMCvmHDC75pwD5hwwi6LIO12i4q5779773t773vv9f/Wjqrp7
6OlT59T3fae7p1vaI91XOd3rl2s02ri0X+CwPiCovtuiS7fo0S36320xpVvM6BZzuoUh2ug1EX3n
zUhvS2rANCAME8AEEBnTkmlJ5EwwE0xYbio3lSi4TdwmosU9557j/hh2CXPqb+LY7xn2/29+/c8w
rMShf5U3/07ONNCK1YrX6qH1EzKQxJz+yJmtKZu1Q2aaSHmyI3KkxI6fuTHuL7Li0H/Ch39kw1nI
g98YsCq7/N/Ghl/ZDnkxG/m7Kis2RfUhaY/PykPSHW1Rebyv1B0fUHV0QsWRSzXHPFQcZRi1YRip
3aS4/MKdTNL3vMnr8fq8Aa/mDXkj3pg34U15M96ct+AteSvemq/G2/C2vB1vzzvw1fkafE2+Fu/I
O/2QbTN+zLeCtsAJqr/EuoV/5F1BV9AT9P/AvgdUB1WHKAcf/SELX0AevqS6oipWXf/Cx4KxYEI5
+emfsnL5H3lZMBXMBPN/i52/42a+/D/AzkHAgBGmsuZQixhCWwgl9vSaey3oCnGkNiRAAvGAREgk
daAXJBFPSIYhxBuGwnTSDGbDXNIVNsAJEs2kMmlkGDOAGUZGMMOZkWQsM4oZQ35hxjETyGRmEjOF
TKdXz2cxMxhEe5rj58p4mQGZJzOUGZJFMmOZE1ksc5a5ke0yjawZ2UUZ/yxl/HM0ezsvL5CfII9Y
fVYfTNm37FswY9+x78CcLWPLwEKBwwWWinGKCWClmKSYCnaK6YpsqKmYrZgLtRXzFMvATVGoWA8N
FBsVv0EzxUHFSeigOK84D10VlxRXoJuiWHEdolEblEOcogK1QbqWl1YD2Kzlo9UYdigdlU6wW+ms
dIO9So1SAweUXkovOKisp6wHh6TrZ3BY2UTZBI4ofZW+cFQZoAyAY8qWypZwXNla2RpOKEOVoXBS
Ga4Mh1PKCGUEnFZ2U8bAGWWiMhEuamPaD5e4aC4GLnNxXA+4yvXk0uAGN4AbAI+RZ3PgCfLsTniD
PPsOPqkYVWdGS9VFNYSJ4ufxt5jhOhN0ZjN7P9/fgtnoSnrFpQvEV67ZWGUNkPpEUak9aqCmqYPb
F2KR6pWoChbSVloqqlwqwqViLNJdNrWhNkaNK7gi3XmDN+6zOTRHcgmEQCKHbMimd9kcJFGsOWvB
WrJWrDVbjbVhbVk71p51YKuzNdiabC3WkXVia7POrAvryrqxIqth3VkPOANn4RychwtwES7BZbgC
V6EYrsF1uAE34RbchjtwF+7BfXgAD+ERPIYncplcLnsrK5W9k72Xlck+yD7KymWfZBX/O+vkaIqc
oWca5PTXCvr03I8pFhmxxCLHkauJljoT6b40NyxKHNX6qBMbYuFIIywq0oz4E54EYhFIOBZd0olE
oD7sisWAxGJRkx5YDEk/kkaMyGAyhJiQ4VjMcHYyxBx0QY9Y4Bw1J1ZgDdbEmt4dUw3na1tig/M1
gtjSq7p2dKbaQ2/oTRzo/TLVoT8MIDVgGAzDOT0OxhFH+AXGEyeYDJOJM87g2cQFZ/AG4gq7YDdx
g9/gANHAUThKPOj5pjp05nlRTd2KnnXqSs86df96Lmxf5bkwFxwpK0bDaFAxejFe0m/DmGaoGFsx
rVAxtmfao2IMZ8IJi7onjihQ8fRCxTiWyyJKbjw3mai4Rdxiosct5QqJAXeeu0CMuUvcVWLKXedu
o5YeqvqZ2CJ7jCYOEjMQR2SGfFJbwnHihjh+nmgQvYuJJyL4deKFGH6b1EUcv0u8Mbe6T+ohlj8k
9RHPH5MGiOlP0UfS/V8NmMivthyutMUVbbH+zpZ6TD38rGSRjGmLuYycWsRSixSo7yKIFrVLieqt
L9GmdnHULh1qlwG1y5Bbya1Gi9ZyG4kFtdGG2mjH3ecekhrcY+4Z2iVZ6kot1VBLvail3sh/CzE/
WIxZRmNqtT+1ujny0lsSiKxUjpmJZFFLpmfl1VfpV46x1CI3yUZoT+c9+bqG0HOZDPSAJl/XMRAK
zrhk+PVzOAN+MBYNmYY4FtKIyKmPWTouCjouWnRclHRctFH3diEcHR0V9TpPx0iH68R1IgJm5j8T
Xcy+pqDvp3E5xBJzsI3EgdvM7SRemIk9I424F9w7EocaYgxJQrUwmQxBdVBI0pH7N5DpyPWXyFzq
+83U91uQwW+SrTQCttEI2E4joIhGwA4aATtpBOxCZn9GdiO7vyB7kOHLyV7kcwU5jhrHlJxHXWNL
rqGWcSL3UJWoSAmqC33yAjneHDMARELMkPoSImWQxFc6y0DaSfdtkRDVT7w/OY7/YwWz6F2Osm8e
IdF0XEUadW2reET85hESShp9XceQJvTqueHXzzFExs3hFuA37+IOYrS9V0nxi2tpnv35eGzpkYiV
387gt5j/O8iK/2lEcYhQHAKKQzKKQ3KKQyzFIQXFIS2KQ0qKQ9oUhziKQyqKQzzFIYHikC7FIT2K
QwYUh9QUhwwpDhlRHDKhOCT9rngPWsAzLWRbcST+2XUYBjgwwKO0Aydwh/rgC62gPR5dNPSEFBiA
2iUdxsJEmIbfmgeLoBDWwmbYAfvgMJzEsbmK4/AASuA1lCH4KxieMWBMGWvGgXHC0fUCJ7S+Fo6F
C20jkP2ktgvUo21XqE/bbtCAtt2hIW2jwIe20dCItjHQmLaxOPOkNg6a0jYemtE2EQJo2xsZVWqT
IZi2s1kTqZVvZE1pu4k1k1rhg1IltaxayUutYoFSh7ZFSoG2O5S6tC1X6tH2k1KfthVKA6lF9aKm
bWNdoN/TExwRCXSR5xlccsY6Atle0g6IB2glxiDaqMG6O7hjHQUeWEcD6gi0zRPrWPDCOg7qYh0P
vtK9H+CHdS/wx7o36gUGrWqBdQq0xLovtMI6FVpjPRvaYD0HgrDOYQ0Jg/YaYb2Jlc58fFCiY9BS
jGq0U451kRL1BtqokO5mUmph/UmpxLpCqU0YtA3Vj7IxccRZFYl82xt5digZTcaTaWQOWUAKyXqy
HXnsKDlLrmLm/wTnduX1PIwkU4x1B4wlEbygIUZTCwhChIxAu+PRimU4WrNxhJbTtgsU0rYrrKBt
N1hJ2+6wirbRsJq2MbCGtlGwlraxsI62cbCetvFKK6lFG62lFq2sRtsipQ1tdyhtaVuutKPtJ6U9
bSuUDlKLFlenbWPIpf6bRz2XRz2XTz1XQD03n/psAfXZQurFRdRzi6nnllDPLZX8oTSkI25ER9yY
jrgJHXFTOuJmdMTN6Yhb0BG3pCMORK5L6F3dMooVhM500JV+oiE9yTeI3lNfi7gjF1eeiQJjGmsm
NEZMpe+W9gJmX3s9pEiSsBfxZAaNFVpLV8hADxGKgBHmNECRiKH4InGaKRkHHSAcOkFHCIMeXEdk
n4jP54WZ/szPzFhmumy2bKlsrfBRKBc+CRWIr3O5XG4el8flcwXcfG4BYu1ubg+3l9vH7ed+4w5w
B4VSgRFkglxgBYWgJSi591wZ94H7yJVzn7gKFcKe6lfVFNVU1TTVdNUM1UxVtmqWaqNqk2qzaotq
q2qbaruqSLVDdVl1VXVNdUN1S3VHdU/1QPVI9URVonqueslr8Upem+d4Fc/zOrzA6/K1eWfehXfl
3XiR1/DuvAdfh/fkvfi6vDdfj6/PN+Ab8j58I74x34Rvyvvyfnwz3l/gBR1BEAwEtWAovBPeC2WC
hWApSNcga9Csj9BMj0XlEIic1pPpjaydhhkdzwzDjE6H3v0s0PxNl2ZlevTcq75sjWwNMVCsUqwm
asUmxSZipChVlKJuw1yFmEi5Cuqba9xd4ihlLKhmxiJ318ecfQPxw2z7EmmNGfcV0oZydxDl7mDK
3W0pd7ej3N2ecncI5e5Qyt0dKHeHUe4Op9zdUfUJWbsTr4dMHU2Zehhl6hGCETL1KLRzK4n4Kx79
9zz4t/jpi4c4OpqEjqY2HUcDOo4WdBwdqOUu1HIvank7anko1SjhnzM/lr7pD/utiHRe15dYV43/
30fxn8fj59jBPejTSCE0UmTUwwrqT4H6U5f6U4/6U5/604D6U039aUj9aUT9aUz9aUL9aUr9aUb9
aY5+MyEWlUevYoUqRy+g3qycsdKcp3FKaJwCjVOGxqms8n95VrfK/5qiKvmKAl9mOkUOOgtoJLM0
krVoJCs/Z7HwAt7Ch0o1oM8YMxaMPeMoa8nGsHFsApvI9mP7swMFW8FeqC7UFByF2oKL4CZohDqC
l+At1BcaCo2EJoKv0ExoIXQVYoV4oYeQJCQLfYX+wkBhsDBcGClkCGOFLGGCMEmYIkwTZgjZwmxh
jpAr5AkFwgJhkbBEWCYUCiuFNcI6YYOwSdgibBN2CLuFvcJ+4YBwSDgiHBNOCKeEM8I54YJwSbgi
XBeeCs+Fl8Jr4e3/3FX+P/dc/h+655Iheqj541m18AE5v/FfuqccZyL0VFytcgewUrpXpvKumn94
j8zX+2hwH4wP0/Vrzv55TSAi0Jecl4HXpBQ1uifjjZ/ww3XBTDsmjOnERDKxiFUpiHrDpGtaPyrS
dayqBffyffH+Y5GuelUt0jWyHxa/35UA6QradyX4j0W6mla1oC1/UpAPvito8/el048K8sd3BUfp
+9KVlm/Lsb8rCVh6/klJ+VFRffq+IGt9X8x+V+y+L5X2fT5euof/OTfxJ+cmgFxD/myIXN8CVXYo
fQ7Kl6efSE9CySKTyQzMfgrIErIS85+tZBf5DTOg0+Qijp9Ir/X+q7X3v1UH/zv1D89/fD47wmMz
Q8p7SFMpF0CuM6bZg3SNA8AR82gG2X469mfATOxng/T27lzMvBjYAM+kJ8DCC8xXXtJ3YLyBt9gv
hfeUMz9g/yN8wn4FI72BhGHkGHMso8C+FiM9NVXFYP7N6ND3eegxmGMzBowh9o0YY+ybSO/nQF61
wL4lY4t9OwYzN8ZBevMHcqwj9p0YJ+zXZmpj35lxJtIbTVyw78pIb+LJYXKwP4eZg/25zFzs58qa
06e4tiQyWStWLT0njkV7WXPWX3qyIducyNgWbJT0nG42Efs9pbcCI1cPxP4g6YlRbAabgf1MdheR
3nC8G/t7lIjMSgazSEZZQ7sXAe3e2qj0tJN0lhLQWaaDWa/Ocp3d2N+jsx/7v6FSBcEadYYM1WQF
zfAQlXUZ3eqff+NMPcOQ6Mpf5n7TIEA1CFANAlV+QQpUgwDVIEA1CFANAvR3H0A1CFANAlSDANUg
QDUIUA0CVIN8PkKGKhGgSgSoEgGqRIAqEaBKBKgSAapEgCoRoEoEqBIBqkSAKhGgSgSoEgGqRIAq
EaBKBKgSAapEgCoRoEoEqBIBqkSAKhGgSgSoEgGqRIAqEaBKBKgSAapEgCoRoEoEqBIBqkSAKhGg
SgSoEgGqRIAqEaBKBKgSAapEgCoRoEoEqBIBqkSAKhGgSgSoEgGqRIAqEaBKBKgSAapEgCoRoEoE
qBIBqkSAKhGgSgSoEgGqRIAqEaBKBKgSAapEgCoRoEoEqBIBqkSAKhGgSgSoEgGqRIAqEaBK5Mvz
Qb4+LcS8K7aGdC0xDxPTzdsrtJ0yW2SW6oAWk5du7oerGjMAGpWorWBrCzLGnCVilIKrrQA5pNdl
QJ4XIrYTnaussSywHmFJL+c0JMEkmvQjyQiicSQN/6TLO41E2yo7kxvWqlA3zw30nT3JKuGOamhy
nSU68Wfz0o1cxHR5npguG5snY4BhuCizo1PpYceLOl8PElg8nMH06GQd5Ao10yFEoxb1pQWlmguP
6tcjsU9CWnIfjZ4oSCu11Frt42KTkvvEaqxFS2kNpzZqkxiTmtwvOT7Nxi85NSU5NSotEf/DXrSV
tsvU5lW3x8bZhCQm9MG92rT1aypam+hoNBpRI7qLHu7unhG46CFqvi6KI0f9LcemI6qk7Sq1vE1w
2/ZfPi77k4+L6WBXdcykt0elI9zgeo5JByAlnXcM03e4nam4EV/RYoNJEXNnPe/+PLXRMNcxF4Ly
1yz2cyuNy9XcdNf4r7yw22G07QXXDaN/LvM8E2J5YWM76+Dj8Vseb+KZcsfIFUvGvD1st/7cTmX/
N1kpk2IuPMuyfjjJzyE24syYYZOTGhQOOBbuNezBdr2wwuzn47q4xv62qoZ2V+sYoxc+O40nzRrL
7BU37VZ1r6abevT8piWeBpk5+Sru3tTOE8tC5+x+ZdbNd4LBPKvGkzfVVI8yc0+3enVpzFnbtQ0L
NmoFX3BYVjLhzbpLZe/rBS9++HJVp/avrzbNcdNPiSl+dG3ZiyRbuV6Ix7a1wftvhqxtGte8T923
2x/mGDf9tZdrZ3EvI8MJMT8drHBEzEQ1jqVVdTkvcgolBjXLaslkopW0UkCxbWjRXnil77Rp17i9
+iN9zs7ouGV+SB/qQCtd6YVrcmS1EWI1adlebioajzA8ov/g8On1xh3hUF1XD2PjLa1nc9XEMOkD
1eTBYhsxMK9lXvNM/x5paSn13dxiUnu7Jn3xomtMcpJbSq9Eaa1bSmpybP+YtH5u6GQMRAxDjMBu
oreLh8bFHUPQFT8kRnw5ZgB5kNhabPVlWWQyG1V+xcCBA3/0FXGp/3Dfab+bdjIpchZ29uq9Iign
0eB2chaTkzhwb+/Y1FpjL/n4Jzmb/nS2lpv6VqeeFntUdTZllT/aMu2JluZez9f95WcWX+5aX5Gr
V75Up2hOO7/kioRpc26eGPrcYbXn0VFdSi7vSvZquSuCC3/b72buq9vK1g0auR09fawk2C6lVF6N
WRSYs3lS5FjBa1pvD63NS1e0yzu55+pEO4OivdfTL4TllxY/X2gTrqc3t6QwM61335zdz1/uSem6
+EpSm7odZ7UZ3ORknS4R1VcmPLYIClCsHu9Ybb7epIUe8+zPvdsQMOxGSUz25MBG7BK31abrOi1Y
1TRkopLVc3E6VF/R2tJ1qaZdWGzh7KOFM7Mds2ZOHvNo7kbEqK2IUQVfMIo1m0Gx1OL3GDXwb8EB
WxpoOPFNv20PTUyKcwlJi0pK+YZQYl13T3exjrumnoRQ7ohPXxbFkev+EwhVU6z+edG6j19iSo+4
VJtmIf42/iFB9ev51/V28faq4+sietRrpqku2n+2yPKHFoXEpQ5IjIn7p4h25kiDkIJ5zeYPWd4m
rG9I1sBldaf+DI3KlzPzQ5ZWnFpjt59Mvt+/T4npg5GCev/FKLKjWt6ABnId+X553pKPfiGKfLl8
i2pKNhPt/eysh0FpbZ+fnq3wD8+YbjPvQkydOdEBE3esvHEpt97bpR3KT9wfeM9T/Szywc4WU4PN
/bQ6emcNzzDs/ejQycAh6X2OnDHqrjQcN21J58b1DzW2GZbk1tF82OEs7+1799TrcdGlo7n9Uyc9
ZYTN+PSFT0/N9J+ScXRv3VHXdbKH7j+z8caskIuDlG/u2ttqRWdG9Ew0K095H1JnZGl1jVnmmF92
dZhdvqy1p1F554fTDy0PyXbs5rzwZnXd2P0vV9fs/wXRtHFE2CrgNdj+fr7Ojg7OPUwdo9MTzr+6
6eUd8R1Y2dd5d6l9QAr3tMmHAR/W1V6913Odrhj6GawQqkSEqjz/TL9/Caw+b5a8SJ2IUUmhqmMV
qEKgEltUgaqGfw2qfrjntB8huPJH6NV8z4CRnTXFyWcazno5pPfPM9VtnVkTC73NzfI3jH8ddqJo
te362KQoy4slDx6/mVLiV2DabG9Z2bMVGyOHz0wK3OD3oWbUIGXo0DXvV2Vz69P2LXvg0nbfsE/D
gvJnna9Za9PKi9fXTBplN/H4q8EfowyTdj4+Onr19fnbOrObHoW+ibbqXXNRTGDZ7fyybdczZsQl
hqze2Dc7tkZ80f4XkdHbf33tMyfQl+ic8GYNa0RcdWIDh/ec5X2xuN+sguPj2zrkLnj8pnHWoKOh
s7pUj1/QVFFrVct969tPe3KNGRX7qc3ZisCCj44jrpQ0Xt7wqcfYwzvtup+MbCBfza3PTmq4uH7w
7FNgrB+d1XQAqit2O6LXgi/o5VHDnKKX5vfo1Y3CAqc9pca4qS+dY8HMWIa+0JiJJt+t1P7qKo2L
WPvzPHb4No/bJycjSKDvEuMTY6LS4mya9k/rkZyamDaYopQoento3BGUPNwRpdwrF92lxf+mxPtn
ULM2tVOkmRi702p2dxsb31kDQno3sjiffPTIi0e9Ps001rtxvX7aKPNNbnnuTyqu7fENsj+XSq54
hnPjDq+0afn6eY/CNoETFhYNDuyb01zrcnn163P7jz2xrF+z4RdGXnlV9NJrwaFI/6urVvjcqNVj
pvnihan9wl6YTLtT7jktNe/8gG7WA/1HZXgbn+zXmd2a0H7CwrWJbpfNVJ+mpDneGuAWWmwodnp3
ekJ0+ZFD3QI0bbfUVN9pIp5IddSrZXegbpBPnrvP5GP53oqMyKCw9FpOrPumwAvBMfdPu0S/8Pe5
X6gkbwPyc091Hl8j5MGQZa1eBpyo29A7d/3AyIUmuROO6E8Ka7i7ULub7MwXqOmKIxIh6kpTTy0J
IVaUYVMFe36og1RUOEmqCTJFA4V2ZRZhBHKW7hjp4Os6RtpL+SlN0JkaWdNvZndvsESTvKjh9osu
otnXDxkyct6aIyGkP2YefqTpd+AmFKZ3bxJWc+bd6uqPTje5kOmd7iwQ234Gt5Zic9E/zy+vaWbj
vw5uXzenYmhLqESBLbQKsLUQA8RmVYDN+18BNmnC+H3e6x/VFwOkU71Gw2sErHqc3GSN+4aejwW3
Pktalj7u1v9p6wYuF/xWqD4deeiimW9/dGjb7BG2XQp93FpvLVgSNud2yrbN698N3tAytbTRo6bD
D9/kTRKPLJxj41Kmarsv7JjL7Vant6fcX6JTIFsYdmNzVmD4y+m+c168elZyO7NanYabw2Y/D7HP
cFqQbjn11jQtq5e3gt6Nzz/8QL3w16CDFqcnpU536puUY/7O8nnI+YSjdhWRVscKxhfVXDs4JqxZ
Qbtj7x/O7xhWnMP4N3Pr9vryyrPp7n0+LpiuvvM48f7SAucdB2vrCXETZ115U1BmUEM7znvaiyHV
Wm07dTPswclBM0wjD3kadyueatVyosuOFXWaWZboGZmTLsWenW2PZx/QLskQxgcnCeogn6GOLeak
nnrV+/DuJynzw6eED5s2Ic+ihSyi9MT8BC5toddTFzeTg/dS6xq8Tl7TMCH9ffu1EzyM46yFrGK9
a7Gvk48HnD1j8nDwPvn6Mx+cr1fLyi3kPqhrNllx5/3NpcMDtml1bx7XvUnQat8nQU/XDRh8kauj
nWQ5QlPtlhBafDf/w93meitisyvaGrsO3cnaDrk1vWnNxL1TJ00/NOFiju1Kncg5zwtWZvYYxfd0
2TagF7GaseKl8U9vjUc5bBl7oueS5hq32Vdv9/W5QH6Obn7q+NhDm03LhNQJu+f7rGKa9KxIzJlx
S2+J3vq6bZXn9/qI6QotxO9nX/DbuEcdit+W/w38FuuKdUREbE8PUVKZKDKlRQ9RWvzvyd9/ht7z
8nuvuX6lxRSnob1czW4W3bq9f1Y7+7YrjhebBjnolpxafKr1ijTRRv+x1rnQ6UYtp1n4TlmZHSnW
uEx6Pfip6Mk4Ld1SQY6p7NFqRzwcxsx9+TrB0vnjT/fHWj26HzQ/f7d9yOEJZf4ntE92XXVyta+8
4P2i3lMTLtS6GhCyOvPk3VoBrjULM4M7tOfvyJw/9Jw8Wewz5lUncW7Zz+dnrntgO/Pnd6fVr5Sb
QpLar/efPK8FadU8Xr+mY/ySmXfOKEa2Kng/erF+c0Pt9Hmjn3YY9AlmW7VVZhA9MeDppmv2Adv2
uYTOW2U9qKlm4NGc6w1GTc2PYjZY6az5WJqzFo7bBYZWvGf37rFRfUHv5Tgii/8Rev9QGH6H3npV
0Vt6D7U4Mvsz+I6cLI6c8GP4zY9ZEPW3h2e63uAVxvmt8hauaN2v42sttWvc/zOo/5ekLI613sys
vZGyZl7FD9evGHjl+OB2bWCNa1rfzkm8evnxHT9N2ux61qBgfFL05nDmSJCNuu2s4iFNboVvW9Vx
tuVNK8gs3Dbo5S8nnzSAkls7JnHswQktbj0PMSoOXj7lzv0JPc+N2H1v2kuFW4bs4a9ODnYpH95+
vDNolqtOqdatlO2mQXMn9uJSp2/OrzcnwWV/O+FRdGRj4+xfbBrf0jJ3f39U02qAxqd2qurgoxSf
igxOfX0PFzXx+YXNJo+Dfhm+37N21/k7H28fpvL96WxIqm2JeHjboLjIzmDCGQqnLxtmv2m4Jb7j
Ohe3++8zMo+2C3swN2Va78J6rc++HbxzmemQaMdnBTmOdRQDzaMP+VgnVUt/rjrgvO2E37q7758M
23B7wZI0z81B+/vaG9QYoGrYfnzfiAA/w+3r1q1uk3Bwnm/FiMG2I3KNxPgHvgZdzQ/m2tme9HtY
++G21y2OOp+96D6idQ2nFg7dIh6FPVt0bdbcw/WTi0bWTFPolwyw3ZmTvrtm6MY1PX3G5Q+IWt8n
X71o57Lmzw2Sy7Pce6/9dL3dwfH2h+KL5lqNMYhlfFxWdZq0+Y7t3Q2rD8esHxTKnm3q2rZw2uqF
g5avy5vR3/zSlDHq/nZu7kuUffI6j6++M+/Z6MO25x9bBx+aXdLyRinEJY9TDTuYePBen0eLZx7X
OFYI+ztHXmxjkX+xzC23sWsH416H1PPLNenymWK6fCoDII4c81/Uy9+dqP12mjdv5D5JpVWGrbZM
w1c9h4zf+21JpRHEqluNJA345R/lGsQiOFvqEtaKe9vkdMb+/fq5lp2zc7aLsVX+hdeEiaF5TiNq
kTYkkcSQVJJMT0PHkzRiQ0LJYJKCSwm4Pgp7Pcjg/BojHP50jqYNTklOSI1K6THY5ndcIk8Hoi69
4+8cs3Hd+vVscbRd2ZUR2qpuA9Uzf2oetbL3cK3RimP9rriV3e5z41nGxi2LnjXz3mo6lnvzYWm3
Ca9Cjw3skVPL28Ng+ZxlT3XeVrs7LpZ7YjZidZPTtXw81pq+unVsaubKFc2WL73Vx3OtukincOaW
0+EDbafMbey8aceeQ+SN9Zrtl66U7K4jj2k6Pv7A82q7P/iOvrMqsr3uw10R+05l/Jp/y/qg96yS
c2Lx5NBBCetWMR3uNVr+qV9Z01mdkx/HCEP6PFKXGhl1fNMm5Uw780fGSz7tb5I+S6f/swd9r80w
LTM68o558Uvm+EXhG1vPfhPftXHXXYxLyfPwvJg6dyadq9snpfTs/tajvfLTGSsxnaniXIUmneFw
lYIGY8Z/jfy/Ox+nVRmKeV1E06pxqPp2wQPwG79uYTW60qky0VNTF3NSLw8UMb8Pw1KNlcfCMdNs
dlVbWuehVnjS07o7T/wOm6UA8d9wNf7S+6cDLlpZxPf07dV69wEb4dDF0dd6vVssW/zoQGPnLXu2
qad0uXp11RGLRvNnegY+mTxhUJfznrcfX6i5vcgpQryRwS379CF+86pBL5Qd88Y2zcyyc98askF1
cN3K05MOBm63T8ktni9rsfqctd9Qm3uXjWZsbaksHhzvZBFy706rhH5jso8v2hndfd3lRne1r678
lDZHprNk6k8D2HeBd1a+vfTmxoyK/o9ezVifV+TQDW6vPDzkxOBjq37LrnDIOma/lIiBYvaTQ2k7
/QNOh5trhdW2eNzeZ9gvqnrz+y0Mbrk0q89F34xhosvHKX5PegrRZlvfjO9Q49CleqlXSjw0k3W1
Yrte6HeEkP8F21sVvw0KZW5kc3RyZWFtDQplbmRvYmoNCjEwNiAwIG9iag0KWyAwWyA1MDddICAz
WyAyMjZdICA4NDJbIDMyNl0gIDg2MlsgNDE4XSAgODY3WyA0MThdIF0gDQplbmRvYmoNCjEwNyAw
IG9iag0KPDwvVHlwZS9YUmVmL1NpemUgMTA3L1dbIDEgNCAyXSAvUm9vdCAxIDAgUi9JbmZvIDIx
IDAgUi9JRFs8QTQ4ODZGQ0ZGQjUxMEM0NTk1MDA5MTAwNDgwOTE4NkI+PEE0ODg2RkNGRkI1MTBD
NDU5NTAwOTEwMDQ4MDkxODZCPl0gL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMjY4Pj4NCnN0
cmVhbQ0KeJw10jlSAlEQgOGeGRjFfYABxFEQ3MAFNxDccBflBBqZGhgbaWrpIYy9gaFVHsAL6AGM
rTKGN/1rB++r7urX9apei5jodCxzeiIhd/CuWC+K86BEKko0p7gZxbuBbyXuwjNQTHwqySu4V3ym
+NdK6lJJt5Xsl4htHhHICZxCC1z4azkzF4LYf2aDBVFwIALL0APnEINeqMAS9EMfZGEQBmAYhsCD
EUhAHHxIQhpSMAoZCGAMijAB45CHHBRgEqZhCuZgFmagDCVYhAWYh2NYgTaswSocwSFUYR12YQNq
0IA6bMEm7MA27EETDmDffHj+Rxel0AixHt+Up98Qu3QLr0pZO52LD5EukmAo7Q0KZW5kc3RyZWFt
DQplbmRvYmoNCnhyZWYNCjAgMTA4DQowMDAwMDAwMDIyIDY1NTM1IGYNCjAwMDAwMDAwMTcgMDAw
MDAgbg0KMDAwMDAwMDEyNSAwMDAwMCBuDQowMDAwMDAwMTk0IDAwMDAwIG4NCjAwMDAwMDA0MjQg
MDAwMDAgbg0KMDAwMDAwMDkwMyAwMDAwMCBuDQowMDAwMDAxMDcxIDAwMDAwIG4NCjAwMDAwMDEz
MTEgMDAwMDAgbg0KMDAwMDAwMTU2MCAwMDAwMCBuDQowMDAwMDA0NDYxIDAwMDAwIG4NCjAwMDAw
MDQ1ODQgMDAwMDAgbg0KMDAwMDAwNDYxNCAwMDAwMCBuDQowMDAwMDA0NzY2IDAwMDAwIG4NCjAw
MDAwMDQ4NDAgMDAwMDAgbg0KMDAwMDAwNTA4MyAwMDAwMCBuDQowMDAwMDA1MjE2IDAwMDAwIG4N
CjAwMDAwMDUyNDYgMDAwMDAgbg0KMDAwMDAwNTQwNyAwMDAwMCBuDQowMDAwMDA1NDgxIDAwMDAw
IG4NCjAwMDAwMDU3MjIgMDAwMDAgbg0KMDAwMDAwNTk2MyAwMDAwMCBuDQowMDAwMDA2ODc2IDAw
MDAwIG4NCjAwMDAwMDAwMjMgNjU1MzUgZg0KMDAwMDAwMDAyNCA2NTUzNSBmDQowMDAwMDAwMDI1
IDY1NTM1IGYNCjAwMDAwMDAwMjYgNjU1MzUgZg0KMDAwMDAwMDAyNyA2NTUzNSBmDQowMDAwMDAw
MDI4IDY1NTM1IGYNCjAwMDAwMDAwMjkgNjU1MzUgZg0KMDAwMDAwMDAzMCA2NTUzNSBmDQowMDAw
MDAwMDMxIDY1NTM1IGYNCjAwMDAwMDAwMzIgNjU1MzUgZg0KMDAwMDAwMDAzMyA2NTUzNSBmDQow
MDAwMDAwMDM0IDY1NTM1IGYNCjAwMDAwMDAwMzUgNjU1MzUgZg0KMDAwMDAwMDAzNiA2NTUzNSBm
DQowMDAwMDAwMDM3IDY1NTM1IGYNCjAwMDAwMDAwMzggNjU1MzUgZg0KMDAwMDAwMDAzOSA2NTUz
NSBmDQowMDAwMDAwMDQwIDY1NTM1IGYNCjAwMDAwMDAwNDEgNjU1MzUgZg0KMDAwMDAwMDA0MiA2
NTUzNSBmDQowMDAwMDAwMDQzIDY1NTM1IGYNCjAwMDAwMDAwNDQgNjU1MzUgZg0KMDAwMDAwMDA0
NSA2NTUzNSBmDQowMDAwMDAwMDQ2IDY1NTM1IGYNCjAwMDAwMDAwNDcgNjU1MzUgZg0KMDAwMDAw
MDA0OCA2NTUzNSBmDQowMDAwMDAwMDQ5IDY1NTM1IGYNCjAwMDAwMDAwNTAgNjU1MzUgZg0KMDAw
MDAwMDA1MSA2NTUzNSBmDQowMDAwMDAwMDUyIDY1NTM1IGYNCjAwMDAwMDAwNTMgNjU1MzUgZg0K
MDAwMDAwMDA1NCA2NTUzNSBmDQowMDAwMDAwMDU1IDY1NTM1IGYNCjAwMDAwMDAwNTYgNjU1MzUg
Zg0KMDAwMDAwMDA1NyA2NTUzNSBmDQowMDAwMDAwMDU4IDY1NTM1IGYNCjAwMDAwMDAwNTkgNjU1
MzUgZg0KMDAwMDAwMDA2MCA2NTUzNSBmDQowMDAwMDAwMDYxIDY1NTM1IGYNCjAwMDAwMDAwNjIg
NjU1MzUgZg0KMDAwMDAwMDA2MyA2NTUzNSBmDQowMDAwMDAwMDY0IDY1NTM1IGYNCjAwMDAwMDAw
NjUgNjU1MzUgZg0KMDAwMDAwMDA2NiA2NTUzNSBmDQowMDAwMDAwMDY3IDY1NTM1IGYNCjAwMDAw
MDAwNjggNjU1MzUgZg0KMDAwMDAwMDA2OSA2NTUzNSBmDQowMDAwMDAwMDcwIDY1NTM1IGYNCjAw
MDAwMDAwNzEgNjU1MzUgZg0KMDAwMDAwMDA3MiA2NTUzNSBmDQowMDAwMDAwMDczIDY1NTM1IGYN
CjAwMDAwMDAwNzQgNjU1MzUgZg0KMDAwMDAwMDA3NSA2NTUzNSBmDQowMDAwMDAwMDc2IDY1NTM1
IGYNCjAwMDAwMDAwNzcgNjU1MzUgZg0KMDAwMDAwMDA3OCA2NTUzNSBmDQowMDAwMDAwMDc5IDY1
NTM1IGYNCjAwMDAwMDAwODAgNjU1MzUgZg0KMDAwMDAwMDA4MSA2NTUzNSBmDQowMDAwMDAwMDgy
IDY1NTM1IGYNCjAwMDAwMDAwODMgNjU1MzUgZg0KMDAwMDAwMDA4NCA2NTUzNSBmDQowMDAwMDAw
MDg1IDY1NTM1IGYNCjAwMDAwMDAwODYgNjU1MzUgZg0KMDAwMDAwMDA4NyA2NTUzNSBmDQowMDAw
MDAwMDg4IDY1NTM1IGYNCjAwMDAwMDAwODkgNjU1MzUgZg0KMDAwMDAwMDA5MCA2NTUzNSBmDQow
MDAwMDAwMDkxIDY1NTM1IGYNCjAwMDAwMDAwOTIgNjU1MzUgZg0KMDAwMDAwMDA5MyA2NTUzNSBm
DQowMDAwMDAwMDk0IDY1NTM1IGYNCjAwMDAwMDAwOTUgNjU1MzUgZg0KMDAwMDAwMDA5NiA2NTUz
NSBmDQowMDAwMDAwMDk3IDY1NTM1IGYNCjAwMDAwMDAwOTggNjU1MzUgZg0KMDAwMDAwMDAwMCA2
NTUzNSBmDQowMDAwMDA4NDM0IDAwMDAwIG4NCjAwMDAwMDg3NjEgMDAwMDAgbg0KMDAwMDEwMDc5
OSAwMDAwMCBuDQowMDAwMTAxMTA5IDAwMDAwIG4NCjAwMDAxNDE2ODcgMDAwMDAgbg0KMDAwMDE0
MTc1MSAwMDAwMCBuDQowMDAwMTQyMDY2IDAwMDAwIG4NCjAwMDAyMTk1OTggMDAwMDAgbg0KMDAw
MDIxOTY3MyAwMDAwMCBuDQp0cmFpbGVyDQo8PC9TaXplIDEwOC9Sb290IDEgMCBSL0luZm8gMjEg
MCBSL0lEWzxBNDg4NkZDRkZCNTEwQzQ1OTUwMDkxMDA0ODA5MTg2Qj48QTQ4ODZGQ0ZGQjUxMEM0
NTk1MDA5MTAwNDgwOTE4NkI+XSA+Pg0Kc3RhcnR4cmVmDQoyMjAxNDQNCiUlRU9GDQp4cmVmDQow
IDANCnRyYWlsZXINCjw8L1NpemUgMTA4L1Jvb3QgMSAwIFIvSW5mbyAyMSAwIFIvSURbPEE0ODg2
RkNGRkI1MTBDNDU5NTAwOTEwMDQ4MDkxODZCPjxBNDg4NkZDRkZCNTEwQzQ1OTUwMDkxMDA0ODA5
MTg2Qj5dIC9QcmV2IDIyMDE0NC9YUmVmU3RtIDIxOTY3Mz4+DQpzdGFydHhyZWYNCjIyMjQ2NA0K
JSVFT0Y=
--=_26b367778be52644a5405fb55c73545d--


From nobody Wed Jul 20 02:04:47 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F392C12D9CE for ; Wed, 20 Jul 2016 02:04:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhZMzwWLj9f6 for ; Wed, 20 Jul 2016 02:04:38 -0700 (PDT)
Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66FF612DAE5 for ; Wed, 20 Jul 2016 02:04:36 -0700 (PDT)
Received: by mail-wm0-x233.google.com with SMTP id o80so58555241wme.1 for ; Wed, 20 Jul 2016 02:04:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to;  bh=cevz2flcLiJvivwZiH5I0/9dFQpphL2qybXoL1FUQUI=; b=K7wZYbt2RDU33+1aEas47VWaqHyvQmc8LaTbNCZrLba85jENwP3Ut45JbT50mIXmss kjVUmiQDXL8YouyS4hKb6OmUZ3uDvJa57dI12d5Nt4umX2ZlYjgii9o+nYtJc2yeEh4J ljC2xJw+1cSYqWVFIGBwULValcgr7CJzxiN9ZATFwyEO/HlFF8yf7coyVp4SN+sQZtSD nL1vgzttzAofHwqorF2drOyexeoyEADXCExsx2bxbA/yGf7RT6xoS6qXpIWhBFv27XLi dvGaRjA/oVd4oDOo0sDAfosIW+AAxoaM/or7e/z6+n/ZZZeNcnR9Gv156T7VJu3lU/ig 4akw==
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; bh=cevz2flcLiJvivwZiH5I0/9dFQpphL2qybXoL1FUQUI=; b=gNZqCOanJDBDOV1iNvD/6yNldDjXthcQTJP7sVtZTcvM12ce2AuVmUJa0uHR0Lj4+j P3VCxcgB57ev3v1GRg4szjKuvf+jiQnyjNQZqtKQGGpIcVC+2wXQ+WERwpznF9Y5pnnz I6qt/gG5spDcWXxHFCr4OPyTvvCe3Kxkx0I2mEP4BoweczZQyh2HDYf2Kfh6aHE75b5H O5dUCNUnoTjzfmueIR5BjaTJzjIlBngOI2kYmqZfrRZh97GaX1GY4uvhjbvcjTmTIwcP XErLhaRzx2ltYN/19DjgtrhQHpG2Uk2PYFFQKjgfFvbdrbVSimVpm/j1aTej/pGwBduF 0YRA==
X-Gm-Message-State: ALyK8tIu0DQKdCzAVF7Pz+bsl0899mLPFFtMOLyEavX382d2iSS6VMsCCVzM4E3LcZEZGOqOgDO6h3csER1hNw==
X-Received: by 10.28.203.138 with SMTP id b132mr2499392wmg.24.1469005474745; Wed, 20 Jul 2016 02:04:34 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Nat Sakimura 
Date: Wed, 20 Jul 2016 09:04:25 +0000
Message-ID: 
To: torsten@lodderstedt.net, OAuth WG 
Content-Type: multipart/alternative; boundary=94eb2c1302367ed5e705380d7df8
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Security BCP (topics)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jul 2016 09:04:46 -0000

--94eb2c1302367ed5e705380d7df8
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Thanks Torsten,

I just wrote a blog about my thoughts around these as well.

See: https://nat.sakimura.org/2016/07/20/fixing-oauth/

We could use this as well.

Best,

Nat

2016=E5=B9=B47=E6=9C=8820=E6=97=A5(=E6=B0=B4) 17:46 :

> Hi all,
>
> I tried to capture the ideas we discussed yesterday regarding a BCP on
> OAuth security in a slide deck. If you like, we can use the deck as a
> basis for our discussion in the session today.
>
> best regards,
> Torsten._______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
--=20

Nat Sakimura

Chairman of the Board, OpenID Foundation

--94eb2c1302367ed5e705380d7df8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Thanks Torsten,=C2=A0

I just wrote a bl=
og about my thoughts around these as well.=C2=A0


=
We could use this as well.=C2=A0

Best,=C2=A0
=


Nat

2016=E5=B9=B47=E6=9C=8820=E6=97=A5(=E6=B0=B4) 17:46 <torsten@lodderstedt.net>:
=

Hi all,



I tried to capture the ideas we discussed yesterday regarding a BCP on

OAuth security in a slide deck. If you like, we can use the deck as a

basis for our discussion in the session today.



best regards,

Torsten._______________________________________________

OAuth mailing list

OAuth@ietf.org

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


-- 
Nat Sakimura


Chairman of the Board, OpenID Foundation




--94eb2c1302367ed5e705380d7df8--


From nobody Wed Jul 20 06:37:14 2016
Return-Path: 
X-Original-To: oauth@ietf.org
Delivered-To: oauth@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5006412D66B; Wed, 20 Jul 2016 06:37:09 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.29.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160720133709.1408.52567.idtracker@ietfa.amsl.com>
Date: Wed, 20 Jul 2016 06:37:09 -0700
Archived-At: 
Cc: oauth@ietf.org
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-native-apps-03.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jul 2016 13:37:09 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol of the IETF.

        Title           : OAuth 2.0 for Native Apps
        Authors         : William Denniss
                          John Bradley
	Filename        : draft-ietf-oauth-native-apps-03.txt
	Pages           : 17
	Date            : 2016-07-20

Abstract:
   OAuth 2.0 authorization requests from native apps should only be made
   through external user-agents, primarily the system browser.  This
   specification details the security and usability reasons why this is
   the case, and how native apps and authorization servers can implement
   this best practice.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-native-apps/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-oauth-native-apps-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-native-apps-03


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Wed Jul 20 06:42:35 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28C7912D741; Wed, 20 Jul 2016 06:42:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Level: 
X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=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=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfTH1gxIm-zV; Wed, 20 Jul 2016 06:42:27 -0700 (PDT)
Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d: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 C71BE12D757; Wed, 20 Jul 2016 06:42:26 -0700 (PDT)
Received: by mail-qk0-x232.google.com with SMTP id x1so45160932qkb.3; Wed, 20 Jul 2016 06:42:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sApaTkldr+m4xWw8Qk2Oyu7JLwuZWaYg7wenbYSgeU4=; b=eShXYfOZaYEDRf8a9I1zdBxGyDmiTVQ8GLin3EtrWiCfu/GHAtse7vlXL5+SA6kKVh omU6BrBqP1Z1KSiNhG7zza+DqAvKJ1BOk0VboFcE8dsSSrhE4lv3ee1tcSZh8BId59IO Zm4YV1IOoZE/qCF1cJhUArBPT1Ry5ygmbO0R98wzDCsNoSZHFmxnxhi85t/ll9wOTmUk 7Vf+Ibfxiczt5Iw6DW4Q2SqqrL9ADjANwDSc66VyB+rhxfOdwk3q3hYhWuDepE0Uyt6r m0IlUbqM8zedFwrHzHSxwxJo0KVVEoFsujulfHrCMVnY29DIlRFI3OB/c1Ll/9IJKfuw DWNw==
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=sApaTkldr+m4xWw8Qk2Oyu7JLwuZWaYg7wenbYSgeU4=; b=LooVWZT37jWvySNWU5rqTm0yRN/vEqqkOT+cD9MQoIiTRkjU5/VpDYTO8nlEs2m8+a 4Vk62qkspKVAgFPzk/8H0CqzmqDXeTB3TqhEAIr9KH28DXTO/N5BDdESYeHqEmnWdTwX wM+WeoeiJvnwjpdrJhWu3SNFKpILyST+N6fD5KbAuFYu6vKdbqbf6hak//LE9zZq57c5 wa0gHv+bd/n3ZufVbBjeMLBiy4OwNi4IUSWJuz9XAP7Sfz5mdkH9/dESq53uEGxWzMSz o6GB4EVYPP9wYQBql2E3N1QC62BoJUzg0VwxDaSQT4QIEhq5C/SuRLh5CT63Zx/7YMEl lOFA==
X-Gm-Message-State: ALyK8tLd66H9W/dodScWIASTOBCBe9ogFFwYuAqyrE9qzum6Ok0rCHdJRNprPsw6GvSCCr0Nk1PcVFXpx6MtdA==
X-Received: by 10.55.159.87 with SMTP id i84mr64347894qke.115.1469022145600; Wed, 20 Jul 2016 06:42:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.34.107 with HTTP; Wed, 20 Jul 2016 06:42:24 -0700 (PDT)
In-Reply-To: <20160720133709.1408.52567.idtracker@ietfa.amsl.com>
References: <20160720133709.1408.52567.idtracker@ietfa.amsl.com>
From: waxmiguel 
Date: Wed, 20 Jul 2016 21:42:24 +0800
Message-ID: 
To: internet-drafts@ietf.org
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: oauth@ietf.org, i-d-announce@ietf.org
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-native-apps-03.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jul 2016 13:42:32 -0000

cheers

On 20/07/2016, internet-drafts@ietf.org  wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Web Authorization Protocol of the IETF.
>
>         Title           : OAuth 2.0 for Native Apps
>         Authors         : William Denniss
>                           John Bradley
> 	Filename        : draft-ietf-oauth-native-apps-03.txt
> 	Pages           : 17
> 	Date            : 2016-07-20
>
> Abstract:
>    OAuth 2.0 authorization requests from native apps should only be made
>    through external user-agents, primarily the system browser.  This
>    specification details the security and usability reasons why this is
>    the case, and how native apps and authorization servers can implement
>    this best practice.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-native-apps/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-oauth-native-apps-03
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-native-apps-03
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>


-- 
waxmigs2902@gmail.com
waxmiguel@mail.ru
waxmiguel@bitrix24.com
0xC840F256B0F0FF9069E918d060063057AAaA6b36


From nobody Wed Jul 20 10:59:42 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41B4512D090 for ; Wed, 20 Jul 2016 10:59:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.889
X-Spam-Level: 
X-Spam-Status: No, score=-103.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 vjKYnSwx9Chs for ; Wed, 20 Jul 2016 10:59:38 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AA5A12D943 for ; Wed, 20 Jul 2016 10:59:38 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 12CB5B80324; Wed, 20 Jul 2016 10:59:38 -0700 (PDT)
To: dick.hardt@gmail.com, stephen.farrell@cs.tcd.ie, Kathleen.Moriarty.ietf@gmail.com, Hannes.Tschofenig@gmx.net, derek@ihtfp.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System 
Message-Id: <20160720175938.12CB5B80324@rfc-editor.org>
Date: Wed, 20 Jul 2016 10:59:38 -0700 (PDT)
Archived-At: 
Cc: rfc-editor@rfc-editor.org, clark@epic.com, oauth@ietf.org
Subject: [OAUTH-WG] [Technical Errata Reported] RFC6749 (4745)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jul 2016 17:59:40 -0000

The following errata report has been submitted for RFC6749,
"The OAuth 2.0 Authorization Framework".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6749&eid=4745

--------------------------------------
Type: Technical
Reported by: Clark Downum 

Section: 5.2

Original Text
-------------
error
         REQUIRED.  A single ASCII [USASCII] error code from the
         following:

         invalid_request
               The request is missing a required parameter, includes an
               unsupported parameter value (other than grant type),
               repeats a parameter, includes multiple credentials,
               utilizes more than one mechanism for authenticating the
               client, or is otherwise malformed.

         invalid_client
               Client authentication failed (e.g., unknown client, no
               client authentication included, or unsupported
               authentication method).  The authorization server MAY
               return an HTTP 401 (Unauthorized) status code to indicate
               which HTTP authentication schemes are supported.  If the
               client attempted to authenticate via the "Authorization"
               request header field, the authorization server MUST
               respond with an HTTP 401 (Unauthorized) status code and
               include the "WWW-Authenticate" response header field
               matching the authentication scheme used by the client.

         invalid_grant
               The provided authorization grant (e.g., authorization
               code, resource owner credentials) or refresh token is
               invalid, expired, revoked, does not match the redirection
               URI used in the authorization request, or was issued to
               another client.

         unauthorized_client
               The authenticated client is not authorized to use this
               authorization grant type.

         unsupported_grant_type
               The authorization grant type is not supported by the
               authorization server.

         invalid_scope
               The requested scope is invalid, unknown, malformed, or
               exceeds the scope granted by the resource owner.

         Values for the "error" parameter MUST NOT include characters
         outside the set %x20-21 / %x23-5B / %x5D-7E.

Corrected Text
--------------
error
         REQUIRED.  A single ASCII [USASCII] error code from the
         following:

         invalid_request
               The request is missing a required parameter, includes an
               unsupported parameter value (other than grant type),
               repeats a parameter, includes multiple credentials,
               utilizes more than one mechanism for authenticating the
               client, or is otherwise malformed.

         invalid_client
               Client authentication failed (e.g., unknown client, no
               client authentication included, or unsupported
               authentication method).  The authorization server MAY
               return an HTTP 401 (Unauthorized) status code to indicate
               which HTTP authentication schemes are supported.  If the
               client attempted to authenticate via the "Authorization"
               request header field, the authorization server MUST
               respond with an HTTP 401 (Unauthorized) status code and
               include the "WWW-Authenticate" response header field
               matching the authentication scheme used by the client.

         invalid_grant
               The provided authorization grant (e.g., authorization
               code, resource owner credentials) or refresh token is
               invalid, expired, revoked, does not match the redirection
               URI used in the authorization request, or was issued to
               another client.

         unauthorized_client
               The authenticated client is not authorized to use this
               authorization grant type.

         unsupported_grant_type
               The authorization grant type is not supported by the
               authorization server.

         invalid_scope
               The requested scope is invalid, unknown, malformed, or
               exceeds the scope granted by the resource owner.

         server_error
               The authorization server encountered an unexpected
               condition that prevented it from fulfilling the request.
               (This error code is needed because a 500 Internal Server
               Error HTTP status code cannot be returned to the client
               via an HTTP redirect.)

         temporarily_unavailable
               The authorization server is currently unable to handle
               the request due to a temporary overloading or maintenance
               of the server.  (This error code is needed because a 503
               Service Unavailable HTTP status code cannot be returned
               to the client via an HTTP redirect.)

         Values for the "error" parameter MUST NOT include characters
         outside the set %x20-21 / %x23-5B / %x5D-7E.

Notes
-----
This is simply adding the server_error and temporarily_unavailable errors in other responses responses to the access token response for non-implicit grant types.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6749 (draft-ietf-oauth-v2-31)
--------------------------------------
Title               : The OAuth 2.0 Authorization Framework
Publication Date    : October 2012
Author(s)           : D. Hardt, Ed.
Category            : PROPOSED STANDARD
Source              : Web Authorization Protocol
Area                : Security
Stream              : IETF
Verifying Party     : IESG


From nobody Wed Jul 20 11:01:13 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2867612D971 for ; Wed, 20 Jul 2016 11:01:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.507
X-Spam-Level: 
X-Spam-Status: No, score=-5.507 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.287, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCXVOIi6H1PK for ; Wed, 20 Jul 2016 11:01:09 -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 E184A12D090 for ; Wed, 20 Jul 2016 11:01:08 -0700 (PDT)
X-AuditID: 12074422-367ff70000002648-bb-578fbc63c223
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 0D.0B.09800.36CBF875; Wed, 20 Jul 2016 14:01:07 -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 u6KI16NL018012 for ; Wed, 20 Jul 2016 14:01:07 -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 u6KI159B019794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 20 Jul 2016 14:01:06 -0400
To: oauth@ietf.org
References: <20160720175938.12CB5B80324@rfc-editor.org>
From: Justin Richer 
Message-ID: 
Date: Wed, 20 Jul 2016 14:00:58 -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: <20160720175938.12CB5B80324@rfc-editor.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKIsWRmVeSWpSXmKPExsUixG6nrpu8pz/c4MhlVYuTb1+xOTB6LFny kymAMYrLJiU1J7MstUjfLoEr4/2hXcwFN8wqPm/7zdzAeEKli5GTQ0LAROL+hheMXYxcHEIC bUwS9z7eYAZJCAkcY5T4sTQDIvGRSWLPo8esIAlhASeJfTsvsYDYIgJCEs939jFBNJhLvJ66 ng3EZhNQlZi+pgUszitgJbFnyiKwXhag+OS1TUA2B4eoQIzE+r4EiBJBiZMzn4CN5BSwkNj4 +DJYK7OArcSdubuZIWx5ie1v5zBPYOSfhaRlFpKyWUjKFjAyr2KUTcmt0s1NzMwpTk3WLU5O zMtLLdI11cvNLNFLTSndxAgOPRelHYwT/3kdYhTgYFTi4U1Y2R8uxJpYVlyZe4hRkoNJSZRX VbQ3XIgvKT+lMiOxOCO+qDQntfgQowQHs5II79ZdQOW8KYmVValF+TApaQ4WJXHe7d/aw4UE 0hNLUrNTUwtSi2CyMhwcShK8JruBGgWLUtNTK9Iyc0oQ0kwcnCDDeYCGW4HU8BYXJOYWZ6ZD 5E8xKkqJ8xqDJARAEhmleXC9oNSQ8Paw6StGcaBXhHkLQKp4gGkFrvsV0GAmoMFzBMAGlyQi pKQaGBk2fvbR/s/+fPPThoZPSy4aLAjnbPGWOlZ7f33Cr3f6jnmfrRa5SziIz7C3OLNqTdOD 0/k7wtxVKryiv/BPPJ+W+uqQ6X+PzUG/eXpYk7ZFvZ/q11nQL31YQKW2o+Om2nOfxsYvWTXS TWWXmHqMph3W2ZB7yCSu8kOsvv8FozzbtSbrBJ+oKrEUZyQaajEXFScCAO+baLHoAgAA
Archived-At: 
Subject: Re: [OAUTH-WG] [Technical Errata Reported] RFC6749 (4745)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jul 2016 18:01:12 -0000

But they're not needed for non-implicit grant types because you've got 
actual HTTP error codes for those things, then.

I don't think this is a valid errata.

  -- Justin


On 7/20/2016 1:59 PM, RFC Errata System wrote:
> The following errata report has been submitted for RFC6749,
> "The OAuth 2.0 Authorization Framework".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=6749&eid=4745
>
> --------------------------------------
> Type: Technical
> Reported by: Clark Downum 
>
> Section: 5.2
>
> Original Text
> -------------
> error
>           REQUIRED.  A single ASCII [USASCII] error code from the
>           following:
>
>           invalid_request
>                 The request is missing a required parameter, includes an
>                 unsupported parameter value (other than grant type),
>                 repeats a parameter, includes multiple credentials,
>                 utilizes more than one mechanism for authenticating the
>                 client, or is otherwise malformed.
>
>           invalid_client
>                 Client authentication failed (e.g., unknown client, no
>                 client authentication included, or unsupported
>                 authentication method).  The authorization server MAY
>                 return an HTTP 401 (Unauthorized) status code to indicate
>                 which HTTP authentication schemes are supported.  If the
>                 client attempted to authenticate via the "Authorization"
>                 request header field, the authorization server MUST
>                 respond with an HTTP 401 (Unauthorized) status code and
>                 include the "WWW-Authenticate" response header field
>                 matching the authentication scheme used by the client.
>
>           invalid_grant
>                 The provided authorization grant (e.g., authorization
>                 code, resource owner credentials) or refresh token is
>                 invalid, expired, revoked, does not match the redirection
>                 URI used in the authorization request, or was issued to
>                 another client.
>
>           unauthorized_client
>                 The authenticated client is not authorized to use this
>                 authorization grant type.
>
>           unsupported_grant_type
>                 The authorization grant type is not supported by the
>                 authorization server.
>
>           invalid_scope
>                 The requested scope is invalid, unknown, malformed, or
>                 exceeds the scope granted by the resource owner.
>
>           Values for the "error" parameter MUST NOT include characters
>           outside the set %x20-21 / %x23-5B / %x5D-7E.
>
> Corrected Text
> --------------
> error
>           REQUIRED.  A single ASCII [USASCII] error code from the
>           following:
>
>           invalid_request
>                 The request is missing a required parameter, includes an
>                 unsupported parameter value (other than grant type),
>                 repeats a parameter, includes multiple credentials,
>                 utilizes more than one mechanism for authenticating the
>                 client, or is otherwise malformed.
>
>           invalid_client
>                 Client authentication failed (e.g., unknown client, no
>                 client authentication included, or unsupported
>                 authentication method).  The authorization server MAY
>                 return an HTTP 401 (Unauthorized) status code to indicate
>                 which HTTP authentication schemes are supported.  If the
>                 client attempted to authenticate via the "Authorization"
>                 request header field, the authorization server MUST
>                 respond with an HTTP 401 (Unauthorized) status code and
>                 include the "WWW-Authenticate" response header field
>                 matching the authentication scheme used by the client.
>
>           invalid_grant
>                 The provided authorization grant (e.g., authorization
>                 code, resource owner credentials) or refresh token is
>                 invalid, expired, revoked, does not match the redirection
>                 URI used in the authorization request, or was issued to
>                 another client.
>
>           unauthorized_client
>                 The authenticated client is not authorized to use this
>                 authorization grant type.
>
>           unsupported_grant_type
>                 The authorization grant type is not supported by the
>                 authorization server.
>
>           invalid_scope
>                 The requested scope is invalid, unknown, malformed, or
>                 exceeds the scope granted by the resource owner.
>
>           server_error
>                 The authorization server encountered an unexpected
>                 condition that prevented it from fulfilling the request.
>                 (This error code is needed because a 500 Internal Server
>                 Error HTTP status code cannot be returned to the client
>                 via an HTTP redirect.)
>
>           temporarily_unavailable
>                 The authorization server is currently unable to handle
>                 the request due to a temporary overloading or maintenance
>                 of the server.  (This error code is needed because a 503
>                 Service Unavailable HTTP status code cannot be returned
>                 to the client via an HTTP redirect.)
>
>           Values for the "error" parameter MUST NOT include characters
>           outside the set %x20-21 / %x23-5B / %x5D-7E.
>
> Notes
> -----
> This is simply adding the server_error and temporarily_unavailable errors in other responses responses to the access token response for non-implicit grant types.
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC6749 (draft-ietf-oauth-v2-31)
> --------------------------------------
> Title               : The OAuth 2.0 Authorization Framework
> Publication Date    : October 2012
> Author(s)           : D. Hardt, Ed.
> Category            : PROPOSED STANDARD
> Source              : Web Authorization Protocol
> Area                : Security
> Stream              : IETF
> Verifying Party     : IESG
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Wed Jul 20 11:49:59 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8510C12D140 for ; Wed, 20 Jul 2016 11:49:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.888
X-Spam-Level: 
X-Spam-Status: No, score=-3.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.287, 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 kTGo6ciIusla for ; Wed, 20 Jul 2016 11:49:55 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A03E12B00C for ; Wed, 20 Jul 2016 11:49:55 -0700 (PDT)
Received: from [192.168.10.131] ([62.156.144.218]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MMoU7-1bQEkJ1TJP-008dQC; Wed, 20 Jul 2016 20:49:52 +0200
To: torsten@lodderstedt.net, OAuth WG 
References: 
From: Hannes Tschofenig 
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
Message-ID: <578FC7D6.4050702@gmx.net>
Date: Wed, 20 Jul 2016 20:49:58 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="jgACrPabh1QTVhMq1NLuS3WNVQU90aoxe"
X-Provags-ID: V03:K0:M8bfK6yYscToorN5o0oC78eB3J4odZSO/kCi8mLbkA7SnU2i/BG /wAllkmIuQF+RsHpIVktdJjlmPgBK71NYL53lRHd1AheVHHzDOivSuaxl13S+xqyGXWK6cD VKchFFs8vUUefPnC8DW4tUHBjUy12vESdDVjSBIDEdFxkDCQiz5SV78gpeMKvcBKN18TJtb dLAYASLhPOGC0s5Kc0gfw==
X-UI-Out-Filterresults: notjunk:1;V01:K0:UMl/UeV55J4=:yzg5OzgH6XBCdmYTKgiqQi TaCBYHT4Ys4/6aYvzuqqic/qK46Fb827axOk/0iLbaEN0DQZPb19sulvxnUTfPuRDEJM+Q4QN q+Hgl82MJYyotVmPbM9ISmpUO07zJmsPCRrvqpzA0WeDWMnFiz3Wq+4GnXWYXWaD/2I1oFO2U JUF1Z75JRg1zSMhfvUAYyxwKSCEbJq2aAao4Onvp180ffR+FxWDDbuDv53ByZH8IVsh3lqbeg 2K6LnD9UKiZ1vSC1oPvezw/Gp/Ev9CJojUl5m7zkJH+NgcdtJYOkFiihbGeUfceMTxHavy6xe vuVV3Np2wRb60JwPKcmscCbnTPsAnaFqO9fJ73KvIiU1Z5O1l2741+Ob5J5z5YU7Vc087CORb jtHlGeNrWl8DAY24VRK0QQUK2zlhTVnyQoQC6ac5m6FCCea8jInLFBcC0NG6xfRBHCfGwL6E2 F493NZa4B/Rsu1YwoL/Ju+q1gKdL0sI3Z/K/jbPOtjUb9TguQFZ7ANWS38VQ39eBeTKt43bMf 6u/jQ/uutEa95FSTDlwny3GDdi/tY7iESskqlM9YsmsiuBP7fmZHNoh5YS+jqDwc/h8PdIzVb PAqsSmA9kxL2VJNtFlhixjIKEKVEFjxgBSvvzvf8XkyXlL+fHPyNcExGYJsjNKbJiikgGEKYc rtSnB+5ZDqFbW++O8HwwR+lHnnaEXnsJa3wlVeOYp66A69WgC+K9mgOwjZiieU1SHZJ3GHt3C sKIBDibQTQ1p/hwbo0BjJPIOSIsxN055vOAT1hpQlnCu6P6Prdxg0E1Y/24=
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Security BCP (topics)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jul 2016 18:49:57 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--jgACrPabh1QTVhMq1NLuS3WNVQU90aoxe
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Thanks for the input, Torsten.

Sorry that I missed your slide deck.

On 07/20/2016 10:45 AM, torsten@lodderstedt.net wrote:
> Hi all,
>=20
> I tried to capture the ideas we discussed yesterday regarding a BCP on
> OAuth security in a slide deck. If you like, we can use the deck as a
> basis for our discussion in the session today.
>=20
> best regards,
> Torsten.
>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>=20


--jgACrPabh1QTVhMq1NLuS3WNVQU90aoxe
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJXj8fWAAoJEGhJURNOOiAt5i0H/Ao7QHeP4Vwhje88EQwNbxxu
WwkOtpoTp66OKj1SUouAMlINfwYGYFHK/26PmhvgBmPfnH9j7Um/xT5CIQ8jaVZp
8R68XO0sW7f/mdrEqYUrpzLIblsRG+Emhpc+AQd6Xlu4+3nle2vMRotEcENe9Gr5
YvSEnezpjVgiXdREkgyi18N5FlWxQ4WvZfxjWvyVTNuETA3PzjsqNr2D/Yl7Tb+L
ZMpKbV08TDCfGPx992XRvy0CVkRXbsJh0pOLNxAMc/S3zCOckXuXZiLyuFuOcdH+
aKS0pFkdtMaRBFck+56ciiE6FghvoU2RN3WSa6GtjnHo2tNHmRLdY6NSRXCrXuc=
=SNwH
-----END PGP SIGNATURE-----

--jgACrPabh1QTVhMq1NLuS3WNVQU90aoxe--


From nobody Thu Jul 21 01:05:46 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E656312DB5D for ; Thu, 21 Jul 2016 01:05:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.888
X-Spam-Level: 
X-Spam-Status: No, score=-3.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.287, 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 DcxFOA5z01zs for ; Thu, 21 Jul 2016 01:05:38 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1537012DB52 for ; Thu, 21 Jul 2016 01:05:37 -0700 (PDT)
Received: from [192.168.10.131] ([31.133.155.135]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MF4iR-1bXcyi1jZL-00GGw7 for ; Thu, 21 Jul 2016 10:05:35 +0200
To: "oauth@ietf.org" 
From: Hannes Tschofenig 
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
Message-ID: <57908256.7090107@gmx.net>
Date: Thu, 21 Jul 2016 10:05:42 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="UVxQIPML3QJldW0JWJeuiKmtf63c8kblC"
X-Provags-ID: V03:K0:c2AB30tQ1dVRnjSqHL6dBRp7C7lqZ+1ibBqpr8VW4vl9Ulan3ns S7gc1h2zep433GhzdT9+zDg+snd8JzS8Lca0RWPXjVxPWxQyKQzOo6r5ka3JbuzQx8KjE+d maYjIi9szhski3BwVFHP8TfS6aWeIMqe111aFFk0Clb3/QuGi+kjk4AY4JdM8Yon3Hv0gpD +DIxm9B8qRksf3eYQCpbg==
X-UI-Out-Filterresults: notjunk:1;V01:K0:kKESb8/3qNw=:tSM27wYt0TCFH6YWFk82Jb 7BZVCSFBLD5KuBxHpveLK2a9M7rm+MSTf+5pVzSYYkZ/FkV1xaDELIrj0RrrqXOZS8Qa2hBYO HPmDvitezC98d0xW1g81Mn6KQn4vWOQakPPCJ77Jyi2h0ENW+c9ZccKh9ibol85KPcjaFqt4H hAPrp+M760D3fRCSqLN53SJ88JZFSSvKWP+ufePtOs8Y97Xhj2CjMf98UwfoIlC0QAql76e99 NjiysWf/JEId9RG8mhby8BNDZ6yC43jguB3OPRMUgsAOacFAn42PkuxLde4S2GLPUOTEmKcQP ExXn+mB321aFs3+NPuIbN856zQNPc58p5b2Xoil+z5B+6BMRtI/5Y9ZTD6+JK3eX5zxaJz8z5 BOe4S268HrIo26LuSOdmgBZS64zgz4dTJuf6V4i6NKgUJvh01dK/FDlAPH0GiWz4JAzbMeu9V Z1W4VPMM3TmXurUfFV3LAhvM0gQHR6V4bZ+1rXZ5aPj2tCIeVpVaiiX14WwbPaWn4SdfDCPkz yv9EPdnB60Egdi3f51E6h2eV6Rp6ZgfEncBwHVOzTwP/ooqOMaJSx/+e1MovemBHhjj8a9Y9R mHHyOjFRUVRAnE2/rTbhQXKlYhvlv+pmuLGLFPFjFcpz1WeRBC77LeNLorFPZC9qA33+7tryo iM+zYIK0Bl7tWubggqFgN4shX+Su/OTNPPT3DSGugUIrCrJKl3BwE2yFagIKZOi/gQ4n1DHVZ I1V1BWyT5H8K2WgFFwxinG+3FUDcWrAKxqXwsi0QJYJf5V7VgUrGQOZoV8s=
Archived-At: 
Subject: [OAUTH-WG] Working Group Last Call on "OAuth 2.0 for Native Apps"
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jul 2016 08:05:45 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--UVxQIPML3QJldW0JWJeuiKmtf63c8kblC
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi all,

William has submitted an update, as promised during the OAuth WG session
on Monday. Hence, we will start a Last Call for comments on the "OAuth
2.0 for Native Apps"  specification.

The document can be found here:
https://tools.ietf.org/html/draft-ietf-oauth-native-apps-03

Please have your comments in no later than August 8th.

Ciao
Hannes & Derek



--UVxQIPML3QJldW0JWJeuiKmtf63c8kblC
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJXkIJWAAoJEGhJURNOOiAt0s0H/12FDCAssJ5vaTdN5PMI9R0m
Q9C+6UmYBPgGsTEH0rZpTpWBveGckUHhiODTcFujpf7U3xpvHNr5yrJ0bgfdpMYA
UQpW0E26IEEG+Tm9mxSsIg//Fmd0QTD7/ATAv51u1kjg/pUqtpBLAUHIJ8XUpFSg
CcSYp0wXQPmlt9b39nrv9TmTftFFDlTrzZO6QoN+O3oL22kDd9Ha8WZ0v3WvA/CP
5alcV1PfZBkiud+tcp4x1nFbwVb57ccTSf7TfDyI8epvKl6o6SPypwk2riNep1tw
raXij+iA4H2KKwgcMV8a+3s+vUadXw49a6lM+PgRmAK4lJceXf+jl1lUhSy188w=
=ujX2
-----END PGP SIGNATURE-----

--UVxQIPML3QJldW0JWJeuiKmtf63c8kblC--


From nobody Thu Jul 21 05:57:10 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0FE12DB8C; Thu, 21 Jul 2016 05:57:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.622
X-Spam-Level: 
X-Spam-Status: No, score=-2.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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
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 ihTDvzcTJzf8; Thu, 21 Jul 2016 05:57:00 -0700 (PDT)
Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.104]) (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 B067212DBA1; Thu, 21 Jul 2016 05:56:55 -0700 (PDT)
Received: from [80.67.16.121] (helo=webmail.df.eu) by smtprelay06.ispgateway.de with esmtpa (Exim 4.84) (envelope-from ) id 1bQDX3-0001CA-EO; Thu, 21 Jul 2016 14:56:53 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Date: Thu, 21 Jul 2016 14:56:53 +0200
From: torsten@lodderstedt.net
To: internet-drafts@ietf.org
In-Reply-To: <20160718085803.12429.32081.idtracker@ietfa.amsl.com>
References: <20160718085803.12429.32081.idtracker@ietfa.amsl.com>
Message-ID: 
X-Sender: torsten@lodderstedt.net
User-Agent: Roundcube Webmail
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-device-flow-03.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jul 2016 12:57:08 -0000

Hi William,

one question regarding your document: Why does the introduction point 
out?

"Note that this device flow does not utilize the client secret."

What is the reason for this exclusion? In my opinion, this flow can be 
used by web-based confidential clients as well as native clients 
utilizing dynamic registration.

Moreover, section 3.4 states
"If the client was issued client credentials (or assigned other
   authentication requirements), the client MUST authenticate with the
   authorization server as described in Section 3.2.1 of [RFC6749]."

best regards,
Torsten.

Am 18.07.2016 10:58, schrieb internet-drafts@ietf.org:
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Web Authorization Protocol of the 
> IETF.
> 
>         Title           : OAuth 2.0 Device Flow
>         Authors         : William Denniss
>                           Stein Myrseth
>                           John Bradley
>                           Michael B. Jones
>                           Hannes Tschofenig
> 	Filename        : draft-ietf-oauth-device-flow-03.txt
> 	Pages           : 10
> 	Date            : 2016-07-18
> 
> Abstract:
>    The device flow is suitable for OAuth 2.0 clients executing on
>    devices that do not have an easy data-entry method (e.g., game
>    consoles, TVs, picture frames, and media hubs), but where the end-
>    user has separate access to a user-agent on another computer or
>    device (e.g., desktop computer, a laptop, a smart phone, or a
>    tablet).
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-oauth-device-flow-03
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-device-flow-03
> 
> 
> Please note that it may take a couple of minutes from the time of 
> submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Thu Jul 21 06:04:19 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA37712DA81 for ; Thu, 21 Jul 2016 06:04:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.987
X-Spam-Level: 
X-Spam-Status: No, score=-3.987 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.287, 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 mkNPd7Nnfwc2 for ; Thu, 21 Jul 2016 06:04:10 -0700 (PDT)
Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::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 A998912D12B for ; Thu, 21 Jul 2016 06:03:54 -0700 (PDT)
Received: by mail-yw0-x22e.google.com with SMTP id z8so51728102ywa.1 for ; Thu, 21 Jul 2016 06:03:54 -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=OhmyyetIRgllRqINzthSB9IcjorrVPT41m5iQOnsYkA=; b=Zzl9jqWXhWtaBaJy7and5HfvNoouENuBkq4RfGZ5stJ3ZwKjwLce1wtIDBL63XV7N7 zE28HlTMomovWeiFsE4IzHnoBDT2A/y8H00KmWr6HgxLE2+RvYHx6+jdFntRgV5CktCi Gl/+NDABKwiS6OnofSvZYqiOUbHP08WO2Aa3fa4PuF4oT9E9DOw9Awe0b5ARjT1S8ACh Jb4/biJoIXp83Xnfo0YBIfNuX2hIIB5MBg1XDnL6x9+TjjncdlcwPH6scJvBwvouxh/F XhB3cfo3qinXqcPAf7foztGiYLsLFQ9ELjILugQjI8qiNgGWGaM+nP23A43QZIo3NaRE ZDgg==
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=OhmyyetIRgllRqINzthSB9IcjorrVPT41m5iQOnsYkA=; b=N7ucWISagLMeuMirROkZiIV782luxWM7gGAor/0mD+ywJpf3AV0JbWT0MMCzRGVACL itbNVT08suV0AvkXxuWR1o1+xyzZ3Wbp0XWD9w31JSFkdQWuE/61VWwKABhB4FnmHg/h 6Nk+by8XQbFytI1yOH4GmRccXdBb1L0Px4J+OnlXG9txjE2lxm6iNSoj8wMv49CaDELF C/Whj3fiRvWuEarYYHZYPErj1p28S8UsJ8DB/wbs85cL/HV83rVZ4hhXVt0U7BMWt8PJ 1tvzJZDczDMuGeQx3Zfz9TCByHnJIOom33bmAW9sXR+vdLxKE42kRPqMQb2QbW9vMqGo KSIg==
X-Gm-Message-State: ALyK8tJi2UskunkJ+F/TbH2Fu+5y+r6kyOT1AJdg5mrL/7d89N50ITsE50Uvvvu5V9Wok/nkAnR+gcSuyt2N8u2e
X-Received: by 10.13.249.196 with SMTP id j187mr37588460ywf.17.1469106233836;  Thu, 21 Jul 2016 06:03:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.13.222.199 with HTTP; Thu, 21 Jul 2016 06:03:34 -0700 (PDT)
In-Reply-To: <578CE7F4.4080600@gmx.net>
References: <578CE7F4.4080600@gmx.net>
From: William Denniss 
Date: Thu, 21 Jul 2016 15:03:34 +0200
Message-ID: 
To: Hannes Tschofenig 
Content-Type: multipart/alternative; boundary=94eb2c08267434f7b1053824f3ac
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Working Group Last Call on "Authentication Method Reference Values"
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jul 2016 13:04:18 -0000

--94eb2c08267434f7b1053824f3ac
Content-Type: text/plain; charset=UTF-8

I'm glad to see this document in working group last call.  The amr values
my team is using in our implementation are included.

I have reviewed the 01 version of this draft, and I believe is ready to
become an RFC.

I have only two minor editorial comments:

1.
Where we reference the claim in Connect (amr draft section 2), we should
also state the specific section, i.e. "is defined by Section 2.0 of the
OpenID Connect Core 1.0 specification".

2.
I found the juxtaposition of the amr claim definition and the values a
little confusing, as the former is re-stating an existing definition while
the latter is new material provided by this spec. I'm glad to see the claim
definition in this draft, as it helps to provide context, but I might
restructure into two sections, as below (green text added/changed).  If
restructured in this way, section 2 would provide the background and
section 3 would provide the new material, making it easier to reference
from other documents.

---

2 .
Authentication Method Reference Claim

   The "amr" (Authentication Methods References) claim is defined by
*section 2.0 of the*
   OpenID Connect Core 1.0 specification [OpenID.Core
]
as follows:

   amr
      OPTIONAL.  Authentication Methods References.  JSON array of
      strings that are identifiers for authentication methods used in
      the authentication.  For instance, values might indicate that both
      password and OTP authentication methods were used.  The definition
      of particular values to be used in the "amr" Claim is beyond the
      scope of this specification.  Parties using this claim will need
      to agree upon the meanings of the values used, which may be
      context-specific.  The "amr" value is an array of case sensitive
      strings.
*   O**penID Connect does not specify any particular
   Authentication Method Reference values to be used in the "amr" claim.*

*   This specification establishes a registry for these values and
defines a starting list.*

   3.  Authentication Method Reference Values


   The following is a list of Authentication Method Reference values
   defined by this specification:


On Mon, Jul 18, 2016 at 4:30 PM, Hannes Tschofenig <
hannes.tschofenig@gmx.net> wrote:

> Hi all,
>
> this is a Last Call for comments on the "Authentication Method Reference
> Values" specification.
>
> The document can be found here:
> https://tools.ietf.org/html/draft-ietf-oauth-amr-values-01
>
> Please have your comments in no later than August 1st.
>
> Ciao
> Hannes & Derek
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

--94eb2c08267434f7b1053824f3ac
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I'm glad to see this document in working group last ca=
ll.=C2=A0 The amr values my team is using in our implementation are include=
d.

I have reviewed the 01 version of this draft, an=
d I believe is ready to become an RFC.

I hav=
e only two minor editorial comments:

1.
=

Where we reference the claim in Connect (amr draft section 2), we shou=
ld also state the specific section, i.e. "is defined by Section 2.0 of=
 the OpenID Connect Core 1.0 specification".

2.
I found the juxtaposition of the amr claim definition an=
d the values a little confusing, as the former is re-stating an existing de=
finition while the latter is new material provided by this spec. I'm gl=
ad to see the claim definition in this draft, as it helps to provide contex=
t, but I might restructure into two sections, as below (green text added/ch=
anged).=C2=A0 If restructured in this way, section 2 would provide the back=
ground and section 3 would provide the new material, making it easier to re=
ference from other documents.

---

2.  Authentication Method Reference Claim


   The "amr" (Authentication Methods References) claim is defined=
 by section 2.0 of the
   OpenID Connect Core 1.0 specification [OpenID.Core] as follows:

   amr
      OPTIONAL.  Authentication Methods References.  JSON array of
      strings that are identifiers for authentication methods used in
      the authentication.  For instance, values might indicate that both
      password and OTP authentication methods were used.  The definition
      of particular values to be used in the "amr" Claim is beyon=
d the
      scope of this specification.  Parties using this claim will need
      to agree upon the meanings of the values used, which may be
      context-specific.  The "amr" value is an array of case sens=
itive
      strings.

   OpenID Connect does not specify any particul=
ar
   Authentication Method Reference values to be used in the "amr"=
 claim.
   This=
 specification establishes a registry for these values and defines a starti=
ng list.
   
3.  Authentication=
 Method Reference Values


   The following is a list of Authent=
ication Method Reference values
   defined by this specification:

On Mon, Jul 18, 2016 at 4:30 PM, Hannes T=
schofenig <hannes.tschofenig@gmx.net> wrote:
Hi all,



this is a Last Call for comments on the "Authentication Method Referen=
ce

Values" specification.



The document can be found here:

https://tools.ietf.org/html/draft-ietf-oa=
uth-amr-values-01



Please have your comments in no later than August 1st.



Ciao

Hannes & Derek








_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





--94eb2c08267434f7b1053824f3ac--


From nobody Thu Jul 21 06:47:48 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F085E12D0AB for ; Thu, 21 Jul 2016 06:47:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.507
X-Spam-Level: 
X-Spam-Status: No, score=-5.507 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.287, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XS86UCpZIQ6V for ; Thu, 21 Jul 2016 06:47:45 -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 2904A12D0F5 for ; Thu, 21 Jul 2016 06:47:44 -0700 (PDT)
X-AuditID: 12074424-a13ff7000000434d-5b-5790d27e2f3e
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 7B.BA.17229.E72D0975; Thu, 21 Jul 2016 09:47:43 -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 u6LDlgQv007191; Thu, 21 Jul 2016 09:47:42 -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 u6LDle7D003298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 21 Jul 2016 09:47:42 -0400
To: torsten@lodderstedt.net
References: <20160718085803.12429.32081.idtracker@ietfa.amsl.com> 
From: Justin Richer 
Message-ID: 
Date: Thu, 21 Jul 2016 09:47:33 -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: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNIsWRmVeSWpSXmKPExsUixG6nolt/aUK4wb5/RhYn375is3h17CmL A5PHkiU/mTyO9fSzBjBFcdmkpOZklqUW6dslcGUs6ZnGWnBetGLF3CXMDYz7BLoYOTkkBEwk DixrYgexhQTamCTe3VLvYuQCsjcySrw7/o0FwrnDJPHhZCMjSJWwgLvEzkmLmEBsEQFpielf DzFCdJdJdJ1rZgGxmQWEJD5cagKz2QRUJaavaQGr5xWwknh17ATYNhag+NsXW4B6OThEBWIk 1vclQJQISpyc+QSslVPAXmL7tX/sECNtJe7M3c0MYctLbH87h3kCo8AsJC2zkJTNQlK2gJF5 FaNsSm6Vbm5iZk5xarJucXJiXl5qka65Xm5miV5qSukmRnCYuqjsYOzu8T7EKMDBqMTDm7Cy P1yINbGsuDL3EKMkB5OSKO/byRPChfiS8lMqMxKLM+KLSnNSiw8xSnAwK4nwml4AyvGmJFZW pRblw6SkOViUxHm3f2sPFxJITyxJzU5NLUgtgsnKcHAoSfAmXwRqFCxKTU+tSMvMKUFIM3Fw ggznARr+GWx4cUFibnFmOkT+FKOilDhvIEizAEgiozQPrheURhLeHjZ9xSgO9IowbwtIFQ8w BcF1vwIazAQ0eI5AP8jgkkSElFQDo4PljMzpYVbZbkZ1McKCaZlGG0zXaSptn3Z9yj5JZpd8 l8VCLJrh/tPMBOyWFCw/lK2Wn5duWZj451nUrJ2aAdvPSyzb92Z31495HZedy//eyjdY9fhx fm1VyMFXbRLXP9+svL16Ce/Bo+KnpuTnbl8ccfZ5wIe7KTysud/Xy/b+iVzHINvrpMRSnJFo qMVcVJwIABYpKUT+AgAA
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-device-flow-03.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jul 2016 13:47:48 -0000

+1 to Torsten's comment, there's no good reason that I can see to limit 
this to public clients.

  -- Justin


On 7/21/2016 8:56 AM, torsten@lodderstedt.net wrote:
> Hi William,
>
> one question regarding your document: Why does the introduction point 
> out?
>
> "Note that this device flow does not utilize the client secret."
>
> What is the reason for this exclusion? In my opinion, this flow can be 
> used by web-based confidential clients as well as native clients 
> utilizing dynamic registration.
>
> Moreover, section 3.4 states
> "If the client was issued client credentials (or assigned other
>   authentication requirements), the client MUST authenticate with the
>   authorization server as described in Section 3.2.1 of [RFC6749]."
>
> best regards,
> Torsten.
>
> Am 18.07.2016 10:58, schrieb internet-drafts@ietf.org:
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> This draft is a work item of the Web Authorization Protocol of the IETF.
>>
>>         Title           : OAuth 2.0 Device Flow
>>         Authors         : William Denniss
>>                           Stein Myrseth
>>                           John Bradley
>>                           Michael B. Jones
>>                           Hannes Tschofenig
>>     Filename        : draft-ietf-oauth-device-flow-03.txt
>>     Pages           : 10
>>     Date            : 2016-07-18
>>
>> Abstract:
>>    The device flow is suitable for OAuth 2.0 clients executing on
>>    devices that do not have an easy data-entry method (e.g., game
>>    consoles, TVs, picture frames, and media hubs), but where the end-
>>    user has separate access to a user-agent on another computer or
>>    device (e.g., desktop computer, a laptop, a smart phone, or a
>>    tablet).
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/
>>
>> There's also a htmlized version available at:
>> https://tools.ietf.org/html/draft-ietf-oauth-device-flow-03
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-device-flow-03
>>
>>
>> Please note that it may take a couple of minutes from the time of 
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Thu Jul 21 07:21:34 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DEDB12D636 for ; Thu, 21 Jul 2016 07:21:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.287
X-Spam-Level: 
X-Spam-Status: No, score=-3.287 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, RP_MATCHES_RCVD=-1.287, 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 5kbegjp56-Ft for ; Thu, 21 Jul 2016 07:21:27 -0700 (PDT)
Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::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 9CFD312D5F9 for ; Thu, 21 Jul 2016 07:21:27 -0700 (PDT)
Received: by mail-yw0-x229.google.com with SMTP id u134so75159014ywg.3 for ; Thu, 21 Jul 2016 07:21:27 -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=llKH9o/405HzIFGhL/u+HLJENY5LUWMSe3MQXi18q7Q=; b=g8YCw7B1Ll+zemP8gYjKf4/zxvs83LwsWZjwU9jmbjYtipYRYfvpyZw7rBI8+mDcz5 9bv5nwgkSlPMsP9UgGjSI1l2qegCZbK7B2O4brvIlFgATXidcFb/+lld/PfLAA2g1LO8 jhaccZIPd8VuVDfAvEJYMw8hZl1pk6qN6sIUn8vGqnJGc/iROWS95sk5OLy3Eg0dKPHL 4ag08RpxoxghocP2WswPe/5cPgCaOdU4d4qBhWg591b9sCF/gn6QCP7DiYGUTAQIAOEd l21K4rXOptyqUAedMbsIPUIaB07c9gTY3w9hLAkqxbMvc0Qgz07NQedMVuqiz4WgFJSB e5cA==
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=llKH9o/405HzIFGhL/u+HLJENY5LUWMSe3MQXi18q7Q=; b=RGv2zjTl4y0aVqUXue2uoFz8ok1ZIGeJWnw63VPhpHdtaIB4EUUhL4p4eH8YVHm8wS ZiXRLFYltZXJPMMjXBgyshMF70Keb5GExVwKi13uIdSqR/m68o8U3pc3yfJ4Xudotvsh qfTnVsRBaj+7ZsvwBJIuh1GDHnVnNp+YvnFzLhn4LGK1sSkkwmbfFTEo0iwOMWIa0H7V sfQUrpdCzNuNC6OiOHvDsk8P48BOYYEJCAvVyHgd2xt+kCNIqVtNKuR3xLroNcDF6eTn ZVSVSwEHikWlpBiMb0Vxq01PIHcvAviCemjMdbuQb0qtR8a6r5t3JDFl5xc57wic6B8Y Eitw==
X-Gm-Message-State: ALyK8tLzKgO0GrvL6ubVLJn5nRQsA31xjtCRfZEGJcWHn5tEClLTK6XrsWE9E6A/emtW+yvVzCMvPk8Ddhmpe+Gp
X-Received: by 10.13.207.129 with SMTP id r123mr34450092ywd.177.1469110886719;  Thu, 21 Jul 2016 07:21:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.13.222.199 with HTTP; Thu, 21 Jul 2016 07:21:07 -0700 (PDT)
In-Reply-To: 
References: <20160718085803.12429.32081.idtracker@ietfa.amsl.com>  
From: William Denniss 
Date: Thu, 21 Jul 2016 16:21:07 +0200
Message-ID: 
To: Justin Richer 
Content-Type: multipart/alternative; boundary=001a114e68868a63bb05382608bc
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-device-flow-03.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jul 2016 14:21:32 -0000

--001a114e68868a63bb05382608bc
Content-Type: text/plain; charset=UTF-8

Good points. That wording was from the original draft from years ago and
has not been changed. I'll revise it on the next update.

Here's a more modern take on the topic of client secrets in native apps:
https://tools.ietf.org/html/draft-ietf-oauth-native-apps-03#section-10   In
this case, like you say we may have confidential clients too. Certainly
many uses of the device flow that I see are for public clients, so I could
include text like that.

On Thu, Jul 21, 2016 at 3:47 PM, Justin Richer  wrote:

> +1 to Torsten's comment, there's no good reason that I can see to limit
> this to public clients.
>
>  -- Justin
>
>
>
> On 7/21/2016 8:56 AM, torsten@lodderstedt.net wrote:
>
>> Hi William,
>>
>> one question regarding your document: Why does the introduction point out?
>>
>> "Note that this device flow does not utilize the client secret."
>>
>> What is the reason for this exclusion? In my opinion, this flow can be
>> used by web-based confidential clients as well as native clients utilizing
>> dynamic registration.
>>
>> Moreover, section 3.4 states
>> "If the client was issued client credentials (or assigned other
>>   authentication requirements), the client MUST authenticate with the
>>   authorization server as described in Section 3.2.1 of [RFC6749]."
>>
>> best regards,
>> Torsten.
>>
>> Am 18.07.2016 10:58, schrieb internet-drafts@ietf.org:
>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>> This draft is a work item of the Web Authorization Protocol of the IETF.
>>>
>>>         Title           : OAuth 2.0 Device Flow
>>>         Authors         : William Denniss
>>>                           Stein Myrseth
>>>                           John Bradley
>>>                           Michael B. Jones
>>>                           Hannes Tschofenig
>>>     Filename        : draft-ietf-oauth-device-flow-03.txt
>>>     Pages           : 10
>>>     Date            : 2016-07-18
>>>
>>> Abstract:
>>>    The device flow is suitable for OAuth 2.0 clients executing on
>>>    devices that do not have an easy data-entry method (e.g., game
>>>    consoles, TVs, picture frames, and media hubs), but where the end-
>>>    user has separate access to a user-agent on another computer or
>>>    device (e.g., desktop computer, a laptop, a smart phone, or a
>>>    tablet).
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/
>>>
>>> There's also a htmlized version available at:
>>> https://tools.ietf.org/html/draft-ietf-oauth-device-flow-03
>>>
>>> A diff from the previous version is available at:
>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-device-flow-03
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of
>>> submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--001a114e68868a63bb05382608bc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Good points. That wording was from the original draft from=
 years ago and has not been changed. I'll revise it on the next update.=


Here's a more modern take on the topic of client se=
crets in native apps:=C2=A0https://tools.ietf.org/html/draft-ietf-o=
auth-native-apps-03#section-10 =C2=A0 In this case, like you say we may=
 have confidential clients too. Certainly many uses of the device flow that=
 I see are for public clients, so I could include text like that.

On Thu, Jul 21,=
 2016 at 3:47 PM, Justin Richer <jricher@mit.edu> wrote:
+1 to Torsten's comment, there's no go=
od reason that I can see to limit this to public clients.



=C2=A0-- Justin






On 7/21/2016 8:56 AM, torsten@lodderstedt.net wrote:



Hi William,



one question regarding your document: Why does the introduction point out?<=
br>


"Note that this device flow does not utilize the client secret."<=
br>


What is the reason for this exclusion? In my opinion, this flow can be used=
 by web-based confidential clients as well as native clients utilizing dyna=
mic registration.



Moreover, section 3.4 states

"If the client was issued client credentials (or assigned other

=C2=A0 authentication requirements), the client MUST authenticate with the<=
br>
=C2=A0 authorization server as described in Section 3.2.1 of [RFC6749].&quo=
t;



best regards,

Torsten.



Am 18.07.2016 10:58, schrieb internet-drafts@ietf.org:



A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.

This draft is a work item of the Web Authorization Protocol of the IETF.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=
 OAuth 2.0 Device Flow

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Will=
iam Denniss

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 Stein Myrseth

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 John Bradley

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 Michael B. Jones

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 Hannes Tschofenig

=C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-ietf-oauth-device=
-flow-03.txt

=C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 10

=C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 2016-07-18


Abstract:

=C2=A0 =C2=A0The device flow is suitable for OAuth 2.0 clients executing on=


=C2=A0 =C2=A0devices that do not have an easy data-entry method (e.g., game=


=C2=A0 =C2=A0consoles, TVs, picture frames, and media hubs), but where the =
end-

=C2=A0 =C2=A0user has separate access to a user-agent on another computer o=
r

=C2=A0 =C2=A0device (e.g., desktop computer, a laptop, a smart phone, or a<=
br>
=C2=A0 =C2=A0tablet).





The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft=
-ietf-oauth-device-flow/



There's also a htmlized version available at:

https://tools.ietf.org/html/draft-ietf-oa=
uth-device-flow-03



A diff from the previous version is available at:

https://www.ietf.org/rfcdiff?url2=
=3Ddraft-ietf-oauth-device-flow-03





Please note that it may take a couple of minutes from the time of submissio=
n

until the htmlized version and diff are available at tools.ietf.org.



Internet-Drafts are also available by anonymous FTP at:

ftp://ftp.ietf.org/internet-drafts/



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





--001a114e68868a63bb05382608bc--


From nobody Sun Jul 24 10:30:49 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6BF12D57B for ; Sun, 24 Jul 2016 10:30:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.621
X-Spam-Level: 
X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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
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 EUGQegm2kkaN for ; Sun, 24 Jul 2016 10:30:45 -0700 (PDT)
Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.24]) (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 4AEAD12D556 for ; Sun, 24 Jul 2016 10:30:45 -0700 (PDT)
Received: from [87.143.162.123] (helo=[192.168.71.104]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1bRNEg-0005XZ-G5; Sun, 24 Jul 2016 19:30:42 +0200
To: Hannes Tschofenig , "oauth@ietf.org" 
References: <57908256.7090107@gmx.net>
From: Torsten Lodderstedt 
Message-ID: <0e5b8c6f-b594-fa9b-dcad-dff590e7bef5@lodderstedt.net>
Date: Sun, 24 Jul 2016 19:30:33 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <57908256.7090107@gmx.net>
Content-Type: multipart/alternative; boundary="------------4E3F53F8DF9BBAC7BAB7A434"
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: Re: [OAUTH-WG] Working Group Last Call on "OAuth 2.0 for Native Apps"
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 24 Jul 2016 17:30:48 -0000

This is a multi-part message in MIME format.
--------------4E3F53F8DF9BBAC7BAB7A434
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

generally, I considers this a highly valuable contribution and support 
to move it forward.

Some nits:

section 7.3, last paragraph: "... as it is less susceptible
    to misconfigured routing and client side firewalls Note ..." - I 
think a period is missing between "firewalls" and "Note" potentially a 
line break would be appropriate.

section 8.2 - The term PKCE is used in the second paragraph but not 
defined before the fourth paragraph. I suggest to define PKCE on first use.

best regards,
Torsten.


Am 21.07.2016 um 10:05 schrieb Hannes Tschofenig:
> Hi all,
>
> William has submitted an update, as promised during the OAuth WG session
> on Monday. Hence, we will start a Last Call for comments on the "OAuth
> 2.0 for Native Apps"  specification.
>
> The document can be found here:
> https://tools.ietf.org/html/draft-ietf-oauth-native-apps-03
>
> Please have your comments in no later than August 8th.
>
> Ciao
> Hannes & Derek
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--------------4E3F53F8DF9BBAC7BAB7A434
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi,

    
generally, I considers this a highly valuable contribution and
      support to move it forward.

    
Some nits:

    
section 7.3, last paragraph: "... as it is less susceptible

         to misconfigured routing and client side firewalls Note ..." -
      I think a period is missing between "firewalls" and "Note"
      potentially a line break would be appropriate.

    
section 8.2 - The term PKCE is used in the second paragraph but
      not defined before the fourth paragraph. I suggest to define PKCE
      on first use.

    
best regards,

      Torsten.

    

    

    
Am 21.07.2016 um 10:05 schrieb Hannes
      Tschofenig:

    

    

      
Hi all,

William has submitted an update, as promised during the OAuth WG session
on Monday. Hence, we will start a Last Call for comments on the "OAuth
2.0 for Native Apps"  specification.

The document can be found here:
https://tools.ietf.org/html/draft-ietf-oauth-native-apps-03

Please have your comments in no later than August 8th.

Ciao
Hannes & Derek




      

      

      

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


    

    

  


--------------4E3F53F8DF9BBAC7BAB7A434--


From nobody Mon Jul 25 03:59:29 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F98112D5BF for ; Mon, 25 Jul 2016 03:59:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.888
X-Spam-Level: 
X-Spam-Status: No, score=-3.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.287, 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 d2pDr_eEQnl4 for ; Mon, 25 Jul 2016 03:59:27 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A484D12D1AA for ; Mon, 25 Jul 2016 03:59:26 -0700 (PDT)
Received: from [192.168.10.131] ([195.149.223.151]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Meutp-1bggS20QC9-00OXrV for ; Mon, 25 Jul 2016 12:59:23 +0200
To: "oauth@ietf.org" 
From: Hannes Tschofenig 
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
Message-ID: <5795F109.9040403@gmx.net>
Date: Mon, 25 Jul 2016 12:59:21 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="4ukuV2mOCUf4VI23v7qQOUoVJ51tHBMia"
X-Provags-ID: V03:K0:fY0mAKjI836f6INRedqjGx1SCNH12+ZLbsLPU5e/8+3I7ZF8EBL GN100J9iNrYXULJGrJf4eHgAP0p6OJmPXafFJg0L5Eht+VzSysxq0lyJ/4sBbZjz3X7QHP4 3lgo/IjEMPh/cAzZFBRE6WqlrgjpDMtl6CP8nd2ulj1zbdfuqx/SAPmSP47IDmTc7UGd7ZU Zo0Zm3YClh/ijggSMF0/A==
X-UI-Out-Filterresults: notjunk:1;V01:K0:ZNiZWlCOy9g=:0DMOM3ulyDQnjbtS/vrIv7 MbzkAhPZoAI0uiOF5UWP2WfJEgUqD9qQkD4Q89XAzW9at4vQkkKkFxIeYnh6yrOWKBscBPkXF Nytx2543jPyq+HBHPU5QPZsZdHYF5bYSdV5rHLLhQNhWgh9D8JLI7l9nt/fjsSPAqsuCMtSjH Jp/TtJGiZTT6Rg4EMmvaTYT0Wl27vr/6pf8YXI9nxYhAjjN97j1jkQRonvBGcfdjivGZ06pEo nYsYWpv9DnEDY6iXbFbhHeeUPQGCfxmXeQVqfzOpDGVw/R8lPuBYdK0N785lSuFhEYvcEnKgM C5L94J0hHBZoifguM0/yw+lQwscAqzJv6Ki8ZiUh980f0XrGyy4vDi1oNBTGFbEpd1T8ST+0M hYX6CArb4/ok3pibKcMD1Mjuu2BoFdThmrUgLvPgwSExfheImkfCtqK2Re1jMXZiDQK/1+nLy 5p5zAZgJRDhs0pNiahbT3F42n++2d//RFSarvxd5dviK4ZBW6wlxnsZeNdhpT+SxsVx8YDQdh Clg6nE0kWFtRXDswJ8a1KphpX/3lLFkKnTXQsuefiBrT73AOaXgzZ/8qQpR8cnk1GFopJGLT6 hCFgvFvopiTwmEQJyyWhJe/cnsGRCaWg3a+K3sKCU4iRokZuSLAt8Z0dkHC9o1dvcmkqF8P7A xe9WmVgWwUfAIJPvyVrjcXHQtziHOBKb/Eh3SMWsHzVltYDHQ06yIa6Mz8dtauN3GhrLm2Osj roN1sX6wk8skGOCYb1dTi9Z/W6o5Np3+w+WFMAMtzafrQX7d1QBklDxvFXk=
Archived-At: 
Subject: [OAUTH-WG] OAuth Security -- Next Steps
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jul 2016 10:59:28 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--4ukuV2mOCUf4VI23v7qQOUoVJ51tHBMia
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi all,

We had two working group sessions at the Berlin IETF meeting and I am
happy about the progress on many of the subjects. We managed to progress
token exchange, native apps, AMR, and authorization server meta-data. We
also identified new use cases to explore with the device flow document.

We also did a call for adoption of the OAuth token binding
functionality, which still needs to be confirmed on the mailing list.
(Further emails will follow.)

There are, however, aspects I am not happy with. I was hoping to make
some progress on the mix-up mitigation and on the wider range of
security documents.

Here is how I see the story after talking to some meeting participants.

1) It seems that the solution approach to deal with the mix-up attack
(only mix-up) described in draft-ietf-oauth-mix-up-mitigation-01 needs
to be modified to reflect the preference of the working group. My
impression (from speaking with participants at the meeting last week
privately) is that there is interest in a solution that does not require
protocol changes but rather relies on configuration. This may include a
combination of exact redirect_URI matching + per-AS redirect_URI +
session state checking. There are also other attacks
described in draft-ietf-oauth-mix-up-mitigation-01, which need to be
moved elsewhere to avoid confusion.

2) We need a new document, ideally a BCP, that serves as a
high-level write-up describing various security issues with OAuth that
points to the mostly existing documents for those who want to read the
background information. Torsten has posted a mail to the list providing
one possible outline of such a document.

How does this sound?

Ciao
Hannes


--4ukuV2mOCUf4VI23v7qQOUoVJ51tHBMia
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJXlfEKAAoJEGhJURNOOiAtCAsH/A/nq1Uqh6QeygO/utZXZtEO
2OfSjI3lEB7HG8SjUws31Pk9tJhhaPLgJQBLNyW2nXcAMwek0Afb9VVhDrTW4Y1i
LPJBQNIz2wgsnB4OQoGrvIcJq09AgV3uCvgwe9ZZR7YhUraT9uDcRGO4f2ihDlwc
Qu6v8sUPaxv57hW1iEheTHpW2AFGVrJssyZhhHYX5BevMmdiTMLSpd1VheWTprrT
5DAlnpHiejMteYSDXxrP/QZPTjMWZfnAhuU/9APD3FZ8vkpZPk/DCqb39SrDsA3y
dDDnrqX51O0J6pe7GlQtqnmanRbHwS0LKEZ8bvY+C/lXgdVPJwVHE60P59/pJJk=
=P/Jr
-----END PGP SIGNATURE-----

--4ukuV2mOCUf4VI23v7qQOUoVJ51tHBMia--


From nobody Mon Jul 25 08:40:09 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF5512D107 for ; Mon, 25 Jul 2016 08:40:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.888
X-Spam-Level: 
X-Spam-Status: No, score=-3.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.287, 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 mvsEMXEsS4qO for ; Mon, 25 Jul 2016 08:40:06 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D4B512D0E7 for ; Mon, 25 Jul 2016 08:40:05 -0700 (PDT)
Received: from [192.168.10.131] ([195.149.223.151]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0Lmr1w-1apLMT2e0C-00h7lF for ; Mon, 25 Jul 2016 17:40:03 +0200
To: "oauth@ietf.org" 
From: Hannes Tschofenig 
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
Message-ID: <579632CC.8020901@gmx.net>
Date: Mon, 25 Jul 2016 17:39:56 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="HvxiANlMB8LGSbXgq0smPhIPegWIQmO0u"
X-Provags-ID: V03:K0:2kB5w3TwIqB56/LkL+TEeSImP1IUqudTZ3PsdEDKTZX2q7SZCLL qOFxWolJKve9+1z/0KH7Bbc9Sbv7wYGSyszEbtsMFn7xan+uMrnSEUDU8sMnYAzAKm8LNPu LfeYLZUp8flwbCcLwXr6zs5Oio6QAdnmlkV92DctxRv0o66hPWcRW8HisUi/v+S3rAyIDAW 3+lw/oQEUpDfIB+edgtxw==
X-UI-Out-Filterresults: notjunk:1;V01:K0:tBcppdY47K0=:X3G8DEvGH/bqIoL9QYvgAq fKiIsfwIwZRDn2+IjO9EOQEtQRXScwJypvXdDmq9T0Hwy/BX5em3xNOPC/gtO3U7hMYsUWanU l3CUuUTGbD5k5UqKT28m/Lh2pnRkY/4fc4gHDQ934mrmGF7mgft6OP2l3O2rSUNbnHjUPQp5A pMrgLlargxlP9If1N64j+fixrQ2f9ywA0NIj2+I1ryHVOUGMCrX4WPyUbfUBH5BeiGuS9lXnC CoN3sxEDBUMiZSK48KKICHeNWRBz78TMPu3uCcAM5g7eErmFET0I68iJ29r1WDEKMJBxRvutt pqvs1bRVBB/W8EhsyVxIsooDIGgVGefR562TXIU70SvW2iYls6U04EbUgf//iXAF58hvqMXwg kOAwHWA/DyO0iPp8+73VTgjOaktyRp+0otqj2z/d5mZtqYpqR+PIfi+C8yx2CiNukG0AcVi2x 2T400kfzikBuQyj063uUK7ynVhH4e1XZjp7D/g5nDEt5MvIMnTxpz3jqDPVaChV0jIJlDvVHV gZfK+NWKFMa8gkCMYCYJRzfUjUTEODNWltui5D1s2lT2CWm+uhfOEiB3ZCIlNAzmJRc6XEClL lyGqzF6NBOYI258SUxGlJGWNP6T+RuCzOxruv+/JZEM0Vz+sA7eYNK4cTXfdKNxvukzTqkE+w p9zVa3bQdU7PgKqQPtwHAPRzrfJIqvpjOHCdSGkL+fuB4RWIvZT3JzbbnpQF+rf/tsevBe3WM m7Ci0Ju9ZKWcaEd7DKM7u7KOJyW7J1ZLPf1bcuO6sQcL/3ZCbXlgB4jcd9w=
Archived-At: 
Subject: [OAUTH-WG] Meeting Minutes
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jul 2016 15:40:07 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--HvxiANlMB8LGSbXgq0smPhIPegWIQmO0u
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi all,

here are the meeting minutes from the OAuth session:
https://www.ietf.org/proceedings/96/minutes/minutes-96-oauth

Please take a look at them to see whether they reflect the discussions
and decisions made during the meeting. Email confirmations will follow.

Ciao
Hannes


--HvxiANlMB8LGSbXgq0smPhIPegWIQmO0u
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJXljLMAAoJEGhJURNOOiAtBrwH/0x14hB/8RN1vK98dhY18KB1
LW8oKnZuZxKF2baYrzGSTULBjfAVTzSBIz+X6fN0oXQkHVBXJVNDzm76OKxkrjW3
EPIWThGgRNE0e4hi/lKmOOS4eT983L4HeNaxVqSLlwrpBkUy9QjsjcVhp/I1AG2y
AwlZUW+KgauF9Q67i24BH2xH8YEPxeFFSt4gfkHl+nN41XUkvoi/5riGPyyT9IKO
YGGxOuruWMpJJs/cqDO3sK2Onzo7BXhypCG3ddjixED7a1GYj6myMta3//broxyb
XGWj6zgQIQ7WoxBiPNjWDkDVdAas7G4T6rVVZTTzGG8LZZOLkEthj8b+un97vd0=
=tZyC
-----END PGP SIGNATURE-----

--HvxiANlMB8LGSbXgq0smPhIPegWIQmO0u--


From nobody Mon Jul 25 10:43:38 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB78E12D56C for ; Mon, 25 Jul 2016 10:43:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.022
X-Spam-Level: 
X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 wPDTnRKSZY-B for ; Mon, 25 Jul 2016 10:43:34 -0700 (PDT)
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0090.outbound.protection.outlook.com [104.47.32.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC60312D548 for ; Mon, 25 Jul 2016 10:43: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=lhL3/racywT4ZsynQuyTfJm30S4iHsVNsClPkROAVyc=; b=Gwzf5IGll2rrjJNCjIkNmXiSBBg15uH9qs+JzEuldcHx04Wz8RpKMX0ddZFaTDnD1NVtU9Ix5u57j0jR65iOkVmxw3/ogDJtpwG/zVPBujosG0PszwI6lmXUqi1MIECTc/NpZ95+rzvjIqA6TRw2mSXIkBXZ40Pk3+hQKf08yMU=
Received: from DM5PR03MB2441.namprd03.prod.outlook.com (10.168.233.11) by DM5PR03MB2441.namprd03.prod.outlook.com (10.168.233.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.544.10; Mon, 25 Jul 2016 17:43:32 +0000
Received: from DM5PR03MB2441.namprd03.prod.outlook.com ([10.168.233.11]) by DM5PR03MB2441.namprd03.prod.outlook.com ([10.168.233.11]) with mapi id 15.01.0544.017; Mon, 25 Jul 2016 17:43:31 +0000
From: Anthony Nadalin 
To: Hannes Tschofenig , "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] OAuth Security -- Next Steps
Thread-Index: AQHR5mOhWN1XRWaqIk2P73CixztdqqApavtA
Date: Mon, 25 Jul 2016 17:43:31 +0000
Message-ID: 
References: <5795F109.9040403@gmx.net>
In-Reply-To: <5795F109.9040403@gmx.net>
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=tonynad@microsoft.com; 
x-originating-ip: [2001:4898:80e8:5::10e]
x-ms-office365-filtering-correlation-id: f0d2b7c6-1c51-44ba-121c-08d3b4b331f9
x-microsoft-exchange-diagnostics: 1; DM5PR03MB2441; 6:JgAfwz14viHWav4fbGQHcRDyIcpy6fDjl6cpNzTPwDcmUmrhYg23NBbIDnsV41JtQsTTjSNKGaGC9idbEzrtSaD1lxDBWXSEQDrRGJhxPYHM9rJq3jCCyTzDqg4xmSV3XaxL9t7cEyZVjbX2AIOSNH+JBsotEohnAkfhOyXECwMJJhGylosfDhi1d71XLMHxbf+PtyAqm3f+vhQ/s6cM5sIAoizudyuVSAxZSxZXF0tTvDjU4M/F/Wg4Z4QfiTcPAy1bocde6YiTg2OD8BsNwZzeMvEryWmThCNUgHySF2WOBHMxCGGaKvqtgWpqaZm+DzhZ877PJL+fJ0xHqS4kiQ==; 5:0yHI33852Wm9yBcXlB4ropPwgzVRQ205VmJAq3Z9EfSbUpbu0wNR5rJ3b1+J8Jler/8Ntz+zTY78wopgLLLlxhyibz4VT4li6adYawr91G0verD+ZNnZtCXO2AEmJC1CAhH6wExMoV3OysbZEi5E5w==; 24:AkxCC+EeOr4pwlzwkaJs+Tbw6BvAwgUa4mfO3PyXp/IeDOfsL+vsG1d7sW2nhp01HCPItXJKsZemfM97+/jVQcGe1HgJCItkYPD0jSupuM0=; 7:nSCCAYl/SPoUUuKDKGfl3fC7q3Y/FGSzTO0YTpUOsieW7e9a2fCpm9w6PNP+RCuW/8PX/ICN7AIrEw0lvsrSUCMYL+ny888KqRMykO5SGWjttNacFLK2jws+LHFdB9puqKnG8lHsJYKpGHIRruYf9X9y4QCgQE9VOwH44qtBePEaS73uq9dqlN+rCe2302p8MSgrUQtgqr+7G2K0fEor8g/IVK+ZW+mG3JE6va8LVML76cbBTBsL9EydO0MDj7JB
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM5PR03MB2441;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:DM5PR03MB2441; BCL:0; PCL:0; RULEID:; SRVR:DM5PR03MB2441; 
x-forefront-prvs: 0014E2CF50
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(7916002)(199003)(189002)(377454003)(13464003)(53754006)(8990500004)(5005710100001)(586003)(2501003)(6116002)(102836003)(10090500001)(107886002)(81156014)(81166006)(19580405001)(19580395003)(2906002)(106356001)(5002640100001)(10400500002)(99286002)(10290500002)(92566002)(8936002)(106116001)(305945005)(189998001)(7846002)(3280700002)(87936001)(101416001)(122556002)(77096005)(2950100001)(3660700001)(7736002)(2900100001)(7696003)(5003600100003)(9686002)(74316002)(76176999)(50986999)(5001770100001)(76576001)(8676002)(54356999)(97736004)(86612001)(15650500001)(68736007)(105586002)(86362001)(33656002)(3826002)(42262002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR03MB2441; H:DM5PR03MB2441.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: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jul 2016 17:43:31.7412 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR03MB2441
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Security -- Next Steps
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jul 2016 17:43:37 -0000

U291bmRzIGFib3V0IHJpZ2h0LCBidXQgSSB3b3VsZCBpbWFnaW5lIHRoYXQgdGhlIEJDUCB3b3Vs
ZCBjb3ZlciBhbnkgaXNzdWUgdGhhdCBhcmlzZXMgbm90IGp1c3QgbWl4LXVwDQoNCi0tLS0tT3Jp
Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0
Zi5vcmddIE9uIEJlaGFsZiBPZiBIYW5uZXMgVHNjaG9mZW5pZw0KU2VudDogTW9uZGF5LCBKdWx5
IDI1LCAyMDE2IDM6NTkgQU0NClRvOiBvYXV0aEBpZXRmLm9yZw0KU3ViamVjdDogW09BVVRILVdH
XSBPQXV0aCBTZWN1cml0eSAtLSBOZXh0IFN0ZXBzDQoNCkhpIGFsbCwNCg0KV2UgaGFkIHR3byB3
b3JraW5nIGdyb3VwIHNlc3Npb25zIGF0IHRoZSBCZXJsaW4gSUVURiBtZWV0aW5nIGFuZCBJIGFt
IGhhcHB5IGFib3V0IHRoZSBwcm9ncmVzcyBvbiBtYW55IG9mIHRoZSBzdWJqZWN0cy4gV2UgbWFu
YWdlZCB0byBwcm9ncmVzcyB0b2tlbiBleGNoYW5nZSwgbmF0aXZlIGFwcHMsIEFNUiwgYW5kIGF1
dGhvcml6YXRpb24gc2VydmVyIG1ldGEtZGF0YS4gV2UgYWxzbyBpZGVudGlmaWVkIG5ldyB1c2Ug
Y2FzZXMgdG8gZXhwbG9yZSB3aXRoIHRoZSBkZXZpY2UgZmxvdyBkb2N1bWVudC4NCg0KV2UgYWxz
byBkaWQgYSBjYWxsIGZvciBhZG9wdGlvbiBvZiB0aGUgT0F1dGggdG9rZW4gYmluZGluZyBmdW5j
dGlvbmFsaXR5LCB3aGljaCBzdGlsbCBuZWVkcyB0byBiZSBjb25maXJtZWQgb24gdGhlIG1haWxp
bmcgbGlzdC4NCihGdXJ0aGVyIGVtYWlscyB3aWxsIGZvbGxvdy4pDQoNClRoZXJlIGFyZSwgaG93
ZXZlciwgYXNwZWN0cyBJIGFtIG5vdCBoYXBweSB3aXRoLiBJIHdhcyBob3BpbmcgdG8gbWFrZSBz
b21lIHByb2dyZXNzIG9uIHRoZSBtaXgtdXAgbWl0aWdhdGlvbiBhbmQgb24gdGhlIHdpZGVyIHJh
bmdlIG9mIHNlY3VyaXR5IGRvY3VtZW50cy4NCg0KSGVyZSBpcyBob3cgSSBzZWUgdGhlIHN0b3J5
IGFmdGVyIHRhbGtpbmcgdG8gc29tZSBtZWV0aW5nIHBhcnRpY2lwYW50cy4NCg0KMSkgSXQgc2Vl
bXMgdGhhdCB0aGUgc29sdXRpb24gYXBwcm9hY2ggdG8gZGVhbCB3aXRoIHRoZSBtaXgtdXAgYXR0
YWNrIChvbmx5IG1peC11cCkgZGVzY3JpYmVkIGluIGRyYWZ0LWlldGYtb2F1dGgtbWl4LXVwLW1p
dGlnYXRpb24tMDEgbmVlZHMgdG8gYmUgbW9kaWZpZWQgdG8gcmVmbGVjdCB0aGUgcHJlZmVyZW5j
ZSBvZiB0aGUgd29ya2luZyBncm91cC4gTXkgaW1wcmVzc2lvbiAoZnJvbSBzcGVha2luZyB3aXRo
IHBhcnRpY2lwYW50cyBhdCB0aGUgbWVldGluZyBsYXN0IHdlZWsNCnByaXZhdGVseSkgaXMgdGhh
dCB0aGVyZSBpcyBpbnRlcmVzdCBpbiBhIHNvbHV0aW9uIHRoYXQgZG9lcyBub3QgcmVxdWlyZSBw
cm90b2NvbCBjaGFuZ2VzIGJ1dCByYXRoZXIgcmVsaWVzIG9uIGNvbmZpZ3VyYXRpb24uIFRoaXMg
bWF5IGluY2x1ZGUgYSBjb21iaW5hdGlvbiBvZiBleGFjdCByZWRpcmVjdF9VUkkgbWF0Y2hpbmcg
KyBwZXItQVMgcmVkaXJlY3RfVVJJICsgc2Vzc2lvbiBzdGF0ZSBjaGVja2luZy4gVGhlcmUgYXJl
IGFsc28gb3RoZXIgYXR0YWNrcyBkZXNjcmliZWQgaW4gZHJhZnQtaWV0Zi1vYXV0aC1taXgtdXAt
bWl0aWdhdGlvbi0wMSwgd2hpY2ggbmVlZCB0byBiZSBtb3ZlZCBlbHNld2hlcmUgdG8gYXZvaWQg
Y29uZnVzaW9uLg0KDQoyKSBXZSBuZWVkIGEgbmV3IGRvY3VtZW50LCBpZGVhbGx5IGEgQkNQLCB0
aGF0IHNlcnZlcyBhcyBhIGhpZ2gtbGV2ZWwgd3JpdGUtdXAgZGVzY3JpYmluZyB2YXJpb3VzIHNl
Y3VyaXR5IGlzc3VlcyB3aXRoIE9BdXRoIHRoYXQgcG9pbnRzIHRvIHRoZSBtb3N0bHkgZXhpc3Rp
bmcgZG9jdW1lbnRzIGZvciB0aG9zZSB3aG8gd2FudCB0byByZWFkIHRoZSBiYWNrZ3JvdW5kIGlu
Zm9ybWF0aW9uLiBUb3JzdGVuIGhhcyBwb3N0ZWQgYSBtYWlsIHRvIHRoZSBsaXN0IHByb3ZpZGlu
ZyBvbmUgcG9zc2libGUgb3V0bGluZSBvZiBzdWNoIGEgZG9jdW1lbnQuDQoNCkhvdyBkb2VzIHRo
aXMgc291bmQ/DQoNCkNpYW8NCkhhbm5lcw0KDQo=


From nobody Tue Jul 26 13:48:42 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79CEA12D51F for ; Tue, 26 Jul 2016 13:48:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.889
X-Spam-Level: 
X-Spam-Status: No, score=-103.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 hGc_ZOJZW8pg for ; Tue, 26 Jul 2016 13:48:39 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 241F412D1F0 for ; Tue, 26 Jul 2016 13:48:39 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 0874EB81C1A; Tue, 26 Jul 2016 13:48:39 -0700 (PDT)
To: dick.hardt@gmail.com, stephen.farrell@cs.tcd.ie, Kathleen.Moriarty.ietf@gmail.com, Hannes.Tschofenig@gmx.net, derek@ihtfp.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System 
Message-Id: <20160726204839.0874EB81C1A@rfc-editor.org>
Date: Tue, 26 Jul 2016 13:48:39 -0700 (PDT)
Archived-At: 
Cc: rfc-editor@rfc-editor.org, oauth@ietf.org
Subject: [OAUTH-WG] [Technical Errata Reported] RFC6749 (4749)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jul 2016 20:48:40 -0000

The following errata report has been submitted for RFC6749,
"The OAuth 2.0 Authorization Framework".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6749&eid=4749

--------------------------------------
Type: Technical
Reported by: Phil Hunt 

Section: 2.3.1

Original Text
-------------
Clients in possession of a client password MAY use the HTTP Basic
authentication scheme as defined in [RFC2617] to authenticate with
the authorization server.  The client identifier is encoded using the
"application/x-www-form-urlencoded" encoding algorithm per
Appendix B, and the encoded value is used as the username; the client
password is encoded using the same algorithm and used as the
password.  The authorization server MUST support the HTTP Basic
authentication scheme for authenticating clients that were issued a
client password.

Corrected Text
--------------
Clients in possession of a client password MAY use the HTTP Basic
authentication scheme as defined in [RFC2617] to authenticate with
the authorization server.  The client identifier is encoded using the
"application/x-www-form-urlencoded" encoding algorithm per
Appendix B, and the encoded value is used as the username; the client
password is encoded using the same algorithm and used as the
password. The url encoded values are then encoded as defined in
[RFC2617]. The authorization server MUST support the HTTP Basic
authentication scheme for authenticating clients that were issued a
client password.

Notes
-----
It was not clear to some implementers that the intention is a 2-step encoding. First for special characters and second the 2617 base 64 encoding.  Implementers thought 6749 was in conflict with 2617.

To avoid inter-op issues, a new clarifying sentence is proposed.
"The url encoded values are then encoded as defined in [RFC2617]."

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6749 (draft-ietf-oauth-v2-31)
--------------------------------------
Title               : The OAuth 2.0 Authorization Framework
Publication Date    : October 2012
Author(s)           : D. Hardt, Ed.
Category            : PROPOSED STANDARD
Source              : Web Authorization Protocol
Area                : Security
Stream              : IETF
Verifying Party     : IESG


From nobody Tue Jul 26 17:08:34 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA9012D1A1 for ; Tue, 26 Jul 2016 17:08:33 -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, 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=manicode-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 cEuVtF_wlkEd for ; Tue, 26 Jul 2016 17:08:32 -0700 (PDT)
Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d: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 DC70212D660 for ; Tue, 26 Jul 2016 17:08:31 -0700 (PDT)
Received: by mail-qk0-x232.google.com with SMTP id x1so20975656qkb.3 for ; Tue, 26 Jul 2016 17:08:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OxWJQSb5XuB5k7HWMHLNeicQcsNRWnh7UtGS3yynxn8=; b=Tt+Vy1jGOCLjYzo3e6AoZWm8hr1LpWL6U5lY8IuWSqCxryl1sGWT6xn1jjBGiU61br xUBiFzwp2X0E1ZkuOfv3x6r0C/UkOLJBRmPAMV7poOHdHm+eCA3QEH8Dg7CTosn+9Uz1 1/LbzJnH+zUvmXbe3pMW362G5TH3SBQPDi/In/V+O+YX9HDt0GaoQKO4t69upcnCCCdI dpalc8Sq86d5NxvVCQgSgZDvBtLx660kSgMtPbzN69QMKxIptWxpqeQBJ3ZGnIuCH9Li dLEoYpr2M3FXF4u5YHgXYrVQ5JPPfDWUpVQF7Zzc8rqDD5oOVWlewzvHVCyn5Q+vz851 IoTQ==
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 :content-transfer-encoding:message-id:references:to; bh=OxWJQSb5XuB5k7HWMHLNeicQcsNRWnh7UtGS3yynxn8=; b=FEMDTmb87fRh9B30Mmt3XJ4UiMdKMYZtB4BTcUBvmgpfNL2YJDkyuz9YulKTsnDkV0 ZvBbGl5koUw/qvwNjHZ9EDcCXq7UmWmfNSCYx+n6Hehyn+kw8e4R3ICC/uSTOqO8hQFW O7Figb0A1P0ivNkRlu+Vk8gYntvS1pN3exp8NRzQtmya77vOpoPoDSR1Ysn44dCEG9wC Uhpv/YKPOBQcaAH9EgzxyQPc599vR1LINk4RJWxNaGSP4wQIjbweTkY0f5a4TIHw0aNQ oVvdcIzRrbwlHcRSZRDa90EnQt9m2r50Nz6r1FRegn7jUIHYUDyx/WyAj2tAt/lR9170 fRag==
X-Gm-Message-State: AEkooutuvIE8VvZsUUh84dvQ+BjjXZDicHRnDwb4wJnlhjFu3ReXJgbYBdpB6CI9dkcJBNQ/
X-Received: by 10.233.220.133 with SMTP id q127mr33847781qkf.33.1469578110944;  Tue, 26 Jul 2016 17:08:30 -0700 (PDT)
Received: from [10.151.74.175] (mobile-107-107-59-138.mycingular.net. [107.107.59.138]) by smtp.gmail.com with ESMTPSA id 2sm2274497qta.2.2016.07.26.17.08.30 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 26 Jul 2016 17:08:30 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Jim Manico 
X-Mailer: iPhone Mail (13G34)
In-Reply-To: <20160726204839.0874EB81C1A@rfc-editor.org>
Date: Tue, 26 Jul 2016 20:08:29 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20160726204839.0874EB81C1A@rfc-editor.org>
To: RFC Errata System 
Archived-At: 
Cc: derek@ihtfp.com, oauth@ietf.org
Subject: Re: [OAUTH-WG] [Technical Errata Reported] RFC6749 (4749)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jul 2016 00:08:33 -0000

Please forgive me if this comment is out of order or inappropriate in any wa=
y...

...but why is HTTP Basic even being discussed in 2016? It has horrific secur=
ity properties at multiple levels; shouldn't we at least move to HTTP Digest=
 if not something stronger?

Regards.
--
Jim Manico
@Manicode

> On Jul 26, 2016, at 4:48 PM, RFC Errata System =
 wrote:
>=20
> The following errata report has been submitted for RFC6749,
> "The OAuth 2.0 Authorization Framework".
>=20
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=3D6749&eid=3D4749
>=20
> --------------------------------------
> Type: Technical
> Reported by: Phil Hunt 
>=20
> Section: 2.3.1
>=20
> Original Text
> -------------
> Clients in possession of a client password MAY use the HTTP Basic
> authentication scheme as defined in [RFC2617] to authenticate with
> the authorization server.  The client identifier is encoded using the
> "application/x-www-form-urlencoded" encoding algorithm per
> Appendix B, and the encoded value is used as the username; the client
> password is encoded using the same algorithm and used as the
> password.  The authorization server MUST support the HTTP Basic
> authentication scheme for authenticating clients that were issued a
> client password.
>=20
> Corrected Text
> --------------
> Clients in possession of a client password MAY use the HTTP Basic
> authentication scheme as defined in [RFC2617] to authenticate with
> the authorization server.  The client identifier is encoded using the
> "application/x-www-form-urlencoded" encoding algorithm per
> Appendix B, and the encoded value is used as the username; the client
> password is encoded using the same algorithm and used as the
> password. The url encoded values are then encoded as defined in
> [RFC2617]. The authorization server MUST support the HTTP Basic
> authentication scheme for authenticating clients that were issued a
> client password.
>=20
> Notes
> -----
> It was not clear to some implementers that the intention is a 2-step encod=
ing. First for special characters and second the 2617 base 64 encoding.  Imp=
lementers thought 6749 was in conflict with 2617.
>=20
> To avoid inter-op issues, a new clarifying sentence is proposed.
> "The url encoded values are then encoded as defined in [RFC2617]."
>=20
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary.=20
>=20
> --------------------------------------
> RFC6749 (draft-ietf-oauth-v2-31)
> --------------------------------------
> Title               : The OAuth 2.0 Authorization Framework
> Publication Date    : October 2012
> Author(s)           : D. Hardt, Ed.
> Category            : PROPOSED STANDARD
> Source              : Web Authorization Protocol
> Area                : Security
> Stream              : IETF
> Verifying Party     : IESG
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Tue Jul 26 17:15:45 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC8F12DA6C for ; Tue, 26 Jul 2016 17:15:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pYUlVaKlf1qy for ; Tue, 26 Jul 2016 17:15:42 -0700 (PDT)
Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 609A412DA60 for ; Tue, 26 Jul 2016 17:15:41 -0700 (PDT)
Received: by mail-it0-x229.google.com with SMTP id u186so130699219ita.0 for ; Tue, 26 Jul 2016 17:15:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:from:date:message-id:subject:to; bh=jaZiyoxFri0qWuo/3QTFBukgK4RGDolaGlPDMz2SvJ0=; b=asZkBAp+J+x+wT9j4ftthrIBIZt0RBx3mpyNCmVaewsCoCClq9cGfWqDzZSHirK5SC w3IbkSnxoNaOByhhTwFLL2KSRSCSEvUxmx/EaMt9HQMNjTl0G+ljX+zbClGEmczycFex lTy+Kv7nPNFXhyTs0OCS8U8Vr/BeMWzlC7P8Ali5ph1XKNCaI32+EPdAQvTVikUh2dhq O87763+Nmln2RiPbG1XZ9i/4WuXrhL0s5AnLJrqINfo/6yqOOYrtQUnDQJqw9NUlgtT8 W85KGBwM7kF9F89Rz2m5hrBjWwXsRXLdgRz5cfs4ZLmHkdgNssqq97dzCSLJQFlV/geK bKFQ==
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=jaZiyoxFri0qWuo/3QTFBukgK4RGDolaGlPDMz2SvJ0=; b=LreN/1P1YkKfhCDe4601gd1PKTPZK0CtK+IVIPw9oEdc/dsShwzlHQer8Wh5+yxvGZ MLK7t/IQDRRyBUQinkO6RA1qZYKhqWpn98n86Ic7i/EE25d0em/fCjW/ufxqV5WCwrtO b0recTAiIJSamvXEEbLUZZWPeLpxaAXdy3shKm0HO1Vv5CanPPoOyvGN0clDWwv24akJ TPCYgOv5cvB39SGPNKMkyddlYzszo+Vpw8BOU1weik3QTCqd0W70LKIEvvhy43LSJ1TG 7TYw1nAZu8k2jmgDdud4ACJzm2bRODns0Zf/TUI8MdxwPCDxg4eD0QuuqCb+ssmPin+6 I5+Q==
X-Gm-Message-State: AEkoousAMunPSE9D532M7Q2ymNeFE9bUwIyPEMRCFZ8DCbPHQT/bVbL1CGbx553EMaQarn+saLRZu92ka5tmgA==
X-Received: by 10.36.26.81 with SMTP id 78mr30692035iti.4.1469578540498; Tue, 26 Jul 2016 17:15:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.79.42.197 with HTTP; Tue, 26 Jul 2016 17:15:21 -0700 (PDT)
From: Dick Hardt 
Date: Tue, 26 Jul 2016 17:15:21 -0700
Message-ID: 
To: Oauth Wrap Wg 
Content-Type: multipart/alternative; boundary=001a1144648ae045a6053892ea84
Archived-At: 
Subject: [OAUTH-WG] URGENT: WPAD attack exposes URL contents even over HTTPS
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jul 2016 00:15:43 -0000

--001a1144648ae045a6053892ea84
Content-Type: text/plain; charset=UTF-8

http://arstechnica.com/security/2016/07/new-attack-that-cripples-https-crypto-works-on-macs-windows-and-linux/

Access tokens included as a URL query parameter when accessing a resource
are susceptible to this attack.

Authorization codes are also visible. From what I know, we have not
depended on the confidentiality of the authorization code.

What are the best current practices that we can point people towards to
ensure they are not susceptible to this attack?

-- Dick
Subscribe to the HARDTWARE  mail list to learn about
projects I am working on!

--001a1144648ae045a6053892ea84
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


http://ars=
technica.com/security/2016/07/new-attack-that-cripples-https-crypto-works-o=
n-macs-windows-and-linux/

Access tokens included as =
a URL query parameter when accessing a resource are susceptible to this att=
ack.

Authorization codes are also visible. From wh=
at I know, we have not depended on the confidentiality of the authorization=
 code.=C2=A0

What are the best current practices t=
hat we can point people towards to ensure they are not susceptible to this =
attack?



--001a1144648ae045a6053892ea84--


From nobody Tue Jul 26 18:04:14 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 327F412D983 for ; Tue, 26 Jul 2016 18:04:14 -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 4MK0Nw0kK7IN for ; Tue, 26 Jul 2016 18:04:12 -0700 (PDT)
Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d: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 113F812DC6C for ; Tue, 26 Jul 2016 18:04:09 -0700 (PDT)
Received: by mail-qk0-x236.google.com with SMTP id s63so21884236qkb.2 for ; Tue, 26 Jul 2016 18:04:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=message-id:mime-version:to:from:subject:date:importance:in-reply-to :references; bh=jjktXeGSCU06tsxJMLZa34WQFFVWx+YiE7gekA6+Fbg=; b=FB/jE0ZK8bjPVMAerVv13W8h+0M0YEVI4AqbnvQqyKeMTX0xsVmU5Vibwq6est9YGo RXoI4biYSBUtch0aozcmLRaMzKoNcaW2OWker8BdpxqOX20l/2oxbz3EwPse1z5Q3s77 +NkiMtKIEGRQ1FKSX0TnAT54TNF7vdGzrahY+6fhOi7JL0ec76+jCAaykTh4HD672HzW NEFMOBjLz2fdYK6AlibPDhYGJN2YG5kSJPUAku2uwIKD/D4S4JS41nUwxbhzXNZbed7G obiAem0TxWwMQl6gGV3zYg2fFwPVRtpIyjpBac3CQgLa1bGgxBBk6B//oToXrf1+cGG+ kPdA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:mime-version:to:from:subject:date :importance:in-reply-to:references; bh=jjktXeGSCU06tsxJMLZa34WQFFVWx+YiE7gekA6+Fbg=; b=NdTMyR+da7+r8s0MlehLPBst3wQi79HWJdSpeXqnXb62haGC+7siluRnhAKaI1BWLx V8UvbF7q/2asGGCLk/HrBgl5zekLRoJC50mEFDdIwj8sn4zrnLzsCtzf1m+HC69hX/Pt zEibGhDXiN/d2jVKddNiq/Lhza5mGvKENMttRC14UlOxERgpXevlUAC9TFul/luQ4rAT Z8ocaE2oxlIiXd2LqIfXItMh72u+LDQ/mTjpXPyoAJXz9Y5ZEniGAgBOB6WqC+uYo/oS grZFYjM+beCaTksN6rAlzLEHL/c3l1hEiTVM2tq+hpI4IrzNNdcsZ3edyah2ll7qSLc/ 5gfA==
X-Gm-Message-State: AEkooutneeNONz4glGGOPZFJl/bNJOjAb6zQxuGsKfwgbUl7MH2t65peNIMjOitz5nSxmocH
X-Received: by 10.55.186.195 with SMTP id k186mr34531706qkf.184.1469581448956;  Tue, 26 Jul 2016 18:04:08 -0700 (PDT)
Received: from ?IPv6:::ffff:50.95.148.144? ([50.95.148.144]) by smtp.gmail.com with ESMTPSA id c23sm2374816qtc.45.2016.07.26.18.04.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Jul 2016 18:04:07 -0700 (PDT)
Message-ID: <57980887.1724c80a.e1de7.c7a7@mx.google.com>
MIME-Version: 1.0
To: Dick Hardt , Oauth Wrap Wg 
From: 
Date: Tue, 26 Jul 2016 21:04:08 -0400
Importance: normal
X-Priority: 3
In-Reply-To: 
References: 
Content-Type: multipart/alternative; boundary="_5E86133D-9FE0-4936-ADFC-D6B52FC4C40D_"
Archived-At: 
Subject: Re: [OAUTH-WG] URGENT: WPAD attack exposes URL contents even over HTTPS
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jul 2016 01:04:14 -0000

--_5E86133D-9FE0-4936-ADFC-D6B52FC4C40D_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"

I need to think about it a bit,  however off the top of my head based on th=
e attack described the code flow should still be safe if the code is truly =
single use.   (Some implementations fudge that)

If the attacker can stop the browser from delivering the code to the client=
 then the client would be susceptible to the cut and paste attack for injec=
ting the code back into the client. =20

The OpenID Connect =E2=80=9Ccode id_token=E2=80=9D flow is not vulnerable t=
o this if the client is properly validating the id_token.

I suspect that this would work against the implicit flow if the JS is sendi=
ng the code back to its web server via a GET. =20
That I think we recommend against doing, or should.

The Token binding proposals would stop a leaked code from being used, but n=
ot from being stolen in this attack.

The attack against a confidential client would be the cut and paste one tha=
t we have identified.  Currently the only mitigation we have is =E2=80=9Cco=
de id_token=E2=80=9D  so the blog post at.
http://openid.net/2016/07/16/preventing-mix-up-attacks-with-openid-connect/

I the most relevant current advice.
The thing to add is that the code leaked in this way should not be repayabl=
e at the client=20

I don=E2=80=99t think that native apps are vulnerable to this if they are u=
sing custom scheme redirects. =20

I don=E2=80=99t know what the risk is if they are using loopback or claimed=
 URI.  It may be that a browser might leak them in the same way.=20
That would need to be tested.

John B.


Sent from Mail for Windows 10

From: Dick Hardt=

--_5E86133D-9FE0-4936-ADFC-D6B52FC4C40D_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="utf-8"


I need to think about it a bit,=C2=
=A0 however off the top of my head based on the attack described the code f=
low should still be safe if the code is truly single use.=C2=A0=C2=A0 (Some=
 implementations fudge that)
 
<=
p class=3DMsoNormal>If the attacker can stop the browser from delivering th=
e code to the client then the client would be susceptible to the cut and pa=
ste attack for injecting the code back into the client.=C2=A0 
 
The OpenID Connect =
=E2=80=9Ccode id_token=E2=80=9D flow is not vulnerable to this if the clien=
t is properly validating the id_token.
 <=
/o:p>
I suspect that this would work against the im=
plicit flow if the JS is sending the code back to its web server via a GET.=
=C2=A0 
That I think we recommend against doing, or=
 should.
 
=
The Token binding proposals would stop a leaked code from being used, but n=
ot from being stolen in this attack.
 
The attack against a confidential client would =
be the cut and paste one that we have identified.=C2=A0 Currently the only =
mitigation we have is =E2=80=9Ccode id_token=E2=80=9D=C2=A0 so the blog pos=
t at.
http://openid.net/2016/07/16/pre=
venting-mix-up-attacks-with-openid-connect/
 
I the most relevant current advice.<=
/p>
The thing to add is that the code leaked in this wa=
y should not be repayable at the client 
 =
;
I don=E2=80=99t think that native apps are =
vulnerable to this if they are using custom scheme redirects.=C2=A0 
 
I don=E2=80=99t=
 know what the risk is if they are using loopback or claimed URI.=C2=A0 It =
may be that a browser might leak them in the same way. 
That would need to be tested.
 
John B.
 =

 
Sent fro=
m Mail for=
 Windows 10
 
=
From: Dick Hardt
S=
ent: July 26, 2016 8:15 PM
To: Oauth Wrap Wg
Subject: [OAUTH-WG] URGENT: WPAD attack exp=
oses URL contents even over HTTPS
 =

http://arstechnica.com/security/2016/07/new-attack-that-cripples-https-=
crypto-works-on-macs-windows-and-linux/
 
Access tok=
ens included as a URL query parameter when accessing a resource are suscept=
ible to this attack.
<=
span style=3D'font-size:12.0pt;font-family:"Times New Roman",serif'>&n=
bsp;
Authorization codes are also=
 visible. From what I know, we have not depended on the confidentiality of =
the authorization code. 
What are the best=
 current practices that we can point people towards to ensure they are not =
susceptible to this attack?
=
 
-- Dick 
Subscribe to the HARDTWARE mail list to learn about p=
rojects I am working on!
&nb=
sp;
=

--_5E86133D-9FE0-4936-ADFC-D6B52FC4C40D_--


From nobody Tue Jul 26 18:11:43 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAC5312DCBF for ; Tue, 26 Jul 2016 18:11:39 -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 8XXJbt07E-39 for ; Tue, 26 Jul 2016 18:11:37 -0700 (PDT)
Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d: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 54A4912DCB7 for ; Tue, 26 Jul 2016 18:11:37 -0700 (PDT)
Received: by mail-qk0-x232.google.com with SMTP id s63so21998953qkb.2 for ; Tue, 26 Jul 2016 18:11:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=message-id:mime-version:to:from:subject:date:importance:in-reply-to :references; bh=neFYMrqnKVIVtda9DYfH4ccYF2wtm8wPtPr6RKBKIF0=; b=sMD5Zielz2qVY3B6Z06idWYt5yT4SkQw+dR86MUuXnlZ/1QU9Tqkq7vOq5rbX91vzO BwAabGp9owqj/8/WEZVK60n2zntqKPOW0F0nJ+nWWOeYF27B1D+mmkkOaTtZtPS4L5zk fH+JZIjZT2Ln6/mrowgHfflzwbxRQrPrQPS2VWXzSqT/vCrrw4+K/WdXrQ72pccqT5nZ 6/SP4Riym6suND83fO/Rgx/Rg6SS+/KQuefyIqiSshWblxXTuluLQQFZ+BZnKmBXRnCw NSI5+QiSq0fvhKR8gqXe+dXb6zPmDKYbtvSRzH0tbPekm/oe/2ojowT8YUvDbQXsFZs+ JA3A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:mime-version:to:from:subject:date :importance:in-reply-to:references; bh=neFYMrqnKVIVtda9DYfH4ccYF2wtm8wPtPr6RKBKIF0=; b=MUAoL9nPYj1w9U/Tyl/om6zPgGLL2yQqCff/jtbq/pkaH84K1+C/H8vGFCxc5YMWIy otcz3LIGJtfPP7viC0wwbSsV6A5hNULOi7UJFUHAhw/l5y1fOo9J58tMOAye+hcBD6Nr mX1iCQXLBad/DP2QTFjHo8H8ooJs9cgEgs1N4XtLVK8hkYOLBHuv/LpFfMxYUPZOF19z wQlI68Bv4/aZr/8kz8pamnQZ0kyh/s8toWNNKlqAChtKmZafoLEQwzTp4cyWDpGO/DAH Z5JTb4yfnPXTy1uKouvRQ8CqliaKiWOI5QoajhLEI4j4XJ132V1giOQBWBvkfNSTA2Rb gS3A==
X-Gm-Message-State: AEkoousXTkoVA3ocqCO385Cvf/16qpCnwJxqDymZJ8TPQ87DxjcFbgzSnXwSF6yVzK7vGp3y
X-Received: by 10.233.237.203 with SMTP id c194mr33674389qkg.126.1469581896284;  Tue, 26 Jul 2016 18:11:36 -0700 (PDT)
Received: from ?IPv6:::ffff:50.95.148.144? ([50.95.148.144]) by smtp.gmail.com with ESMTPSA id j38sm2404145qtj.35.2016.07.26.18.11.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Jul 2016 18:11:35 -0700 (PDT)
Message-ID: <57980a47.e928c80a.c54fd.c891@mx.google.com>
MIME-Version: 1.0
To: Dick Hardt , Oauth Wrap Wg 
From: 
Date: Tue, 26 Jul 2016 21:11:36 -0400
Importance: normal
X-Priority: 3
In-Reply-To: <57980887.1724c80a.e1de7.c7a7@mx.google.com>
References:  <57980887.1724c80a.e1de7.c7a7@mx.google.com>
Content-Type: multipart/alternative; boundary="_F3431F28-041D-4F26-B831-E6EBBB9FEB6A_"
Archived-At: 
Subject: Re: [OAUTH-WG] URGENT: WPAD attack exposes URL contents even overHTTPS
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jul 2016 01:11:40 -0000

--_F3431F28-041D-4F26-B831-E6EBBB9FEB6A_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"

PS   Using PKCE S256 would prevent this attack on web server clients, as lo=
ng as the client uses a different PKCE vale for each request.    Even if th=
e attacker can observe both the request and response, they would not have t=
he code_verifyer and if replaying the code to the client the client will us=
e the wrong verifier value to exchange the code and will get an error.

That is probably the simplest mitigation against this for the code flow on =
web servers and native apps.

I will think about it overnight.

John B.

Sent from Mail for Windows 10

From: ve7jtb@ve7jtb.com=

--_F3431F28-041D-4F26-B831-E6EBBB9FEB6A_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="utf-8"


PS=C2=A0=C2=A0 Using PKCE S256 would=
 prevent this attack on web server clients, as long as the client uses a di=
fferent PKCE vale for each request.=C2=A0=C2=A0=C2=A0 Even if the attacker =
can observe both the request and response, they would not have the code_ver=
ifyer and if replaying the code to the client the client will use the wrong=
 verifier value to exchange the code and will get an error.
 
That is probably the sim=
plest mitigation against this for the code flow on web servers and native a=
pps.
 
I wi=
ll think about it overnight.
 
<=
p class=3DMsoNormal>John B.
 <=
/o:p>
Sent from Mail for Windows 10
<=
span style=3D'font-size:12.0pt;font-family:"Times New Roman",serif'>&n=
bsp;
From: ve7jtb@ve7jtb.com
Sent: July 26, 2016 9:04 PMTo: Dick Hardt; Oauth Wrap Wg
Subject: RE: [OAUTH-=
WG] URGENT: WPAD attack exposes URL contents even overHTTPS
http://openid.net=
/2016/07/16/preventing-mix-up-attacks-with-openid-connect/
 
I the most relevant =
current advice.
The thing to add is that the code l=
eaked in this way should not be repayable at the client 
 
I don=E2=80=99t think that =
native apps are vulnerable to this if they are using custom scheme redirect=
s.  
 
I don=E2=80=99t know what the risk is if they are using loopback or claime=
d URI.  It may be that a browser might leak them in the same way. 
=

That would need to be tested.
=
 
John B.
<=
o:p> 
 
Sent from Mail for Windows 10
 
<=
div style=3D'border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0=
cm 0cm'>
From: Dick Hardt
Sent: July 26, 2016 8:15 PM
To: <=
a href=3D"mailto:oauth@ietf.org">Oauth Wrap Wg
Subject: [OAUT=
H-WG] URGENT: WPAD attack exposes URL contents even over HTTPS
 
http://arstechnica.com/security=
/2016/07/new-attack-that-cripples-https-crypto-works-on-macs-windows-and-li=
nux/
 <=
/p>
Access tokens included as a URL query paramete=
r when accessing a resource are susceptible to this attack.
 
Authorization codes are also visible. From what I know, we have =
not depended on the confidentiality of the authorization code. 
 
=

What are the best current practices that we can point p=
eople towards to ensure they are not susceptible to this attack?=

 
-- Dick 
Subscribe to the HAR=
DTWARE mail list to learn about projects I am working on!
 
 
=

--_F3431F28-041D-4F26-B831-E6EBBB9FEB6A_--


From nobody Tue Jul 26 18:18:30 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D49CC12DA88 for ; Tue, 26 Jul 2016 18:18:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.987
X-Spam-Level: 
X-Spam-Status: No, score=-3.987 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.287, 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 d4sMVasDk_Tr for ; Tue, 26 Jul 2016 18:18:26 -0700 (PDT)
Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::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 3D01D12D597 for ; Tue, 26 Jul 2016 18:18:26 -0700 (PDT)
Received: by mail-yw0-x22c.google.com with SMTP id j12so41812167ywb.2 for ; Tue, 26 Jul 2016 18:18:26 -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=HpqUYZ0WkFphNPiZKdj4Bpx5yqQGXt1Wyk71HDetW6c=; b=cIVi80qOnyF4Vv7gd5ebTTpRhtLElTIJZbmCI8QRwaVMTAtB/Jwm+Ok86eWBt2Y9X8 Q5wSqdADKKa5sjku9b2/QUlhTI8o4/GiI8Ojf8AOffGxy1WRCowqqfDVnF79ij1VlzBo vFpY6QTV15sqI+FLOkFLlFe9OpOkPsbD19Kyb8ZMDLo1tlHW8itVpimDe/fjLvudUqbP j6UnLpOkwBjKD0YVMQ1TGOYDfzcz4EDDFsa0LRf+RMZNMLRFUG4noVOhUH6gg7c70TBq OlKfc3heD4Q25xeIWBqvxALpQLWzWCLgkPCrl/3cOaCWI1C6oageTeX/METHz4ayoRyU UUMg==
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=HpqUYZ0WkFphNPiZKdj4Bpx5yqQGXt1Wyk71HDetW6c=; b=UQnhFjpM/3rJ6pg9Pq9G87P5dnuSQ+FJg70pEbsohycNYrgdLQD2tvvB53MRhnjGyh /jQ7Lx4dhhAlZXsuV4hAX2JaPMCHtYJej3Y2u3s811aw6rpiQZmXJxbFikTOb9qavmrZ 3Es6dHLf8RfUouXeglwxfEDB3Wo5eA+339TttRzArtJLuTQwjrpONOlcyQkFJko9r6yB yVLE/TBOGwelebPUBh7m0Y5UsAuYZ/OhXO9GMjh0zTcJLr6sovQyw5Ke5h7jOknGnr6R BsQG7/AahjXXef0Fi4nmtEo9aeWUNaL1blFaxmuHsWHhvmqh55TO6GJ16eG7JTKnsBTy Su7g==
X-Gm-Message-State: AEkooutG32TwdwZ8hctpAoLWzf1kkJQrfNCtYb8b/iYx2Lti1Wea1ab6pgYWfW0QTtmZhK6STpfBECbMYocGGE0H
X-Received: by 10.37.18.11 with SMTP id 11mr22380261ybs.88.1469582305277; Tue, 26 Jul 2016 18:18:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.169.7 with HTTP; Tue, 26 Jul 2016 18:18:05 -0700 (PDT)
In-Reply-To: <57980a47.e928c80a.c54fd.c891@mx.google.com>
References:  <57980887.1724c80a.e1de7.c7a7@mx.google.com> <57980a47.e928c80a.c54fd.c891@mx.google.com>
From: William Denniss 
Date: Tue, 26 Jul 2016 18:18:05 -0700
Message-ID: 
To: John Bradley 
Content-Type: multipart/alternative; boundary=001a11c1628246a942053893cbb2
Archived-At: 
Cc: Oauth Wrap Wg 
Subject: Re: [OAUTH-WG] URGENT: WPAD attack exposes URL contents even overHTTPS
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jul 2016 01:18:29 -0000

--001a11c1628246a942053893cbb2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

PKCE S256 was indeed designed to protect against eavesdropping of both the
authorization request & response.  It was originally created for native
apps where URL leakage was deemed more likely (since it goes over
inter-process communication channels), perhaps the practice should be
expanded to all clients.

On Tue, Jul 26, 2016 at 6:11 PM,  wrote:

> PS   Using PKCE S256 would prevent this attack on web server clients, as
> long as the client uses a different PKCE vale for each request.    Even i=
f
> the attacker can observe both the request and response, they would not ha=
ve
> the code_verifyer and if replaying the code to the client the client will
> use the wrong verifier value to exchange the code and will get an error.
>
>
>
> That is probably the simplest mitigation against this for the code flow o=
n
> web servers and native apps.
>
>
>
> I will think about it overnight.
>
>
>
> John B.
>
>
>
> Sent from Mail  for
> Windows 10
>
>
>
> *From: *ve7jtb@ve7jtb.com
> *Sent: *July 26, 2016 9:04 PM
> *To: *Dick Hardt ; Oauth Wrap Wg 
> *Subject: *RE: [OAUTH-WG] URGENT: WPAD attack exposes URL contents even
> overHTTPS
>
>
>
> I need to think about it a bit,  however off the top of my head based on
> the attack described the code flow should still be safe if the code is
> truly single use.   (Some implementations fudge that)
>
>
>
> If the attacker can stop the browser from delivering the code to the
> client then the client would be susceptible to the cut and paste attack f=
or
> injecting the code back into the client.
>
>
>
> The OpenID Connect =E2=80=9Ccode id_token=E2=80=9D flow is not vulnerable=
 to this if the
> client is properly validating the id_token.
>
>
>
> I suspect that this would work against the implicit flow if the JS is
> sending the code back to its web server via a GET.
>
> That I think we recommend against doing, or should.
>
>
>
> The Token binding proposals would stop a leaked code from being used, but
> not from being stolen in this attack.
>
>
>
> The attack against a confidential client would be the cut and paste one
> that we have identified.  Currently the only mitigation we have is =E2=80=
=9Ccode
> id_token=E2=80=9D  so the blog post at.
>
> http://openid.net/2016/07/16/preventing-mix-up-attacks-with-openid-connec=
t/
>
>
>
> I the most relevant current advice.
>
> The thing to add is that the code leaked in this way should not be
> repayable at the client
>
>
>
> I don=E2=80=99t think that native apps are vulnerable to this if they are=
 using
> custom scheme redirects.
>
>
>
> I don=E2=80=99t know what the risk is if they are using loopback or claim=
ed URI.
> It may be that a browser might leak them in the same way.
>
> That would need to be tested.
>
>
>
> John B.
>
>
>
>
>
> Sent from Mail  for
> Windows 10
>
>
>
> *From: *Dick Hardt 
> *Sent: *July 26, 2016 8:15 PM
> *To: *Oauth Wrap Wg 
> *Subject: *[OAUTH-WG] URGENT: WPAD attack exposes URL contents even over
> HTTPS
>
>
>
>
> http://arstechnica.com/security/2016/07/new-attack-that-cripples-https-cr=
ypto-works-on-macs-windows-and-linux/
>
>
>
> Access tokens included as a URL query parameter when accessing a resource
> are susceptible to this attack.
>
>
>
> Authorization codes are also visible. From what I know, we have not
> depended on the confidentiality of the authorization code.
>
>
>
> What are the best current practices that we can point people towards to
> ensure they are not susceptible to this attack?
>
>
>
> -- Dick
>
> Subscribe to the HARDTWARE  mail list to learn
> about projects I am working on!
>
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

--001a11c1628246a942053893cbb2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


PKCE S256 was indeed designed to protect against eavesdrop=
ping of both the authorization request & response.=C2=A0 It was origina=
lly created for native apps where URL leakage was deemed more likely (since=
 it goes over inter-process communication channels), perhaps the practice s=
hould be expanded to all clients.


--001a11c1628246a942053893cbb2--


From nobody Tue Jul 26 23:46:30 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D106C12DD48 for ; Tue, 26 Jul 2016 23:46:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.621
X-Spam-Level: 
X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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
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 p9YJeiovhxH6 for ; Tue, 26 Jul 2016 23:46:25 -0700 (PDT)
Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.97]) (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 D3F7E12DD47 for ; Tue, 26 Jul 2016 23:46:24 -0700 (PDT)
Received: from [78.11.48.201] (helo=[172.16.3.30]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES128-GCM-SHA256:128) (Exim 4.84) (envelope-from ) id 1bSIbm-0002qS-1I; Wed, 27 Jul 2016 08:46:22 +0200
Date: Wed, 27 Jul 2016 08:45:42 +0200
Message-ID: 
In-Reply-To: 
References:  <57980887.1724c80a.e1de7.c7a7@mx.google.com> <57980a47.e928c80a.c54fd.c891@mx.google.com> 
From: "torsten@lodderstedt.net" 
To: wdenniss@google.com, John Bradley 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--_com.syntomo.email_157298224073321"
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] URGENT: WPAD attack exposes URL contents even overHTTPS
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jul 2016 06:46:29 -0000

----_com.syntomo.email_157298224073321
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64

KzEKCkkgYWxzbyB0aGluayBQS0NFIGlzIGN1cnJlbnRseSB0aGUgc2ltcGxlc3Qgd2F5IHRvIHBy
b3RlY3QgT0F1dGggY2xpZW50cyBmcm9tIGluamVjdGlvbi4KClNlbnQgYnkgTWFpbFdpc2Ug4oCT
IFNlZSB5b3VyIGVtYWlscyBhcyBjbGVhbiwgc2hvcnQgY2hhdHMuCgotLS0tLS0tLSBPcmlnaW5h
bG5hY2hyaWNodCAtLS0tLS0tLQpCZXRyZWZmOiBSZTogW09BVVRILVdHXSBVUkdFTlQ6IFdQQUQg
YXR0YWNrIGV4cG9zZXMgVVJMIGNvbnRlbnRzIGV2ZW4Jb3ZlckhUVFBTClZvbjogV2lsbGlhbSBE
ZW5uaXNzIDx3ZGVubmlzc0Bnb29nbGUuY29tPgpBbjogSm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3
anRiLmNvbT4KQ2M6IE9hdXRoIFdyYXAgV2cgPG9hdXRoQGlldGYub3JnPgoKPlBLQ0UgUzI1NiB3
YXMgaW5kZWVkIGRlc2lnbmVkIHRvIHByb3RlY3QgYWdhaW5zdCBlYXZlc2Ryb3BwaW5nIG9mIGJv
dGggdGhlCj5hdXRob3JpemF0aW9uIHJlcXVlc3QgJiByZXNwb25zZS4gIEl0IHdhcyBvcmlnaW5h
bGx5IGNyZWF0ZWQgZm9yIG5hdGl2ZQo+YXBwcyB3aGVyZSBVUkwgbGVha2FnZSB3YXMgZGVlbWVk
IG1vcmUgbGlrZWx5IChzaW5jZSBpdCBnb2VzIG92ZXIKPmludGVyLXByb2Nlc3MgY29tbXVuaWNh
dGlvbiBjaGFubmVscyksIHBlcmhhcHMgdGhlIHByYWN0aWNlIHNob3VsZCBiZQo+ZXhwYW5kZWQg
dG8gYWxsIGNsaWVudHMuCj4KPk9uIFR1ZSwgSnVsIDI2LCAyMDE2IGF0IDY6MTEgUE0sIDx2ZTdq
dGJAdmU3anRiLmNvbT4gd3JvdGU6Cj4KPj4gUFMgICBVc2luZyBQS0NFIFMyNTYgd291bGQgcHJl
dmVudCB0aGlzIGF0dGFjayBvbiB3ZWIgc2VydmVyIGNsaWVudHMsIGFzCj4+IGxvbmcgYXMgdGhl
IGNsaWVudCB1c2VzIGEgZGlmZmVyZW50IFBLQ0UgdmFsZSBmb3IgZWFjaCByZXF1ZXN0LiAgICBF
dmVuIGlmCj4+IHRoZSBhdHRhY2tlciBjYW4gb2JzZXJ2ZSBib3RoIHRoZSByZXF1ZXN0IGFuZCBy
ZXNwb25zZSwgdGhleSB3b3VsZCBub3QgaGF2ZQo+PiB0aGUgY29kZV92ZXJpZnllciBhbmQgaWYg
cmVwbGF5aW5nIHRoZSBjb2RlIHRvIHRoZSBjbGllbnQgdGhlIGNsaWVudCB3aWxsCj4+IHVzZSB0
aGUgd3JvbmcgdmVyaWZpZXIgdmFsdWUgdG8gZXhjaGFuZ2UgdGhlIGNvZGUgYW5kIHdpbGwgZ2V0
IGFuIGVycm9yLgo+Pgo+Pgo+Pgo+PiBUaGF0IGlzIHByb2JhYmx5IHRoZSBzaW1wbGVzdCBtaXRp
Z2F0aW9uIGFnYWluc3QgdGhpcyBmb3IgdGhlIGNvZGUgZmxvdyBvbgo+PiB3ZWIgc2VydmVycyBh
bmQgbmF0aXZlIGFwcHMuCj4+Cj4+Cj4+Cj4+IEkgd2lsbCB0aGluayBhYm91dCBpdCBvdmVybmln
aHQuCj4+Cj4+Cj4+Cj4+IEpvaG4gQi4KPj4KPj4KPj4KPj4gU2VudCBmcm9tIE1haWwgPGh0dHBz
Oi8vZ28ubWljcm9zb2Z0LmNvbS9md2xpbmsvP0xpbmtJZD01NTA5ODY+IGZvcgo+PiBXaW5kb3dz
IDEwCj4+Cj4+Cj4+Cj4+ICpGcm9tOiAqdmU3anRiQHZlN2p0Yi5jb20KPj4gKlNlbnQ6ICpKdWx5
IDI2LCAyMDE2IDk6MDQgUE0KPj4gKlRvOiAqRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5j
b20+OyBPYXV0aCBXcmFwIFdnIDxvYXV0aEBpZXRmLm9yZz4KPj4gKlN1YmplY3Q6ICpSRTogW09B
VVRILVdHXSBVUkdFTlQ6IFdQQUQgYXR0YWNrIGV4cG9zZXMgVVJMIGNvbnRlbnRzIGV2ZW4KPj4g
b3ZlckhUVFBTCj4+Cj4+Cj4+Cj4+IEkgbmVlZCB0byB0aGluayBhYm91dCBpdCBhIGJpdCwgIGhv
d2V2ZXIgb2ZmIHRoZSB0b3Agb2YgbXkgaGVhZCBiYXNlZCBvbgo+PiB0aGUgYXR0YWNrIGRlc2Ny
aWJlZCB0aGUgY29kZSBmbG93IHNob3VsZCBzdGlsbCBiZSBzYWZlIGlmIHRoZSBjb2RlIGlzCj4+
IHRydWx5IHNpbmdsZSB1c2UuICAgKFNvbWUgaW1wbGVtZW50YXRpb25zIGZ1ZGdlIHRoYXQpCj4+
Cj4+Cj4+Cj4+IElmIHRoZSBhdHRhY2tlciBjYW4gc3RvcCB0aGUgYnJvd3NlciBmcm9tIGRlbGl2
ZXJpbmcgdGhlIGNvZGUgdG8gdGhlCj4+IGNsaWVudCB0aGVuIHRoZSBjbGllbnQgd291bGQgYmUg
c3VzY2VwdGlibGUgdG8gdGhlIGN1dCBhbmQgcGFzdGUgYXR0YWNrIGZvcgo+PiBpbmplY3Rpbmcg
dGhlIGNvZGUgYmFjayBpbnRvIHRoZSBjbGllbnQuCj4+Cj4+Cj4+Cj4+IFRoZSBPcGVuSUQgQ29u
bmVjdCDigJxjb2RlIGlkX3Rva2Vu4oCdIGZsb3cgaXMgbm90IHZ1bG5lcmFibGUgdG8gdGhpcyBp
ZiB0aGUKPj4gY2xpZW50IGlzIHByb3Blcmx5IHZhbGlkYXRpbmcgdGhlIGlkX3Rva2VuLgo+Pgo+
Pgo+Pgo+PiBJIHN1c3BlY3QgdGhhdCB0aGlzIHdvdWxkIHdvcmsgYWdhaW5zdCB0aGUgaW1wbGlj
aXQgZmxvdyBpZiB0aGUgSlMgaXMKPj4gc2VuZGluZyB0aGUgY29kZSBiYWNrIHRvIGl0cyB3ZWIg
c2VydmVyIHZpYSBhIEdFVC4KPj4KPj4gVGhhdCBJIHRoaW5rIHdlIHJlY29tbWVuZCBhZ2FpbnN0
IGRvaW5nLCBvciBzaG91bGQuCj4+Cj4+Cj4+Cj4+IFRoZSBUb2tlbiBiaW5kaW5nIHByb3Bvc2Fs
cyB3b3VsZCBzdG9wIGEgbGVha2VkIGNvZGUgZnJvbSBiZWluZyB1c2VkLCBidXQKPj4gbm90IGZy
b20gYmVpbmcgc3RvbGVuIGluIHRoaXMgYXR0YWNrLgo+Pgo+Pgo+Pgo+PiBUaGUgYXR0YWNrIGFn
YWluc3QgYSBjb25maWRlbnRpYWwgY2xpZW50IHdvdWxkIGJlIHRoZSBjdXQgYW5kIHBhc3RlIG9u
ZQo+PiB0aGF0IHdlIGhhdmUgaWRlbnRpZmllZC4gIEN1cnJlbnRseSB0aGUgb25seSBtaXRpZ2F0
aW9uIHdlIGhhdmUgaXMg4oCcY29kZQo+PiBpZF90b2tlbuKAnSAgc28gdGhlIGJsb2cgcG9zdCBh
dC4KPj4KPj4gaHR0cDovL29wZW5pZC5uZXQvMjAxNi8wNy8xNi9wcmV2ZW50aW5nLW1peC11cC1h
dHRhY2tzLXdpdGgtb3BlbmlkLWNvbm5lY3QvCj4+Cj4+Cj4+Cj4+IEkgdGhlIG1vc3QgcmVsZXZh
bnQgY3VycmVudCBhZHZpY2UuCj4+Cj4+IFRoZSB0aGluZyB0byBhZGQgaXMgdGhhdCB0aGUgY29k
ZSBsZWFrZWQgaW4gdGhpcyB3YXkgc2hvdWxkIG5vdCBiZQo+PiByZXBheWFibGUgYXQgdGhlIGNs
aWVudAo+Pgo+Pgo+Pgo+PiBJIGRvbuKAmXQgdGhpbmsgdGhhdCBuYXRpdmUgYXBwcyBhcmUgdnVs
bmVyYWJsZSB0byB0aGlzIGlmIHRoZXkgYXJlIHVzaW5nCj4+IGN1c3RvbSBzY2hlbWUgcmVkaXJl
Y3RzLgo+Pgo+Pgo+Pgo+PiBJIGRvbuKAmXQga25vdyB3aGF0IHRoZSByaXNrIGlzIGlmIHRoZXkg
YXJlIHVzaW5nIGxvb3BiYWNrIG9yIGNsYWltZWQgVVJJLgo+PiBJdCBtYXkgYmUgdGhhdCBhIGJy
b3dzZXIgbWlnaHQgbGVhayB0aGVtIGluIHRoZSBzYW1lIHdheS4KPj4KPj4gVGhhdCB3b3VsZCBu
ZWVkIHRvIGJlIHRlc3RlZC4KPj4KPj4KPj4KPj4gSm9obiBCLgo+Pgo+Pgo+Pgo+Pgo+Pgo+PiBT
ZW50IGZyb20gTWFpbCA8aHR0cHM6Ly9nby5taWNyb3NvZnQuY29tL2Z3bGluay8/TGlua0lkPTU1
MDk4Nj4gZm9yCj4+IFdpbmRvd3MgMTAKPj4KPj4KPj4KPj4gKkZyb206ICpEaWNrIEhhcmR0IDxk
aWNrLmhhcmR0QGdtYWlsLmNvbT4KPj4gKlNlbnQ6ICpKdWx5IDI2LCAyMDE2IDg6MTUgUE0KPj4g
KlRvOiAqT2F1dGggV3JhcCBXZyA8b2F1dGhAaWV0Zi5vcmc+Cj4+ICpTdWJqZWN0OiAqW09BVVRI
LVdHXSBVUkdFTlQ6IFdQQUQgYXR0YWNrIGV4cG9zZXMgVVJMIGNvbnRlbnRzIGV2ZW4gb3Zlcgo+
PiBIVFRQUwo+Pgo+Pgo+Pgo+Pgo+PiBodHRwOi8vYXJzdGVjaG5pY2EuY29tL3NlY3VyaXR5LzIw
MTYvMDcvbmV3LWF0dGFjay10aGF0LWNyaXBwbGVzLWh0dHBzLWNyeXB0by13b3Jrcy1vbi1tYWNz
LXdpbmRvd3MtYW5kLWxpbnV4Lwo+Pgo+Pgo+Pgo+PiBBY2Nlc3MgdG9rZW5zIGluY2x1ZGVkIGFz
IGEgVVJMIHF1ZXJ5IHBhcmFtZXRlciB3aGVuIGFjY2Vzc2luZyBhIHJlc291cmNlCj4+IGFyZSBz
dXNjZXB0aWJsZSB0byB0aGlzIGF0dGFjay4KPj4KPj4KPj4KPj4gQXV0aG9yaXphdGlvbiBjb2Rl
cyBhcmUgYWxzbyB2aXNpYmxlLiBGcm9tIHdoYXQgSSBrbm93LCB3ZSBoYXZlIG5vdAo+PiBkZXBl
bmRlZCBvbiB0aGUgY29uZmlkZW50aWFsaXR5IG9mIHRoZSBhdXRob3JpemF0aW9uIGNvZGUuCj4+
Cj4+Cj4+Cj4+IFdoYXQgYXJlIHRoZSBiZXN0IGN1cnJlbnQgcHJhY3RpY2VzIHRoYXQgd2UgY2Fu
IHBvaW50IHBlb3BsZSB0b3dhcmRzIHRvCj4+IGVuc3VyZSB0aGV5IGFyZSBub3Qgc3VzY2VwdGli
bGUgdG8gdGhpcyBhdHRhY2s/Cj4+Cj4+Cj4+Cj4+IC0tIERpY2sKPj4KPj4gU3Vic2NyaWJlIHRv
IHRoZSBIQVJEVFdBUkUgPGh0dHA6Ly9oYXJkdHdhcmUuY29tLz4gbWFpbCBsaXN0IHRvIGxlYXJu
Cj4+IGFib3V0IHByb2plY3RzIEkgYW0gd29ya2luZyBvbiEKPj4KPj4KPj4KPj4KPj4KPj4gX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPj4gT0F1dGggbWFp
bGluZyBsaXN0Cj4+IE9BdXRoQGlldGYub3JnCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vb2F1dGgKPj4KPj4KPgo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18KPk9BdXRoIG1haWxpbmcgbGlzdAo+T0F1dGhAaWV0Zi5vcmcKPmh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgKPg==
----_com.syntomo.email_157298224073321
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64

PHAgZGlyPSJsdHIiPisxPC9wPgo8cCBkaXI9Imx0ciI+SSBhbHNvIHRoaW5rIFBLQ0UgaXMgY3Vy
cmVudGx5IHRoZSBzaW1wbGVzdCB3YXkgdG8gcHJvdGVjdCBPQXV0aCBjbGllbnRzIGZyb20gaW5q
ZWN0aW9uLjwvcD4KPHAgZGlyPSJsdHIiPlNlbnQgYnkgPGEgaHJlZj1odHRwOi8vd3d3Lm1haWwt
d2lzZS5jb20vaW5zdGFsbGF0aW9uLzI+TWFpbFdpc2U8L2E+ICYjODIxMTsgU2VlIHlvdXIgZW1h
aWxzIGFzIGNsZWFuLCBzaG9ydCBjaGF0cy48L3A+Cjxicj48YnI+LS0tLS0tLS0gT3JpZ2luYWxu
YWNocmljaHQgLS0tLS0tLS08YnI+QmV0cmVmZjogUmU6IFtPQVVUSC1XR10gVVJHRU5UOiBXUEFE
IGF0dGFjayBleHBvc2VzIFVSTCBjb250ZW50cyBldmVuCW92ZXJIVFRQUzxicj5Wb246IFdpbGxp
YW0gRGVubmlzcyAmbHQ7d2Rlbm5pc3NAZ29vZ2xlLmNvbSZndDs8YnI+QW46IEpvaG4gQnJhZGxl
eSAmbHQ7dmU3anRiQHZlN2p0Yi5jb20mZ3Q7PGJyPkNjOiBPYXV0aCBXcmFwIFdnICZsdDtvYXV0
aEBpZXRmLm9yZyZndDs8YnI+PGJyPjxkaXYgZGlyPSJsdHIiPlBLQ0UgUzI1NiB3YXMgaW5kZWVk
IGRlc2lnbmVkIHRvIHByb3RlY3QgYWdhaW5zdCBlYXZlc2Ryb3BwaW5nIG9mIGJvdGggdGhlIGF1
dGhvcml6YXRpb24gcmVxdWVzdCAmYW1wOyByZXNwb25zZS7CoCBJdCB3YXMgb3JpZ2luYWxseSBj
cmVhdGVkIGZvciBuYXRpdmUgYXBwcyB3aGVyZSBVUkwgbGVha2FnZSB3YXMgZGVlbWVkIG1vcmUg
bGlrZWx5IChzaW5jZSBpdCBnb2VzIG92ZXIgaW50ZXItcHJvY2VzcyBjb21tdW5pY2F0aW9uIGNo
YW5uZWxzKSwgcGVyaGFwcyB0aGUgcHJhY3RpY2Ugc2hvdWxkIGJlIGV4cGFuZGVkIHRvIGFsbCBj
bGllbnRzLjwvZGl2PjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+PGRpdiBjbGFzcz0iZ21h
aWxfcXVvdGUiPk9uIFR1ZSwgSnVsIDI2LCAyMDE2IGF0IDY6MTEgUE0sICA8c3BhbiBkaXI9Imx0
ciI+Jmx0OzxhIGhyZWY9Im1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbSIgdGFyZ2V0PSJfYmxhbmsi
PnZlN2p0YkB2ZTdqdGIuY29tPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj48YmxvY2txdW90ZSBj
bGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDox
cHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij48ZGl2IGxhbmc9IkVOLUNBIiBsaW5rPSJi
bHVlIiB2bGluaz0iIzk1NEY3MiI+PGRpdiBjbGFzcz0ibV8tNTY4NzYwODY1NTg3Njg2NTk1NFdv
cmRTZWN0aW9uMSI+PHAgY2xhc3M9Ik1zb05vcm1hbCI+UFPCoMKgIFVzaW5nIFBLQ0UgUzI1NiB3
b3VsZCBwcmV2ZW50IHRoaXMgYXR0YWNrIG9uIHdlYiBzZXJ2ZXIgY2xpZW50cywgYXMgbG9uZyBh
cyB0aGUgY2xpZW50IHVzZXMgYSBkaWZmZXJlbnQgUEtDRSB2YWxlIGZvciBlYWNoIHJlcXVlc3Qu
wqDCoMKgIEV2ZW4gaWYgdGhlIGF0dGFja2VyIGNhbiBvYnNlcnZlIGJvdGggdGhlIHJlcXVlc3Qg
YW5kIHJlc3BvbnNlLCB0aGV5IHdvdWxkIG5vdCBoYXZlIHRoZSBjb2RlX3ZlcmlmeWVyIGFuZCBp
ZiByZXBsYXlpbmcgdGhlIGNvZGUgdG8gdGhlIGNsaWVudCB0aGUgY2xpZW50IHdpbGwgdXNlIHRo
ZSB3cm9uZyB2ZXJpZmllciB2YWx1ZSB0byBleGNoYW5nZSB0aGUgY29kZSBhbmQgd2lsbCBnZXQg
YW4gZXJyb3IuPC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjx1PjwvdT7CoDx1PjwvdT48L3A+PHAg
Y2xhc3M9Ik1zb05vcm1hbCI+VGhhdCBpcyBwcm9iYWJseSB0aGUgc2ltcGxlc3QgbWl0aWdhdGlv
biBhZ2FpbnN0IHRoaXMgZm9yIHRoZSBjb2RlIGZsb3cgb24gd2ViIHNlcnZlcnMgYW5kIG5hdGl2
ZSBhcHBzLjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48dT48L3U+wqA8dT48L3U+PC9wPjxwIGNs
YXNzPSJNc29Ob3JtYWwiPkkgd2lsbCB0aGluayBhYm91dCBpdCBvdmVybmlnaHQuPC9wPjxzcGFu
IGNsYXNzPSIiPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjx1PjwvdT7CoDx1PjwvdT48L3A+PHAgY2xh
c3M9Ik1zb05vcm1hbCI+Sm9obiBCLjx1PjwvdT48dT48L3U+PC9wPjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjx1PjwvdT7CoDx1PjwvdT48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+U2VudCBmcm9tIDxh
IGhyZWY9Imh0dHBzOi8vZ28ubWljcm9zb2Z0LmNvbS9md2xpbmsvP0xpbmtJZD01NTA5ODYiIHRh
cmdldD0iX2JsYW5rIj5NYWlsPC9hPiBmb3IgV2luZG93cyAxMDwvcD48cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1l
cyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPjx1PjwvdT7CoDx1PjwvdT48L3NwYW4+PC9wPjwvc3Bh
bj48ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNlMWUxZTEgMS4wcHQ7
cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJv
cmRlcjpub25lO3BhZGRpbmc6MGNtIj48Yj5Gcm9tOiA8L2I+PGEgaHJlZj0ibWFpbHRvOnZlN2p0
YkB2ZTdqdGIuY29tIiB0YXJnZXQ9Il9ibGFuayI+dmU3anRiQHZlN2p0Yi5jb208L2E+PGJyPjxi
PlNlbnQ6IDwvYj5KdWx5IDI2LCAyMDE2IDk6MDQgUE08YnI+PGI+VG86IDwvYj48YSBocmVmPSJt
YWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5EaWNrIEhhcmR0PC9h
PjsgPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T2F1dGgg
V3JhcCBXZzwvYT48YnI+PGI+U3ViamVjdDogPC9iPlJFOiBbT0FVVEgtV0ddIFVSR0VOVDogV1BB
RCBhdHRhY2sgZXhwb3NlcyBVUkwgY29udGVudHMgZXZlbiBvdmVySFRUUFM8L3A+PC9kaXY+PGRp
dj48ZGl2IGNsYXNzPSJoNSI+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlm
Ij48dT48L3U+wqA8dT48L3U+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj5JIG5lZWQg
dG8gdGhpbmsgYWJvdXQgaXQgYSBiaXQswqAgaG93ZXZlciBvZmYgdGhlIHRvcCBvZiBteSBoZWFk
IGJhc2VkIG9uIHRoZSBhdHRhY2sgZGVzY3JpYmVkIHRoZSBjb2RlIGZsb3cgc2hvdWxkIHN0aWxs
IGJlIHNhZmUgaWYgdGhlIGNvZGUgaXMgdHJ1bHkgc2luZ2xlIHVzZS7CoMKgIChTb21lIGltcGxl
bWVudGF0aW9ucyBmdWRnZSB0aGF0KTwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48dT48L3U+wqA8
dT48L3U+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHRoZSBhdHRhY2tlciBjYW4gc3RvcCB0
aGUgYnJvd3NlciBmcm9tIGRlbGl2ZXJpbmcgdGhlIGNvZGUgdG8gdGhlIGNsaWVudCB0aGVuIHRo
ZSBjbGllbnQgd291bGQgYmUgc3VzY2VwdGlibGUgdG8gdGhlIGN1dCBhbmQgcGFzdGUgYXR0YWNr
IGZvciBpbmplY3RpbmcgdGhlIGNvZGUgYmFjayBpbnRvIHRoZSBjbGllbnQuwqAgPC9wPjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjx1PjwvdT7CoDx1PjwvdT48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+
VGhlIE9wZW5JRCBDb25uZWN0IOKAnGNvZGUgaWRfdG9rZW7igJ0gZmxvdyBpcyBub3QgdnVsbmVy
YWJsZSB0byB0aGlzIGlmIHRoZSBjbGllbnQgaXMgcHJvcGVybHkgdmFsaWRhdGluZyB0aGUgaWRf
dG9rZW4uPC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjx1PjwvdT7CoDx1PjwvdT48L3A+PHAgY2xh
c3M9Ik1zb05vcm1hbCI+SSBzdXNwZWN0IHRoYXQgdGhpcyB3b3VsZCB3b3JrIGFnYWluc3QgdGhl
IGltcGxpY2l0IGZsb3cgaWYgdGhlIEpTIGlzIHNlbmRpbmcgdGhlIGNvZGUgYmFjayB0byBpdHMg
d2ViIHNlcnZlciB2aWEgYSBHRVQuwqAgPC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYXQgSSB0
aGluayB3ZSByZWNvbW1lbmQgYWdhaW5zdCBkb2luZywgb3Igc2hvdWxkLjwvcD48cCBjbGFzcz0i
TXNvTm9ybWFsIj48dT48L3U+wqA8dT48L3U+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBU
b2tlbiBiaW5kaW5nIHByb3Bvc2FscyB3b3VsZCBzdG9wIGEgbGVha2VkIGNvZGUgZnJvbSBiZWlu
ZyB1c2VkLCBidXQgbm90IGZyb20gYmVpbmcgc3RvbGVuIGluIHRoaXMgYXR0YWNrLjwvcD48cCBj
bGFzcz0iTXNvTm9ybWFsIj48dT48L3U+wqA8dT48L3U+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwi
PlRoZSBhdHRhY2sgYWdhaW5zdCBhIGNvbmZpZGVudGlhbCBjbGllbnQgd291bGQgYmUgdGhlIGN1
dCBhbmQgcGFzdGUgb25lIHRoYXQgd2UgaGF2ZSBpZGVudGlmaWVkLsKgIEN1cnJlbnRseSB0aGUg
b25seSBtaXRpZ2F0aW9uIHdlIGhhdmUgaXMg4oCcY29kZSBpZF90b2tlbuKAncKgIHNvIHRoZSBi
bG9nIHBvc3QgYXQuPC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHA6Ly9vcGVu
aWQubmV0LzIwMTYvMDcvMTYvcHJldmVudGluZy1taXgtdXAtYXR0YWNrcy13aXRoLW9wZW5pZC1j
b25uZWN0LyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9vcGVuaWQubmV0LzIwMTYvMDcvMTYvcHJl
dmVudGluZy1taXgtdXAtYXR0YWNrcy13aXRoLW9wZW5pZC1jb25uZWN0LzwvYT48L3A+PHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHU+PC91PsKgPHU+PC91PjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj5J
IHRoZSBtb3N0IHJlbGV2YW50IGN1cnJlbnQgYWR2aWNlLjwvcD48cCBjbGFzcz0iTXNvTm9ybWFs
Ij5UaGUgdGhpbmcgdG8gYWRkIGlzIHRoYXQgdGhlIGNvZGUgbGVha2VkIGluIHRoaXMgd2F5IHNo
b3VsZCBub3QgYmUgcmVwYXlhYmxlIGF0IHRoZSBjbGllbnQgPC9wPjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjx1PjwvdT7CoDx1PjwvdT48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkb27igJl0IHRo
aW5rIHRoYXQgbmF0aXZlIGFwcHMgYXJlIHZ1bG5lcmFibGUgdG8gdGhpcyBpZiB0aGV5IGFyZSB1
c2luZyBjdXN0b20gc2NoZW1lIHJlZGlyZWN0cy7CoCA8L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHU+PC91PsKgPHU+PC91PjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRvbuKAmXQga25vdyB3
aGF0IHRoZSByaXNrIGlzIGlmIHRoZXkgYXJlIHVzaW5nIGxvb3BiYWNrIG9yIGNsYWltZWQgVVJJ
LsKgIEl0IG1heSBiZSB0aGF0IGEgYnJvd3NlciBtaWdodCBsZWFrIHRoZW0gaW4gdGhlIHNhbWUg
d2F5LiA8L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhdCB3b3VsZCBuZWVkIHRvIGJlIHRlc3Rl
ZC48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHU+PC91PsKgPHU+PC91PjwvcD48cCBjbGFzcz0i
TXNvTm9ybWFsIj5Kb2huIEIuPC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjx1PjwvdT7CoDx1Pjwv
dT48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHU+PC91PsKgPHU+PC91PjwvcD48cCBjbGFzcz0i
TXNvTm9ybWFsIj5TZW50IGZyb20gPGEgaHJlZj0iaHR0cHM6Ly9nby5taWNyb3NvZnQuY29tL2Z3
bGluay8/TGlua0lkPTU1MDk4NiIgdGFyZ2V0PSJfYmxhbmsiPk1haWw8L2E+IGZvciBXaW5kb3dz
IDEwPC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+PHU+PC91PsKg
PHU+PC91Pjwvc3Bhbj48L3A+PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp
ZCAjZTFlMWUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxiPkZyb206IDwvYj48YSBocmVmPSJtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20i
IHRhcmdldD0iX2JsYW5rIj5EaWNrIEhhcmR0PC9hPjxicj48Yj5TZW50OiA8L2I+SnVseSAyNiwg
MjAxNiA4OjE1IFBNPGJyPjxiPlRvOiA8L2I+PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3Jn
IiB0YXJnZXQ9Il9ibGFuayI+T2F1dGggV3JhcCBXZzwvYT48YnI+PGI+U3ViamVjdDogPC9iPltP
QVVUSC1XR10gVVJHRU5UOiBXUEFEIGF0dGFjayBleHBvc2VzIFVSTCBjb250ZW50cyBldmVuIG92
ZXIgSFRUUFM8dT48L3U+PHU+PC91PjwvcD48L2Rpdj48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t
YW4mcXVvdDssc2VyaWYiPjx1PjwvdT7CoDx1PjwvdT48L3NwYW4+PC9wPjxkaXY+PHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj48YSBocmVmPSJodHRwOi8vYXJzdGVjaG5p
Y2EuY29tL3NlY3VyaXR5LzIwMTYvMDcvbmV3LWF0dGFjay10aGF0LWNyaXBwbGVzLWh0dHBzLWNy
eXB0by13b3Jrcy1vbi1tYWNzLXdpbmRvd3MtYW5kLWxpbnV4LyIgdGFyZ2V0PSJfYmxhbmsiPmh0
dHA6Ly9hcnN0ZWNobmljYS5jb20vc2VjdXJpdHkvMjAxNi8wNy9uZXctYXR0YWNrLXRoYXQtY3Jp
cHBsZXMtaHR0cHMtY3J5cHRvLXdvcmtzLW9uLW1hY3Mtd2luZG93cy1hbmQtbGludXgvPC9hPjx1
PjwvdT48dT48L3U+PC9zcGFuPjwvcD48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx
dW90OyxzZXJpZiI+PHU+PC91PsKgPHU+PC91Pjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTom
cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPkFjY2VzcyB0b2tlbnMgaW5jbHVkZWQg
YXMgYSBVUkwgcXVlcnkgcGFyYW1ldGVyIHdoZW4gYWNjZXNzaW5nIGEgcmVzb3VyY2UgYXJlIHN1
c2NlcHRpYmxlIHRvIHRoaXMgYXR0YWNrLjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD48L2Rpdj48
ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+PHU+PC91PsKgPHU+
PC91Pjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv
dDssc2VyaWYiPkF1dGhvcml6YXRpb24gY29kZXMgYXJlIGFsc28gdmlzaWJsZS4gRnJvbSB3aGF0
IEkga25vdywgd2UgaGF2ZSBub3QgZGVwZW5kZWQgb24gdGhlIGNvbmZpZGVudGlhbGl0eSBvZiB0
aGUgYXV0aG9yaXphdGlvbiBjb2RlLsKgPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPjwvZGl2Pjxk
aXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj48dT48L3U+wqA8dT48
L3U+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90
OyxzZXJpZiI+V2hhdCBhcmUgdGhlIGJlc3QgY3VycmVudCBwcmFjdGljZXMgdGhhdCB3ZSBjYW4g
cG9pbnQgcGVvcGxlIHRvd2FyZHMgdG8gZW5zdXJlIHRoZXkgYXJlIG5vdCBzdXNjZXB0aWJsZSB0
byB0aGlzIGF0dGFjaz88dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTom
cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPjx1PjwvdT7CoDx1PjwvdT48L3NwYW4+
PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4t
LSBEaWNrwqA8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5TdWJzY3JpYmUgdG8gdGhlIDxhIGhyZWY9Imh0
dHA6Ly9oYXJkdHdhcmUuY29tLyIgdGFyZ2V0PSJfYmxhbmsiPkhBUkRUV0FSRTwvYT4gbWFpbCBs
aXN0IHRvIGxlYXJuIGFib3V0IHByb2plY3RzIEkgYW0gd29ya2luZyBvbiE8dT48L3U+PHU+PC91
Pjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHU+PC91PsKgPHU+PC91PjwvcD48cCBj
bGFzcz0iTXNvTm9ybWFsIj48dT48L3U+wqA8dT48L3U+PC9wPjwvZGl2PjwvZGl2PjwvZGl2Pjwv
ZGl2Pjxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi
cj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9y
ZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9vYXV0aCIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48YnI+DQo8YnI+
PC9ibG9ja3F1b3RlPjwvZGl2Pjxicj48L2Rpdj4NCg==
----_com.syntomo.email_157298224073321--


From nobody Tue Jul 26 23:46:34 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D05FE12DD47 for ; Tue, 26 Jul 2016 23:46:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.621
X-Spam-Level: 
X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 PpC-pLP5gqrF for ; Tue, 26 Jul 2016 23:46:25 -0700 (PDT)
Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.32]) (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 D3DD212DD46 for ; Tue, 26 Jul 2016 23:46:24 -0700 (PDT)
Received: from [78.11.48.201] (helo=[172.16.3.30]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES128-GCM-SHA256:128) (Exim 4.84) (envelope-from ) id 1bSIbl-0001wz-Jh; Wed, 27 Jul 2016 08:46:21 +0200
Date: Wed, 27 Jul 2016 08:45:42 +0200
Message-ID: 
In-Reply-To: 
References:  <57980887.1724c80a.e1de7.c7a7@mx.google.com> <57980a47.e928c80a.c54fd.c891@mx.google.com> 
From: "torsten@lodderstedt.net" 
To: wdenniss@google.com, John Bradley 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--_com.syntomo.email_157292972712490"
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] URGENT: WPAD attack exposes URL contents even overHTTPS
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jul 2016 06:46:30 -0000

----_com.syntomo.email_157292972712490
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64

KzEKCkkgYWxzbyB0aGluayBQS0NFIGlzIGN1cnJlbnRseSB0aGUgc2ltcGxlc3Qgd2F5IHRvIHBy
b3RlY3QgT0F1dGggY2xpZW50cyBmcm9tIGluamVjdGlvbi4KClNlbnQgYnkgTWFpbFdpc2Ug4oCT
IFNlZSB5b3VyIGVtYWlscyBhcyBjbGVhbiwgc2hvcnQgY2hhdHMuCgotLS0tLS0tLSBPcmlnaW5h
bG5hY2hyaWNodCAtLS0tLS0tLQpCZXRyZWZmOiBSZTogW09BVVRILVdHXSBVUkdFTlQ6IFdQQUQg
YXR0YWNrIGV4cG9zZXMgVVJMIGNvbnRlbnRzIGV2ZW4Jb3ZlckhUVFBTClZvbjogV2lsbGlhbSBE
ZW5uaXNzIDx3ZGVubmlzc0Bnb29nbGUuY29tPgpBbjogSm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3
anRiLmNvbT4KQ2M6IE9hdXRoIFdyYXAgV2cgPG9hdXRoQGlldGYub3JnPgoKPlBLQ0UgUzI1NiB3
YXMgaW5kZWVkIGRlc2lnbmVkIHRvIHByb3RlY3QgYWdhaW5zdCBlYXZlc2Ryb3BwaW5nIG9mIGJv
dGggdGhlCj5hdXRob3JpemF0aW9uIHJlcXVlc3QgJiByZXNwb25zZS4gIEl0IHdhcyBvcmlnaW5h
bGx5IGNyZWF0ZWQgZm9yIG5hdGl2ZQo+YXBwcyB3aGVyZSBVUkwgbGVha2FnZSB3YXMgZGVlbWVk
IG1vcmUgbGlrZWx5IChzaW5jZSBpdCBnb2VzIG92ZXIKPmludGVyLXByb2Nlc3MgY29tbXVuaWNh
dGlvbiBjaGFubmVscyksIHBlcmhhcHMgdGhlIHByYWN0aWNlIHNob3VsZCBiZQo+ZXhwYW5kZWQg
dG8gYWxsIGNsaWVudHMuCj4KPk9uIFR1ZSwgSnVsIDI2LCAyMDE2IGF0IDY6MTEgUE0sIDx2ZTdq
dGJAdmU3anRiLmNvbT4gd3JvdGU6Cj4KPj4gUFMgICBVc2luZyBQS0NFIFMyNTYgd291bGQgcHJl
dmVudCB0aGlzIGF0dGFjayBvbiB3ZWIgc2VydmVyIGNsaWVudHMsIGFzCj4+IGxvbmcgYXMgdGhl
IGNsaWVudCB1c2VzIGEgZGlmZmVyZW50IFBLQ0UgdmFsZSBmb3IgZWFjaCByZXF1ZXN0LiAgICBF
dmVuIGlmCj4+IHRoZSBhdHRhY2tlciBjYW4gb2JzZXJ2ZSBib3RoIHRoZSByZXF1ZXN0IGFuZCBy
ZXNwb25zZSwgdGhleSB3b3VsZCBub3QgaGF2ZQo+PiB0aGUgY29kZV92ZXJpZnllciBhbmQgaWYg
cmVwbGF5aW5nIHRoZSBjb2RlIHRvIHRoZSBjbGllbnQgdGhlIGNsaWVudCB3aWxsCj4+IHVzZSB0
aGUgd3JvbmcgdmVyaWZpZXIgdmFsdWUgdG8gZXhjaGFuZ2UgdGhlIGNvZGUgYW5kIHdpbGwgZ2V0
IGFuIGVycm9yLgo+Pgo+Pgo+Pgo+PiBUaGF0IGlzIHByb2JhYmx5IHRoZSBzaW1wbGVzdCBtaXRp
Z2F0aW9uIGFnYWluc3QgdGhpcyBmb3IgdGhlIGNvZGUgZmxvdyBvbgo+PiB3ZWIgc2VydmVycyBh
bmQgbmF0aXZlIGFwcHMuCj4+Cj4+Cj4+Cj4+IEkgd2lsbCB0aGluayBhYm91dCBpdCBvdmVybmln
aHQuCj4+Cj4+Cj4+Cj4+IEpvaG4gQi4KPj4KPj4KPj4KPj4gU2VudCBmcm9tIE1haWwgPGh0dHBz
Oi8vZ28ubWljcm9zb2Z0LmNvbS9md2xpbmsvP0xpbmtJZD01NTA5ODY+IGZvcgo+PiBXaW5kb3dz
IDEwCj4+Cj4+Cj4+Cj4+ICpGcm9tOiAqdmU3anRiQHZlN2p0Yi5jb20KPj4gKlNlbnQ6ICpKdWx5
IDI2LCAyMDE2IDk6MDQgUE0KPj4gKlRvOiAqRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5j
b20+OyBPYXV0aCBXcmFwIFdnIDxvYXV0aEBpZXRmLm9yZz4KPj4gKlN1YmplY3Q6ICpSRTogW09B
VVRILVdHXSBVUkdFTlQ6IFdQQUQgYXR0YWNrIGV4cG9zZXMgVVJMIGNvbnRlbnRzIGV2ZW4KPj4g
b3ZlckhUVFBTCj4+Cj4+Cj4+Cj4+IEkgbmVlZCB0byB0aGluayBhYm91dCBpdCBhIGJpdCwgIGhv
d2V2ZXIgb2ZmIHRoZSB0b3Agb2YgbXkgaGVhZCBiYXNlZCBvbgo+PiB0aGUgYXR0YWNrIGRlc2Ny
aWJlZCB0aGUgY29kZSBmbG93IHNob3VsZCBzdGlsbCBiZSBzYWZlIGlmIHRoZSBjb2RlIGlzCj4+
IHRydWx5IHNpbmdsZSB1c2UuICAgKFNvbWUgaW1wbGVtZW50YXRpb25zIGZ1ZGdlIHRoYXQpCj4+
Cj4+Cj4+Cj4+IElmIHRoZSBhdHRhY2tlciBjYW4gc3RvcCB0aGUgYnJvd3NlciBmcm9tIGRlbGl2
ZXJpbmcgdGhlIGNvZGUgdG8gdGhlCj4+IGNsaWVudCB0aGVuIHRoZSBjbGllbnQgd291bGQgYmUg
c3VzY2VwdGlibGUgdG8gdGhlIGN1dCBhbmQgcGFzdGUgYXR0YWNrIGZvcgo+PiBpbmplY3Rpbmcg
dGhlIGNvZGUgYmFjayBpbnRvIHRoZSBjbGllbnQuCj4+Cj4+Cj4+Cj4+IFRoZSBPcGVuSUQgQ29u
bmVjdCDigJxjb2RlIGlkX3Rva2Vu4oCdIGZsb3cgaXMgbm90IHZ1bG5lcmFibGUgdG8gdGhpcyBp
ZiB0aGUKPj4gY2xpZW50IGlzIHByb3Blcmx5IHZhbGlkYXRpbmcgdGhlIGlkX3Rva2VuLgo+Pgo+
Pgo+Pgo+PiBJIHN1c3BlY3QgdGhhdCB0aGlzIHdvdWxkIHdvcmsgYWdhaW5zdCB0aGUgaW1wbGlj
aXQgZmxvdyBpZiB0aGUgSlMgaXMKPj4gc2VuZGluZyB0aGUgY29kZSBiYWNrIHRvIGl0cyB3ZWIg
c2VydmVyIHZpYSBhIEdFVC4KPj4KPj4gVGhhdCBJIHRoaW5rIHdlIHJlY29tbWVuZCBhZ2FpbnN0
IGRvaW5nLCBvciBzaG91bGQuCj4+Cj4+Cj4+Cj4+IFRoZSBUb2tlbiBiaW5kaW5nIHByb3Bvc2Fs
cyB3b3VsZCBzdG9wIGEgbGVha2VkIGNvZGUgZnJvbSBiZWluZyB1c2VkLCBidXQKPj4gbm90IGZy
b20gYmVpbmcgc3RvbGVuIGluIHRoaXMgYXR0YWNrLgo+Pgo+Pgo+Pgo+PiBUaGUgYXR0YWNrIGFn
YWluc3QgYSBjb25maWRlbnRpYWwgY2xpZW50IHdvdWxkIGJlIHRoZSBjdXQgYW5kIHBhc3RlIG9u
ZQo+PiB0aGF0IHdlIGhhdmUgaWRlbnRpZmllZC4gIEN1cnJlbnRseSB0aGUgb25seSBtaXRpZ2F0
aW9uIHdlIGhhdmUgaXMg4oCcY29kZQo+PiBpZF90b2tlbuKAnSAgc28gdGhlIGJsb2cgcG9zdCBh
dC4KPj4KPj4gaHR0cDovL29wZW5pZC5uZXQvMjAxNi8wNy8xNi9wcmV2ZW50aW5nLW1peC11cC1h
dHRhY2tzLXdpdGgtb3BlbmlkLWNvbm5lY3QvCj4+Cj4+Cj4+Cj4+IEkgdGhlIG1vc3QgcmVsZXZh
bnQgY3VycmVudCBhZHZpY2UuCj4+Cj4+IFRoZSB0aGluZyB0byBhZGQgaXMgdGhhdCB0aGUgY29k
ZSBsZWFrZWQgaW4gdGhpcyB3YXkgc2hvdWxkIG5vdCBiZQo+PiByZXBheWFibGUgYXQgdGhlIGNs
aWVudAo+Pgo+Pgo+Pgo+PiBJIGRvbuKAmXQgdGhpbmsgdGhhdCBuYXRpdmUgYXBwcyBhcmUgdnVs
bmVyYWJsZSB0byB0aGlzIGlmIHRoZXkgYXJlIHVzaW5nCj4+IGN1c3RvbSBzY2hlbWUgcmVkaXJl
Y3RzLgo+Pgo+Pgo+Pgo+PiBJIGRvbuKAmXQga25vdyB3aGF0IHRoZSByaXNrIGlzIGlmIHRoZXkg
YXJlIHVzaW5nIGxvb3BiYWNrIG9yIGNsYWltZWQgVVJJLgo+PiBJdCBtYXkgYmUgdGhhdCBhIGJy
b3dzZXIgbWlnaHQgbGVhayB0aGVtIGluIHRoZSBzYW1lIHdheS4KPj4KPj4gVGhhdCB3b3VsZCBu
ZWVkIHRvIGJlIHRlc3RlZC4KPj4KPj4KPj4KPj4gSm9obiBCLgo+Pgo+Pgo+Pgo+Pgo+Pgo+PiBT
ZW50IGZyb20gTWFpbCA8aHR0cHM6Ly9nby5taWNyb3NvZnQuY29tL2Z3bGluay8/TGlua0lkPTU1
MDk4Nj4gZm9yCj4+IFdpbmRvd3MgMTAKPj4KPj4KPj4KPj4gKkZyb206ICpEaWNrIEhhcmR0IDxk
aWNrLmhhcmR0QGdtYWlsLmNvbT4KPj4gKlNlbnQ6ICpKdWx5IDI2LCAyMDE2IDg6MTUgUE0KPj4g
KlRvOiAqT2F1dGggV3JhcCBXZyA8b2F1dGhAaWV0Zi5vcmc+Cj4+ICpTdWJqZWN0OiAqW09BVVRI
LVdHXSBVUkdFTlQ6IFdQQUQgYXR0YWNrIGV4cG9zZXMgVVJMIGNvbnRlbnRzIGV2ZW4gb3Zlcgo+
PiBIVFRQUwo+Pgo+Pgo+Pgo+Pgo+PiBodHRwOi8vYXJzdGVjaG5pY2EuY29tL3NlY3VyaXR5LzIw
MTYvMDcvbmV3LWF0dGFjay10aGF0LWNyaXBwbGVzLWh0dHBzLWNyeXB0by13b3Jrcy1vbi1tYWNz
LXdpbmRvd3MtYW5kLWxpbnV4Lwo+Pgo+Pgo+Pgo+PiBBY2Nlc3MgdG9rZW5zIGluY2x1ZGVkIGFz
IGEgVVJMIHF1ZXJ5IHBhcmFtZXRlciB3aGVuIGFjY2Vzc2luZyBhIHJlc291cmNlCj4+IGFyZSBz
dXNjZXB0aWJsZSB0byB0aGlzIGF0dGFjay4KPj4KPj4KPj4KPj4gQXV0aG9yaXphdGlvbiBjb2Rl
cyBhcmUgYWxzbyB2aXNpYmxlLiBGcm9tIHdoYXQgSSBrbm93LCB3ZSBoYXZlIG5vdAo+PiBkZXBl
bmRlZCBvbiB0aGUgY29uZmlkZW50aWFsaXR5IG9mIHRoZSBhdXRob3JpemF0aW9uIGNvZGUuCj4+
Cj4+Cj4+Cj4+IFdoYXQgYXJlIHRoZSBiZXN0IGN1cnJlbnQgcHJhY3RpY2VzIHRoYXQgd2UgY2Fu
IHBvaW50IHBlb3BsZSB0b3dhcmRzIHRvCj4+IGVuc3VyZSB0aGV5IGFyZSBub3Qgc3VzY2VwdGli
bGUgdG8gdGhpcyBhdHRhY2s/Cj4+Cj4+Cj4+Cj4+IC0tIERpY2sKPj4KPj4gU3Vic2NyaWJlIHRv
IHRoZSBIQVJEVFdBUkUgPGh0dHA6Ly9oYXJkdHdhcmUuY29tLz4gbWFpbCBsaXN0IHRvIGxlYXJu
Cj4+IGFib3V0IHByb2plY3RzIEkgYW0gd29ya2luZyBvbiEKPj4KPj4KPj4KPj4KPj4KPj4gX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPj4gT0F1dGggbWFp
bGluZyBsaXN0Cj4+IE9BdXRoQGlldGYub3JnCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vb2F1dGgKPj4KPj4KPgo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18KPk9BdXRoIG1haWxpbmcgbGlzdAo+T0F1dGhAaWV0Zi5vcmcKPmh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgK
----_com.syntomo.email_157292972712490
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64

PHAgZGlyPSJsdHIiPisxPC9wPgo8cCBkaXI9Imx0ciI+SSBhbHNvIHRoaW5rIFBLQ0UgaXMgY3Vy
cmVudGx5IHRoZSBzaW1wbGVzdCB3YXkgdG8gcHJvdGVjdCBPQXV0aCBjbGllbnRzIGZyb20gaW5q
ZWN0aW9uLjwvcD4KPHAgZGlyPSJsdHIiPlNlbnQgYnkgPGEgaHJlZj1odHRwOi8vd3d3Lm1haWwt
d2lzZS5jb20vaW5zdGFsbGF0aW9uLzI+TWFpbFdpc2U8L2E+ICYjODIxMTsgU2VlIHlvdXIgZW1h
aWxzIGFzIGNsZWFuLCBzaG9ydCBjaGF0cy48L3A+Cjxicj48YnI+LS0tLS0tLS0gT3JpZ2luYWxu
YWNocmljaHQgLS0tLS0tLS08YnI+QmV0cmVmZjogUmU6IFtPQVVUSC1XR10gVVJHRU5UOiBXUEFE
IGF0dGFjayBleHBvc2VzIFVSTCBjb250ZW50cyBldmVuCW92ZXJIVFRQUzxicj5Wb246IFdpbGxp
YW0gRGVubmlzcyAmbHQ7d2Rlbm5pc3NAZ29vZ2xlLmNvbSZndDs8YnI+QW46IEpvaG4gQnJhZGxl
eSAmbHQ7dmU3anRiQHZlN2p0Yi5jb20mZ3Q7PGJyPkNjOiBPYXV0aCBXcmFwIFdnICZsdDtvYXV0
aEBpZXRmLm9yZyZndDs8YnI+PGJyPjxkaXYgZGlyPSJsdHIiPlBLQ0UgUzI1NiB3YXMgaW5kZWVk
IGRlc2lnbmVkIHRvIHByb3RlY3QgYWdhaW5zdCBlYXZlc2Ryb3BwaW5nIG9mIGJvdGggdGhlIGF1
dGhvcml6YXRpb24gcmVxdWVzdCAmYW1wOyByZXNwb25zZS7CoCBJdCB3YXMgb3JpZ2luYWxseSBj
cmVhdGVkIGZvciBuYXRpdmUgYXBwcyB3aGVyZSBVUkwgbGVha2FnZSB3YXMgZGVlbWVkIG1vcmUg
bGlrZWx5IChzaW5jZSBpdCBnb2VzIG92ZXIgaW50ZXItcHJvY2VzcyBjb21tdW5pY2F0aW9uIGNo
YW5uZWxzKSwgcGVyaGFwcyB0aGUgcHJhY3RpY2Ugc2hvdWxkIGJlIGV4cGFuZGVkIHRvIGFsbCBj
bGllbnRzLjwvZGl2PjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+PGRpdiBjbGFzcz0iZ21h
aWxfcXVvdGUiPk9uIFR1ZSwgSnVsIDI2LCAyMDE2IGF0IDY6MTEgUE0sICA8c3BhbiBkaXI9Imx0
ciI+Jmx0OzxhIGhyZWY9Im1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbSIgdGFyZ2V0PSJfYmxhbmsi
PnZlN2p0YkB2ZTdqdGIuY29tPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj48YmxvY2txdW90ZSBj
bGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDox
cHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij48ZGl2IGxhbmc9IkVOLUNBIiBsaW5rPSJi
bHVlIiB2bGluaz0iIzk1NEY3MiI+PGRpdiBjbGFzcz0ibV8tNTY4NzYwODY1NTg3Njg2NTk1NFdv
cmRTZWN0aW9uMSI+PHAgY2xhc3M9Ik1zb05vcm1hbCI+UFPCoMKgIFVzaW5nIFBLQ0UgUzI1NiB3
b3VsZCBwcmV2ZW50IHRoaXMgYXR0YWNrIG9uIHdlYiBzZXJ2ZXIgY2xpZW50cywgYXMgbG9uZyBh
cyB0aGUgY2xpZW50IHVzZXMgYSBkaWZmZXJlbnQgUEtDRSB2YWxlIGZvciBlYWNoIHJlcXVlc3Qu
wqDCoMKgIEV2ZW4gaWYgdGhlIGF0dGFja2VyIGNhbiBvYnNlcnZlIGJvdGggdGhlIHJlcXVlc3Qg
YW5kIHJlc3BvbnNlLCB0aGV5IHdvdWxkIG5vdCBoYXZlIHRoZSBjb2RlX3ZlcmlmeWVyIGFuZCBp
ZiByZXBsYXlpbmcgdGhlIGNvZGUgdG8gdGhlIGNsaWVudCB0aGUgY2xpZW50IHdpbGwgdXNlIHRo
ZSB3cm9uZyB2ZXJpZmllciB2YWx1ZSB0byBleGNoYW5nZSB0aGUgY29kZSBhbmQgd2lsbCBnZXQg
YW4gZXJyb3IuPC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjx1PjwvdT7CoDx1PjwvdT48L3A+PHAg
Y2xhc3M9Ik1zb05vcm1hbCI+VGhhdCBpcyBwcm9iYWJseSB0aGUgc2ltcGxlc3QgbWl0aWdhdGlv
biBhZ2FpbnN0IHRoaXMgZm9yIHRoZSBjb2RlIGZsb3cgb24gd2ViIHNlcnZlcnMgYW5kIG5hdGl2
ZSBhcHBzLjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48dT48L3U+wqA8dT48L3U+PC9wPjxwIGNs
YXNzPSJNc29Ob3JtYWwiPkkgd2lsbCB0aGluayBhYm91dCBpdCBvdmVybmlnaHQuPC9wPjxzcGFu
IGNsYXNzPSIiPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjx1PjwvdT7CoDx1PjwvdT48L3A+PHAgY2xh
c3M9Ik1zb05vcm1hbCI+Sm9obiBCLjx1PjwvdT48dT48L3U+PC9wPjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjx1PjwvdT7CoDx1PjwvdT48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+U2VudCBmcm9tIDxh
IGhyZWY9Imh0dHBzOi8vZ28ubWljcm9zb2Z0LmNvbS9md2xpbmsvP0xpbmtJZD01NTA5ODYiIHRh
cmdldD0iX2JsYW5rIj5NYWlsPC9hPiBmb3IgV2luZG93cyAxMDwvcD48cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1l
cyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPjx1PjwvdT7CoDx1PjwvdT48L3NwYW4+PC9wPjwvc3Bh
bj48ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNlMWUxZTEgMS4wcHQ7
cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJv
cmRlcjpub25lO3BhZGRpbmc6MGNtIj48Yj5Gcm9tOiA8L2I+PGEgaHJlZj0ibWFpbHRvOnZlN2p0
YkB2ZTdqdGIuY29tIiB0YXJnZXQ9Il9ibGFuayI+dmU3anRiQHZlN2p0Yi5jb208L2E+PGJyPjxi
PlNlbnQ6IDwvYj5KdWx5IDI2LCAyMDE2IDk6MDQgUE08YnI+PGI+VG86IDwvYj48YSBocmVmPSJt
YWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5EaWNrIEhhcmR0PC9h
PjsgPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T2F1dGgg
V3JhcCBXZzwvYT48YnI+PGI+U3ViamVjdDogPC9iPlJFOiBbT0FVVEgtV0ddIFVSR0VOVDogV1BB
RCBhdHRhY2sgZXhwb3NlcyBVUkwgY29udGVudHMgZXZlbiBvdmVySFRUUFM8L3A+PC9kaXY+PGRp
dj48ZGl2IGNsYXNzPSJoNSI+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlm
Ij48dT48L3U+wqA8dT48L3U+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj5JIG5lZWQg
dG8gdGhpbmsgYWJvdXQgaXQgYSBiaXQswqAgaG93ZXZlciBvZmYgdGhlIHRvcCBvZiBteSBoZWFk
IGJhc2VkIG9uIHRoZSBhdHRhY2sgZGVzY3JpYmVkIHRoZSBjb2RlIGZsb3cgc2hvdWxkIHN0aWxs
IGJlIHNhZmUgaWYgdGhlIGNvZGUgaXMgdHJ1bHkgc2luZ2xlIHVzZS7CoMKgIChTb21lIGltcGxl
bWVudGF0aW9ucyBmdWRnZSB0aGF0KTwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48dT48L3U+wqA8
dT48L3U+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHRoZSBhdHRhY2tlciBjYW4gc3RvcCB0
aGUgYnJvd3NlciBmcm9tIGRlbGl2ZXJpbmcgdGhlIGNvZGUgdG8gdGhlIGNsaWVudCB0aGVuIHRo
ZSBjbGllbnQgd291bGQgYmUgc3VzY2VwdGlibGUgdG8gdGhlIGN1dCBhbmQgcGFzdGUgYXR0YWNr
IGZvciBpbmplY3RpbmcgdGhlIGNvZGUgYmFjayBpbnRvIHRoZSBjbGllbnQuwqAgPC9wPjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjx1PjwvdT7CoDx1PjwvdT48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+
VGhlIE9wZW5JRCBDb25uZWN0IOKAnGNvZGUgaWRfdG9rZW7igJ0gZmxvdyBpcyBub3QgdnVsbmVy
YWJsZSB0byB0aGlzIGlmIHRoZSBjbGllbnQgaXMgcHJvcGVybHkgdmFsaWRhdGluZyB0aGUgaWRf
dG9rZW4uPC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjx1PjwvdT7CoDx1PjwvdT48L3A+PHAgY2xh
c3M9Ik1zb05vcm1hbCI+SSBzdXNwZWN0IHRoYXQgdGhpcyB3b3VsZCB3b3JrIGFnYWluc3QgdGhl
IGltcGxpY2l0IGZsb3cgaWYgdGhlIEpTIGlzIHNlbmRpbmcgdGhlIGNvZGUgYmFjayB0byBpdHMg
d2ViIHNlcnZlciB2aWEgYSBHRVQuwqAgPC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYXQgSSB0
aGluayB3ZSByZWNvbW1lbmQgYWdhaW5zdCBkb2luZywgb3Igc2hvdWxkLjwvcD48cCBjbGFzcz0i
TXNvTm9ybWFsIj48dT48L3U+wqA8dT48L3U+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBU
b2tlbiBiaW5kaW5nIHByb3Bvc2FscyB3b3VsZCBzdG9wIGEgbGVha2VkIGNvZGUgZnJvbSBiZWlu
ZyB1c2VkLCBidXQgbm90IGZyb20gYmVpbmcgc3RvbGVuIGluIHRoaXMgYXR0YWNrLjwvcD48cCBj
bGFzcz0iTXNvTm9ybWFsIj48dT48L3U+wqA8dT48L3U+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwi
PlRoZSBhdHRhY2sgYWdhaW5zdCBhIGNvbmZpZGVudGlhbCBjbGllbnQgd291bGQgYmUgdGhlIGN1
dCBhbmQgcGFzdGUgb25lIHRoYXQgd2UgaGF2ZSBpZGVudGlmaWVkLsKgIEN1cnJlbnRseSB0aGUg
b25seSBtaXRpZ2F0aW9uIHdlIGhhdmUgaXMg4oCcY29kZSBpZF90b2tlbuKAncKgIHNvIHRoZSBi
bG9nIHBvc3QgYXQuPC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHA6Ly9vcGVu
aWQubmV0LzIwMTYvMDcvMTYvcHJldmVudGluZy1taXgtdXAtYXR0YWNrcy13aXRoLW9wZW5pZC1j
b25uZWN0LyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9vcGVuaWQubmV0LzIwMTYvMDcvMTYvcHJl
dmVudGluZy1taXgtdXAtYXR0YWNrcy13aXRoLW9wZW5pZC1jb25uZWN0LzwvYT48L3A+PHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHU+PC91PsKgPHU+PC91PjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj5J
IHRoZSBtb3N0IHJlbGV2YW50IGN1cnJlbnQgYWR2aWNlLjwvcD48cCBjbGFzcz0iTXNvTm9ybWFs
Ij5UaGUgdGhpbmcgdG8gYWRkIGlzIHRoYXQgdGhlIGNvZGUgbGVha2VkIGluIHRoaXMgd2F5IHNo
b3VsZCBub3QgYmUgcmVwYXlhYmxlIGF0IHRoZSBjbGllbnQgPC9wPjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjx1PjwvdT7CoDx1PjwvdT48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkb27igJl0IHRo
aW5rIHRoYXQgbmF0aXZlIGFwcHMgYXJlIHZ1bG5lcmFibGUgdG8gdGhpcyBpZiB0aGV5IGFyZSB1
c2luZyBjdXN0b20gc2NoZW1lIHJlZGlyZWN0cy7CoCA8L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHU+PC91PsKgPHU+PC91PjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRvbuKAmXQga25vdyB3
aGF0IHRoZSByaXNrIGlzIGlmIHRoZXkgYXJlIHVzaW5nIGxvb3BiYWNrIG9yIGNsYWltZWQgVVJJ
LsKgIEl0IG1heSBiZSB0aGF0IGEgYnJvd3NlciBtaWdodCBsZWFrIHRoZW0gaW4gdGhlIHNhbWUg
d2F5LiA8L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhdCB3b3VsZCBuZWVkIHRvIGJlIHRlc3Rl
ZC48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHU+PC91PsKgPHU+PC91PjwvcD48cCBjbGFzcz0i
TXNvTm9ybWFsIj5Kb2huIEIuPC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjx1PjwvdT7CoDx1Pjwv
dT48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHU+PC91PsKgPHU+PC91PjwvcD48cCBjbGFzcz0i
TXNvTm9ybWFsIj5TZW50IGZyb20gPGEgaHJlZj0iaHR0cHM6Ly9nby5taWNyb3NvZnQuY29tL2Z3
bGluay8/TGlua0lkPTU1MDk4NiIgdGFyZ2V0PSJfYmxhbmsiPk1haWw8L2E+IGZvciBXaW5kb3dz
IDEwPC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+PHU+PC91PsKg
PHU+PC91Pjwvc3Bhbj48L3A+PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp
ZCAjZTFlMWUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxiPkZyb206IDwvYj48YSBocmVmPSJtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20i
IHRhcmdldD0iX2JsYW5rIj5EaWNrIEhhcmR0PC9hPjxicj48Yj5TZW50OiA8L2I+SnVseSAyNiwg
MjAxNiA4OjE1IFBNPGJyPjxiPlRvOiA8L2I+PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3Jn
IiB0YXJnZXQ9Il9ibGFuayI+T2F1dGggV3JhcCBXZzwvYT48YnI+PGI+U3ViamVjdDogPC9iPltP
QVVUSC1XR10gVVJHRU5UOiBXUEFEIGF0dGFjayBleHBvc2VzIFVSTCBjb250ZW50cyBldmVuIG92
ZXIgSFRUUFM8dT48L3U+PHU+PC91PjwvcD48L2Rpdj48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t
YW4mcXVvdDssc2VyaWYiPjx1PjwvdT7CoDx1PjwvdT48L3NwYW4+PC9wPjxkaXY+PHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj48YSBocmVmPSJodHRwOi8vYXJzdGVjaG5p
Y2EuY29tL3NlY3VyaXR5LzIwMTYvMDcvbmV3LWF0dGFjay10aGF0LWNyaXBwbGVzLWh0dHBzLWNy
eXB0by13b3Jrcy1vbi1tYWNzLXdpbmRvd3MtYW5kLWxpbnV4LyIgdGFyZ2V0PSJfYmxhbmsiPmh0
dHA6Ly9hcnN0ZWNobmljYS5jb20vc2VjdXJpdHkvMjAxNi8wNy9uZXctYXR0YWNrLXRoYXQtY3Jp
cHBsZXMtaHR0cHMtY3J5cHRvLXdvcmtzLW9uLW1hY3Mtd2luZG93cy1hbmQtbGludXgvPC9hPjx1
PjwvdT48dT48L3U+PC9zcGFuPjwvcD48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx
dW90OyxzZXJpZiI+PHU+PC91PsKgPHU+PC91Pjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTom
cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPkFjY2VzcyB0b2tlbnMgaW5jbHVkZWQg
YXMgYSBVUkwgcXVlcnkgcGFyYW1ldGVyIHdoZW4gYWNjZXNzaW5nIGEgcmVzb3VyY2UgYXJlIHN1
c2NlcHRpYmxlIHRvIHRoaXMgYXR0YWNrLjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD48L2Rpdj48
ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+PHU+PC91PsKgPHU+
PC91Pjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv
dDssc2VyaWYiPkF1dGhvcml6YXRpb24gY29kZXMgYXJlIGFsc28gdmlzaWJsZS4gRnJvbSB3aGF0
IEkga25vdywgd2UgaGF2ZSBub3QgZGVwZW5kZWQgb24gdGhlIGNvbmZpZGVudGlhbGl0eSBvZiB0
aGUgYXV0aG9yaXphdGlvbiBjb2RlLsKgPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPjwvZGl2Pjxk
aXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj48dT48L3U+wqA8dT48
L3U+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90
OyxzZXJpZiI+V2hhdCBhcmUgdGhlIGJlc3QgY3VycmVudCBwcmFjdGljZXMgdGhhdCB3ZSBjYW4g
cG9pbnQgcGVvcGxlIHRvd2FyZHMgdG8gZW5zdXJlIHRoZXkgYXJlIG5vdCBzdXNjZXB0aWJsZSB0
byB0aGlzIGF0dGFjaz88dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTom
cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPjx1PjwvdT7CoDx1PjwvdT48L3NwYW4+
PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4t
LSBEaWNrwqA8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5TdWJzY3JpYmUgdG8gdGhlIDxhIGhyZWY9Imh0
dHA6Ly9oYXJkdHdhcmUuY29tLyIgdGFyZ2V0PSJfYmxhbmsiPkhBUkRUV0FSRTwvYT4gbWFpbCBs
aXN0IHRvIGxlYXJuIGFib3V0IHByb2plY3RzIEkgYW0gd29ya2luZyBvbiE8dT48L3U+PHU+PC91
Pjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHU+PC91PsKgPHU+PC91PjwvcD48cCBj
bGFzcz0iTXNvTm9ybWFsIj48dT48L3U+wqA8dT48L3U+PC9wPjwvZGl2PjwvZGl2PjwvZGl2Pjwv
ZGl2Pjxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi
cj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9y
ZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9vYXV0aCIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48YnI+DQo8YnI+
PC9ibG9ja3F1b3RlPjwvZGl2Pjxicj48L2Rpdj4NCg==
----_com.syntomo.email_157292972712490--


From nobody Wed Jul 27 00:19:36 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E797B12D65E for ; Wed, 27 Jul 2016 00:19:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id adwWMaMkhmo0 for ; Wed, 27 Jul 2016 00:19:32 -0700 (PDT)
Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::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 7ECBC12D0A6 for ; Wed, 27 Jul 2016 00:19:32 -0700 (PDT)
Received: by mail-vk0-x22c.google.com with SMTP id x130so2845462vkc.0 for ; Wed, 27 Jul 2016 00:19:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xIlQdKJGxfwzQs0aAXVpT/vlwHC5l01XsL+RTAJ1ZoM=; b=riJLqyNZJcLGlK1P1g+grtQ4HnJZFAgcH0qScvgCLOwgU3QuJlE4WJxNKt2vNY06Ey /GZWuVR18GJ8ELTdx8UlBl7QvSmWLjdJfLUsMMB6HEa9HCtxJot/7gNy19dEeW4CtM12 jOXcCqE1whmqA9HkA+YXOLEL8CuMN0I+6GBlx7dwz7KXgifOtGEOJQLQIBOHVXutcFza qRQQ0ucacbnlNm04Lua+XHgJdJ81s0QuuYBuVvjmwqBTNbPtKzAm4bgJQAtl7pe62Pc9 iYfQYi/eoUUDUysgiwBDpYTJkoWAUIabQSjrZKUggbx84J2JQb8I6hpzKjaLi6kOMBUP a9Jg==
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=xIlQdKJGxfwzQs0aAXVpT/vlwHC5l01XsL+RTAJ1ZoM=; b=fKK5rQ0U0bWAlhsn/qOWGfZIdN2jFGcZ8+v6LYZEp2/GyJvM09ISVMQPk+9Ud6vW6n aOotuH0GM4qVS+yW2DIHVxNgcUX6HWiTiA6BmmoEY0NHn4Oa1mjpPY+Dnl7Mbqb0zTuI dFuLVRWwSBB9ao2zQXvKiErCPKVSmNlqdh4cbSqDnaWddxrxrZNILPgDkY83zQaHV23o 02qiTfXOhXS+iDYLc0xbwqm0gFqPZUEH8bRvakFyJRCtogBf9Ohf81h5ocm95VluEW9w chMRYOUnJWAd7cObFstlEvaL99fNrahGfO6hA+vvqyodEjZKkmpiYGR03Qtt56LHItFU 0OhQ==
X-Gm-Message-State: AEkooutWgz053f1nDobuh7INMDCfotasi8Pr4geegORKNP7kJXvtoKTr+YysYhzkldoM+MnKUpAI7mB6/AH9wQ==
X-Received: by 10.31.242.141 with SMTP id q135mr11572682vkh.79.1469603971495;  Wed, 27 Jul 2016 00:19:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.2.118 with HTTP; Wed, 27 Jul 2016 00:19:30 -0700 (PDT)
In-Reply-To: 
References:  <57980887.1724c80a.e1de7.c7a7@mx.google.com> <57980a47.e928c80a.c54fd.c891@mx.google.com>  
From: nov matake 
Date: Wed, 27 Jul 2016 16:19:30 +0900
Message-ID: 
To: "torsten@lodderstedt.net" 
Content-Type: multipart/alternative; boundary=94eb2c14c148ae7fb4053898d6d0
Archived-At: 
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] URGENT: WPAD attack exposes URL contents even overHTTPS
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jul 2016 07:19:35 -0000

--94eb2c14c148ae7fb4053898d6d0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

In Connect, if RP verifies nonce value in ID Token issued from Token
Endpoint, code cut & paste attack can be mitigated in "code" flow, not in
"code id_token", can't it?

In pure OAuth2 senario, I also think PKCE would be the simplest solution.

2016-07-27 15:45 GMT+09:00 torsten@lodderstedt.net 
:

> +1
>
> I also think PKCE is currently the simplest way to protect OAuth clients
> from injection.
>
> Sent by MailWise  =E2=80=93 See =
your
> emails as clean, short chats.
>
>
> -------- Originalnachricht --------
> Betreff: Re: [OAUTH-WG] URGENT: WPAD attack exposes URL contents even
> overHTTPS
> Von: William Denniss 
> An: John Bradley 
> Cc: Oauth Wrap Wg 
>
>
> PKCE S256 was indeed designed to protect against eavesdropping of both th=
e
> authorization request & response.  It was originally created for native
> apps where URL leakage was deemed more likely (since it goes over
> inter-process communication channels), perhaps the practice should be
> expanded to all clients.
>
> On Tue, Jul 26, 2016 at 6:11 PM,  wrote:
>
>> PS   Using PKCE S256 would prevent this attack on web server clients, as
>> long as the client uses a different PKCE vale for each request.    Even =
if
>> the attacker can observe both the request and response, they would not h=
ave
>> the code_verifyer and if replaying the code to the client the client wil=
l
>> use the wrong verifier value to exchange the code and will get an error.
>>
>>
>>
>> That is probably the simplest mitigation against this for the code flow
>> on web servers and native apps.
>>
>>
>>
>> I will think about it overnight.
>>
>>
>>
>> John B.
>>
>>
>>
>> Sent from Mail  for
>> Windows 10
>>
>>
>>
>> *From: *ve7jtb@ve7jtb.com
>> *Sent: *July 26, 2016 9:04 PM
>> *To: *Dick Hardt ; Oauth Wrap Wg 
>> *Subject: *RE: [OAUTH-WG] URGENT: WPAD attack exposes URL contents even
>> overHTTPS
>>
>>
>>
>> I need to think about it a bit,  however off the top of my head based on
>> the attack described the code flow should still be safe if the code is
>> truly single use.   (Some implementations fudge that)
>>
>>
>>
>> If the attacker can stop the browser from delivering the code to the
>> client then the client would be susceptible to the cut and paste attack =
for
>> injecting the code back into the client.
>>
>>
>>
>> The OpenID Connect =E2=80=9Ccode id_token=E2=80=9D flow is not vulnerabl=
e to this if the
>> client is properly validating the id_token.
>>
>>
>>
>> I suspect that this would work against the implicit flow if the JS is
>> sending the code back to its web server via a GET.
>>
>> That I think we recommend against doing, or should.
>>
>>
>>
>> The Token binding proposals would stop a leaked code from being used, bu=
t
>> not from being stolen in this attack.
>>
>>
>>
>> The attack against a confidential client would be the cut and paste one
>> that we have identified.  Currently the only mitigation we have is =E2=
=80=9Ccode
>> id_token=E2=80=9D  so the blog post at.
>>
>>
>> http://openid.net/2016/07/16/preventing-mix-up-attacks-with-openid-conne=
ct/
>>
>>
>>
>> I the most relevant current advice.
>>
>> The thing to add is that the code leaked in this way should not be
>> repayable at the client
>>
>>
>>
>> I don=E2=80=99t think that native apps are vulnerable to this if they ar=
e using
>> custom scheme redirects.
>>
>>
>>
>> I don=E2=80=99t know what the risk is if they are using loopback or clai=
med URI.
>> It may be that a browser might leak them in the same way.
>>
>> That would need to be tested.
>>
>>
>>
>> John B.
>>
>>
>>
>>
>>
>> Sent from Mail  for
>> Windows 10
>>
>>
>>
>> *From: *Dick Hardt 
>> *Sent: *July 26, 2016 8:15 PM
>> *To: *Oauth Wrap Wg 
>> *Subject: *[OAUTH-WG] URGENT: WPAD attack exposes URL contents even over
>> HTTPS
>>
>>
>>
>>
>> http://arstechnica.com/security/2016/07/new-attack-that-cripples-https-c=
rypto-works-on-macs-windows-and-linux/
>>
>>
>>
>> Access tokens included as a URL query parameter when accessing a resourc=
e
>> are susceptible to this attack.
>>
>>
>>
>> Authorization codes are also visible. From what I know, we have not
>> depended on the confidentiality of the authorization code.
>>
>>
>>
>> What are the best current practices that we can point people towards to
>> ensure they are not susceptible to this attack?
>>
>>
>>
>> -- Dick
>>
>> Subscribe to the HARDTWARE  mail list to learn
>> about projects I am working on!
>>
>>
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>


--=20
nov matake

--94eb2c14c148ae7fb4053898d6d0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


In Connect, if RP verifies =
nonce value in ID Token issued from Token Endpoint, code cut & paste at=
tack can be mitigated in "code" flow, not in "code id_token&=
quot;, can't it?

<=
div style=3D"font-size:14px">In pure OAuth2 senario, I also think PKCE woul=
d be the simplest solution.

On Tue, Jul 26, 2016 at 6:11 PM,  &=
lt;ve7jtb@ve7jtb.com=
> wrote:
PS=C2=A0=C2=A0 Using PKCE S256 would preven=
t this attack on web server clients, as long as the client uses a different=
 PKCE vale for each request.=C2=A0=C2=A0=C2=A0 Even if the attacker can obs=
erve both the request and response, they would not have the code_verifyer a=
nd if replaying the code to the client the client will use the wrong verifi=
er value to exchange the code and will get an error.
=C2=A0
That is probably the sim=
plest mitigation against this for the code flow on web servers and native a=
pps.
=C2=A0
I will think about it overnight.
=C2=A0
John B.
=C2=A0
Sent=
 from Mail for Windows 10
=
=C2=A0
From: ve7jtb@ve7jtb.com
Sent: July 26, 2016 9:04 PM<=
br>To: Dic=
k Hardt; Oauth Wrap=
 Wg
Subject: RE: [OAUTH-WG] URGENT: WPAD attack exposes URL c=
ontents even overHTTPS
=C2=A0
I need to thin=
k about it a bit,=C2=A0 however off the top of my head based on the attack =
described the code flow should still be safe if the code is truly single us=
e.=C2=A0=C2=A0 (Some implementations fudge that)
=
=C2=A0
If the attacker can stop the=
 browser from delivering the code to the client then the client would be su=
sceptible to the cut and paste attack for injecting the code back into the =
client.=C2=A0 
=C2=A0
The OpenID Connect =E2=80=9Ccode id_token=E2=80=9D flow is n=
ot vulnerable to this if the client is properly validating the id_token.
=C2=A0
I su=
spect that this would work against the implicit flow if the JS is sending t=
he code back to its web server via a GET.=C2=A0 
=
That I think we recommend against doing, or should.
=C2=A0
The Token binding proposa=
ls would stop a leaked code from being used, but not from being stolen in t=
his attack.
=C2=A0
The attack against a confidential client would be the cut and pas=
te one that we have identified.=C2=A0 Currently the only mitigation we have=
 is =E2=80=9Ccode id_token=E2=80=9D=C2=A0 so the blog post at.
http://openid.net/2016/07/16/=
preventing-mix-up-attacks-with-openid-connect/
=C2=A0
I the most relevant curren=
t advice.
The thing to add is that the code leake=
d in this way should not be repayable at the client 
=C2=A0
I don=E2=80=99t think th=
at native apps are vulnerable to this if they are using custom scheme redir=
ects.=C2=A0 
=C2=A0
I don=E2=80=99t know what the risk is if they are using loopback=
 or claimed URI.=C2=A0 It may be that a browser might leak them in the same=
 way. 
That would need to be tested.
=C2=A0
John B.
=C2=A0
=
=C2=A0
Sent from Mail for Windows =
10
=C2=A0
<=
p class=3D"MsoNormal">From: Dick Hardt
Sent: July 26, 2016 8:15 PM
<=
b>To: Oauth Wrap Wg=

Subject: [OAUTH-WG] URGENT: WPAD attack exposes URL contents=
 even over HTTPS
=
=C2=A0
http://arstechnica.com/secur=
ity/2016/07/new-attack-that-cripples-https-crypto-works-on-macs-windows-and=
-linux/
=
=C2=A0
Access tokens=
 included as a URL query parameter when accessing a resource are susceptibl=
e to this attack.
=C2=A0
A=
uthorization codes are also visible. From what I know, we have not depended=
 on the confidentiality of the authorization code.=C2=A0
=C2=A0
=

What are the best current practices t=
hat we can point people towards to ensure they are not susceptible to this =
attack?
=C2=A0
-- Dick=C2=
=A0
Subscri=
be to the HARDTWARE=
 mail list to learn about projects I am working on!
=C2=A0
<=
/u>=C2=A0

___________________________=
____________________

OAuth mailing list

OAuth@ietf.org

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



2016-07-27 15:45 GMT+09:00 torsten@lodderstedt.net <torsten@lodderst=
edt.net>:
+1=



I also think PKCE is currently the simplest way to protect O=
Auth clients from injection.


Sent by MailWise =E2=80=93 See your emails as clean, short ch=
ats.



-------- Originalnachricht --------
Betreff: Re: [OAUTH-WG] URGE=
NT: WPAD attack exposes URL contents even	overHTTPS
Von: William Denniss=
 <wdenniss@goog=
le.com>
An: John Bradley <ve7jtb@ve7jtb.com>
Cc: Oauth Wrap Wg <oauth@ietf.org>


PKCE S256 was in=
deed designed to protect against eavesdropping of both the authorization re=
quest & response.=C2=A0 It was originally created for native apps where=
 URL leakage was deemed more likely (since it goes over inter-process commu=
nication channels), perhaps the practice should be expanded to all clients.=


On Tue, Jul=
 26, 2016 at 6:11 PM,  <ve7jtb@ve7jtb.com> wrote:
PS=C2=A0=C2=A0 Using PKCE S256 would prevent t=
his attack on web server clients, as long as the client uses a different PK=
CE vale for each request.=C2=A0=C2=A0=C2=A0 Even if the attacker can observ=
e both the request and response, they would not have the code_verifyer and =
if replaying the code to the client the client will use the wrong verifier =
value to exchange the code and will get an error.
=C2=A0
That is probably the simple=
st mitigation against this for the code flow on web servers and native apps=
.
=C2=A0
=
I will think about it overnight.
=C2=
=A0
John B.
=C2=A0
Sent from Mai=
l for Windows 10
=C2=A0
From: ve=
7jtb@ve7jtb.com
Sent: July 26, 2016 9:04 PM
To: Dick Hardt; Oauth Wrap Wg
Sub=
ject: RE: [OAUTH-WG] URGENT: WPAD attack exposes URL contents even over=
HTTPS
=C2=A0
I need to think about it a bit,=C2=A0 howeve=
r off the top of my head based on the attack described the code flow should=
 still be safe if the code is truly single use.=C2=A0=C2=A0 (Some implement=
ations fudge that)
=C2=A0
If the attacker can stop the browser from delivering the c=
ode to the client then the client would be susceptible to the cut and paste=
 attack for injecting the code back into the client.=C2=A0 
=C2=A0
The OpenID Connec=
t =E2=80=9Ccode id_token=E2=80=9D flow is not vulnerable to this if the cli=
ent is properly validating the id_token.
=
=C2=A0
I suspect that this would work agai=
nst the implicit flow if the JS is sending the code back to its web server =
via a GET.=C2=A0 
That I think we recommend again=
st doing, or should.
=C2=A0
The Token binding proposals would stop a leaked code fro=
m being used, but not from being stolen in this attack.
=C2=A0
The attack against a =
confidential client would be the cut and paste one that we have identified.=
=C2=A0 Currently the only mitigation we have is =E2=80=9Ccode id_token=E2=
=80=9D=C2=A0 so the blog post at.
http://openid.net/2016/07/16/preventing-mix-up-attacks-with=
-openid-connect/
=C2=A0
I the most relevant current advice.
The thing to add is that the code leaked in this way should not be re=
payable at the client 
=C2=A0
I don=E2=80=99t think that native apps are vulnerable =
to this if they are using custom scheme redirects.=C2=A0 
=C2=A0
I don=E2=80=99t kno=
w what the risk is if they are using loopback or claimed URI.=C2=A0 It may =
be that a browser might leak them in the same way. 
That would need to be tested.
=C2=A0=

John B.
=C2=
=A0
=C2=A0
Sent from Mail for Windows 10
From: <=
/b>Dick Hardt=

Sent: July 26, 2016 8:15 PM
To: Oauth Wrap Wg
Subject: [OAUTH-W=
G] URGENT: WPAD attack exposes URL contents even over HTTPS
=C2=A0
http://arstechnica.com/security/2016/07/new-attack-that-cripp=
les-https-crypto-works-on-macs-windows-and-linux/<=
/p>
=C2=A0
Access tokens included as a URL query paramete=
r when accessing a resource are susceptible to this attack.
=C2=A0<=
/p>
Authorization codes are also visib=
le. From what I know, we have not depended on the confidentiality of the au=
thorization code.=C2=A0
=C2=A0
What are the best current practices that we can point people towards t=
o ensure they are not susceptible to this attack?
<=
/div>
=C2=A0
<=
div>
-- Dick=C2=A0
=

Subscribe to the HARDTWARE mail list to learn about projects =
I am working on!
=C2=
=A0
=C2=A0

_______________________________________________

OAuth mailing list

OAuth@ietf.org

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






_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





-- 
nov matake




--94eb2c14c148ae7fb4053898d6d0--


From nobody Wed Jul 27 01:00:52 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A02BE12D8BE for ; Wed, 27 Jul 2016 01:00:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.588
X-Spam-Level: 
X-Spam-Status: No, score=-5.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 SXKUus_7u1ab for ; Wed, 27 Jul 2016 01:00:48 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FCAE12B024 for ; Wed, 27 Jul 2016 01:00:47 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id DE90EBE2D; Wed, 27 Jul 2016 09:00:44 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NikEsmFHPzub; Wed, 27 Jul 2016 09:00:43 +0100 (IST)
Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 37375BDF9; Wed, 27 Jul 2016 09:00:42 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1469606442; bh=uV8uWWjqWjtSl0zvKhBMMMGYcB815disTuI6n77LyqA=; h=Subject:To:References:From:Date:In-Reply-To:From; b=3mqNuVoU+F4Qga2ZQqwa9xrJni0Tp7WavY17DnfDQ1y27HrEjNMb7rSRlcML2C9Bw 2yDsUrIuzIe0s21EKP2qlg3+0mKjnGYkb502a6HJ68daS6zGmVlIxKc6Yj+fpHoMsr LAQUX04zOmWICjtxBh16iJKTCXE+drx3TEnJBTJw=
To: Dick Hardt , Oauth Wrap Wg 
References: 
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: 
Date: Wed, 27 Jul 2016 09:00:41 +0100
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: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060106000702090604090509"
Archived-At: 
Subject: Re: [OAUTH-WG] URGENT: WPAD attack exposes URL contents even over HTTPS
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jul 2016 08:00:51 -0000

This is a cryptographically signed message in MIME format.

--------------ms060106000702090604090509
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Is there any information as to what percentage of browsers have a
vulnerable configuration? That's not clear to me and seems relevant.
My impression was that wpad wasn't that widely enabled in browsers
nowadays, but that may well be wrong.

S.

On 27/07/16 01:15, Dick Hardt wrote:
> http://arstechnica.com/security/2016/07/new-attack-that-cripples-https-=
crypto-works-on-macs-windows-and-linux/
>=20
> Access tokens included as a URL query parameter when accessing a resour=
ce
> are susceptible to this attack.
>=20
> Authorization codes are also visible. From what I know, we have not
> depended on the confidentiality of the authorization code.
>=20
> What are the best current practices that we can point people towards to=

> ensure they are not susceptible to this attack?
>=20
> -- Dick
> Subscribe to the HARDTWARE  mail list to learn a=
bout
> projects I am working on!
>=20
>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>=20


--------------ms060106000702090604090509
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
CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ
BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll
bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw
aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA
Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra
C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3
rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5
R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r
dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt
3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw
MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ
QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv
BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5
BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu
Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll
bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc
MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE
MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG
9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD
C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9
U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM
aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai
9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC
BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE
BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs
IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g
QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC
SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv
mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm
VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4
D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI
dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu
N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE
FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp
MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE
WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG
JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+
SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g
BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv
bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY
0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF
NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9
uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p
6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv
Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu
mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7
RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO
/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN
JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM
MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG
A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0
Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA
oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3Mjcw
ODAwNDJaMC8GCSqGSIb3DQEJBDEiBCBvx6ktAWj3X9ekCRzbxezhwrNUaX+AuiA/Sm4ld649
TTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw
IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB
nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD
VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq
hkiG9w0BAQEFAASCAQBSIYGKyZLQkvbDID3Q7N/hxpHSRWiaZtEgD1BGnrwEU861gO7rpnXL
JKOaz9OXLd2ZGpbgucislUGWe0c6ofQQ5FY9rb9vV1FZymRC7JDUJmodC+7D/NolhY8/u1va
dTBwBm2rEG+peJPMrtSXtZungMnOPFmDUPS7/Lj/SYDlzYx0hvsgPEviHfkNJ46it25MCYtp
O5yZGNvCD7KKNpxP/XFmMppBTkzqdh+yzqD/oGWo+I6+nh3G7QKVwQMd5BogdjXHTV9pX4ug
ERCqZEwm/AXuB5W3a3u9uB/MP14ylTPvYPlmRiEEYlnlo17tLIedhuD6d+tL6zpvLMU/tSaQ
AAAAAAAA
--------------ms060106000702090604090509--


From nobody Wed Jul 27 05:21:43 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E73812E11A for ; Wed, 27 Jul 2016 05:21:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.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 BEVSQGZtPezt for ; Wed, 27 Jul 2016 05:21:40 -0700 (PDT)
Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FBC312E119 for ; Wed, 27 Jul 2016 05:21:40 -0700 (PDT)
Received: by mail-it0-x22d.google.com with SMTP id f6so140919575ith.1 for ; Wed, 27 Jul 2016 05:21:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tArw0ZZ8UCj9ECEzXtPbO/OgaAL9IUyI+uXAoUgTp4s=; b=e3PholQX7pzCSIn4NU1qstHn7UEdSeAfTTZlUp2v/yTnoikHc6y5QXKWDg/gLlHn1Q hrOHAIwDpWMuSzivV9DnZkpR4wR7no5AA7DOg5eiBNqBfoZWqtoN8hF9r6s2/SI8WS+j pRzscTt11q9oQz8JIhY84ytYHO2w9U12+wEe0=
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=tArw0ZZ8UCj9ECEzXtPbO/OgaAL9IUyI+uXAoUgTp4s=; b=TXmfI7lW/FuEVRvhxtpTxoTs/t0lZvKZ9zEhYyLnjg5C7veZzFkMiBb2d/JooTzayj f1DXjle5SQ3KftU4FJzMEGPf4E/M6C5hjvZPmq+B1iPizYcMQDEaaiiMH3MHPTlwEFXk C1sMPNOXczX3RnfcxcLq02sDUK29rOUFkWm0rmwwFNed1X61H368iVcSjKSQhAZyvmBB MeMCWk/qE8nED9WBMVTx/dRctMoSkkdYzOXJo5KK3xn10OQ9JJIOiK1CJjQEBDzsH1qv mzw2+5B9yztl9xx/QORi5STI5aF1JsQyNKw7rAMdNmMcGYIjA8fOPWo48mVsoQYgylQ3 UMCw==
X-Gm-Message-State: ALyK8tIURNntFIjwWcCg73YxKDhHV7odZmtsWRXADwgymSuYcSG+rPy7vsqCohxfpGCqCRm64iA8TsUGTjfFBQeB
X-Received: by 10.36.206.129 with SMTP id v123mr102549921itg.11.1469622099557;  Wed, 27 Jul 2016 05:21:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.79.28.149 with HTTP; Wed, 27 Jul 2016 05:21:10 -0700 (PDT)
In-Reply-To: 
References:  <57980887.1724c80a.e1de7.c7a7@mx.google.com> <57980a47.e928c80a.c54fd.c891@mx.google.com>   
From: Brian Campbell 
Date: Wed, 27 Jul 2016 06:21:10 -0600
Message-ID: 
To: nov matake 
Content-Type: multipart/alternative; boundary=94eb2c0af9fc32df9f05389d0fe3
Archived-At: 
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] URGENT: WPAD attack exposes URL contents even overHTTPS
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jul 2016 12:21:42 -0000

--94eb2c0af9fc32df9f05389d0fe3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Yeah, in a Connect "code" only flow, the nonce is optional but if the
client/RP sends and checks it, that should mitigate this.

On Wed, Jul 27, 2016 at 1:19 AM, nov matake  wrote:

> In Connect, if RP verifies nonce value in ID Token issued from Token
> Endpoint, code cut & paste attack can be mitigated in "code" flow, not in
> "code id_token", can't it?
>
> In pure OAuth2 senario, I also think PKCE would be the simplest solution.
>
> 2016-07-27 15:45 GMT+09:00 torsten@lodderstedt.net <
> torsten@lodderstedt.net>:
>
>> +1
>>
>> I also think PKCE is currently the simplest way to protect OAuth clients
>> from injection.
>>
>> Sent by MailWise  =E2=80=93 See=
 your
>> emails as clean, short chats.
>>
>>
>> -------- Originalnachricht --------
>> Betreff: Re: [OAUTH-WG] URGENT: WPAD attack exposes URL contents even
>> overHTTPS
>> Von: William Denniss 
>> An: John Bradley 
>> Cc: Oauth Wrap Wg 
>>
>>
>> PKCE S256 was indeed designed to protect against eavesdropping of both
>> the authorization request & response.  It was originally created for nat=
ive
>> apps where URL leakage was deemed more likely (since it goes over
>> inter-process communication channels), perhaps the practice should be
>> expanded to all clients.
>>
>> On Tue, Jul 26, 2016 at 6:11 PM,  wrote:
>>
>>> PS   Using PKCE S256 would prevent this attack on web server clients, a=
s
>>> long as the client uses a different PKCE vale for each request.    Even=
 if
>>> the attacker can observe both the request and response, they would not =
have
>>> the code_verifyer and if replaying the code to the client the client wi=
ll
>>> use the wrong verifier value to exchange the code and will get an error=
.
>>>
>>>
>>>
>>> That is probably the simplest mitigation against this for the code flow
>>> on web servers and native apps.
>>>
>>>
>>>
>>> I will think about it overnight.
>>>
>>>
>>>
>>> John B.
>>>
>>>
>>>
>>> Sent from Mail  for
>>> Windows 10
>>>
>>>
>>>
>>> *From: *ve7jtb@ve7jtb.com
>>> *Sent: *July 26, 2016 9:04 PM
>>> *To: *Dick Hardt ; Oauth Wrap Wg 
>>> *Subject: *RE: [OAUTH-WG] URGENT: WPAD attack exposes URL contents even
>>> overHTTPS
>>>
>>>
>>>
>>> I need to think about it a bit,  however off the top of my head based o=
n
>>> the attack described the code flow should still be safe if the code is
>>> truly single use.   (Some implementations fudge that)
>>>
>>>
>>>
>>> If the attacker can stop the browser from delivering the code to the
>>> client then the client would be susceptible to the cut and paste attack=
 for
>>> injecting the code back into the client.
>>>
>>>
>>>
>>> The OpenID Connect =E2=80=9Ccode id_token=E2=80=9D flow is not vulnerab=
le to this if the
>>> client is properly validating the id_token.
>>>
>>>
>>>
>>> I suspect that this would work against the implicit flow if the JS is
>>> sending the code back to its web server via a GET.
>>>
>>> That I think we recommend against doing, or should.
>>>
>>>
>>>
>>> The Token binding proposals would stop a leaked code from being used,
>>> but not from being stolen in this attack.
>>>
>>>
>>>
>>> The attack against a confidential client would be the cut and paste one
>>> that we have identified.  Currently the only mitigation we have is =E2=
=80=9Ccode
>>> id_token=E2=80=9D  so the blog post at.
>>>
>>>
>>> http://openid.net/2016/07/16/preventing-mix-up-attacks-with-openid-conn=
ect/
>>>
>>>
>>>
>>> I the most relevant current advice.
>>>
>>> The thing to add is that the code leaked in this way should not be
>>> repayable at the client
>>>
>>>
>>>
>>> I don=E2=80=99t think that native apps are vulnerable to this if they a=
re using
>>> custom scheme redirects.
>>>
>>>
>>>
>>> I don=E2=80=99t know what the risk is if they are using loopback or cla=
imed
>>> URI.  It may be that a browser might leak them in the same way.
>>>
>>> That would need to be tested.
>>>
>>>
>>>
>>> John B.
>>>
>>>
>>>
>>>
>>>
>>> Sent from Mail  for
>>> Windows 10
>>>
>>>
>>>
>>> *From: *Dick Hardt 
>>> *Sent: *July 26, 2016 8:15 PM
>>> *To: *Oauth Wrap Wg 
>>> *Subject: *[OAUTH-WG] URGENT: WPAD attack exposes URL contents even
>>> over HTTPS
>>>
>>>
>>>
>>>
>>> http://arstechnica.com/security/2016/07/new-attack-that-cripples-https-=
crypto-works-on-macs-windows-and-linux/
>>>
>>>
>>>
>>> Access tokens included as a URL query parameter when accessing a
>>> resource are susceptible to this attack.
>>>
>>>
>>>
>>> Authorization codes are also visible. From what I know, we have not
>>> depended on the confidentiality of the authorization code.
>>>
>>>
>>>
>>> What are the best current practices that we can point people towards to
>>> ensure they are not susceptible to this attack?
>>>
>>>
>>>
>>> -- Dick
>>>
>>> Subscribe to the HARDTWARE  mail list to learn
>>> about projects I am working on!
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>
>
> --
> nov matake
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

--94eb2c0af9fc32df9f05389d0fe3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Yeah, in a Connect "code" only flow, the nonce i=
s optional but if the client/RP sends and checks it, that should mitigate t=
his. 

On=
 Wed, Jul 27, 2016 at 1:19 AM, nov matake <matake@gmail.com> =
wrote:
In Connect, if RP verifies nonce value in ID Token issued fro=
m Token Endpoint, code cut & paste attack can be mitigated in "cod=
e" flow, not in "code id_token", can't it?

In pu=
re OAuth2 senario, I also think PKCE would be the simplest solution.
<=
/div>

2016-07-27 15:45 GMT+09:00 torsten@lodderstedt.net <torsten@l=
odderstedt.net>:
+1


I also think PKCE is currently the simplest way to protect O=
Auth clients from injection.


Sent by MailWise =E2=80=93 See your emails as clean, short ch=
ats.



-------- Originalnachricht --------
Betreff: Re: [OAUTH-WG] URGE=
NT: WPAD attack exposes URL contents even	overHTTPS
Von: William Denniss=
 <wdenniss@goog=
le.com>
An: John Bradley <ve7jtb@ve7jtb.com>
Cc: Oauth Wrap Wg <oauth@ietf.org>
<=
div>

PKCE S256 was indeed designed to protect again=
st eavesdropping of both the authorization request & response.=C2=A0 It=
 was originally created for native apps where URL leakage was deemed more l=
ikely (since it goes over inter-process communication channels), perhaps th=
e practice should be expanded to all clients.

On Tue, Jul 26, 2016 at 6:11 PM,  <ve7jt=
b@ve7jtb.com> wrote:
P=
S=C2=A0=C2=A0 Using PKCE S256 would prevent this attack on web server clien=
ts, as long as the client uses a different PKCE vale for each request.=C2=
=A0=C2=A0=C2=A0 Even if the attacker can observe both the request and respo=
nse, they would not have the code_verifyer and if replaying the code to the=
 client the client will use the wrong verifier value to exchange the code a=
nd will get an error.
=C2=A0
That is probably the simplest mitigation against this f=
or the code flow on web servers and native apps.
=
=C2=A0
I will think about it overni=
ght.
=C2=A0
John B.
=C2=A0
Sent from Mail for Windows 10
=C2=A0
From: ve7jtb@ve7jtb.com
Sen=
t: July 26, 2016 9:04 PM
To: Dick Hardt; Oauth Wrap Wg
Subject: RE: [OAUTH-WG] URGE=
NT: WPAD attack exposes URL contents even overHTTPS
=C2=A0
I need to think about it a bit,=C2=A0 however off the top of my head base=
d on the attack described the code flow should still be safe if the code is=
 truly single use.=C2=A0=C2=A0 (Some implementations fudge that)
=C2=A0
If the attac=
ker can stop the browser from delivering the code to the client then the cl=
ient would be susceptible to the cut and paste attack for injecting the cod=
e back into the client.=C2=A0 
=C2=A0
The OpenID Connect =E2=80=9Ccode id_token=E2=
=80=9D flow is not vulnerable to this if the client is properly validating =
the id_token.
=C2=A0
I suspect that this would work against the implicit flow if the=
 JS is sending the code back to its web server via a GET.=C2=A0 
That I think we recommend against doing, or should.
=C2=A0
The Token=
 binding proposals would stop a leaked code from being used, but not from b=
eing stolen in this attack.
=C2=A0<=
/p>
The attack against a confidential client would be=
 the cut and paste one that we have identified.=C2=A0 Currently the only mi=
tigation we have is =E2=80=9Ccode id_token=E2=80=9D=C2=A0 so the blog post =
at.
http://openid.=
net/2016/07/16/preventing-mix-up-attacks-with-openid-connect/
=C2=A0
I the most =
relevant current advice.
The thing to add is that=
 the code leaked in this way should not be repayable at the client 
=C2=A0
I don=E2=
=80=99t think that native apps are vulnerable to this if they are using cus=
tom scheme redirects.=C2=A0 
=C2=A0=

I don=E2=80=99t know what the risk is if they ar=
e using loopback or claimed URI.=C2=A0 It may be that a browser might leak =
them in the same way. 
That would need to be test=
ed.
=C2=A0
John B.
=C2=A0
=C2=A0
Sent from Mail for Windows 10
=C2=A0=

From: Dick Hardt
Sent: July 26, 201=
6 8:15 PM
To: Oauth Wrap Wg
Subject: [OAUTH-WG] URGENT: WPAD attack expose=
s URL contents even over HTTPS
=C2=A0
http://arstechn=
ica.com/security/2016/07/new-attack-that-cripples-https-crypto-works-on-mac=
s-windows-and-linux/
=C2=A0
=
Access tokens included as a URL query parameter when accessing a resource a=
re susceptible to this attack.
=C2=A0
Authorization codes are also visible. From what I know, we hav=
e not depended on the confidentiality of the authorization code.=C2=A0
=C2=A0<=
/u>
What are the best curre=
nt practices that we can point people towards to ensure they are not suscep=
tible to this attack?
=C2=A0
<=
span style=3D"font-size:12.0pt;font-family:"Times New Roman",seri=
f">-- Dick=C2=A0
Subscribe to the H=
ARDTWARE mail list to learn about projects I am working on!
=C2=A0
=C2=A0

_______________=
________________________________

OAuth mailing list

OAuth@ietf.org

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






_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





-- 
nov matake


You know, I've tried to solve this problem 6 =
years ago and I failed, but I'm glad that community is looking to this agai=
n and I hope that John and others will eventually come up with something be=
tter than what we have now.

If I come up with a sane idea, I'll definitely share.
 


 
 
 
 
  
 From:=
 Liyu Yi <liyuyi@gmail.com>
 To: Oleg Gryb <oleg@gryb.info> 
Cc: John Bradley <ve7jtb@ve7jtb.co=
m>; "<oauth@ietf.org>" <oauth@ietf.org>
 Sent: Friday, July 1, 2016 6:37 PM
 <=
b id=3D"yui_3_16_0_ym19_1_1467405732310_95932">Subject: Re:=
 [OAUTH-WG] Security concern for URI fragment as Implicit grant
 =
 
 

John and Oleg, good point. I missed that. So in this case the "web-hosted =
client resource" is a party different from the RS and is also different fro=
m AS and is not supposed to access to AT. But I guess this "web-hosted clie=
nt resource" must be trusted, since its JS has access the the AT on the bro=
wser side anyways.

Maybe the secure way is to let the AS return an HTML=
 with embedded JS and AT. It does make the AS do more work, but it cuts out=
 the need of "web-hosted client resource".

Comments?

-- Liyu

On Fri, Jul 1, 2016 at 6:14 PM, Oleg Gryb <oleg_gryb=
@yahoo.com> wrote:
As John has already pointed out - you're confusing RS with the web-hosted client resource.


 
 =

  
  
 From: Liyu Yi <liyuyi@gmail.com>
 To: John Bradley=
 <ve7jtb@ve7jtb.com=
> 
Cc: Oleg Gryb <oleg@gryb.info>; "<oauth@ietf.org>" <oauth@ietf.org>
 Sent: Friday, July 1, 2016 6:11 PM

 Subject: Re: [OAUTH-WG] Security concern for URI fragment a=
s Implicit grant
 
 
 

I would=
 say AT is supposed to be consumed by the Resource Server. Although the ori=
ginal spec does not show how AT is used by the client, but the AT will be s=
ent out, most likely by the browser directly, or in a rare case if the clie=
nt application has another channel, indirectly.

The fact is that the AT is not sent in the 1st GET request does leav=
e the RS JavaScript a chance to choose the right method, say an ajax POST. =
But AT is NOT  a secrete to RS.



On Fri, Jul 1, 2016 at 5:53 PM, John Bradley <ve7jtb@ve7jt=
b.com> wrote:
yes

On Jul 1, 2016, at 8:39 PM, Oleg Gryb <oleg_gryb@yahoo.com> wrote:
I think, the intention was not to share AT with the web-hosted cl=
ient resource. As you can see in the original flow the latter never receive=
s the AT, it simply provides code that can get AT from a fragment and some =
UI. In the modified flow AT is sent to the web-hosted client resource, whic=
h makes security worse in my view, because you have your AT exposed in two =
places now - in the User Agent *and* in the web-hosted client resource.



 
 
 
 
  =

 From: John =
Bradley <ve7jtb@ve7jtb.=
com>
 To: Liyu Yi <liyuyi@g=
mail.com> 
Cc=
: Oleg Gryb <oleg@=
gryb.info>; "<oauth@ie=
tf.org>" <oauth@ietf.o=
rg>
 Sent: Friday, July 1, 2016 4:06 PM
 Subject: Re: [OAUTH-WG] Security concern for =
URI fragment as Implicit grant
  
 

I take it that Web-hosted client resource is part of the c=
lient.

I think perhaps you have client an=
d resource serve r mixed up a bit in your diagram.

Yes you could do that but it is not a great way to build th=
e client as it will blow away context.  
You can do it but p=
eople generally want to start the application in the browser first and then=
 call out to the IdP  in a iFrame.

=

What you propose would work more or less.  I don=E2=80=99t see it=
 as a pattern that I would necessarily recommend over the current fragment =
encoding.

If we mover to post messa=
ge it would include API  for logout and session management, not just l=
ogin.

John B.


On Jul 1, 2016, at 6:43 PM, Liyu Yi <liyuyi@gmail.com> wrote:

<=
div>
Understood there is an Authorization Code grant t=
ype; here I am more focusing on the Implicit grant type. 
&n=
bsp; 
also when I mentioned POST, I did not mean postMessage=
, it is simply the HTTP POST. Specifically it is more like this ...



4.2.  Implic=
it Grant (modified)



     +=
----------+
     | Resource |
     |  Owner   |
     |          |
     +----------+
          ^
          |
         (B)
     +----|-----+          Client Identifier     +---------------+
     |         -+----(A)-- & Redirection URI --->|               |
     |  User-   |                                | Authorization |
     |  Agent  -|----(B)-- User authenticates -->|     Server    |
     |          |                                |               |
     |          |<---(C)- Response embedded JS -<|               |
     |          |          with Access Token     +---------------+
     |          |            in JS content, which will be posted to Resourc=
e Server
     |          |                                +---------------+
     |          |----(D)-- JS post to RS URI --->|   Web-Hosted  |
     |          |         with Access Token      |     Client    |
     |          |                                |    Resource   |
     |     (F)  |<---(E)----- RS Script --------<|               |
     |          |         with Access Token      +---------------+
     +-|--------+
       |    |
      (A)  (G) Access Token
       |    |
       ^    v
     +---------+
     |         |
     |  Client |
     |         |
     +---------+



                       Figure 4: Implicit Grant Flow


=
   The flow illustrated in Figure 4 includes the following steps:

   (A)  The client initiates the flow by directing the resource owner's
        user-agent to the authorization endpoint.  The client includes
        its client identifier, requested scope, local state, and a
        redirection URI to which the authorization server will send the
        user-agent back once access is granted (or denied).

   (B)  The authorization server authenticates the resource owner (via
        the user-agent) and establishes whether the resource owner
        grants or denies the client's access request.

   (C)  Assuming the resource owner grants access, the authorization
        server responds with a JavaScript logic which automatically posts t=
o=20
        "redirection" URI provided earlier.  The JavaScript includes
        the access token in the URI fragment.

   (D)  The user-agent does the post with the access token. Granted,  
=

              =
    user agent can actually do post without the access token  in a different=
 iframe, 
                  then use postMessage to pass the token over, but =
I do not see why get it need that compexity.


On Fri, Jul 1, 2016 at 3:13 PM, J=
osh Mandel <jmandel@gmail.com> wrote:
=

Thanks John! Yes, we're following the CORS based flow you'=
ve described below (though I should note that the actual redirection back t=
o the client could be a 302, or could be a simple Web link that the user fo=
llows from an authorization page; this is up to the authorization server). =

Overall I don't argue that this flow is "more secure=
" than the implicit flow -- though I believe it does help client developers=
 avoid some common pitfalls. (For example, clients that, through careless p=
rogramming or poor understanding of the spec, fail to validate incoming "st=
ate" are still not susceptible to arbitrary token injection, which means at=
 least they won't readily be tricked into using a token designated for an e=
ntirely different client. With poorly written implicit flow clients, this i=
s an issue.) 
That said, I wasn't aiming to discuss t=
he relative security; just wanted to make sure I knew what you meant by "wo=
n't work well".
Thanks again! 
-Josh


On Jul 1, 2016 18:02, "John Bradley" <ve7jtb@ve7jtb.com> wrote:
I am making a distinction betwee=
n a browser talking to a Web server that is acting as a OAuth Client POST r=
esponse mode =3D good , and a oauth client running in the browser user agen=
t as a Java script application (that can=E2=80=99t directly capture a POST =
response back to the server)

So it depend=
s on where the client is actually running.

Are you saying that you are using a 302 redirect from the authoriza=
tion endpoint back to the server hosting the JS and then loading the JS inc=
luding the code and then using CORES  to exchange the code for a AT?

You can do that but I don=E2=80=99t =
think a public client like that is more secure than just using the fragment=
 encoded response and is more work.
It also may give the server a=
 false sense of security.

John B.
On Jul 1, 2016, at 5:5=
2 PM, Josh Mandel <jman=
del@gmail.com> wrote:

=
I think the confusion here is that I'm not using HEART's OAuth profiles :-)=


I'm using the SMART profiles, where we d=
o specify the use of an authorization code grant even for browser-based pub=
lic clients (in which case, no client_secret is issued or used). I'm just t=
rying to understand your perspective eon why this "won't work well". Perhap=
s you didn't mean this comment to refer to browser-based OAuth clients gene=
rally?

  -Josh

On Fri, Jul 1, 2016 at 5:45 PM, John Bradley <ve7jtb@ve7jtb=
.com> wrote:
I don=E2=80=99t think the post response mode is supported =
by heart so I suspect that we are talking about different things.

You are probably using the supported code flow tha=
t uses a 302 get to return the code to the OAuth client on the server. &nbs=
p;
The Web server is then acting as a confidential client to exch=
ange the code via a POST (different POST) with the AS token_endpoint.
=


The Token endpoint will return a access =
token (AT) and optional refresh token (RT).

The web page may be getting the server to make the OAuth calls on =
it=E2=80=99s behalf to the Resource Server, or possibly you are passing the=
 AT from the server back to a Java script app that is using CORES to make c=
alls directly to the RS without going through the Web server.
Passing the AT back to the user agent from the c=
lient is not recommended. 

For=
 in browser clients where the JS is using the AT to make the calls directly=
 to the RS via CORES the recommended approach is to use the fragment encode=
d response via a 302 to deliver the AT directly to the client (It never hit=
s the backend Web server).

However =
I believe In browser OAuth clients are not currently supported in HEART, so=
 I am not quite sure what you are doing.

Perhaps Justin has a better answer.

John B.


On Jul 1, 2016, at 5:33 PM, J=
osh Mandel <jmandel@gma=
il.com> wrote:

John,
I appreciate your response. I'm hoping you=
 can clarify why you say that "HTTP POST... won't work well for... [a] sing=
le page OAuth client"?

We commonly build =
single-page apps that act as OAuth clients for SMART (e.g. thi=
s sample app ), and we've had good experience with the technique. =
Could you elaborate?

  -J

On Fri, Jul 1, 2016 at 5:26 PM, =
John Bradley <ve7jtb@ve7jtb.com> wrote:
HEART only supports web server clien=
ts at the moment.   That might change in future to support native apps=
 if that an be made to support the security requirements of Heath IT.
<=
br clear=3D"none">
So the thing HTTP POST responses won=E2=80=99t work =
well for is a type of in browser single page OAuth client.  That still=
 needs fragment encoded responses or the new post-message Java Script API a=
pproach.

John B.


On Jul 1, 2016, at 5:16 PM, Josh Mandel <jmandel@gmail.com> wrote:

Thanks Justin,

To clarify: John's comment and my question were about POST. (I do u=
nderstand the behavior of HTTP POST and of window.postMessage; these are to=
tally different things.) From my perspective in SMART Health IT, we use the=
 OAuth 2.0 authorization code flow, including HTTP POST, in our authorization spec even for public clients, a=
nd it has worked very well for us, with about a dozen electronic health rec=
ord servers supporting this approach. That's why I was curious to hear John=
's perspective about limitations.

&=
nbsp; -J

On Fri, Jul 1, 2016 at 5:09 PM, =
Oleg Gryb <oleg_gryb@yahoo.com> wrote:
> POST =
will send things to the server, which isn=E2=80=99t desirable if your clien=
t is solely in the browser
Why it's not desirable, as=
suming that we disregard performance? You can generate HTTP POST from JS, e=
.g. through an AJAX call. What is wrong with this?
=



 
 
 
 
  
 From: Justin Richer <jr=
icher@mit.edu>
 To: Josh Mandel <jmandel@gmail.com> 
Cc: Oleg Gryb <oleg@gryb.info>; "<oauth@ietf.org>" <oauth@ietf.org>; Liyu Yi <liyuyi@gmail.com>
 Sent: Friday, July 1, 2016 2:00 PM
<=
br clear=3D"none"> Subject:=
 Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant
 
 
 

POST will send things to the server, which isn=E2=80=99t desirable if your=
 client is solely in the browser. postMessage is a browser API and not to b=
e confused with HTTP POST. postMessage messages stay (or can stay) within t=
he browser, which is the intent here.

&nb=
sp;=E2=80=94 Justin

On Jul 1, 2016, at 4:56 PM, Josh Mandel <jmandel@gmail.com> wrote:

John,

Could you clarify wh=
at you mean by "POST doesn't really work"=
? Do you just mean that CORS support (e.g., http:/=
/caniuse.com/#feat=3Dcors) isn't universal, or something more?

On Fri, Jul 1, 2016 at 4:51 PM, John Bradl=
ey <v=
e7jtb@ve7jtb.com> wrote:
Yes but POST doesn't really work for in browser apps.

If it is a server app it should be using the code fl=
ow with GET or POST as you like.

If=
 we do a  post message based binding it will be targeted at in browser=
 applications.

John B.
<=
div>
On Fri, Jul 1, 2016 at 4:42 PM, Liyu Yi <liyuyi@gmail.=
com> wrote:
BTW,=
 I do not see any significant performance concerns for post. Parsing and ex=
ecuting the Javascript logic for post operation will be on the client side,=
 no extra server load is introduced.

Plus=
 post will remove the size restriction of the URL length.

-- Liyu&=
nbsp;

On Fri, Jul 1, 2016=
 at 1:35 PM, Liyu Yi <liyuyi@gmail.com> wrote:
Thanks for the great comments and advices.

I think it is a good idea for the working g=
roup to revise the fragment part in the spec, since there might be public a=
vailable tools already implemented this approach and people can end up with=
 a solution with serious security loopholes.

<=
div>The re-append issue can be mitigate by a logic on Resource Server which=
 carefully re-writes/removes the fragment in any redirect, if the the redir=
ect can not be avoided.

-- Liyu
 
<=
/div>

On Fri, Jul 1, 2016 a=
t 11:33 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
This behaviour started c=
hanging around 2011

From HTTP/1.1
See https://tools.ietf.org/htm=
l/rfc7231#section-7.1.2I
      f the Loc=
ation value provided in a 3xx (Redirection) response does
   not have a fragment component, a user agent MUST process the
   redirection as if the value inherits the fragment component of the
   URI reference used to generate the request target (i.e., the
   redirection inherits the original reference's fragment, if any).

   For example, a GET request generated for the URI reference
   "http://www.example.org/~tim" might result in a 303 (=
See Other)
   response containing the header field:

     Location: /People.html#tim

   which suggests that the user agent redirect to
   "http://www.example.org/People.html#tim=E2=
=80=9D

   Like=
wise, a GET request generated for the URI reference
   "http://www.example.org/index.html#larry"=
 might result in a 301
   (Moved Permanently) response containing the header field:

     Location: http://www.example.net/index.html

   which suggests that the user agent redirect to
   "http://www.example.net/index.html#larry"=
, preserving the original
   fragment identifier.



This blog also explores the change.


On Jul 1, 2016, at 1:05 PM, Oleg Gryb <oleg_gryb@yahoo.com> wrote:
"Browsers now re-append  fragments across =
302 redirects unless they are explicitly cleared this makes fragment encodi=
ng less safe than it was  when originally specified" - thanks Jim. Loo=
ks like a good reason for vetting this flow out.
<=
div dir=3D"ltr">
John,
Please provide more details/link=
s about re-appending fragments. 
Thanks,
Oleg.


 
 =

 
  
 From: Jim Manico <jim@manicode.com>
 To: Oleg Gryb <oleg@gryb.info> 
Cc: "oauth@ietf.org" <oauth@i=
etf.org>; Liyu Yi <liyuyi@gmail.com>
 Sent: Thursday, June 30, 2016 10:25 PM
=
 Subject: Re: [OAUTH-WG] Se=
curity concern for URI fragment as Implicit grant
   

Oleg! Hello! Great to see you pop =
up here with a similar concern.

Joh=
n Bradley just answered this thread with the details I was looking for (tha=
nks John, hat tip your way).

He als=
o mentioned details about fragment leakage:

"Browsers now re-append  fragments across 302 redirects=
 unless they are explicitly cleared this makes fragment encoding less safe =
than it was when originally specified"

=

Again, I'm new here but I'm grateful for this conversation.

Aloha,
--
Jim =
Manico
@Manicode

On Jul 1=
, 2016, at 1:24 AM, Oleg Gryb <oleg_gryb@yahoo.com> wrote:

We've discussed access tokens in URI back in=
 2010 (https://=
www.ietf.org/mail-archive/web/oauth/current/msg04043.html). There were =
two major objectives when I was saying that it's not secure:

1. Fragment is not sent =
to a server by a browser. When I've asked if this is true for every browser=
 in the world, nobody was able to answer.
2. Replacin=
g with POST would mean a significant performance impact in some high volume=
 implementations (I think it was Goole folks who were saying this, but I do=
n't remember now).

AFAIR, nobody was arguing about browsing history, so it's valid.

So, 6 years =
later we're at square one with this and I hope that this time the community=
 will be more successful with getting rid of secrets in URL.

BTW, Jim, if you can com=
e up with other scenarios when fragments can leak, please share. It'll prob=
ably help the community with solving this problem faster than in 6 years.

Thanks,
Oleg.


 
 
 
 
  
 From:=
 Jim Manico <j=
im@manicode.com>
 To: Liyu Yi <liyuyi@gmail.com>; oauth@ietf.org 
 Sent: Wednesday, June 29, 2016 7:30 AM
 <=
span style=3D"font-weight:bold;">Subject: Re: [OAUTH-WG] Securit=
y concern for URI fragment as Implicit grant
  
 

    
> Shouldn=E2=80=99t it be more secure if we change to
        use a post method for access token, similar to the SAML does?

    
I say yes. But please note I'm very new at this and someone with
      more experience will have more to say or correct my comments.

    
Here are a few more details to consider.

    

    
1) OAuth is a framework and not a standard, per se. Different
      authorization servers will have different implementations that are
      not necessarily compatible with other service providers. So there
      is no standard to break, per se.

    

    
2) Sensitive data in a URI is a bad idea. They leak all over the
      place even over HTTPS. Even in fragments.

    

    
3) Break the "rules" and find a way to submit sensitive data like
      access tokens, session information or any other (even short term)
      sensitive data in a secure fashion. This includes POST, JSON data
      payloads over PUT/PATCH and other verbs - all over well configured
      HTTPS.

    

    
4) If you really must submit sensitive data over GET , consider
      JWT/JWS/JWE (with limited scopes/lifetimes) to provide message
      level confidentiality and integrity.

    

    Aloha,

    
Jim Manico
Manicode Security
https://www.manicode.com

    

    
On 6/27/16 9:30 PM, Liyu Yi wrote:

    

    

      

        
While we are working on a project
            with OAuth2 implementation, one question arises from our
            engineers.

        
        
  

        
(C)  Assuming the resource owner
            grants access, the authorization

        
        server redire=
cts the
            user-agent back to the client using the

        
        redirection U=
RI provided
            earlier.  The redirection URI includes

        
        the access to=
ken in the URI
            fragment.

        
 

        
For my understanding, the browser
            keeps the URI fragment in the history, and this introduces
            unexpected exposure of the access token. A user without
            authorization for the resource can get the access token as
            long as he has the access to the browser. This can happen in
            a shared computer in library, or for an IT staff who works
            on other employee=E2=80=99s computer.

        
 

        
Shouldn=E2=80=99t it be more secure if we
            change to use a post method for access token, similar to the
            SAML does?

        
I feel there might be something I
            missed here. Any advices will be appreciated.

      

      

      

      

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


    

    

    
--=20


  



 
=
 
 
 

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


 
 
  

<=
/div>









_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth<=
/a>




_______________________________________________
OAuth mai=
ling list
OAut=
h@ietf.org
https://ww=
w.ietf.org/mailman/listinfo/oauth

=


_________________________________=
______________
OAuth mailing list
OAuth@ietf.org
=
https://www.ietf.org/mailman/listinfo/oauth<=
/a>


 
 
 
 
=


_______________________________________________
OAuth mai=
ling list
OAut=
h@ietf.org
https://ww=
w.ietf.org/mailman/listinfo/oauth
=


<=
br clear=3D"none">



I think the confusion here is that I'm not using HEART=
's OAuth profiles :-)

I'm using the SMART profil=
es, where we do specify the use of an authorization code grant even for bro=
wser-based public clients (in which case, no client_secret is issued or use=
d). I'm just trying to understand your perspective eon why this "w=
on't work well". Perhaps you didn't mean this comment to refer=
 to browser-based OAuth clients generally?

=C2=A0 =
-Josh

On Fri=
, Jul 1, 2016 at 5:45 PM, John Bradley <ve7jtb@ve7jtb.com> w=
rote:
I don=E2=80=99t think the post response mode is supported by heart so I su=
spect that we are talking about different things.

You ar=
e probably using the supported code flow that uses a 302 get to return the =
code to the OAuth client on the server. =C2=A0
The Web server is =
then acting as a confidential client to exchange the code via a POST (diffe=
rent POST) with the AS token_endpoint.

The Token e=
ndpoint will return a access token (AT) and optional refresh token (RT).

The web page may be getting the server to make the O=
Auth calls on it=E2=80=99s behalf to the Resource Server, or possibly you a=
re passing the AT from the server back to a Java script app that is using C=
ORES to make calls directly to the RS without going through the Web server.=


Passing the AT back to the user agent from the cl=
ient is not recommended.=C2=A0

For in browser clie=
nts where the JS is using the AT to make the calls directly to the RS via C=
ORES the recommended approach is to use the fragment encoded response via a=
 302 to deliver the AT directly to the client (It never hits the backend We=
b server).

However I believe In browser OAuth clie=
nts are not currently supported in HEART, so I am not quite sure what you a=
re doing.

Perhaps Justin has a better answer.

John B.


On Jul 1, 2016, at 5:33 PM, Josh Mandel <jmandel@gmail.com&=
gt; wrote:

John,

I apprec=
iate your response. I'm hoping you can clarify why you say that "H=
TTP POST... won't work well for... [a] single page OAuth client"?<=
div>
We commonly build single-page apps that act as OAuth cli=
ents for SMART (e.g. this sample app=C2=A0), and we've had good experience with the te=
chnique. Could you elaborate?

=C2=A0 -J

On Fri, Jul 1, 2016 at 5=
:26 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
HEART only suppor=
ts web server clients at the moment. =C2=A0 That might change in future to =
support native apps if that an be made to support the security requirements=
 of Heath IT.

So the thing HTTP POST responses won=E2=80=99t w=
ork well for is a type of in browser single page OAuth client.=C2=A0 That s=
till needs fragment encoded responses or the new post-message Java Script A=
PI approach.

John B.


On Jul 1, 2016, at 5:16 PM, J=
osh Mandel <jmand=
el@gmail.com> wrote:

Thanks Justin,
To clarify: John's comment and my question were about=
 POST. (I do understand the behavior of HTTP POST and of window.postMessage=
; these are totally different things.) From my perspective in SMART Health =
IT, we use the OAuth 2.0 authorization code flow, including HTTP POST, in o=
ur authorization spec=C2=A0even for public clients, and it has worked v=
ery well for us, with about a dozen electronic health record servers suppor=
ting this approach. That's why I was curious to hear John's perspec=
tive about limitations.

=C2=A0 -J

On Fri, Jul 1, 2016 at 5:09=
 PM, Oleg Gryb <oleg_gryb@yahoo.com> wrote:
> POST will send things to the server, which isn=E2=80=99t=
 desirable if your client is solely in the browser
Why it's not desirable, assuming that we disregard performance? Yo=
u can generate HTTP POST from JS, e.g. through an AJAX call. What is wrong =
with this?


 
 
 
 
  
 From: Justin Richer <jricher@mit.edu>
 =
To: Josh Mandel <jmandel@gmail.com> <=
br>Cc: Oleg Gryb <oleg@gryb.info>; "=
<oauth@ietf.org&=
gt;" <oauth@iet=
f.org>; Liyu Yi <liyuyi@gmail.com>
 Sent=
: Friday, July 1, 2016 2:00 PM

 Subject: Re: [OAUTH-WG] Security concern for UR=
I fragment as Implicit grant
 
 
 
=

POST will send things to the server, which isn=E2=80=99t desi=
rable if your client is solely in the browser. postMessage is a browser API=
 and not to be confused with HTTP POST. postMessage messages stay (or can s=
tay) within the browser, which is the intent here.

<=
/div>
=C2=A0=E2=80=94 Justin

On Jul 1, 2016, at 4:56 PM, Josh Mandel <jmandel@gmail.com> wrote:

John,
Could you clarify what you mean by "POST doesn't really work"? Do you ju=
st mean that CORS support (e.g.,=C2=A0http://caniuse.com=
/#feat=3Dcors) isn't universal, or something more?

On Fri, Jul 1, 2016 at 4:51 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
Yes but POST doesn't really work =
for in browser apps.

If it is a server ap=
p it should be using the code flow with GET or POST as you like.
=

If we do a =C2=A0post message based binding i=
t will be targeted at in browser applications.

John B.

On Fri, Jul 1, =
2016 at 4:42 PM, Liyu Yi <liyuyi@gmail.com<=
/a>> wrote:
BTW, I do=
 not see any significant performance concerns for post. Parsing and executi=
ng the Javascript logic for post operation will be on the client side, no e=
xtra server load is introduced.

Plus post=
 will remove the size restriction of the URL length.

-- Liyu=C2=A0=


On Fri, Jul 1, 2016 at 1=
:35 PM, Liyu Yi <liyuyi@gmail.com> wrote:
Thanks for th=
e great comments and advices.

I think it=
 is a good idea for the working group to revise the fragment part in the sp=
ec, since there might be public available tools already implemented this ap=
proach and people can end up with a solution with serious security loophole=
s.

The re-append issue can be mitigate by=
 a logic on Resource Server which carefully re-writes/removes the fragment =
in any redirect, if the the redirect can not be avoided.

-- L=
iyu
=C2=A0

On Fri, Jul 1, 2016 at 11:33 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
=

This behaviour started changin=
g around 2011

From HTTP/1.1
=C2=A0 =C2=A0 =C2=A0 f the Location va=
lue provided in a 3xx (Redirection) response does
 =
  not have a fragment component, a user agent MUST process the
   redirection as if the value inherits the fragment component of the
   URI reference used to generate the request target (i.e., the
   redirection inherits the original reference's fragment, if any).

   For example, a GET request generated for the URI reference
   "http://www.example.org/~tim" might result =
in a 303 (See Other)
   response containing the header field:

     Location: /People.html#tim

   which suggests that the user agent redirect to
   "http://www.example.org/People.html#tim=E2=80=9D

   L=
ikewise, a GET request generated for the URI reference
   "http://www.example.org/index.html#larry=
" might result in a 301
   (Moved Permanently) response containing the header field:

     Location: http://www.example.net/index.html

   which suggests that the user agent redirect to
   "http://www.example.net/index.html#larry=
", preserving the original
   fragment identifier.



This blog also explores the change.


On Jul 1, 2016, at 1:05 PM, Oleg Gryb <ole=
g_gryb@yahoo.com> wrote:

"Browsers now re-append =C2=A0fragments across 302 redirects unle=
ss they are explicitly cleared this makes fragment encoding less safe than =
it was =C2=A0when originally specified" - thanks Jim. Looks like a goo=
d reason for vetting this flow out.

John,
Please provide more details/links about re-ap=
pending fragments.=C2=A0

Thanks,
Oleg.


=

 
 
 
 
  
 From: Jim M=
anico <jim@manicode.com>
 To: Oleg Gryb <oleg@gryb.i=
nfo> 
Cc: "oauth@ietf.org" <oauth@ietf.org<=
/a>>; Liyu Yi <liyuyi@gmail.com>
=
 Sent: Thursday, June 30, 20=
16 10:25 PM
 Subject:=
 Re: [OAUTH-WG] Security concern for URI fragment as Implicit gr=
ant
  
 

Oleg!=
 Hello! Great to see you pop up here with a similar concern.

John Bradley just answered this thread with the d=
etails I was looking for (thanks John, hat tip your way).

He also mentioned details about fragment leakage:

"Browsers now re-append =
=C2=A0fragments across 302 redirects unless they are explicitly cleared thi=
s makes fragment encoding less safe than it was when originally specified&q=
uot;

Again, I'm new here=
 but I'm grateful for this conversation.

<=
/div>
Aloha,
--
Jim Manico
@Manicode=


On Jul 1, 2016, at 1:24 AM, Oleg G=
ryb <oleg_gryb@yahoo.com> wrote:
=

We've discusse=
d access tokens in URI back in 2010 (https://www.ietf.org/mail-archive/web/oauth/current/m=
sg04043.html). There were two major objectives when I was saying that i=
t's not secure:

1. Fragment is not sent to a server by a browser. When I've as=
ked if this is true for every browser in the world, nobody was able to answ=
er.
2. Replacing with POST would mean a significant p=
erformance impact in some high volume implementations (I think it was Goole=
 folks who were saying this, but I don't remember now).

AFAIR, nobody was arguin=
g about browsing history, so it's valid.

So, 6 years later we're at square one=
 with this and I hope that this time the community will be more successful =
with getting rid of secrets in URL.

BTW, Jim, if you can come up with other scenarios =
when fragments can leak, please share. It'll probably help the communit=
y with solving this problem faster than in 6 years.
<=
br clear=3D"none">
Thanks,
Oleg=
.


 
 
 
   
 <=
span style=3D"font-weight:bold">From: Jim Manico <=
jim@manicode.com>
 To: Liyu Yi <liyuyi@gmail.com>; oauth@ietf.org 
 Sent: Wednesday, June 29, 2016 7:30 AM
 =
Subject: Re: [OAUTH-WG] Securit=
y concern for URI fragment as Implicit grant
  
 

    
> Shouldn=E2=80=99t it be more secure if we change to
        use a post method for access token, similar to the SAML does?

    
I say yes. But please note I'm very new at this and someone wi=
th
      more experience will have more to say or correct my comments.

    
Here are a few more details to consider.

    

    
1) OAuth is a framework and not a standard, per se. Different
      authorization servers will have different implementations that are
      not necessarily compatible with other service providers. So there
      is no standard to break, per se.

    

    
2) Sensitive data in a URI is a bad idea. They leak all over the
      place even over HTTPS. Even in fragments.

    

    
3) Break the "rules" and find a way to submit sensitive =
data like
      access tokens, session information or any other (even short term)
      sensitive data in a secure fashion. This includes POST, JSON data
      payloads over PUT/PATCH and other verbs - all over well configured
      HTTPS.

    

    
4) If you really must submit sensitive data over GET , consider
      JWT/JWS/JWE (with limited scopes/lifetimes) to provide message
      level confidentiality and integrity.

    

    Aloha,

    
Jim Manico
Manicode Security
https://www.manicode.com

    

    
On 6/27/16 9:30 PM, Liyu Yi wrote:

    

    

      

        
While we are working on a project
            with OAuth2 implementation, one question arises from our
            engineers.

        
        
=C2=A0=C2=A0

        
(C)=C2=A0 Assuming the resource owner
            grants access, the authorization

        
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 server redire=
cts the
            user-agent back to the client using the

        
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 redirection U=
RI provided
            earlier.=C2=A0 The redirection URI includes

        
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the access to=
ken in the URI
            fragment.

        
=C2=A0

        
For my understanding, the browser
            keeps the URI fragment in the history, and this introduces
            unexpected exposure of the access token. A user without
            authorization for the resource can get the access token as
            long as he has the access to the browser. This can happen in
            a shared computer in library, or for an IT staff who works
            on other employee=E2=80=99s computer.

        
=C2=A0

        
Shouldn=E2=80=99t it be more secure if we
            change to use a post method for access token, similar to the
            SAML does?

        
I feel there might be something I
            missed here. Any advices will be appreciated.

      

      

      

      

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


    

    

    
--=20


  



 
 
 
 

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


 
 
 =